OASIS ebXML Messaging Services TC

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

If we assume asynchronous intermediaries, how are the life cycle management
response messages (e.g. CreateSequenceResponse, CloseSequenceResponse)
routed back to the source?  

If the life cycle management creation messages are piggy-backed on a dummy
ebMS message from Sender to Ultimate Receiver, we need to use the same
mechanism for Ultimate Receiver to send the life cycle management response
messages to Sender.

If the dummy ebMS message from Sender includes ebMS header fields (From,
From Role, To, To Role, AgreementRef, Service, Action, ConversationId,
MessageId, RefToMessageId, perhaps message properties), we need a way for
the Ultimate Receiver (or the ultimate ebMS intermediary) to construct a
corresponding dummy ebMS message.  What mechanism do we assume for this?
-  Reverse From and To
-  Reverse From Role and To Role
-  Copy AgreementRef 
-  Copy value of ConversationId
-  Set value of returning RefToMessageId to value of incoming MessageId
-  Copy Service ??
-  What to with Action??  
-  What about message properties?? Some of them may be relevant to routing.


The non-dummy response action value depends on the business process, but we
cannot assume that messaging component like an intermediary that the
response to a "Place Order" action is a "Confirm Order" action. Perhaps we
should just copy the value and have the presence of a RefToMessageId
indicate this is the "reverse routing". Or have a separate
ebMSDummyResponseMessageSignal in addition to the ebMSDummyMessageSignal. In
any case, asynchronous intermediaries should be configurable to support
consistent routing in both directions.

Perhaps we need to require these messages to be synchronous end-to-end, but
that has its own drawbacks.
See separate but related message on routing asynchronous
wsrm:SequenceAcknowledgement messages.


________________________________

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

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