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] Strawman Proposal for New wording of Section 5.2

Lets discuss this on email, or at the teleconference.  I put this forth 
as a strawman to discuss, because there
was no activity on the list for several days.

This first attempt is trying to clarify how wsdl relates to what our 
protocol does.  I tried to clarify
it with the restrictions which we had in the protocol already.   I do 
not think ws reliability version 1.1
can support a consumer initiated response payload in the callback 
response, and I know it cannot in the poll response.

I tried to not be Binding specific, however the Soap binding is 
introduced so the
ws reliability elements can be thought of as being explicit wsdl message 
parts bound to the header.

Another alternative is to eliminate wsdl altogether from the spec.

I did not make this point specifically, but SOMEHOW the receiving RMP 
has to be aware of
whether a response payload must be waited for.  WSDL is one way to have 
this awareness happen. Other ways may be api specific configuration 
based on the operation name etc.

Tom Rutt

Doug Bunting wrote:

> Tom,
> I do not have an opportunity prior to Tuesday's meeting to propose an 
> alternative.  That is not good because I get very confused midway 
> through this email as to how you are proposing to resolve the various 
> issues I have described.  We may do better to talk about the features 
> WS-Reliability provides in direct terms rather than mapping that 
> language to WSDL.  That is, we can talk about which RM-Reply patterns 
> support or disallow consumer payloads, when those payloads are 
> returned (carried over the wire).
> Your text seems to move further toward tying the WS-Reliability 
> protocol's use of the underlying transport to the producer / consumer 
> interface choices.  This seems to be heading in the wrong direction.
> thanx,
>     doug
> On 18-Jun-04 12:24, Tom Rutt wrote:
> ...

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

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