[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Response to discussion of public comment feedback
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.
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]