Subject: RE: [wsrm] Contribution taking away one-way restriction on Callback and Poll
I believe our latest requirements document required Callback and Poll to accommodate both One-way and Request-response MEPs (see wsrm-reqm-issues-2004-01-15.xml:
1. Agree to have requirement for Spec having a solution for response Ack binding pattern, for both one way and request/response MEP<br />
2. Agree to have requirement for Spec having a solution for Callback Ack binding pattern, for both one way and request/response MEP<br />
3. Add new requirment for spec having a solution for sender to recieve delayed Acks when it is not willing to recieve underlying protocol requests, for one way MEP
Proposals 1 and 2 accepted<br />
Proposal 3 accepted
>If we are going to support any
>underlying protocol and any binding, we need to describe what the Sending
>RMP (or, for the asynchronous poll and callback patterns, the Receiving
>RMP) can expect to be returned.
I have discussed this with our implementor (Hamid), and we concur on the following:
The only requirement, as far as the sender RMP is concerned, is that when sending a reliable message with
"Callback" (or "Poll") reply pattern, the sender RMP must never
get an RM Response header on the underlying protocol response leg (HTTP response in our example)
A Receiving RMP , when receiving a message with RM Request header containing Callback or Poll,
does not have to analyze which SOAP MEP is being used for processing RM requirements,
This is valid for both SOAP One-way or SOAP Request-response, and does not mandate a different
handling of these from the RMP.
So all what the sending RMP is expecting - in case of Callback reply pattern - is
an RM Reply arriving on a different MEP request coming from Receiver.
>I know of no way to even describe to a
>standard SOAP processor a situation in which a SOAP message may or may not
>result in a SOAP Envelope in the underlying response.
This is a surprising argument:
A Sending RMP is not required again to distinguish HTTP requests carrying a Callback RM Request,
based on whether they will/should have an empty response or not.
Enforcing the use of One-way only, would precisely require making this distinction at the Sending RMP level !
The use of SOAP MEPs, is determined by the application contracts, and in most deployment scenarios,
an RMP implementation is unaware of which one is used (except for RMP-specific signals).
Receiving a unexpected SOAP envelope on an HTTP response, is precisely something that
BP 1.0 requires to detect, and would be detectable at run-time by a WS stack implementing
the WSDL binding.
E.g. Axis 1.2 is BP 1.0 compliant (and will not generate a response on Receiver side for One-way
calls,) while Axis 1.1 is not.
Overall, we do not think there are complications with:
- supporting the definitions of Callback / Poll as they were initially in Section 2,
- authorizing an HTTP binding that accepts SOAP envelopes on the HTTP response.
Jacques & Hamid
From: Doug Bunting [mailto:Doug.Bunting@sun.com]
Sent: Sunday, August 15, 2004 7:28 PM
Subject: Re: [wsrm] Contribution taking away one-way restriction on
Callback and Poll
On 15-Aug-04 09:39, Tom Rutt wrote:
> Due to the issue raised by Jacques in his email, I did not initiate the
> Kavi CD ballot on draft 1.85
> To facillitate discussion and, possibly, voting on a CD at our next
> Teleconference, I just posted a contribution which removes the
> restriction (and fixes a typo)
> Based on Jacques email, I produced a version which takes away the
> restriction of using call back and poll with only one-way mep. I also
> corrected a typo. I just posted the revision as contribution:
> Requirement R3.7 states:
> *R3.7 *The Specification must support the Polling RM-Reply Pattern for
> WSDL 1.1 Request-Reply
> While there is no corresponding requirement for Callback Reply pattern,
> it was allowed in all prior CDs we have voted on. Since the protocol
> will work with callback reply pattern with request-reply operations,
> there is no reason for the restriction at this late time in the
> progression of this specification.
> The restrictions pointed out by Jacques, in section 6, have been there
> since CD .992 and earlier, however they are pertinent only for the
> one-way example, as shown in the figures. These had to be clarified as
> pertaining to one-way.
With the restrictions in Section 6 in place, we had two possible ways
forward: (1) support those restrictions with general constraints earlier in
the document, as I did and as the group apparently supported me in doing;
or (2) write a new HTTP Binding that (somehow) provides an indication to
the SOAP processor about whether or not it should expect a SOAP Envelope in
the underlying response for every SOAP message initiated in what *might be*
a request-response situation. You have chosen a version of route (2) but
have only relaxed the restrictions without providing any information to
fill the gaps now open.
The restrictions in Section 6 have existed since that section was first
written, long before .992. They have never before been constrained to only
the one-way model. You are creating a new protocol and have not filled in
the gaps in that protocol when an RMP (seemingly at its whim) makes use of
an underlying request-response binding. If we are going to support any
underlying protocol and any binding, we need to describe what the Sending
RMP (or, for the asynchronous poll and callback patterns, the Receiving
RMP) can expect to be returned. I know of no way to even describe to a
standard SOAP processor a situation in which a SOAP message may or may not
result in a SOAP Envelope in the underlying response.
> The following changes were made, against draft 1.085
> , to take away restrictions on use of callback and poll only with
> one-way mep.
> Page: 11
> Sequence number: 1
> Type: Typographic error
> line 336 - "between between"
Thanks for catching this.
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.