RE: [ebxml-msg] Groups - ebms_core-3.0-spec-wd-21.pdf (ebms_core-3.0-spec-wd-21.pdf) uploaded

["Pim van der Eijk" <pim.vandereijk@oasis-open.org>]

 

Hello Jacques,

 

Thanks, this answers all of my questions.  In response to your question about my comment about line 3433, the restriction would be compatible with ebMS2:

 

"The SequenceNumber is unique within the ConversationId and MSH.  The From Party MSH and the To Party MSH each set an independent SequenceNumber as the Sending MSH within the ConversationId. "

 

I notice you are addressing how ebMS3 can do this in F.2.3.5 as a compatibility option, and that PMode.Reliability.Correlation allows to express this but also other options.

Thinking about it more, I think you are right that this may be useful.  E.g. a "Place Order" could create a new business conversation, and then it may be necessary for each "Change Order" to be processed in sequence within the conversation. A "Cancel Order" would terminate the conversation and should be processed immediately, no need to wait until any in-process intermediate "Change Order"s have been processed, they could all be negatively accepted.  So it now seems you are offering a better In Order processing model with ebMS3 than in ebMS2.  Thanks for the clarification.

 

Pim

---

Line 3433, "OrderedDelivery: No Restriction". 
Should there be some text here about a restriction among ConversationId and Group membership? It seems okay to reuse a group for multiple conversations, but messages that are part of a single conversation should not be in multiple groups (or rather concurrently active groups:  a conversation could start in one group, and continue in later one if that group is terminated).

<JD> No: both patterns are allowed and controlled by P-Mode parameters. Why wouldn't a same conversation be allowed to proceed over concurrent, intertwined reliable sequences (with different reliability levels?).

Line 3559-3561:
"Any pair of sequence lifecycle message
(CreateSequence/CreataSequenceResponse,
CloseSequence/CloseSequenceResponse, TerminateSequence/ TerminateSequenceResponse ) MUST be exchanged over a single HTTP request-response."

Line 3458, section B.2
Should there be some text here about correlation of use of ConversationId and Sequences? It seems okay to reuse a sequence for multiple conversations, but messages that are part of a single conversation should not be in different sequences (or rather concurrently active sequences:  a conversation could start in one group, and continue in later one if that group is terminated).

<JD> see previous comment for Line 3433.