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.