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

RE: Another possible decision for the tree

From: Yalcinalp, Umit <umit.yalcinalp@sap.com>
Date: Wed, 25 May 2005 02:05:11 +0200
Message-ID: <2BA6015847F82645A9BB31C7F9D64165092761@uspale20.pal.sap.corp>
To: "David Orchard" <dorchard@bea.com>, "David Hull" <dmh@tibco.com>, <public-ws-async-tf@w3.org>
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.
Received on Wednesday, 25 May 2005 00:06:49 GMT

This archive was generated by hypermail 2.2.0 + w3c-0.30 : Wednesday, 25 May 2005 00:06:49 GMT