RE: [ebxml-msg] scenario: RM-transparent Intermediaries

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

There are potential issues with the routing of wsrm:SequenceAcknowledgments
when we assume asynchronous store-and-forward intermediaries. I.e. in a path
Source -> AsyncInt -> Target, there are two connections:
 
Source -> AsyncInt
AsyncInt -> Target
 
If the AcksTo for the sequence is the WS-Addressing anonymous IRI, the
response wsrm:SequenceAcknowledgement must be sent on the back-channel of
the HTTP connection.  When Source includes a wsrm:AckRequested header with
an ebMS message, AsyncInt cannot satisfy the request to provide the
corresponding acknowledgment information. This is because it has yet to
forward this request to Target.   So, synchronous end-to-end sequence
acknowledgments are incompatible with asynchronous intermediaries.
 
Option 1: 
We could assume asynchronous acknowledgments, which WSRM supports. But then
it is based on the WS-A AcksTo address. If WS-A headers are signed (and
cannot be rewritten by AsyncInt), then that address will be the address of
Source, not AsyncInt's address.  So this acknowledgment would flow directly
to Source, bypassing AsyncInt.  
Advantage:
Simple and seems not to require any special functionality on intermediary or
endpoints. Regular WSRM functionality.
Drawback: 
The point of having an intermediary is often that such a direct connection
is not possible (due to firewall issues, or due to a policy that all
messages should flow via the intermdiary for monitoring purposes, or due to
the Source and Target not being available at the same times e.g. both are
small business endpoints just available at most a few hours a day). 
 
Option 2:  
Sticking to the synchronous acknowledgment model, we could assume a hybrid
model where ebMS user messages are sent asynchronously, but (some) signal
message(s) are to be processed synchronously. The asynchronous user messages
would carry the regular wsrm:Sequence elements that identify sequence and
number in that sequence.  Exceptionally, we assume that there is a
designated ebMS signal that is to be processed synchronously. Perhaps it is
the same signal that we already need to carry the sequence life cycle
messages. This signal is used to piggy-back standalone wsrm:AckRequested
headers, and return the wsrm:SequenceAcknowledgement synchronously on the
HTTP back channels. With multiple intermediaries, this assumes all
connections are synchronous.
Advantage:
- We get the ebXML header-based routing we want, no issues with signed WS-A
headers. 
Drawbacks:
- When we have multiple intermediaries, the requirement to have these
synchronous connections assumes both Source and Target and all
intermediaries are available at the same time, and the point of having an
intermediary may be that this is not the case. It is also potentially less
robust.
- We get an even more complicated model:  intermediaries need to be either
synchronous or asynchronous depending on message content.  It would be
simpler if we could just assume them to e.g. always be purely asynchronous. 
 
Possible solution 3:
Assuming synchronous wsrm:SequenceAcknowledgments (anonymous AcksTo IRI).
Source sends an ebMS user message with a wsrm:AckRequested to AsyncInt.
AsyncInt just HTTP 200 closes the connection and does not provide the
acknowledgment. Then AsyncInt forwards the wsrm:AckRequested header to
Target, and gets a wsrm:SequenceAcknowledgment on the back-channel. AsyncInt
just stores the information and waits for the next message from Source, and
includes this information on the back-channel for this connection. 
Advantages:
-  Supports a fully asynchronous model for all message types
-  Supports ebXML intermediary routing and no issues with WS-A headers and
signatures
Drawbacks:  
-  We assume Source's wsrm processor does not complain about the lacking
wsrm:AckRequested when it first sends it to AsyncInt. Not sure if that is a
valid assumption.
-  Less overall control over when Source actually gets the acknowledgments. 
-  How does AsyncInt correlate a waiting wsrm:SequencAcknowledgments to a
particular Source?  What are the security issues?
-  What if the wsrm:AckRequested is on the last message in a sequence?  In
WSRM this is covered by the wsrm:CloseSequence which could be bundled with
an ebMS signal. The wsrm:CloseSequence should be required in this use case
(it is optional in the WSRM spec).  But an asynchronous
wsrm:CloseSequenceResponse has its own routing issues, see separate message.

Possible solution 4 (extension to solution 3)
For two way message exchanges, wsrm:SequenceAcknowledgments could be bundled
with business response messages.  Or with other (possibly unrelated)
messages that Target happens to send to Source If those response messages
require acknowledgments, those could be piggybacked on subsequent messages
from Source to Target. 
Advantages:
- Same as solution 3.
Drawbacks:
- Same as solution 3, plus:
- Does not work for the one way MEP.
- Even tighter coupling between ebMS or business functionality and WSRM
processor.

Pim
 

________________________________

From: Durand, Jacques R. [mailto:JDurand@us.fujitsu.com] 
Sent: 13 December 2007 22:02
To: ebxml-msg@lists.oasis-open.org
Subject: [ebxml-msg] scenario: RM-transparent Intermediaries


Scenario: 
-------------
RM-transparent Intermediaries
 
 
Assumptions: 
-------------------
 
- the sender does not have to know the ultimate destination (MSH URL) of its
messages, but it has to know whether two messages are intended for the same
destination or not, because it has to assign every message sent reliably to
an active RM sequence (and an RM sequence must go to a single RM
destination).
 
- An ultimate MSH is also supposed to represent a single RM destination. But
the same ultimate MSH could deliver to different parties (message
consumers), i.e. different PartyID, different Service/Action, etc.
 
- the sender knows what fileds in a message are used to determine the
ultimate destination (these fields are used for the routing function)
 
 
Features:
-------------
 
- Only the two ultimate endpoints are RM enabled. The Intermediaries are
fully transparent: they do not touch the RM headers, nor related signatures
etc. 
 
- The difficulty of this scenario is in the establishment of the RM sequence
that will be used by user messages intended for the same destination. RM
"sequence lifecycle messages" such as CreateSequence, TerminateSequence, and
their responses, must be routed in the same way as ebMS messages. A way to
achieve this is to piggyback RM signals on ebMS messages (either dummy
user-messages, or signal-messages). This ebMS header would have same
"determining header fields" as the future user messages intended for this RM
sequence. 
 
- A piggybacking option is to use a "dummy" ebMS user message on all RM
sequence management messages.
Advantage: no new ebMS signal needs be designed for this piggybacking : a
"dummy"  user message has the service field set to:
http://docs.oasis-open.org/ebxml-msg/ebms/v3.0/ns/core/200704/service
<BLOCKED::http://docs.oasis-open.org/ebxml-msg/ebms/v3.0/ns/core/200704/serv
ice> 
which is enough to process it correctly in core V3, i.e. to NOT deliver it
to the MSH consumer layer. (that way, no additional feature is required from
the destination MSH, other than core V3 compliance). We might want to
specify a new Action field value, but no need to interpret it on receiver
side. The drawback is that the Service field should not be one of the
determining fields for routing...
 
- Another piggybacking option is to define a new ebMS signal, that would
still have all the potential business headers used for routing.
 
- the response RM management messages need be routed back. Suggest to put
the burden of the piggybacking for these responses on the last MSH
intermediary, not on the ultimate MSH who should not be aware of the
RM-thru-intermediaries aspects. So the communication between last
intermediary and ultimate Receiver is unconstrained (e.g. get Acks on HTTP
responses, etc), exactly as if the last Intermediary was the original sender
in a one-hop.
 
 
Evaluation:
---------------
  
- Advantages: Very clear RM QoS: end-to-end RM is getting same level of
reliability QoS than any one-hop RM exchange, and using the same RM
infrastructure. Conventional RM modules are used (except for the fact the
piggybacking of RM seq lifecycle messages must be controllable), and if the
module supports duplicate detection for on-hop, will also work for
multi-hop. But most of all, the intermediaries are really fully transparent:
no overhead with RM headers substitution, no restriction on use of security
(remember that RM headers are usually candidates for signing and other
integrity protection). End-to-end security covers RM headers. 
 
- drawbacks: Need to design a piggybacking system introducing special ebMS
messages, for routing the RM sequence management messages. The reliable
"message sets" need be known in advance by sender, at least until the last
intermediary: the initial sender has to know what are the messages intended
for the same destination (might be indicated by P-Mode anyway). 
 
- do the initial sender / ultimate receiver need to support more than Core
V3? Not receiver. But Sender implementation need be able to control
piggybacking of RM signals. Although not really additional feature beyond
Core V3 (unless a new signal introduced), it is a constraint on
implementations.