Re: RE: [ebxml-msg] Sequences and sequence sharing

["Sander Fieten" <sander@fieten-it.com>]

Because the routing function of the intermediaries in the I-cloud can use several meta data attributes for routing messages the PMode.Reliability.Correlation parameter will be defined (partly) by the I-cloud. The expression will need to contain all meta data attributes that the [actual] I-cloud will use for routing. Endpoint can then further narrow the usage of a sequence by adding other XPath expressions.

I would like to leave the definition of these common XPath expression out of scope and something determined out of band.

Sander

----- original message --------

Subject: RE: [ebxml-msg] Sequences and sequence sharing
Sent: Wed, 03 Sep 2008
From: Pim van der Eijk<pvde@sonnenglanz.net>

> 
> Jacques,
> 
> Thanks for clarification. To summarize: multiple messages are sent on a
> single sequence if (1)-(3) apply:
> 
> (1) if the messages are correlated based on Xpath expressions in
> Pmode.Reliability.Correlation, the must have the same Delivery Assurance
> Pmode. (The Xpaths should be written to make sure this is always the case
> for any pair of messages that are correlated using these expressions).
> 
> In addition to this, when using an in-order contract:
> 
> (2) the Xpath expressions specified in the Pmode.Reliability.Correlation
> MUST include eb:UserMessage/@mpc. 
> 
> When using Delivery Assurances other than in-order:
> 
> (3) constraint (2) applies, except that it is a SHOULD instead of a MUST.
> 
> Pim
> 
> -----Original Message-----
> From: Durand, Jacques R. [mailto:JDurand@us.fujitsu.com] 
> Sent: 03 September 2008 08:23
> To: Pim van der Eijk; ebxml-msg@lists.oasis-open.org
> Subject: RE: [ebxml-msg] Sequences and sequence sharing
> 
> Pim:
> inline 
> 
> -----Original Message-----
> From: Pim van der Eijk [mailto:pvde@sonnenglanz.net]
> Sent: Tuesday, September 02, 2008 1:08 PM
> To: ebxml-msg@lists.oasis-open.org
> Subject: [ebxml-msg] Sequences and sequence sharing
> 
> 
> 
> Hello,
> 
> To follow up on the discussion on (re-)using sequences from two weeks
> ago:
> which ebMS messages are sent on the same WSRM sequence? This is more
> about ebMS 3.0 in general than about multihop.
> 
> Jacques mentioned a default assumption that each Pmode is associated
> with a distinct sequence.
> 
> <JD> I should have been more nuanced:
> Core V3 says (B.2.1): "It is RECOMMENDED that all messages transmitted
> over a same sequence use the same MPC. This becomes a requirement for
> the In-Order reliability contract."
> So messages from an RM sequence should not go over several MPCs, but the
> reverse is not a problem: several RM sequences can use the same MPC.
> The constraint is more about RM sequence vs. MPC, rather than Pmode.
> Now, each leg of an MEP in a Pmode is assigned to only one MPC so far (I
> ignore here the case of "sub-channels" of an MPC). But an MPC can easily
> be shared by several Pmodes.
> The key point about RM sequences, is that (B.2.1) we require that the
> same Delivery Assurance(Ordering, At-Least-Once....) be used for all
> messages of the same sequence. Given this, a Pmode could share a
> sequence (and an MPC) with other Pmodes, and also a Pmode (which is
> usually associated with a single Deliv Assurance, at least for each one
> of its "legs") can still make use of several RM sequences for a single
> "leg" - e.g. a pool of sequences - provided they are associated with
> same delivery assurance.</JD>
> 
> 
> 
> 
> 1) In the document on routing examples
> (http://www.oasis-open.org/apps/org/workgroup/ebxml-msg/document.php?doc
> umen
> t_id=28981) I discuss a number of routing scenarios. The simplest case
> assumes routing is based on To:PartyId only.  It basically asserts for
> an I-Cloud that any ebMS message, including messages to be sent
> reliably, is
> handled by the same final MSH.   This means that an ebMS MSH can
> optimize
> its sequence creation, as some Pmodes can use the same sequence. It was
> suggested to leave this out of the multihop specification and leave this
> to implementers as it is an optimization rather than a potential
> conformance or
> interoperability issue.   
> 
> 2) Section 2.5 mentions a situation where a message is routed
> differently based on a message property value. This means that there
> have to be different sequences based only on property values.  Can there
> be two Pmodes that are the same except for a particular message property
> value? 
> 
> <JD> I think so.
> 
> 
> If not, the routing document should not refer to routing based on
> properties.
> 
> 3) The ebMS 2.0 message ordering module associates ordering with
> ConversationId. Do we want to support a similar model with ebMS 3.0?  If
> we have a business process where "conversations" consist of a
> "PlaceOrder"
> action, followed by one or more "ChangeOrder" actions followed by an
> option "CancelOrder" action and they are to be processed in order, then
> the MSH must use the same sequence to send them.  How and where is this
> specified?
> 
> <JD> I think we have in the Pmode some way to associate a conversation
> with a delivery assurance.
> See Pmode.Reliability.Correlation and the like.
> 
> Pim
> 
> 
> 
> 
> 
> 
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe from this mail list, you must leave the OASIS TC that
> generates this mail.  Follow this link to all your TCs in OASIS at:
> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php 
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe from this mail list, you must leave the OASIS TC that
> generates this mail.  Follow this link to all your TCs in OASIS at:
> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php 
> 
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe from this mail list, you must leave the OASIS TC that
> generates this mail.  Follow this link to all your TCs in OASIS at:
> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php 
> 
> 

--- original message end ----