[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Requirements for ebXML Intermediary Processing
Requirements and Use Cases for ebXML Intermediary Processing 0. Introduction Discussions in the ebXML Messaging TC show an interest in supporting intermediaries in Part 2 of ebMS3. In support of this, this note intends to provide some information on requirements and relative priorities, mainly from a user perspective. Some end user deployments of ebMS2 use intermediaries today. They have an interest in seeing that functionality preserved or extended in ebMS3. Other communities do not use ebXML today, but use protocols that provide intermediary functionality (see examples below). If ebMS3 supported that functionality, they could be encouraged to migrate to ebMS3. There are also new features in ebMS3, part 1, that intermediaries could extend. To be able to explain these requirements, sections 1-9 introduce some terminology and describe some options (some more realistic than others) and design choices of relevance for intermediaries. Section 10 discusses five use cases of intermediaries using this terminology. The MEPs introduced in ebMS3, part 1, involve two ebXML MSHs. One of these acts as the initiating MSH and the other as responding MSH. One of these operates in Sending role and the other in Receiving role. The initiating MSH acts in Sending role in a Push binding and in Receiving role in Pull binding. In the presence of a single Intermediary, there are two separate connections. The Intermediary is like a responding MSH when connected to the "true" initator and receiving an incoming message on behalf of the "true" responder. It is like an initiating MSH when connected to the "true" responder and sending an outgoing message on behalf of the "true" initiator. The scope of this note is limited to intermediaries that do not perform a role in a business collaboration in the CPA or ebBP sense, though they may perform some specialized business functions. This note is not about intermediaries that (also) deliver (part of) the message. 1. General Benefits/Requirements of Intermediaries Benefits of ebXML intermediaries, common to many use cases, include: Handling network connectivity constraints: in some environments, message sender and message receiver are not in a single network, for instance when either or both are on private networks that do not allow incoming network connections, or use private IP addresses or server URLs that cannot be resolved on the public Internet. Routing based on ebXML business header: the intermediary can route messages to recipients based on PartyId or other information in the ebXML business document header. This routing configuration can be managed centrally, allowing ebXML services to be moved from one MSHs to another, or transport configuration of an MSH to be changed, without impacting trading partners. Only the configuration of the intermediary needs to be updated. Business activity monitoring: an intermediary can be used to track conversations involving two or multiple parties, based on ebXML message header information such as message IDs and conversation IDs. Advanced protocol handling: an ebXML intermediary can also perform Web Services security or reliability functions or ebMS3 functionality which one of the two party endpoint MSHs are incapable of. An MSH that only supports the Light Handler conformance profile can interact using ebXML messages with an Intermediary that, on its behalf, provides these more advanced features to communicate with business partners. 2. Endpoint or Intermediary A single ebXML MSH may operate either exclusively as an Intermediary or as an Endpoint, or decide whether to deliver or to forward a message based on inspecting the eb:Messaging structure. It can also provide distinct URLs for intermediary and endpoint message handlers. See section on Routing for discussion. 3. Supported version of the ebXML Messaging service. While part 2 is about defining functionality of ebMS3, some of these concepts can be made to work with ebMS2 very (or even more) easily or are used with ebMS2 today. 4. Synchronous and Asynchronous Intermediaries The connection between "true initiator" (or previous intermediary) and Intermediary, and the connection between Intermediary and "true responder" (or next intermediary) can be synchronized or be handled asynchronously. When using an underlying two way protocol like HTTP, use of a synchronous intermediary is defined such that that information received on the back channel of the second connection can be passed back via the first connection. This is relevant in the discussion of MEP bindings, routing and error handling (see sections). When used in an asynchronous way, an intermediary provides a store-and-forward mechanism. It terminates the incoming transport connection. If there are no routing or other errors, the connection is closed using a successful status code. Then, it creates or uses a separate connection to forward the message to the recipient or next intermediary node. An asynchronous intermediary has added value compared to the synchronous intermediary. It improves connectivity and scalability in a community. It can act as a queue to handle situations where one partner generates more messages than the other partner is capable of handling, or when the receiving MSH in temporarily unavailable. Also see the discussion on reliability. When an intermediary supports both synchronous and asynchronous functionality, a question is how one of the two options is selected. The intermediary can offer separate server URLs for the two modes, and let the initating MSH decide which one to invoke. This means no configuration of the intermediary is necessary. Another approach is to select a mode based on inspection of the ebXML message header (e.g. the value of To/PartyId) and configuration information, or to use an extension element. See the section on Routing for discussion. In some profiles or use cases, only one of the two modes (synchronous or asynchronous) may be supported. 5. Transparency of the Intermediary The intermediary is transparent if it does not modify the eb:Messaging structure or any of the referenced payloads. An advantage of this is that any digital signatures are preserved. An intermediary can also provide additional functionality that modifies the message. This may break any signatures, if present. 6. Bridge functionality An intermediary can serve as a bridge between different configurations and/or between assumptions of initiator and recipient. 6.1 Intermediaries preserving MEP Bindings An intermediary preserves the message exchange pattern bindings when the incoming connection from the initator MSH and the outgoing connection to the responding MSH (or next Intermediary) use the same transport channel binding and the same transport protocol binding. For instance, this means that when the incoming message is a "Push" of an ebXML message using the HTTP protocol, the outgoing connection will also be a "Push" message using the HTTP protocol. Here I describe thirteen potential cases. In ebMS3 part 1, the following seven MEPs and channel bindings are defined. One Way Push One Way Pull Two-Way Sync Two Way Push-and-Push Two Way Pull-and-Pull Two Way Pull-and-Push Two Way Push-and-Pull Assuming Intermediaries are either Synchronous (IntSync) or Asynchrous (IntASync), the One Way MEP can (theoretically) be bound in four ways when the MEP binding is to be preserved: One Way Push, IntSync One Way Push, IntASync One Way Pull, IntSync One Way Pull, IntAsync In the asynchronous case, messages pushed to an intermediary may be stored for some time before being forwarded. Messages pulled by the intermediary from the sender may be stored for some time before being pulled by the receiver. The Two Way MEP with Sync channel binding inherently assumes a synchronous Intermediary: Two-Way Sync, IntSync The four asynchronous Two Way MEP bindings with combinations of Pull or Push channel bindings are compatible with either synchronous or asynchronous intermedaries, adding eight additional combinations. 6.2 Intermediaries bridging MEP channel bindings An intermediary is said to bridge an MEP channel binding when the incoming and outgoing connections related to a single message differ in transport channel binding. Eleven such cases will be mentioned here. For the One Way MEP, two cases are: One Way Push, IntASync, Pull One Way Pull, IntASync, Push In the first case, the initiating MSH pushes a message to the intermediary. Once successfully received, the intermediary closes the connection. The message stays at the intermediary until the receiving MSH pulls it from there. In the second case, the intermediary pulls a message from the initiator and then pushes it to the receiver. Each of these combinations are also possible for the two legs of an asynchronous Two Way MEP, adding four scenarios. Some combinations with a Sync channel binding invoked by the asynchronous Intermediary: Two Way Push-and-Push, IntASync, Sync Two Way Push-and-Pull, IntASync, Sync Two Way Pull-and-Push, IntASync, Sync Two Way Pull-and-Pull, IntASync, Sync In the first case, partner A as an initator pushes a message to the intermediary. The Intermediary invokes a synchronous service on partner B. The intermediary pushes the synchronously received response back to A on a separate connection. In the second case, partner A pushes a message to the intermediary. The intermediary invokes a synchronous service on B, and stores the result in an MPC. Some time thereafter, A pulls the response from the intermediary. In the fourth case, the intermediary pulls a message from A. It invokes a synchronous service on A. It leaves the response in an MPC until A pulls it. Of the four cases where the first leg of the Two Way MEP is Sync, a case is: Two Way Sync, IntSync, Push-and-Push Here, A calls a synchronous service on the Intermediary. The intermediary pushes the request asynchronously to B, and does not close the incoming connection until it has received an incoming response connection with a response from B. 6.3 Intermediaries bridging MEP transport bindings Apart from channel bindings, an intermediary can bridge transport protocol or transport security bindings. It can forward a message using SMTP, which it received on an HTTP connection. It can use TLS on one connection and not the other. 6.4 Intermediaries bridging ebXML Messaging versions An intermediary bridges versions of the ebXML Messaging service if it can forward an incoming ebMS2 (user) message as an ebMS3 (user) message or vice versa. 7. Routing There are several cases to consider: Routing User Messages Routing Signal Messages User messages can be routed based on the content of the eb:UserMessage SOAP extension element. Endpoints using ebXML Collaboration Protocol Agreements select the properties of the delivery channel based on From/PartyId, To/PartyId, FromRole, ToRole, Service, Action and CPAId/AgreementRef. Intermediaries can limit this to a subset of these elements to simplify configuration. When the incoming ebXML message is a Pull signal, the Intermediary would need to be able to set up the second connection based on the MPC value specified in the incoming Pull request. In version 2.0 of ebXML Messaging acknowledgments and error messages are also ebXML messages and always include the From/PartyId and To/PartyId ebXML extension elements. This means that asynchronous acknowledgment messages generated to support reliable messaging can be routed using the same mechanism as user messages. The absence of those elements in ebMS 3.0 (where signal missing have no From and To elements) means routing Signal messages requires a separate and more complex mechanism. If the routing of user messages at the intermediary is based on information in the eb:UserMessage structure, it may only be possible to process reliability information in ebMS3 and support end-to-end reliability if they are bundled with user messages. Asynchronous Error messages could be routed based on the value of RefToMessageInError, if there is some record of the earlier referenced user message and its origin that would allow the intermediary to create and route the error message back to the sender or another way of configuring or determining where error messages are to be sent to. Other asynchronous signal messages would need a similar mechanism to route based on RefToMessageId. 8. Quality of Service 8.1 Reliable Messaging In the reliable messaging module of version 2.0 of ebXML messaging, intermediaries need to respond to "nextMSH" receipt acknowledgment requests and must not eliminate duplicates. The ebMS2 specification has limited information about the resending behaviour of intermediaries. End-to-end reliable messaging is based on receipts from the toParty MSH. Separately from message level reliability, a transport level retry mechanism, to handle HTTP/SMTP connection errors, can be used when the intermediary operates in asynchronous mode, to prevent unnecessary end-to-end retries from the initating MSH. The end-to-end ebXML retry interval should then be set at a value (e.g. hours or more) that allows such transport level retries (e.g. occurring within minutes) to complete first. A question is how these transport level retries (number of retries and interval) are configured. A simple option is a fixed configuration for all transport retries. If these transport retries are exhausted, end-to-end reliable messaging could be used as defined for ebMS2. Synchronous operation of the intermediary could be restricted to use neither transport-level nor message-level reliability. In ebMS3 the reliable messaging functions are based on WS-Reliability or WS-ReliableMessaging. The Intermediary may or may not support this functionality and may or may not support reliable messaging between intermediaries, in addition to any end-to-end reliable messaging. 8.2 Security The intermediary can provide transport level security using TLS or HTTP authentication. It can act as a SOAP intermediary and copy the WS-Security signatures and encrypted parts unmodified in the outgoing message. An intermediary situated at the edge of an enterprise could provide WS-Security processing for ebXML messages with business partners on behalf of endpoints within the enterprise that want to connect to external business partners. 9. Error Handling This is probably one of the more difficult issues. Errors and faults can be generated at the HTTP/SMTP, TLS, SOAP and ebMS3 levels. When operating in synchronous mode, the intermediary can relay any faults and errors received on the backchannel of the outgoing connection on the backchannel of the incoming connection. Reliability is an issue (e.g. the incoming connection may be closed while the intermediary is receiving data on the outgoing connection). When operating asynchronously, the intermediary cannot report synchronously any faults or errors encountered on the outgoing connection. An out-of-band mechanism may be used to report any such errors. Errors specific to the intermediary processing may also be generated, for instance if there is no routing information or if the connection is not authorized. The intermediary may also have specific reasons to refuse relaying a message, thus acting as a filter. See further down for some examples. 10. Use Cases of Intermediary Functionality Sections 1-9 provided an overview of terminology, design choices and options. That overview was needed to be able to introduces some use cases that use (today, using ebMS 2.0 or other protocols) or could use (requirements enabled by ebMS 3.0) particular combinations of choices. The use cases or profiles are: - Simple Asynchronous Relay - Simple Synchronous Relay - Synchronous-Asynchronous mapper - Hosted mailbox - ebXML version mapper This section is an attempt to describe these profiles/use cases referencing the section headers to describe the specified functionality. 10.1 Simple Asynchronous Relay This use case description is based on a very large HL7 implementation that uses ebMS2 and two ebMS2 deployments in an e-government context, all in Europe. At least two commercial ebXML messaging version 2.0 products and a bespoke solution support this profile. The use case is also similar to the scenario "One Way, Passive Recipient, Recording" of OSCI transport 1.2 [3]. OSCI transport is a protocol widely used in e-Government applications in Germany and other European countries. OSCI is also used in a European Union message exchange protocol called eLink [1]. OSCI is of particular interest in a discussion on Intermediaries as it uses an Intermediary for all message exchanges. An asynchronous relay function is also used in SuwiML transport, a SOAP-based message protocol used in the Netherlands social security sector [4]. 10.1.1 General Requirements The first two of the requirements (routing based on ebXML message structure, network connectivity) are addressed in this profile. 10.1.2 Endpoint or Intermediary In the ebMS2 deployments, an MSH is pre-configured to operate as Intermediary or as Endpoint. It does not decide whether to forward or to deliver based on inspection of the incoming message or other criteria. 10.1.3 Supported versions This description is based on an existing use of ebMS2. It can be made to work with ebMS3 with some complications noted below. 10.1.4. Synchronous and Asynchronous Intermediaries The intermediary always operates in asynchronous mode. Synchronous mode is not supported. See 10.2 for a variant that does. In OSCI and SuwiML both synchronous and an asychronous intermediary functionality exist. In SuwiML [4] an extension element is used to indicate to the Intermediary if it requests a response synchronously or asynchronously. 10.1.5. Transparency of the Intermediary The intermediary is fully transparent. Messages are forwarded without modification. 10.1.6 Bridge functionality The intermediary preserves MEP bindings. It supports the "One Way Push" and "Two Way Push-and-Push" message exchange patterns. The intermediary only supports HTTP transport, so preserves message transport binding. TLS may use server and client authentication. The use of TLS is configured per partner at the Intermediary. As the intermediary is transparent, it preserves the ebXML SOAP structure, which is version-dependent. This profile description is based on some implementations of ebMS2. The profile could cover ebMS3 with some issues mentioned below. 10.1.7. Routing Routing of User Messages is based on To/PartyId, To/PartyId/@type or a combination of these only. Routing on other criteria (Service, From/PartyId, ConversationId, message properties etc.) is not supported. For ebMS2, this routing mechanism also supports routing of Signal Messages. See earlier section on routing of ebMS3 signal messages and intermediaries. 10.1.8. Quality of Service 10.1.8.1 Reliable Messaging The intermediary provides a transport-level retry mechanism if no transport connection can be set up. It does not provide any additional reliable messaging functionality, at the Web Services protocol level. The profile therefore supports the functional equivalents of the following Reliable Messaging Patterns defined in version 2.0 of ebMS, provided the messages supporting the reliable messaging functionality (acknowledgments, sequence creation and termination messages) are bundled with ebXML messages or otherwise routed between true initiator and responder: - Profile 2 : Reliable Messaging at the end-to-end level only based upon end-to-end retransmission. Duplication Elimination, if needed, is done at endpoints, never at the intermediary. AckRequested toPartyMSH: yes AckRequested nextMSH: never - Profile 4: At-Most-Once Duplicate Elimination only at the To Party No retries at the Intermediate or the End - Profile 6: At-Least-Once Reliable Messaging duplicates possible at the Intermediate and the To Party. - Profile 8: Best Effort. 10.1.8.2 Security As it is transparent, message-level security using XML Digital Signatures or XML Encryption (in ebMS2) or WS-Security (in ebMS3) provided by other MSHs (endpoints or intermediaries) is supported as the message structure is copied in outgoing message. As the SOAP header structure and payloads are not modified, a receiving MSH can verify signatures and decrypt content. 10.1.9. Error Handling HTTP/SMTP, TLS, SOAP and ebXML errors reported by the receiver or next intermediary in the outgoing connection from the intermediary are logged locally and reported using an out-of-band mechanism. 10.1.10 Value of the Simple Asynchronous Relay The Simple Relay can provide additional functionality beyond its message routing functionality. Some examples are: The relay can also provide filtering functionality, rejecting incoming messages based on certain configurable criteria such as message size, presence in attachments of unallowed file types (e.g. ".exe") or detected viruses. The relay then acts as a filter. The relay can also act as business activity monitor for a trading community, calculating statistics etc, correlating messages based on ConversationId. The relay can also log or archive (certain) messages for long-term reference purposes. This is called "Recording" in OSCI [3]. 10.2 Simple Synchronous Relay This profile is a synchronous variant of the Simple Asynchronous Relay. I'm not aware of existing ebXML deployments that use this scenario. It is used in OSCI 1.2 in the scenarios "Request-Response, Passive Recipient, Recording" and "Request-Response, Passive Recipient, No Recording" which in ebMS3 terminology are Two Way Sync connections. In SuwiML transport a synchronous relay is available, its use being restricted to on-line queries, satisfying the idempotency requirement [2]. 10.2.4 Synchronous and Asynchronous Intermediaries The OSCI intermediary is asynchronous in the case of a "One Way" scenario. It is synchronous in the case of a "Request-Response" scenario. In SuwiML an extension element is used to select synchronous or asynchronous operation. 10.2.6 Bridge functionality No bridging is used. 10.3 Synchronous-Asynchronous mapper This functionality has been requested in some projects that use ebXML Messaging. This use case is similar to the Simple Relay, except that it provides an MEP bridge. This functionality has been requested in some user communities. The request is for an intermediary to map a Two Way Sync MEP binding with the initiating MSH to a Two Way Push-and-Push MEP binding with the receiving MSH. The assumption is that the second Push (the ebXML message of the responding business activity) will be provided quickly after the first push (the ebXML message of the requesting business activity), such that the intermediary can keep the connection set up by the initiating MSH open until the responding MSH has sent a response message using a separate, incoming connection. This means that a single incoming connection with the initiator corresponds to one outgoing connection to the receiver (first leg of two way interaction) and one incoming connection back from the receiver (second leg of two way interaction). 10.4 Hosted mailbox This use case would provide a third party hosted mailbox functionality for business partners that support the ebMS3 Light Handler conformance profile (LH-RM-CP). This functionality exists in OSCI 1.2 where it is called One-Way Message, Active Recipient, Recording, described in section 3.5.1 in the OSCI specification. This use case enables two Light Handlers to communicate. When two partners both only support the Light Handler conformance profile (LH-RM-CP), they cannot directly communicate as this profile requires at least one of them to be able to receive incoming connections, such as a Pull request from the business partner. The LH-RM-CP therefore works best with asymmetric relations (one partner, typically a large company, using a full featured B2B gateway and the other, typically a Small or Medium size Enterprise, using a light handler). When both partners are SMEs, Partner A could "push" a message to an Intermediary (e.g. hosted by a service provider) which offers an ebXML mailbox for Partner B, which can "pull" Partner A's message at a convenient time. This supports the One Way MEP and (by reversing A and B in the second leg) the Two Way MEP. This profile is similar to the email model, with Internet Service Providers providing POP3 or IMAP-based email services to millions of small businesses. 10.5 ebXML version mapper Appendix F of ebMS3, part 1, provides a compatibility mapping for ebMS3 to ebMS2. An intermediary could provide a protocol bridge, allowing business partners using ebMS3-only software to connect with existing partners that still communicate using ebMS2. This profile should be limited to the subset of functionality mapped in that appendix. Some of these partners may use a vendor product that supports ebMS2 but does not (yet) support ebMS3. This profile could also be combined with MEP bridge functions such as the hosted mailbox. New small partners supporting only the LH-RM-CP profile could then join a trading community that uses ebMS2. When a small partner pushes an ebMS3 message to the intermediary, the intermediary would forward it as an ebMS2 message. When a larger business partner sends an ebMS2 message to the intermediary, the intermediary would offer an ebMS3 mailbox from which it can be retrieved using an ebMS3 pull request. This would allow a community to smoothly support evolving versions of the ebXML Messaging standard. 11. References [1] IDABC eLink specification. URL http://ec.europa.eu/idabc/en/document/3489/5585. [2] Idempotent Receiver Pattern. URL http://www.enterpriseintegrationpatterns.com/IdempotentReceiver.html [3] OSCI Transport. URL http://www1.osci.de/sixcms/media.php/13/osci-specification_1_2_english.pdf [4] SUWIML Transport. URL http://www.bkwi.nl/fileadmin/downloads/Suwinet/sgr/SuwiML_Transactiestandaar d_v0200.pdf
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]