OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

ebxml-msg-comment message

[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

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

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

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

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

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

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

For ebMS2, this routing mechanism also supports routing of Signal
Messages. See earlier section on routing of ebMS3 signal messages and

10.1.8.  Quality of Service 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. 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

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. 
[4] SUWIML Transport. 

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]