- From: Prasad Yendluri <pyendluri@webmethods.com>
- Date: Wed, 07 Jul 2004 16:36:00 -0700
- To: David Orchard <dorchard@bea.com>
- Cc: www-ws-desc@w3.org, Sanjiva Weerawarana <sanjiva@watson.ibm.com>, paul.downey@bt.com
- Message-ID: <40EC88E0.9010105@webmethods.com>
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. > 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 [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 19:37:40 UTC