WSA use cases and MEPs

In lieu of a detailed response to Dave's uber-MEP proposal (which I plan
to do but which will take longer), here is a relevant use case from WSA
along with a proposal for treating it in terms of the existing SOAP
request-response MEP and the proposed SOAP one-way MEP.

The use case will be familiar to anyone who has followed the discussion
of the Async TF.  It appears to be something of a worst case; a
framework that can handle it cleanly can handle a fairly wide range of
other useful cases as well.  In fact, I'm not presently aware of any
useful cases that could not be handled by such a framework.

The use case is that of an in-out operation with WS-Addressing engaged. 
The address of the endpoint is a normal HTTP URL.  The [fault endpoint]
of the inbound message has the anonymous address, while the [reply
endpoint] is an EPR with an [address] other than the anonymous (or
"none") address defined in WSA.  Further, this address should be one for
a transport that only natively supports one-way messaging (e.g., UDP,
some various forms of pub-sub, or an email binding which doesn't try to
define request-response directly.  For simplicity, we generally call
such a beast the "mythical one-way transport")

In English, this means that the sender of the inbound message (the
"client") would like faults to be returned directly on the HTTP response
channel, but in the normal case, replies should be sent one-way to the
[reply endpoint] address.  (It actually doesn't matter for our purposes
here which of [reply endpoint] and [fault endpoint] is anonymous and
which isn't.  This particular setup seems a bit more realistic than the
other way around).

I've asserted that the reply address should use a one-way transport in
order to explicitly mention that there are plausibly transports for
which it makes most sense only to define a one-way exchange, and leave
correlation and such to WSA.

Probably the trickiest bit here is that we don't know whether anything
significant needs to come back over the HTTP response channel until the
service has completed enough of the operation to know whether it is
generating a fault or a normal reply.  As I understand it, this is
exactly the inspiration for the various "optional response" approaches.

Elsewhere, I've proposed [1] and somewhat refined [2] a set of rules by
which WSDL 2.0 MEPs map to SOAP MEPs.  These rules treat the particular
operation above in one of two ways, depending on the result of the
operation:

    * If there is a fault (more generally, if the response is sent to an
      anonymous address) then the operation is realized as a single
      instance of the SOAP request-response MEP.
    * If there is a normal reply (more generally, if the response is
      sent to a non-anonymous address) then the operation is realized as
      an instance of the one-way SOAP MEP, from the client to the
      service, together with a separate instance of the one-way MEP from
      the service to the reply destination.

To make this work, any transport for which both request-response and
one-way are defined must define the two MEPs compatibly, in that the
inbound message is handled identically in either case and it is possible
for the sender to determine which case actually occurred.  In the case
of SOAP/HTTP, this is easily done by defining a one-way message as a
normal SOAP request message together with an empty 202 response.

Putting this together, the exchange above would be either

    * A POST with the SOAP request and a fault response in the usual manner
    * A POST with the SOAP request and an empty 202 response, together
      with a one-way reply realized appropriately for the transport of
      the [reply endpoint] address.

IMO, /every/ transport should define a binding for the one-way MEP. 
This allows for easy, direct handling of true one-way messaging (e.g.,
Notification/Eventing), and if a transport can't handle the simple case
of moving a SOAP envelope from point A to point B, something's broken. 
In the case of HTTP, this would mean officially blessing the "empty 202"
convention or something equivalent.

Further, /some/ transports, namely those that provide request-response
semantics natively in a standard way, should define bindings for the
request-response MEP.  This naturally includes HTTP, and probably
includes email, at least in a profile where a from: address is mandatory
(at this point there are open questions as to how best to coordinate
email headers with their equivalent WSA MAPs).

A sender SHOULD NOT use the anonymous address for a response endpoint
when sending over a transport that does not support the SOAP
request-response MEP.  The anonymous address is really only well-defined
in the context of request-response.  The proposed rules make this
connection explicit (though as written they don't explicitly prohibit
such use).

[1]
http://lists.w3.org/Archives/Public/public-ws-addressing/2005Nov/0051.html
[2]
http://lists.w3.org/Archives/Public/public-ws-addressing/2005Nov/0093.html