RE: [ebxml-msg] multi-hop / routing: current state of discussions

["Pim van der Eijk" <pvde@sonnenglanz.net>]

Here are some more (unfortunately somewhat pessimistic) thoughts on 
intelligent routing and WS-ReliableMessaging.

If we are talking about routing based on ebMS based on ebMS header
information, a common requirement for and benefit of the intermediary
is that it can serve to decouple the sender and the recipient and
to centralize some configuration change management:

(1) It allows two partners to communicate even they are in different
networks without even a shared DNS.
(2) If the connection properties of Partner B change, it allows B to
just communicate these changes to the Intermediary from which it
receives incoming messages, not to all partners sending via that
intermediary. 
(3) If Partner B distributes its services over multiple MSHs and some
ebMS-aware dispatcher is used to distribute messages to the correct
MSH, B's partners should not have to know how many MSHs B has, but
only the address of the dispatcher. 

The third use case is about giving B the freedom to add MSHs as
traffic patterns evolve.  B should also be able to change the routing
logic without having to tell A. For example, to move from To/PartyId
based routing to Service/Action based routing to routing based on more
dynamic properties, e.g. (RefTo)MessageId or ConversationId. The
latter would support a kind of ebXML load balancing, assuming a
conversation/transaction affinity similar to the way some networking
appliances implement TLS session affinity.

To me it seems there is a basic incompatibility between wanting to
support intelligent ebMS-aware routing by an intermediary and wanting
to implement end-to-end reliability using WS-ReliableMessaging and
WS-A.  The sequence concept of WS-RM requires all messages sent in the
sequence to be delivered to a single MSH. This means that a sending
MSH needs (i) to know all different(ultimate) MSHs it will send
messages to, (ii) to set up sequences with all these MSHs and (iii) to
send each message on the correct sequence. If it knew all this, would
it still need an intelligent intermediary? There is some discussion on
message ordering and multiple recipient MSHs in an early ebXML IIC
document: M. Wang. ebMS Implementation Guidelines. Version 0.2. 2002.
URL:
http://www.oasis-open.org/committees/download.php/2950/ebMS_implementationGu
idelines.doc

If Partner A establishes a sequence with Partner B, and some
intermediary happens to send some messages from the sequence to a
different MSH, the sequence fails. This problem would not occur if we
could have end-to-end reliability without having to use message
ordering, as was possible with ebMS 2.0. There are production ebMS 2.0
deployments that support this. Unfortunately, WS-ReliableMessaging
implements reliability using sequencing. And due to the
CreateSequence, TerminateSequence overhead for every sequence,
WS-ReliableMessaging is not useful when the sequence consists of just
one message to send.

When using an ebMS3 intermediary or any form of intermediary that has
some intelligent routing capability, use of message ordering protocols
like WS-ReliableMessaging imposes a requirement that the end-to-end
association between originating MSH and ultimate MSH is the same for
any message in a sequence. This requirement can be a property of the
way the routing is set up. If routing is based on To/PartyId, and if
there is just one MSH per To/PartyId, and if the sender sets up a
different sequence for all its business partners, this would
work. When using a more fine-grained (routing based on Service) or
dynamic (e.g. load balancing between multiple MSHs) type of routing
the intermediary should probably record the assigned MSH for any
sequence and reuse it for all subsequent messages. I.e. only the first
sequence in the sequence should be inspected to make the routing
decision.

The assignment of a sequence to an MSH should be done at the time the
intermediary first becomes aware of a new sequence being set up. With
WS-ReliableMessaging, this happens when the intermediary observes a
CreateSequence message and the corresponding CreateSequenceResponse
message flowing through. At this point the sequence is established and
the intermediary should set the destination MSH and effectively freeze
it for the sequence. (There may be some more options for
intermediaries other than "the last").  The purpose of an ebMS3
intermediary (or other router with some intelligence) would be to be
able to inspect the ebXML message header to set this destination.
With ebMS 2.0, this is perfectly possible, as the MessageOrder element
is an element in a regular ebMS message that also contains From and To
PartyIds, Service, Action and ConversationId.  WS-Reliability also
supports this.  A second disappointment with WS-ReliableMessaging: the
CreateSequence message is a stand-alone message that occupies the SOAP
body and that is to be sent before the first real, meaningful message
in the sequence is sent. So the intermediary has no information to
base any intelligent routing decisions on.

A solution could be to piggy-back ebMS information with the message
that carries the CreateSequence structure.  If this ebMS information
is a full UserMessage, to allow it to carry all user message
information that a router might want to use, can we risk piggy-backing
it on the CreateSequence message that itself is non-reliable? What
does this message look like?  If it uses the default Service for
testing, what if the intermediary wants to know the intended
meaningful business Service to make a routing decision?

An alternative would be to have two reliability chains (up to the
Intermediary for incoming messages, and from the Intermediary for
forwarded messages) and some way to tie them.  Could we define "Ack on
Delivery" for an Intermediary as: "Ack on successful forward", meaning
that intermediate SOAP nodes in the SOAP path do not send their
acknowledgments until they have delivery confirmation from the next
node (which, if it behaves the same, would also wait, meaning no
intermediary ACKs until the final MSH has ACKed).  If I read 8.2.3 of
ebMS 3.0, it seems to indicate WS-ReliableMessaging does not support
"Ack on Delivery", so "Ack on Forward" probably won't work either ..
 
Perhaps multiple separate but connected reliability chains do provide
enough overall robustness and the end-to-end acknowledgment should
rely on something like an ebBP ReceiptAcknowledgment instead ..