Re: Another possible decision for the tree

Marc Hadley wrote:

> 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.

I'm only 90% sure of that.  It's certainly true for a pure one-way
binding.  The other 10% is the idea that, in /any/ binding (not just
HTTP) that can produce a response, the binding must specify a standard
"MEP complete" marker.  Naturally, the particular HTTP spelling of this
marker (202, 204, whatever) would be peculiar to HTTP, but the idea that
the receiver must explicitly "hang up the phone" if able when receiving
a one-way message would be generic to the SOAP MEP.

Again, I'm leaning fairly strongly away from such a requirement, but I
don't think it can be rejected out of hand, particularly if such a "MEP
complete" marker makes sense in other contexts as well.

>
> 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.
>
>
>