W3C home > Mailing lists > Public > public-ws-async-tf@w3.org > March 2005

RE: In-optional out

From: David Orchard <dorchard@bea.com>
Date: Tue, 29 Mar 2005 14:12:40 -0800
Message-ID: <32D5845A745BFB429CBDBADA57CD41AF0E90A002@ussjex01.amer.bea.com>
To: "David Hull" <dmh@tibco.com>, "Yalcinalp, Umit" <umit.yalcinalp@sap.com>
Cc: "Marc Hadley" <Marc.Hadley@Sun.COM>, <public-ws-async-tf@w3.org>
It seems to me that the binding of a one-way onto the connection-oriented HTTP protocol causes the side-effect that the one-way sender can have some knowledge about the connection.  If the one-way was over a true connectionless protocol, it would have no way of knowing whether it was OK or not, ie 202 or 4xx.  A central question is: does this "extra knowledge" that HTTP offers leak into the application or not?  If it does, then a one-way message might actually get a fault, if say a 400 was returned.  I have a feeling that nobody would deploy a true one-way over HTTP, they would deploy the robust variation that allows the fault.  We could say something along the lines of "If binding to a connection oriented protocol, then you may want to use the robust variation for the protocol response code".  And then if somebody does truly deploy a one-way over HTTP, then a 4xx fault return code gets dropped on the floor as the app won't be expecting it.

 

FWIW, this is yet another problem of all these different abstraction layers and then trying to compose them together in a meaningful way in the real application.

 

Then there is the 2nd issue, which is that given a 202 back, how does the SOAP sender "know" that there may be a body in the HTTP response?  Again, this depends upon the mep in action.  If it's a one-way only, then close the connection after the 202.  If it's a robust or in-out, then sit in "receiving" mode until some content shows up, a content-length shows up, or the connection is closed.

 

Cheers,

Dave

 

  _____  

From: public-ws-async-tf-request@w3.org [mailto:public-ws-async-tf-request@w3.org] On Behalf Of David Hull
Sent: Tuesday, March 29, 2005 1:55 PM
To: Yalcinalp, Umit
Cc: Marc Hadley; public-ws-async-tf@w3.org
Subject: Re: In-optional out

 

Yalcinalp, Umit wrote: 

The response at the HTTP transport is just a side effect of using the http protocol (202). It is an HTTP response, not SOAP response for one way messages. Wrt SOAP MEP perspective, this is not an ACK per se for SOAP protocol, but for http transport since there is no SOAP response message. Hence, I don't think we should bring the side effect of the transport with an explicit ACK at the SOAP layer. 
  

The question then is, how do you know when you're done?

If you get an explicit 202 back, you know you're not going to get an actual message on the back-channel.  Do we try to capture that at the SOAP level?  Whatever we choose to call it, how would the SOAP level distinguish "in, no out" from "in, no out yet"?



 
--umit
 
 
-----Original Message-----
From: public-ws-async-tf-request@w3.org [mailto:public-ws-async-tf-request@w3.org] 
Sent: Tuesday, Mar 29, 2005 12:33 PM
To: Marc Hadley
Cc: public-ws-async-tf@w3.org
Subject: Re: In-optional out
 
 
Marc Hadley wrote:
 
  

	On Mar 29, 2005, at 1:51 PM, David Hull wrote:
	 
	    

		 Marc Hadley wrote:
		 This is all a bit confusing. SOAP doesn't define anything like an 
		ACK, that's an application level construct (assuming its a SOAP 
		message) so the in-(out|ACK) MEP is just a SOAP in-out (or 
		request/response).
		 
		 My understanding was that, if there were no explicit reply, you 
		would still want to get back an empty (i.e., non-SOAP) message with a 
		202 code.  This is distinct from, e.g.,  the receiver simply closing 
		the connection.  Thus the (possible) need to introduce the notion of 
		an ACK at the SOAP level.
		 
		      

	I think my confusion here stems from the fact that SOAP MEPs only talk 
	about exchanging SOAP messages not underlying protocol exchanges 
	(that's where the binding comes in) so if the ACK is purely at the 
	underlying protocol level then it won't show up as part of the SOAP MEP.
	    

 
The question then is whether it is enough to model POST in/202 out as 
in-[out] with no out, or whether the SOAP layer needs to report that 
/something/ happened.  If it needs to report that something happened, 
then it can't very well report a SOAP message arrived, and we (or 
someone :-) will have to create some new construct -- which I'm calling 
an ACK -- to describe what happened.
 
  

	 
	Marc.
	 
	    

		 This would not be an application-level construct.  The application 
		may well view things differently.  For example, it might consider 
		sending the request and getting back a reply or fault as separate 
		events.
		 
		 E.g.
		 
		 
		 
		App View
		 
		SOAP View
		 
		 
		App sends request, reply-to: a callback, fault-to: the back channel
		 
		Sender sends the inbound message of an in-[out]
		 
		 
		(normal processing) App gets reply on callback
		 
		Receiver sends back ACK.  And that's it (sending back the reply is a 
		separate interaction)
		 
		 
		(fault processing) App gets a fault
		 
		Receiver sends back a message (and that's it).
		 
		 
		 
		 
		 
		 Marc.
		 
		 On Mar 29, 2005, at 12:46 PM, David Hull wrote:
		 
		 
		  I've just read over the minutes from last week, and I'm doubly 
		sorry I missed the discussion.  I'd also like to thank Jonathan for 
		the clear and thorough minutes.
		 
		  When I first heard of an in-[out] (or even [in]-[out]) "über MEP", 
		it seemed like it was trying to generalize any possible MEP.  An 
		in-only would be treated as [in]-[out] with an in and no out, and so 
		forth.
		 
		  This seemed like a bad idea.  It wouldn't actually cover all 
		possible MEPs, but it would add a layer of complexity to in-only or 
		even in-out ("in-out is [in]-[out] with both in and out present" as 
		opposed to "in-out is in-out").  Thence the George Carlin quote about 
		volleyball being team ping-pong with a raised net etc.
		 
		  Reading through the minutes, though, in-[out] looks to be more 
		narrowly focused on an important fact of life: In some scenarios you 
		can't tell in advance whether you will get an application-level reply 
		on the back-channel.  For example, if the normal course of action 
		were to send messages on to the "approval" and "logging" endpoints 
		given in the message addressing properties, while a fault should come 
		back on the back-channel, you would have to find out dynamically 
		which alternative was actually in effect.  I suppose the 
		request/reply case with the one of the two endpoints directed to the 
		back-channel and the other directed elsewhere would also be an example.
		 
		  In such cases, the in-[out] pattern captures the fact that you 
		might get back a message on the back-channel, or you might just get 
		back an ACK.  It doesn't quite capture the possibility of getting 
		more than one message back on the back-channel (e.g., two or more 
		non-mutually-exclusive endpoints both pointed at the back-channel), 
		but perhaps it could be expanded to cover that, too.  It might also 
		be better to describe the pattern as "in-(out|ACK)", emphasizing that 
		something always comes back (if that's what we mean).
		 
		  As a side-effect, we could also model a one-way WSDL MEP as an 
		in-[out] with just an ACK coming back.
		 
		  This is all described at the SOAP level, without reference to HTTP 
		or any other physical binding, which is why I say "ACK" instead of 
		"202".  It's up to the binding to say what form the ACK takes.
		 
		  With this in place, as I understand it:
		 
		     *     a in-only message would manifest as in-[out] with just an 
		ACK in reply
		 
		     *     existing synchronous request/reply still manifests as 
		request/reply
		     *     asynchronous request/reply manifests as in-[out]
		  Is this all roughly correct?
		 
		 
		 
		 
		 
		 
		 ---
		 Marc Hadley <marc.hadley at sun.com>
		 Business Alliances, CTO Office, Sun Microsystems.
		 
		 
		 
		 
		      

	---
	Marc Hadley <marc.hadley at sun.com>
	Business Alliances, CTO Office, Sun Microsystems.
	 
	    

 
 
  

 
Received on Tuesday, 29 March 2005 22:12:55 GMT

This archive was generated by hypermail 2.2.0 + w3c-0.30 : Tuesday, 29 March 2005 22:12:56 GMT