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

["Durand, Jacques R." <JDurand@us.fujitsu.com>]

Interesting analysis. There is a fundamental issue in combining
"ebMS-intelligent" routing, and the need to establish a fixed
reliability path (using RM seq lifecycle messages) prior to all reliable
exchanges to take place between two "multi-hop" parties.

WS-Reliability appears easier to deal with for 3 reasons: (a) no
separate lifecycle messages, (b) there is the option (like in ebMS2) to
*not* use sequence numbers, (c) the Ack semantics is on delivery, which
could mean "forward" for an intermediary. This makes it easier to chain
several reliable path segments.
This is something we will have to seriously consider. At this point it
looks like Part 2 - like Core part - cannot afford to ignore either
reliability spec. 
Reliable (ordered) sequences are still something desirable, because they
allow for high performance and very robust duplicate detection, and loss
detection. But they assume the destination is resolved from the start.
WS-Reliability makes this a little more flexible (i.e. sender only has
to know what messages are for the same destination, vs. knowing the
destination).

With WS-ReliableMessaging, an approach could be: All routing is based on
wsa:To, which identifies the reliable destination (even if the routing
path may change). No ebMS-intelligent routing.

Chains of reliable segments appear unsafe, opening loopholes during
intermediary forward.

In all cases, it seems more important than ever to clarify the
requirements for multi-hop, and the use cases to be addressed.

Jacques
 


-----Original Message-----
From: Pim van der Eijk [mailto:pvde@sonnenglanz.net] 
Sent: Sunday, November 18, 2007 8:03 AM
To: Durand, Jacques R.; ebxml-msg@lists.oasis-open.org
Subject: RE: [ebxml-msg] multi-hop / routing: current state of
discussions


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_implementati
onGu
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 ..



---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the OASIS TC that
generates this mail.  You may a link to this group and all your TCs in
OASIS
at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php