W3C home > Mailing lists > Public > www-ws-desc@w3.org > July 2004

Re: Revised Asynch Binding

From: Prasad Yendluri <pyendluri@webmethods.com>
Date: Wed, 07 Jul 2004 15:34:21 -0700
Message-ID: <40EC7A6D.9040509@webmethods.com>
To: David Orchard <dorchard@bea.com>
Cc: www-ws-desc@w3.org, Sanjiva Weerawarana <sanjiva@watson.ibm.com>, paul.downey@bt.com
Hi Dave,

David Orchard wrote:

> Prasad,
>  
> I never said that the reply address had to be fixed.  I fully expect 
> it to be dynamic.

I based my comment on the following in your proposal 
(http://lists.w3.org/Archives/Public/www-ws-desc/2004Jun/0287.html):

The endpoint has an additional optional asynch address attribute.  This attribute specifies a location of the 2nd message if the interface operation is bound to 2 protocol messages.  

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

If that was not the intent we are in agreement.

> And you don't answer the same question I asked of Sanjiva: How are the 
> soap binding components set in the callback mep?  You don't answer how 
> soap action is set on the 2nd soap req/resp mep for example.  This 
> ought to be done in the binding.

By callback MEP I take you mean output of an operation (?) with async 
binding. I agree things like soap action need to be accommodated. This 
should perhaps be dynamic and handled at the EPR Spec (WS-Addressing) 
level as well, like <wsa:Action> under <wsa:ReplyTo>?
Supplied with the reply only if present?

Regards, Prasad

> Cheers,
> Dave
>
>     -----Original Message-----
>     From: Prasad Yendluri [mailto:pyendluri@webmethods.com]
>     Sent: Wednesday, July 07, 2004 1:35 PM
>     To: www-ws-desc@w3.org
>     Cc: David Orchard; Sanjiva Weerawarana; paul.downey@bt.com
>     Subject: 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
>
>
Received on Wednesday, 7 July 2004 18:36:00 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 7 December 2009 10:58:32 GMT