Re: Revised Asynch Binding

I agree with Sanjiva that this needs to be kept simple. Since Dave's 
analysis shows there is no conflict in using the same protocol URI (for 
soap/http) here, I like to propose that we take Paul's suggestion and 
accomplish this by adding the wsdl:async attribute on the 
binding/operation. The presence of this attribute with a value of "true" 
implies the operation supports async exchanges (default "false").
However, I do not think it makes sense to "fix" the reply address at the 
service level (asynclocation) as proposed by Dave, as we want this to be 
dynamic based on the specific client that is interacting with the 
service (EP). Hence I propose that we attach the following semantics 
when @wsdl:async=true on a binding/operation:

If the EP identified in the service/endpoint/@location is that 
references a binding (@binding) with the @async=true, it is declaring 
itself to be capable of asynchronous exchanges. However for the EP to 
respond asynchronously, the asyncLocation / replyTo address must be 
communicated by other means (WS-Addressing header or WS-MD header etc.).

Perhaps this can be added as an extension to <service> (or binding  or 
binding/operation?). E.g.
<service ... @EPRprotocol="xs:anyURI"? ...>

<definitions>
  <binding name="xs:NCName" interface="xs:QName"? type="xs:anyURI"
           wsoap:protocol="xs:anyURI"
           wsoap:mepDefault="xs:anyURI"? >
 
    <operation ref="xs:QName" 
               wsoap:mep="xs:anyURI"?
               wsoap:action="xs:anyURI"? 
	       wsdl:async="xs:boolean"
	       >
  
    <input messageLabel="xs:NCName"? >
    </input>*
    <output messageLabel="xs:NCName"? >

    </output>*
    </operation>
  </binding>

<service name="xs:NCName" interface="xs:QName" 
    <endpoint name="xs:NCName" binding="xs:QName" location="xs:anyURI" EPRprotocol="xs:anyURI"?>
    </endpoint>*
</service>*


Regards, Prasad

-------- Original Message --------
Subject: 	RE: Revised Asynch Binding
Resent-Date: 	Tue, 6 Jul 2004 13:19:34 -0400 (EDT)
Resent-From: 	www-ws-desc@w3.org
Date: 	Tue, 6 Jul 2004 10:15:30 -0700
From: 	David Orchard <dorchard@bea.com>
To: 	Sanjiva Weerawarana <sanjiva@watson.ibm.com>, <www-ws-desc@w3.org>


> -----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