Re: [wsrm] comment on 1.085jdak

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

Jacques,

Seems fine with the exception of the comment I have inserted below.

On 19-Aug-04 17:32, Jacques Durand wrote:
> 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

...

> - 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 do not understand what you mean by "initiated outside the RMP".  I also 
would avoid "over" when "using" is meant and reduce the number of words.  I 
recommend "Except when the Callback RM-Reply is bundled with a new Reliable 
Message (as described in Section 4.4), the Receiving RMP must send this 
RM-Reply using a SOAP One-way MEP."

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

We are treading a fine line here.  A statement such as 'the "application" 
has control whenever the message is initiated by it' is not valid according 
to our abstract model.  The RMP *always* has complete control over the wire 
level interactions.  The intent of our statements earlier is to let readers 
know the RMP defers to the Producer with respect to the SOAP MEP when 
sending the Reliable Message itself.  We have not, for example, had the RMP 
defer to the Consumer when the Respond operation is invoked.

I hope you are not describing additional changes to the document based on 
this sentiment.

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

Just a reminder that the RMP is more than a SOAP processor and retry loops 
(for example) make use of this SOAP processor to send and receive SOAP 
messages.  The interoperability requirement is basically that RMPs call 
their internal SOAP processors in a consistent fashion.  Where those calls 
rely upon the Consumer interface description, consistency is (almost) a 
given.  Where the messages are RMP signals and nothing else, our 
specification should provide an equivalent amount of detail to a WSDL instance.

...

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

We do not use the phrase "application exchange" elsewhere in the document. 
  Rather than introducing new terminology and "either a SOAP 
Request-response or One-way MEP instance" seems to be empty of meaning 
since we have defined only those two MEPs.  How about, "Step 1: The Sending 
RMP sends the Reliable Message using the SOAP MEP appropriate for this WSDL 
operation, as the Consumer requested."

Separately, I believe you and I are looking at different PDF files and line 
numbers.  My comment was about the paragraph above the bullets which 
describe overall MEP requirements for this RM-Reply Pattern.

...

thanx,
	doug