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: ;
Tel: +1 732 801 5744 Fax: +1 732 774 5133
