Re: Revised Asynch Binding


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

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

> Cheers,
> Dave

Regards, Prasad

>     -----Original Message-----
>     From: Prasad Yendluri []
>     Sent: Wednesday, July 07, 2004 3:34 PM
>     To: David Orchard
>     Cc:; Sanjiva Weerawarana;
>     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
>     (
>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 []
>>         Sent: Wednesday, July 07, 2004 1:35 PM
>>         To:
>>         Cc: David Orchard; Sanjiva Weerawarana;
>>         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"? ...>
>>  <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>*
>>         Regards, Prasad
>>         -------- Original Message --------
>>         Subject: 	RE: Revised Asynch Binding
>>         Resent-Date: 	Tue, 6 Jul 2004 13:19:34 -0400 (EDT)
>>         Resent-From:
>>         Date: 	Tue, 6 Jul 2004 10:15:30 -0700
>>         From: 	David Orchard <>
>>         To: 	Sanjiva Weerawarana <>,
>>         <>
>>> -----Original Message-----
>>> From: []On
>>> Behalf Of Sanjiva Weerawarana
>>> Sent: Tuesday, July 06, 2004 8:49 AM
>>> To:
>>> 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
>>> 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:
>>> -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.

Received on Wednesday, 7 July 2004 19:37:40 UTC