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

 


Help: OASIS Mailing Lists Help | MarkMail Help

ebxml-msg message

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


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




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



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