Response to discussion of public comment feedback

["Pim van der Eijk" <lists@sonnenglanz.net>]

This message is in response to
http://lists.oasis-open.org/archives/ebxml-msg/200705/msg00007.html related
to earlier comments on the public review. 
 
 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.