[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [ebxml-msg] Sequences and sequence sharing
Pim: -----Original Message----- From: Pim van der Eijk [mailto:pvde@sonnenglanz.net] Sent: Wednesday, September 03, 2008 12:54 AM To: Durand, Jacques R.; ebxml-msg@lists.oasis-open.org Subject: RE: [ebxml-msg] Sequences and sequence sharing 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). <JD> yes, although I believe these "sequence control" Pmode elements ( Reliability.StartGroup, Reliability.Correlation, Reliability.TerminateGroup) were primarily intended for Ordered sequences, which had to map to precise sequences of business messages. Whether you use or not these parameters, all messages under the same Pmode will have the same RM deliv. Assurance automatically (defined by the Pmode.Reliability configuration). Now if these messages may split into several Conversations, and for some reason you want a conversation to map to a single sequence, then you'll set Reliability.Correlation accordingly. There is a gray area as whether Reliability.StartGroup for a sequence could be specified in a different Pmode as Reliability.Correlation for the same sequence (as starting a seq may require a specific Service/Action). In such case indeed both Pmodes should have same RM DA. So when message M1 under Pmode 123 must be correlated based on its ConversationID to a sequence that has been initiated by message M0 under Pmode 111, the MSH will see if there is already a sequence attached to this Conversation, and use it.</JD> 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. <JD> Not if Pmode.Reliability.Correlation is under a Pmode that already specifies an MPC. In that case this MPC is implicitly used for all messages under this Pmode. 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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]