RE: Revised Asynch Binding

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

-----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  <mailto:dorchard@bea.com> <dorchard@bea.com>	
To: 	Sanjiva Weerawarana  <mailto:sanjiva@watson.ibm.com> <sanjiva@watson.ibm.com>,  <mailto:www-ws-desc@w3.org> <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 <http://dev.w3.org/cvsweb/%7Echeckout%7E/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