RE: Another possible decision for the tree

You are right Umit, it's an HTTP Request-response binding, but more
appropriately named a SOAP Request-Optional-Response HTTP Binding, where
we use the adjective after the noun form of English (in keeping with
soap response binding etc.).  

 

  _____  

From: Yalcinalp, Umit [mailto:umit.yalcinalp@sap.com] 
Sent: Tuesday, May 24, 2005 5:05 PM
To: David Orchard; David Hull; public-ws-async-tf@w3.org
Subject: RE: Another possible decision for the tree

 

In SAP's opinion, we definitely need to define a SOAP Request/In MEP. 

 

I am not sure what you mean from an HTTP binding perspective whether
this would be a request-optional-response binding but rather
request-response binding where the response is always HTTP response with
2xx. 

 

--umit

 

	 

	
  _____  


	From: public-ws-async-tf-request@w3.org
[mailto:public-ws-async-tf-request@w3.org] On Behalf Of David Orchard
	Sent: Tuesday, May 24, 2005 3:12 PM
	To: David Hull; public-ws-async-tf@w3.org
	Subject: RE: Another possible decision for the tree

	1. I think is the right way to go.  That's why I proposed the
soap request mep.  I think this makes writing the binding easier.   One
could either create a new one-way binding, as I did, or create a new
request-optional-response binding.  The optional-response binding then
specifies behaviour for one-way or request-response meps.

	 

	Dave 

	 

	
  _____  


	From: public-ws-async-tf-request@w3.org
[mailto:public-ws-async-tf-request@w3.org] On Behalf Of David Hull
	Sent: Tuesday, May 24, 2005 12:17 PM
	To: public-ws-async-tf@w3.org
	Subject: Another possible decision for the tree

	 

	>From recent pondering, there appear (to me) to be three
different ways to handle fire-and-forget one-way:

	1.	Define a "SOAP request" MEP, analogous to "SOAP reply",
with the semantic that such a MEP is just the first part of the "SOAP
request-response" MEP, with behavior after delivery of the "request"
unspecified.  This reflects the idea that the sender doesn't care what
happens after it sends the message, and allows the receiver to do
whatever it likes, even close the connection.  The term "request" would
be a bit of a misnomer, given that a response will not always be
expected. 
	2.	Define a SOAP one-way MEP with the semantic that, if
there is a back-channel, the receiver MUST send some sort of empty
"marker" message 
	3.	Try to define SOAP one-way in terms of SOAP
request-response.  This would work for HTTP with a marker message, but I
don't see how it would work with a pure one-way binding.  Perhaps define
such a binding as always producing some sort of synthetic marker
response, but this seems backwards. 

	Right now, I'm split between (1) and (2).  Option 1 has a
certain symmetry to it, but I'm not sure whether the lack of constraint
is a bug or a feature.  If it's a bug, then option 2 is good.