ebXML Messaging Upgrade of OAG TestBed: Some Requirements and Design Options Jacques Durand / Philippe DeSmedt ebXML IIC

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 Some TestBed Requirements we start from: (from OAG TestBed presentation slides )

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.

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.)

monitoring Center-components Proxy- Component (e.g. “Vitiris”?) Notification / API Call Participant A Participant B Participant C Participant D Participant E TesBed Node Routing Reflection ebXML Messages Non-ebXML communication ? ?

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…).

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.

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.)

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.

MSH Particpt A HTTP MSH Particpt B MSH Particpt A HTTP MSH Particpt B HTTP Router/Extract MSH Local Simulat. MSH Router Extract App Local simulator Center-components Design #1 Design #2 Testbed Node

MSH Particpt A HTTP HTTP Router/Extract Local Simulat. Center-components Testbed Node Predefined Msg templates (ebXML envelopes) 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). Test case data (header params + BODs)

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.

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.