Do we even need SOAP MEPs? (was Re: Another possible decision for the tree)

I'm less and less sure where any of this matters.  That's actually a
hopeful statement -- if it doesn't matter, no one has to specify it.

As far as async support goes, I can do async request-response and
variants if the endpoint I'm talking to understands WSA.  Beyond that, I
need to know if the binding supports a back-channel (aka anonymous).  If
not, I always have to give an explicit [reply endpoint].  If the
back-channel is involved, I want a way of knowing when I'm done with it,
which in some cases requires some form of "MEP complete" marker.  If
there is no such marker, I need to be sure that [reply endpoint] and
[fault endpoint] are either both anonymous or both not anonymous.

And that's it.  I don't see where I really need to say which SOAP MEP
I'm participating in, per se.  I send a message, the other endpoint
follows the rules, and I can always figure out what happened.

What I do need to know from the SOAP binding level is whether a
back-channel is available and what the "MEP complete" marker, if any,
looks like.  The current SOAP MEPs are, of course, silent on both.  One
way to cover this -- what's currently on the table -- is to define new
SOAP MEPs to cover the cases we've found, then map the WSDL MEP involved
and the combination of [* endpoint] headers into one of these MEPs, with
the SOAP binding saying whether the MEP we want is supported and (if
necessary) what any "MEP complete" marker looks like.

Another alternative would be for a binding simply to say whether it
supports a back channel, and if so, whether it provides a "MEP complete"
marker, and if so, what it looks like.  From this I can tell exactly
which combinations of WSA headers will work and what to expect when I
send a message.  Further, this will extend to any other variants we may
like to spin, without any possible need to concoct new SOAP MEPs for
them to map to.  For backward compatibility, bindings that provide a
back-channel should also define the request-response and response MEPs. 
Naturally, the HTTP binding already does this.

In this view, everything, including the current synchronous behavior,
really is built up from one-way messages like we say it is in section 3
of the core.  To some extent, we're just making explicit what's been
implicit all along -- there always has been a back-channel, but when
everything is synchronous there's no need to mention it explicitly.

It's also been bothering me for a while that we have the notion of MEPs
at two different levels, but they're really two different notions, with
a fair bit of impedance matching in between.  That's certainly been a
stumbling block when explaining our setup to others.  It seems cleaner
to talk about capabilities at the SOAP level and build MEPs out of them.

In terms of recommendations, we can still recommend that bindings must
at least be able to convey whether they have a back-channel and
optionally, how they signal that no message will arrive on a given
channel.  Whether we do this explicitly or indirectly through MEPs, it
still has to be done.

David Orchard wrote:

> You are right Umit, it's an HTTP Request-response binding, but more
> appropriately named a SOAP Request-Optional-Response HTTP Binding,
> where we use the adjective after the noun form of English (in keeping
> with soap response binding etc.).  
>
>  
>
> ------------------------------------------------------------------------
>
> *From:* Yalcinalp, Umit [mailto:umit.yalcinalp@sap.com]
> *Sent:* Tuesday, May 24, 2005 5:05 PM
> *To:* David Orchard; David Hull; public-ws-async-tf@w3.org
> *Subject:* RE: Another possible decision for the tree
>
>  
>
> 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.
>