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 16:59:18 -0700
Message-ID: <40EC8E56.8040006@webmethods.com>
To: David Orchard <dorchard@bea.com>
Cc: www-ws-desc@w3.org, Sanjiva Weerawarana <sanjiva@watson.ibm.com>, paul.downey@bt.com


David Orchard wrote:

> Comments inline, DBO> 
>  
> I think you have come around to my proposal, FWIW.

Reluctantly though :)  I am not totally convinced of the use cases that 
drive this. Esp. I like to see the @asyncLocation removed and 
@asyc="xs:boolean" added (wherever this extension goes).

Regards, Prasad

>  
> Cheers,
> Dave
>
>     -----Original Message-----
>     From: Prasad Yendluri [mailto:pyendluri@webmethods.com]
>     Sent: Wednesday, July 07, 2004 4:36 PM
>     To: David Orchard
>     Cc: www-ws-desc@w3.org; Sanjiva Weerawarana; paul.downey@bt.com
>     Subject: Re: Revised Asynch Binding
>
>     Dave,
>
>     Please see below in line..
>
>     David Orchard wrote:
>
>>     I had the asynchLocation listed as optional, in case for some
>>     reason the callback was fixed.  For example, Amazon.com might
>>     give out a WSDL that says it will make an asynch call into a
>>     supplier, and the supplier must always respond to a static address.
>
>     Thats good. It seemed it was made optional so that it is specified
>     only for the async case (named asyncLocation).
>
>>      
>>     By callback MEP, I do mean the output of an operation with asynch
>>     binding.  Why not support a static soap action on the output as
>>     well as the input?  I expect a very common scenario is that a
>>     service will specify these things statically, such as "getFoo"
>>     and then "getFooResponse".  I particularly like the idea of
>>     taking the wsa:action rules defined in the latest WS-Addressing
>>     spec and being able to use those for the callback MEP.  BTW, any
>>     argument for leaving out soap action on the output of an
>>     interface operation could also be applied to leaving it out on
>>     the input...
>
>     I consider things like SOAP Action to be receiver's preferences /
>     choices and it does not make sense from my perspective to fix
>     those in the binding from the server side, especially when there
>     are ways to communicate these dynamically. But I agree there would
>     be scenarios (such as the one you describe above), where this can
>     be fixed for all receivers (of the response). If that is desirable
>     then, perhaps the @async and all the other extensions should move
>     down to the operation/output level. That way it is clear the reply
>     (output) can come back asynchronously.    
>      
>     DBO> moving the extensions into the input (for the out-in case)
>     and the input (for the in-out case) is what I've proposed.
>
>>     And soap action it just one aspect.  The protocol is another. 
>>     Somebody could switch from SOAP over HTTP on the first MEP to
>>     SOAP over JMS or somesuch on the callback.  hence why I argue
>>     that the information that is carried in the binding operation
>>     must also be available for the callback MEP in the binding.
>
>     I see the point but I am not sure if this is a useful scenario to
>     tell all clients, I will receive messages SOAP/HTTP but I will
>     only reply via SOAP/JMS if it is async. If that is the case, I
>     guess the protocol property could be overridden at the
>     operation/output level. IMO for the most useful cases the protocol
>     won't change but the request and responses are asynchronous and
>     potentially to a different EP than the request originated from. 
>      
>     DBO> I agree that the most common cases will involve the protocol
>     remaining the same for the callback.  But I thought I heard at
>     least 1 request from the WG for that.
>
>>     Cheers,
>>     Dave
>
>     Regards, Prasad
>
>>         -----Original Message-----
>>         From: Prasad Yendluri [mailto:pyendluri@webmethods.com]
>>         Sent: Wednesday, July 07, 2004 3:34 PM
>>         To: David Orchard
>>         Cc: www-ws-desc@w3.org; Sanjiva Weerawarana; paul.downey@bt.com
>>         Subject: Re: Revised Asynch Binding
>>
>>         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 20:00:35 GMT

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