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