- From: Prasad Yendluri <pyendluri@webmethods.com>
- Date: Wed, 07 Jul 2004 16:59:18 -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: <40EC8E56.8040006@webmethods.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 UTC