ebXML Messaging Upgrade of

1
ebXML Messaging Upgrade of OAG TestBed Some
Requirements and Design Options Jacques Durand /
Philippe DeSmedt ebXML IIC
2
Some TestBed Requirements we start from (from
OAG TestBed presentation slides)

• Test application output conformance
• Send a standard BOD from the application to the
  testbed using HTTP Post to check the BOD format
• Test application input processing
• Use the testbed to send a standard BOD to your
  own application
• Test transactions among the collaborating
  applications
• Route messages through the testbed to the
  collaborating participant and check the message
  format
• Monitor and check the interactions among users
  graphically
• Track information exchanges graphically
• Check the interactions conformance with a
  business process specification, choreography

3

• Assumptions about the use of ebXML messaging in
  the TestBed
• We assume the previous requirements (for HTTP
  transport) still apply when upgrading to ebXML
  messaging.
• Each participant in the ebXML-upgraded OAG
  TestBed, is assumed able to operate a local ebXML
  Message Service Handler (MSH) over HTTP, and to
  configure it in agreement with other participants
  (e.g. based on a CPA).
• Prior to using the TestBed, each participant is
  supposed to have demonstrated ebXML messaging
  interoperability with its partners (e.g. through
  UCC / DGI interoperability tests.)(UCC Uniform
  Code Council org.)
• The participants will not use advanced security
  features (e.g. encryption) that would prevent the
  TestBed Node to understand the message (payload
  header).
• Even though the participants use the TestBed to
  send messages to each others, the message content
  (header payload) will be the same as if the
  message were sent directly to the participant.
  Only the destination URL will change.

4

• Assumptions about the new architecture
• We assume the TestBed will act as a single -
  messaging Node, to which every participant will
  have to connect to (or be reachable from). (was
  this the architecture set-up in the OAG Vendor
  Challenge?)
• This Node will act as a message router facility,
  forwarding each message to its actual
  destination. So it will be like a messaging hub
  between participants.
• This Node will also feed monitoring tools, that
  will support the TestBed functions BOD
  validation, msg logging and admin console,
  possibly later simulation driver, choreography
  checking. These are called center-components, as
  they are attached to the Testbed Node.
• There may be other components that provide some
  services that concern only a subset of
  participants, and that act as intermediary
  components between these participants and the
  TestBed Node. They are called proxy-components.
  (They act as participants with regard to the
  TestBed Node.)

5
TesBed Node
Participant D
Participant A

• Routing
• Reflection

?
Notification / API Call
Participant B
Participant E
?
Proxy- Component (e.g. Vitiris?)
monitoring
Center-components
Participant C
6

• From an ebXML message processing viewpoint, the
  TestBed Node must be able to
• Extract the standard BOD contained in the
  payload of an ebXML message.
• Extract some ebXML header data (e.g. To PartyId
  element, etc.).
• Route an ebXML message to another destination
  Node.
• Send back (reflect) an ebXML message to the
  sender Node.
• Generate a test message (containing a test BOD)
  to a participant.
• Invoke or notify the monitoring / validation
  components (center-components), passing BOD msg
  header parameters (e.g. timestamp, party Ids).

7

• ebXML MS capabilities in this architecture
• In this design, the TestBed Node will then be
  the only ebXML message-dependent component of
  the architecture (except for the participants).
• Other functional center-components (monitoring,
  etc) will be notified with the actual content of
  the message (BOD), plus some header data
  (process/service/user/timestamp), and will not
  have to understand ebXML messaging.
• The proxy-components, acting ion the role of
  participants to the TestBed, are expecting to
  send/receive ebXML messages to/from the testbed,
  so they should be ebXML-enabled.

8

• Design Outline 1 TestBed Node as an
  intelligent piece of wire
• We assume the TestBed will act as a HTTP/SOAP
  Node between the participants, transparent to the
  ebXML transport layer.
• This node will have no hardcoded knowledge of
  ebXML messaging. But it will have just enough
  configurable intelligence to extract from the
  message, ebXML elements it needs to understand,
  i.e. at least (1) destination identity (To
  PartyID), (2) payload(BOD), using Manifest
  element.
• A Routing module will (1) map the destination
  element to an actual URL, (2) forward the message
  as is to this URL, (3) feed other
  center-components with message data (BOD other).
• The test-message generation is supported by an
  ebXML-enabled participant end-point that is
  local to the TestBed Node. (So this MSH only
  plays a marginal role in this architecture.)

9

• Design Outline 2 TestBed Node as an ebXML
  Messaging Node
• The TestBed will act as an ebXML MSH Node
  between the participants, (but not necessarily in
  a multi-hop mode). So, here the ebXML MSH plays a
  central role in the architecture all messages go
  through it.
• This node will have a testbed application
  component on top of the MSH, that consumes and
  forward messages, also implementing the
  routing/extraction function described in 1.
• The test-message generation is supported by the
  Testbed application layer on top of the MSH
  Node, which will provide simulation functions in
  addition to routing/extraction.

10
Testbed Node
Design 1
Center-components
Local Simulat.
MSH
HTTP Router/Extract
HTTP
Design 2
Testbed Node
Center-components
Local simulator
HTTP
11

• Variant for Design 1 (no MSH capability even
  for message generation)
• The TestBed message generation function (for
  tests simulating an external party) will use
  ebXML message templates. These will be
  instantiated on demand (header BOD payload),
  and directly sent over HTTP by simulator
  component.
• These templates assume a predefined CPA
  (possibly several CPA options).

Testbed Node
Test case data (header params BODs)
Center-components
Local Simulat.
Predefined Msg templates (ebXML envelopes)
HTTP Router/Extract
HTTP
12

• Advantages of Design 1
• The TestBed architecture is not so much
  dependent on ebXML message structure. It can
  withstand more easily future changes/upgrades in
  messaging spec, with minimal maintenance. It can
  also be easily extended to other types of (XML)
  messages.
• The TestBed node does not have to rely on an
  ebXML MSH implementation that would become the
  de-facto interoperability reference
  (hub-and-spoke). Having one vendor MSH playing
  such a strategic role may not be well accepted by
  other participants. (The only use of an MSH is
  for generating test-messages, as an optional
  function.)
• The TestBed will be neutral with regard to
  interoperability. Two participants having
  undergone successful 1-to-1 interoperability
  tests, under a particular MSH configuration,
  will have much greater chances to interoperate in
  the testbed design 1, where the hub simply passes
  the HTTP message around, than in design 2, where
  a new MSH stands in the way. In addition, such a
  hub MSH would have to support a broad array of
  CPA-based configurations, for all communicating
  pairs.

13

• Advantages of Design 2
• The TestBed architecture will be usable later
  for multi-hop ebXML routing and testing. That may
  be closer to a marketplace architecture, where
  all messages are supposed to transit via a
  marketplace Hub.
• The capture of the message payload being done at
  higher level than the HTTP router module of
  Design 1, the router app module in this design
  does not have to filter out noisy messages such
  as Acknowledgements, Errors, or Repeats in case
  of sending messages reliably. (So less
  intelligence is required.)
• This architecture is less sensitive on a change
  in underlying transport (e.g. SMTP instead of
  HTTP), as the routing/capture is done above this
  level.