Re: Another possible decision for the tree

Perhaps I'm misunderstanding but this seems to be confusing the MEP  
and the binding of the MEP. A one-way MEP just has a SOAP message  
going in one direction, end-of-story. The binding of that MEP to a  
particular protocol might say something about other protocol-level  
messages (like a 202 HTTP response for the HTTP binding) but that  
doesn't need to be reflected in the SOAP MEP.

Marc.

On May 24, 2005, at 3:17 PM, David Hull wrote:

> >From recent pondering, there appear (to me) to be three different  
> ways to handle fire-and-forget one-way:
> 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.
> 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
> 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.
>

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

Received on Tuesday, 24 May 2005 21:28:54 UTC