- From: Sanjiva Weerawarana <sanjiva@watson.ibm.com>
- Date: Thu, 8 Jul 2004 19:27:17 +0600
- To: <www-ws-desc@w3.org>
I sent this earlier today but it doesn't seem to have made it to the list for some reason. Sanjiva. ----- Original Message ----- From: "Sanjiva Weerawarana" <sanjiva@watson.ibm.com> To: <www-ws-desc@w3.org> Sent: Thursday, July 08, 2004 6:31 AM Subject: Re: Revised Asynch Binding Hi Dave, > Ah, but you haven't seen the legal maven DaveO in action. This looks a bit too slick willy to me ;-). > 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. I don't think so! Glen/JJM/Gudge/Jack/<any other XMLPers>: What do you think? > 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 understand your proposal .. but I think its unnecessarily complex. There's nothing whatsoever wrong with mapping our MEP to a single SOAP MEP. The problem w.r.t. enabling asynch is how that SOAP MEP is being mapped to HTTP operations. Thta's what my proposal addresses. > > 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. See that's where we differ. I don't need *two* SOAP MEPs. I still want to use one SOAP MEP and bind it to two distinct HTTP operations. Let me try to explain it again. Consider a WSDL operation foo: <operation name="foo"> <input element="x:foo-in"/> <output element="x:foo-out"/> </operation> We bind this to a *single* SOAP request-response MEP, but not using the XMLP defined SOAP-HTTP binding. Let's first consider an SMTP binding of this: - the endpoint/@address would be where the message with payload x:foo-in should be sent to - where the reply should be sent will be indicated to the service using the ReplyTo: SMTP header - service sends the message containing the x:foo-out payload to that address - receiving email server correlates the message with the outgoing message and completes the WSDL in-out MEP Now, consider an HTTP binding: - the originator of the foo operation will do an HTTP POST of the foo-in element to endpoint/@address, along with something like WS-Addressing's <ReplyTo> element to indicate where the reply POST should go. - service responds with 201 OK (or 200 OK / content=0) (time elapses) - service does an HTTP POST to the ReplyTo address with the response SOAP envelope - receiving HTTP server responds with 201 OK - receiving HTTP server correlates the message with the outgoing message and completes the WSDL in-out MEP This is much simpler, and cleaner, than using two SOAP-MEPs for one WSDL MEP. I don't see why that makes sense at all. Sanjiva.
Received on Thursday, 8 July 2004 09:27:56 UTC