Re: [wsrm] comment on 1.085jdak

[Tom Rutt <tom@coastin.com>]

Jacques took an action item to post a document for review by thursday 
evening.

Tom Rutt

Doug Bunting wrote:

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

-- 
----------------------------------------------------
Tom Rutt	email: tom@coastin.com; trutt@us.fujitsu.com
Tel: +1 732 801 5744          Fax: +1 732 774 5133