RE: Revised Asynch Binding

> -----Original Message-----
> From: www-ws-desc-request@w3.org [mailto:www-ws-desc-request@w3.org]On
> Behalf Of Sanjiva Weerawarana
> Sent: Tuesday, July 06, 2004 8:49 AM
> To: www-ws-desc@w3.org
> Subject: Re: Revised Asynch Binding
> 
> 
> 
> Hi Dave,
> 
> Good discussion.
> 
> > I already argued the point about SOAP HTTP binding of interface
> > operations.  How is my or even Paul's proposed use of asynch
> > violating the XMLP defined SOAP HTTP binding?  That binding roughly
> > says that the HTTP request and response contain a SOAP body.
> 
> I just read section 7 of SOAP 1.2 part 2 and to me it says pretty
> clearly that the HTTP request carries the request message of the
> SOAP request-response MEP and and the *response to that request*
> contains the response message of the SOAP request-response MEP.
> 
> (See http://www.w3.org/TR/2003/REC-soap12-part2-20030624/#soapinhttp)
> 
> Can one of the XMLPers please confirm or deny that statement please?)
> 
> If that is true, we CANNOT claim to use the SOAP-HTTP protocol
> binding defined by XMLP and use WS-Addressing ReplyTo or other such
> mechanism to do an asynch call.

Ah, but you haven't seen the legal maven DaveO in action.

I would argue that in the case of 2 separate http operations, we can be quite creative
in the interpretation of the word "that" in "that request".  If I have a protocol trace of
->Request #1 (wsdl operation input)
<-Response #1 (200/empty)
<-Request #2 (wsdl operation output)
->Response #2 (200/empty)

I feel completely comfortable in saying that both of the 200/empties are
responses to the respective request.  That is the 200/empty is the
*response to the request*.  We have layered *gasp* an abstraction on top
that isn't seen by the underlying protocol, and the underlying protocol
doesn't need to care.

Remember soap/http binding just says what goes on the wire.  The interpretation of that
is up to us.

> 
> > It says nothing about how a WSDL operation is sent on the wire.
> > In particular, it does NOT say that a wsdl operation response must
> > come over the HTTP response.
> 
> That's right- it talks about the SOAP request-response MEP (and the
> SOAP response MEP). However, in our binding we say that we map an
> in-out WSDL MEP to a request-response SOAP MEP (see the default
> rules:
> http://dev.w3.org/cvsweb/~checkout~/2002/ws/desc/wsdl20/wsdl20
> -bindings.html#soap-defaults).
> So, if a WSDL in-out MEP is in use and
> the default SOAP MEP value is used then you cannot do asynch with the
> @protocol value pointing to the XMLP defined SOAP-HTTP protocol
> binding.

And I'm arguing that we can validly say that we map an in-out WSDL MEP to either:
- a single http operation request-response SOAP-MEP (default)
- a double http operation of 2 request-response SOAP-MEPs.

> 
> > I find it ironic that people keep
> > talking about interfaces being abstract, but then they almost
> > invariably think that an interface operation binds directly to
> > a protocol operation.
> 
> I certainly don't think so.
> 
> > My proposal takes 1 interface operation
> > and maps it to 2 HTTP protocol operations.
> 
> That's precisely what mine does too! Obviously I haven't explained
> it properly: it replaces the XMLP-defined binding of the SOAP
> request-response MEP to HTTP with one that uses two HTTPs, with
> the URL of the 2nd being somehow specified in the first (via ReplyTo,
> for example).

> 
> > Your proposal removes the ability for the WSDL to specify the
> > soap information for the callback, such as soap action, in the
> > binding of the interface operation.
> 
> Not at all! One can specify the SOAP Action for the output message
> and it'll work just great. We currently specify SOAP action at
> the operation level, which is by itself a problem .. see 
> WS-Addressing's
> <Action> gizmo for example .. it uses different actions for the
> request and response messages. Paul's message described a scenario
> which motivates that.
> 
> (Which again reminds me that I want to propose a solution for the
> "operation name" problem to address that too.)
> 
> > In your proposal, I have to have 2 interface operations to do
> > the callback, whereas mine allows for a single interface operation.
> 
> Absolutely not - my proposal allows a single WSDL operation using
> the WSDL in-out MEP to be bound to two HTTPs to enable the asynch
> behaviour we are looking for.
>  

Can you show me how your proposal would do this?  I'm not seeing it...

My proposal uses the binding output to allow the adornment of the 2nd soap request/response mep.  I don't see where yours would allow this data.

Cheers,
Dave

Received on Tuesday, 6 July 2004 13:19:23 UTC