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