RE: [wsrm] comment on 1.085jdak

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

Title: RE: [wsrm] comment on 1.085jdak

inline <JD>

-----Original Message-----
From: Doug Bunting [mailto:Doug.Bunting@sun.com]
Sent: Wednesday, August 18, 2004 11:32 PM
To: Jacques Durand
Cc: 'tom@coastin.com'; wsrm
Subject: Re: [wsrm] comment on 1.085jdak

I suspect it will be necessary and useful to go one step further than "An
RMP MUST be able to distinguish which SOAP MEP is being used when sending
or receiving a Reliable Message."  We need to explicitly state any WSDL
instance describing the relevant Consumer interface defines the wire-level
for the Reliable Message.  That is, "The Sending RMP MUST use the SOAP MEP
(as defined in Section 2.3) corresponding to the WSDL operation associated
with this Reliable Message."

<JD> Right. I thought that went without saying but that removes any misinterpretation.
(which SOAP MEP is in use for a reliable message is generally dictated by factors external
to the RMP, such as WSDL bindings.) 

I would also recommend resurrecting table 5.2 though not as a table.  I do
not believe the current drafts explicitly state the restriction that "the
Response RM-Reply Pattern MUST NOT be used when the relevant Consumer WSDL
is a one-way operation".  This seems important and should not need to be
inferred from other restrictions in our specification.  Words to that
effect should appear in Section 2.4.1 (or earlier).

<JD> Agree. 2.4.1 seems the right place (reply patterns not introduced before 2.4)</JD>

A few additional comments on draft "1085jdak"[1] (using lines from the PDF[2]):

- At line 411 (in Section 2.4.2), the MEP restrictions on the Callback
message itself (the publication) have been lifted.  This implies it is
possible for the Sending RMP to respond in some way to this message but we
have not described any purpose for such a response.  Since this SOAP
message is almost always (apart from the "bundle" case discussed in Section
4.4, see below) an RMP signal and nothing else, this restriction should
stand for the general case.  It should, however, be overridden in the case
where a Response and Reliable Message are combined -- meaning the Reliable
Message constraints "win" when bundled.  I recommend this change to step 2
not be made.

<JD>How about: "Except for the case where the Callback RM Reply is bundled with a new Reliable message initiated outside the RMP (e.g. a Producer component), the RMP must generate this RM Reply over a SOAP One-way MEP instance".

(I think the key aspect in SOAP MEP allowed, is who has control on which MEP is used,
and the "application" has control whenever the message is initiated by it.
So far we only talk of bundling with Reliable messages,though that would not make much difference whether reliable or not.)</JD>

Generally, the Consumer interface description controls the sending of a
Reliable Message and, optionally, its response.  That interface or WSDL
instance does not describe how other RMP signals are exchanged.  We do,
however, need to clearly describe these exchanges in this specification --
without multiple options.

<JD> Except for bundling cases (where an RMP mostly behaves in good SOAP processor,
inserting and consuming headers on messages generated outside), agree that we
can be more specific - probably which SOAP MEP and SOAP Body the signal
must contain, is enough.</JD>

- For this section and the next, we probably need to also be explicit about
the soap:Body being empty (and the lack of attachments) for all steps in
the sequences in the Callback and Poll RM-Reply Patterns but the first.
That is, no application content may be bundled with the callback
publication or poll request / response (except in the single bundle we
define later).

<JD> Although all this makes sense - i.e. signals messages generated by RMP should
be "payload-empty" - I wouldnot get into too many details (e.g. attachments) in Section 2.
Section 6 might be the right place to state further interoperability requirements on
signals (as I believe that is the concern at the root of your remark), and there I'd simply say that when binding to HTTP, these signal messages must conform to WS-I Simple Soap profile (same as BP 1.0)(no attachment...).  </JD>

- At line 416 (in Section 2.4.3), the requirements on SOAP MEP support have
been changed and made overly broad.  These requirements should now be
closer to the previous edit, though widened a bit: "... the SOAP One-way
MEP MUST be supported. When using the "synchronous" option described below
or when a Consumer payload is expected, the RMPs MUST also support the SOAP
request-response MEP."

<JD> I'd propose then to simplify L416:
"When the Poll RM-Reply Pattern is in use, the following exchange pattern occurs:"
and to mention these requirements when appropriate in the text after.
I believe the choice of SOAP MEP on which the Poll reliable message is carried,
is determined by external factors (e.g. WSDL binding, code generation), so this being a given, it must be accommodated by RM features in step #1 (should not appear as a"choice" the RMP has):

Reword: "Step 1: The Sending RMP sends the Reliable Message in a request of a SOAP Request-response MEP instance or in the message of a SOAP One-way MEP." as:

"Step 1: The Sending RMP sends the Reliable Message in the SOAP MEP instance required
for this application exchange - either a SOAP Request-response or One-way MEP instance."</JD>

- At lines 425 and 429, the MEP restrictions on the asynchronous Poll
request and response have been lifted.  Similarly to line 411, these
extensions do not enhance interoperability and instead leave confusing
options open.  Unlike the Callback case, our protocol does not support
bundling a Poll request or response with a Reliable Message.  Therefore, I
recommend this change to steps 2 and 3 not be made.

<JD> These signals associated with Poll have indeed been given some freedom...
I talked to our developer, and also Sunil confirmed this to me:
there is not much value in allowing more than SOAP One-way for these.
So I'll revert to the One-way restriction for Step 2 and 3 in the draft I'm editing.
If others have issues with this, its time to let me know...</JD>

 

- At line 932 (in Section 4.4), we introduce the idea of combining a
Callback message with an unrelated Reliable Message.  This paragraph should
describe whether the Callback RM-Reply Pattern (ie. the original Reliable
Message) or the new Reliable Message decides the SOAP MEP for this message.

<JD> Right. A blanket statement (Section 2) that says that when the message carrying
RM headers is initiated outside the RMP, the SOAP MEP being used (and the role the message plays in it) is the one that is "required for this application exchange", should do.</JD>

 
  An additional sentence such as "The restrictions described in step 2 of
Section 2.4.2 are not relevant for such a message; the Reliable Message is
exchanged as it would without the additional (Response) element." might do it.

<JD> I'd favor we built-in this exception in 2.4.2 Step 2, since it is "abstract" enough. (so we don't have to "contradict" 2.4.2 later.)</JD>

- At line 1033 (in Section 4.5), the changes combine to leave us with "When
a Reliable Message is sent over a SOAP Request-response MEP (regardless of
the RM-Reply Pattern value),  a Consumer response payload is therefore
expected, and ..."  Why not simply "When a Reliable Message is sent using a
SOAP Request-response MEP and ..."?  Perhaps a "(regardless of the RM-Reply
Pattern used)" bit could be added but the rest is redundant.

<JD> sounds fine.

- Starting at line 1417 (in Section 6.2), a number of reminders that each
message must be sent using the "HTTP POST method" appear.  Since such
requirements have already been made for the general case (the bullets at
line 1320 in Section 6, for example), these additions seem unnecessary.
The early references to the examples also do not seem as clear as the
previous bulleted list of steps.

<JD> OK.

- The new bullets as line 1430 seem correct but should be placed in Section
6 as they cover the general case.  What is necessary in the sections
specific to the RM-Reply Patterns is an explanation of and introduction to
the examples.  BP 1.0, SOAP, HTTP and WSDL have already been documented
quite thoroughly, as has our general mapping from our generic SOAP MEPs to
HTTP exchanges.

<JD> Will improve the wording and flow here.

- editorial: At line 1432, "then" is always unnecessary with a simple "if"
clause.  Most of these have been removed from the document, making this
sentence inconsistent with the rest of the specification.  This is one
example of a more general need to repeat a number of editorial fixes
(removing spaces and unnecessary "join" words mostly) before we are done.

More generally, who is doing what at the moment?  I have seen no email
among the previous editing team and cannot quite grasp the outcome of our
teleconference from either my time on the call or the preliminary minutes.

thanx,
        doug

[1]
http://www.oasis-open.org/apps/org/workgroup/wsrm/download.php/8746/WS-Reliability-1085-jdak.sxw
[2]
http://www.oasis-open.org/apps/org/workgroup/wsrm/download.php/8747/WS-Reliability-1085-jdak.pdf