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

["Durand, Jacques R." <JDurand@us.fujitsu.com>]

Pim:

 

inline

-----Original Message-----
From: Pim van der Eijk [mailto:pim.vandereijk@oasis-open.org]
Sent: Wednesday, April 25, 2007 12:48 PM
To: ebxml-msg@lists.oasis-open.org
Subject: RE: [ebxml-msg] Groups - ebms_core-3.0-spec-wd-21.pdf (ebms_core-3.0-spec-wd-21.pdf) uploaded


Hello,

I know there will be a second public review in some time, but I read some parts, in particular chapter 8 and appendix B and thought I might share some comments on them already.

Line 2875: 
Typo: line has two commas.

Line 2895-2898: 
"This response is sent back reliably over the response leg of the same SOAP Request-response MEP instance that carried the previous message."

This seems to be refer to the specific case of an ebMS Transport Channel
Binding of type "Sync"?    

Request and response messages in a Push-and-Push message exchange can also both be sent reliably.  If the assumption is that sending an asynchronous response message reliably is like sending an asynchronous request or one way message reliably and needs no special discussion, then it would be useful to state this explicitly at this point.

If RM-SubmitResponse is not used for asynchronous ebMS response messages, then its name is too general, something like RM-SubmitSyncResponse would be more accurate.

<JD> Reading again the reliability model, I think there is no reason to assume that RM-SubmitResponse is to be used only for 2-way underlying protocols, and on the back-channel of these. You are right to question why the model does not remain "abstract" here. A specific binding of  RM-SubmitResponse to the underlying protocol (e.g. to the back-channel of which) belongs to the RM bindings section (Appendix B) . I suggest we simply replace the sentence, in the definition of RM-SubmitResponse :

"This response is sent back reliably over the response leg of the same SOAP Request-response MEP instance that carried the previous message."

with: "This response is then sent back reliably ."

 

Line 2908:
Related to earlier comment.  Does this diagram also cover the second leg in a Request-Reply MEP with a channel binding Two Way/Push-and-Push and Two Way/Pull-and-Push?

<JD> Although these "asynchronous" MEPs are not described in the core part, the answer is yes. And therefore again we should avoid the expression "Request Message" and "Response Message" unless tightly associated with the protocol level they are supposed to relate to (e.g. underlying protocol response, SOAP response, ebMS MEP response...). I suggest to change comment of Fig 10 as: "Fig 10: Operations for sending a message reliably."

Then, in the comment immediately below, replace:

"– either a user message in the One-Way/Push MEP, the first leg of a One-Way/Pull MEP, or the first leg of a Request-Reply MEP."

with:

"– as indicated in the "Reliability of ebMS MEPs" section (8.3), this sequence of operations is used for the user message in the One-Way/Push MEP, the Pull signal of a One-Way/Pull MEP, or the first leg of a Two-way/Sync MEP."

Also, Fig 11 should be commented as:

"Fig 11: Sending reliably a response message in an ebMS MEP."

Then, in the comment immediately below, replace:

"- either a pulled user message in the One-Way/Pull MEP or the response user message in a Two-Way/Sync MEP.

with:

"– as indicated in the "Reliability of ebMS MEPs" section (8.3), this sequence of operations is used for the pulled user message in the One-Way/Pull MEP,  or the response user message in a Two-way/Sync MEP."

(we will indicate later in 8.3  that for 2-way async MEPs, the second leg can be treated as the first leg: using same seq of operations (RM-Submit..))

Line 2966
"the MSH" -> "the sending MSH"

<JD> Right.

Line 2971:
"generatedand" -> "generated and"

<JD> Right.


Line 2982:
"a failure do deliver must cause" -> "a failure to deliver MUST cause"

<JD> Right.

Line 2984:
"may be notified" -> "MAY be notified"
<JD> Right.

Line 3025-3027:
This will not work in case of multi-hop messaging, where the SOAP fault or HTTP response failure is received by an intermediary, which will often not have enough information or no channel to propagate this error back to the original ebMS sender.

<JD> Replace: "However, in case of HTTP binding," with: "However, in case of HTTP binding and when no intermediaries are present,"

Line 3042:
"periodic sending of status request ebMS signal (defined in Part 2 of this specification)" -> "periodic sending of status request signals (as may be defined in a future Part 2 of this specification)"
Reason: Part 2 does not yet exist, so some caution is good when referring to it.

<JD> Remove the second bullet.

Line 3045:
There is no section on reliability of the Two Way Push-and-Push and Two Way Pull-and-Push.  If they are covered by section 8.3.1, a sentence stating this could be added at line 3048.

<JD> Add: new section 8.3.4 "Reliability of other Transport-Channel-bound MEPs"

that says:

"Each one of the MEPs defined in 2.2.8: Two-way / Push-and-push, Two-way / Push-and-pull, Two-way / Pull-and-push, has been characterized as having a message choreography equivalent to a sequence of two of the previous MEPs (e.g. Two-way / Push-and-pull has a choreography equivalent to One-way /Push + One-way/Pull). The reliability of these more complex MEPs may be handled by composing reliable versions of these simpler exchanges, which are described in 8.3.1, 8.3.2, and 8.3.3. It can be noted that in such case, the reliable Two-way / Push-and-push MEP will not make use of the RM-SubmitResponse operation." 

Similarly, there is no section on the Two-Way Push-and-Pull and Two-Way Pull-and-Pull. If these are covered by section 8.3.2, a similar textual addition would be useful.

Line 3062
"workflow":  confusing term perhaps.

<JD> I think the TC settled on replacing with "operation sequence".

Line 3115:
Formatting issue (should not be bullet)

<JD> Right.

Line 3065, Figure 12, Reliability Ack
Would this reliability Ack be a standalone message? Some explanation might be useful.

<JD> Add: "The way the Reliability Acknowledgement binds to the underlying protocol - e.g. as a separate HTTP request, or on the back-channel of a previous message - is controlled by  the P-Mode parameter Reliability.AtLeastOnce.ReplyPattern."

Figure 13/14, second Reliability Ack.
Idem.

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."

Does this mean that any use of WS-ReliableMessaging (in ebMS3) is tied to the HTTP protocol? 
Can this MUST be relaxed to a SHOULD? Some ebMS end users have and prefer an all-asynchronous setup for their messaging (today ebMS2), is this not possible with ebMS3?

<JD> Use instead: " When an underlying two-way protocol is used, any pair of sequence lifecycle message (...) SHOULD be exchanged over a single request-response MEP of this protocol."

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.

Line 3865, figure 15.
This is an example of a Two-Way MEP, but the PMode.MEP in the figure says "200704/oneWay".

<JD>Right, should say "twoWay"

<JD> Additionally: replace "simple request-response MEP" in B.1.4 title, with: "Two-way / Sync MEP"

-----Original Message-----
From: Durand, Jacques R. [mailto:JDurand@us.fujitsu.com]
Sent: 25 April 2007 03:14
To: pete.wenzel@sun.com; ebxml-msg@lists.oasis-open.org
Subject: RE: [ebxml-msg] Groups - ebms_core-3.0-spec-wd-21.pdf
(ebms_core-3.0-spec-wd-21.pdf) uploaded

Thanks Pete:

A substitution that we missed:

- 2.2.6: the error "EmptyMessagePartitionFlow" should be renamed:
EmptyMessagePartitionChannel

- same in 3.2 (L727)

- same in table 6.7.1

- same in B.2.3 (L3591)

- same in F.2.5.2 (L4346)

Quite benign edit, and pretty straightforward...

- Jacques