Re: [wsrm] comment on 1.085jdak

[Doug Bunting <Doug.Bunting@Sun.COM>]

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

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

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.

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.

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

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

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

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

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

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

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

- 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

On 18-Aug-04 16:45, Jacques Durand wrote:

> inline
> 
> -----Original Message-----
> From: Tom Rutt [mailto:tom@coastin.com]
> Sent: Wednesday, August 18, 2004 10:46 AM
> To: wsrm
> Subject: [wsrm] comment on 1.085jdak
> 
> 
> In general I like the  approach taken by Jacques.
> 
> My only concern is that the figures 9, 10, and 11 in the http binding
> section for callback and poll do not show
> the rm-operations for Respond.
> 
> Either:
> - the figures can be clarified as examples illustrating the use in the
> one-way soap mep case (the easiest approch),  with an explanation that
> the corresponding figures for request/response mep are not shown, or
> - change to a new set of figures which have a dotted respond arrow with
> an explanation that the respond arrow is only used for request/response
> mep.
> 
> <JD> I'll keep track of these proposed updates in case Iwasa cannot do 
> them for
> teh contribution by tomorrow.
> 
> In any case there needs to be a statement that the sending and receiving
> RMP must know when an application response is required for the operation.
> 
> <JD> Yes, although the need to "know" which SOAP MEP is used when sending a
> Reliable Message, has always been there due to the fact that the sender 
> (and receiver) needs to distinguish which SOAP MEP is used with the 
> Response reply pattern ( One-way MEP not allowed). The Receiving RMP 
> also had to distinguish (for handling of SOAP Faults)
> 
>  (see lines 1027-1046), although we could argue that just looking at the
> RM Reply Pattern used was a sufficient - yet not error proof - way to 
> figure this out (no longer the case in this contribution as Callback and 
> Poll can be used on either MEP)
> 
> So we may want to make this more explicit.
> I'll suggest a line in Section 2.3, after L382, saying:
> "An RMP MUST be able to distinguish which SOAP MEP is being used when
> sending or receiving a Reliable Message."
> Hamid reassures me that this is well supported by the WS stacks, whether an
> RMP is implemented as a handler or an end-point (e.g. SOAP node)
> so there is no need to specify further how the RNP gets this knowledge
> (implementation specific) (see my previous email).
> 
> Jacques
> 
> 
> 
> 
> Tom Rutt
> 
> -- 
> ----------------------------------------------------
> Tom Rutt        email: tom@coastin.com; trutt@us.fujitsu.com
> Tel: +1 732 801 5744          Fax: +1 732 774 5133
> 
> 
> 
> 
> To unsubscribe from this mailing list (and be removed from the roster of 
> the OASIS TC), go to 
> http://www.oasis-open.org/apps/org/workgroup/wsrm/members/leave_workgroup.php.