OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

wsrm message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: RE: [wsrm] comment on 1.085jdak and NEC's position on same


NEC implementors have told me that the changes to the WS Reliability spec are not substantive,
Therefore, if we vote to make the spec a CD on Tuesday's call, I propose that we should not go out for another public review.  Instead we should submit the spec to OASIS for member votes.

Further clarification:  the NEC position on the SOAP MEP issue, is that we endorse Jacques proposals and do not think we should put SOAP One-way MEP restrictions for Callback and Poll (as in WS-Reliability-1085-ak). Therefore, we are in favor of the WS-Reliability-1085jdak spec, with the changes/rewording noted in the mails below.  In particular,  we support the proposed rewording in Doug's mail and Jacques comment on same, in the two emails directly below with Subject:  "[wsrm] comment on 1.085jdak".

Finally, we also agree with Jacque's explanations in the email he previously sent with Subject: "[wsrm] HTTP binding upgrade for Callback : proposal." 

Talk with you next Tuesday (I will be out of town, on vacation that day, but on the call).  Hope we can quickly agree on the wording changes in the mails below and have the CD vote (finally)



Alan Weissberger
1 408 863 6042 voice
1 408 863 6099 fax


----- Original Message -----
From: Jacques Durand
Date: Fri, 20 Aug 2004 10:01:49 -0700
To: "'Doug Bunting'" ,Jacques Durand
Subject: RE: [wsrm] comment on 1.085jdak

Agree with most of the rewording you propose. A couple of comments:

>Where the messages are RMP signals and nothing else, our
>specification should provide an equivalent amount of detail to a WSDL instance.

In the coming draft, we tightened the MEPs such signals are supposed to use,
the headers they carry (and don't carry), the payload or lack of.
In addition to this, the compliance with a WS-I profile is probably as far as we should go
in order to support interoperability.

>"Step 1: The Sending
>RMP sends the Reliable Message using the SOAP MEP appropriate for this WSDL
>operation, as the Consumer requested."

Definition and use of SOAP MEPs don't assume always a WSDL to be there,
so a more general expression would be better.


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


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



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]