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