MEPS Part II: SOAP

Following on to the previous proposal for WSDL MEPs, here is what I 
think we will need at the SOAP layer to make everything play together.  
This may also help clarify a couple of phrases in the previous proposal, 
namely " if the binding defines a default means of delivering outbound 
messages" and "there will have been enough information in the WSDL 
binding to detect the situation".  Again, this is largely a synthesis of 
ideas we've already discussed.  For me, the key point is that it looks 
like we really have identified all the pieces we need, and they can be 
made to fit together.

For the sake of concreteness and since most of the discussion has 
revolved around in-[out], I'll cast what follows in terms of three MEPs 
(in-only, in-[out] and the existing request-reply), but the same general 
approach would work with a single configurable "über MEP".  This 
approach is built around a fairly simple case analysis.  One of these 
cases will always hold:

    * The sender doesn't care what comes back directly to it.
    * The sender expects a return message under some circumstances, and
      needs to know either that such a message arrived or definitely
      won't arrive.
    * The sender expects a return message under all circumstances.

In all cases, even the first, there may be transport faults.

These three cases obviously correspond to in-only, in-[out] and 
request-reply respectively.  The first case is valid on /any/ messaging 
protocol.  The last two apply only when the messaging protocol is 
capable of sending return messages to the sender without the assistance 
of a [reply endpoint] MAP or similar device.  HTTP can support all three 
cases.  An email binding might or might not support all three depending 
on how it's defined.  A pure pub/sub protocol could only support the 
first.  In all cases, the binding definition will say what MEPs are 
supported, so a potential client can know ahead of time whether in-[out] 
and request-reply are available.

The obligations for the transport layer follow directly from these cases

    * In in-only, the transport is obligated only to send the message
      (or report a transport fault).
    * In in-[out], the transport is obligated to send the message and
      report whether a return message was sent (or report a transport fault)
    * In request-reply, the transport is obligated to send the message
      and deliver a return message (or report a transport fault).

Here is how the WSDL MEPs and related variations layer on top of the 
three SOAP MEPs:


      Request/Reply

    * If both [reply endpoint] and [fault endpoint] are defined (note
      1), use in-only.
    * Else if the binding in use only supports in-only, then [reply
      endpoint] and [fault endpoint] MUST be defined.  You just can't do
      request/reply over a fire-and-forget transport without saying
      where you want replies and faults to go.
    * Else if the binding in use supports in-[out] and request-reply, then
          o If exactly one of the two is defined (note 1, note 2), use
            in-[out].
          o If none is defined, use request-reply.

Note 1: I'm assuming no anonymous endpoints here.  If we allow these, 
then an anonymous reply or fault endpoint has the same effect as if the 
property were undefined.

Note 2: The "[fault endpoint] defaults to [reply  endpoint] if possible" 
rule can apply here if we want.  I left it out as it complicates the 
text but doesn't really change the picture.


      Robust In-Only

As before, this is just a reduced form of the request/reply case

    * If  [fault endpoint] is defined (note 1), use in-only.
    * Else if the binding in use only supports in-only, then  [fault
      endpoint] MUST be defined.  You just can't do robust in-only over
      a fire-and-forget transport without saying where you want faults
      to go.
    * Else if the binding in use supports request-reply and [fault
      endpoint] is not defined, use request-reply.


      In-only

    * Use in-only
    * And that's it


      Other patterns (e.g., request/reply/alternate,
      initial/normal/urgent etc.)

Again, the service advertising such a service can set any contract it 
likes and define whatever properties it likes.  However, the rules given 
above extend smoothly to other patterns, with the modifications shown in 
bold,  because the SOAP MEPs themselves don't look at the [* endpoint] 
properties.  Note that the previous rules fall out as special cases 
(including in-only, since the first condition is vacuously true).  :

    * If *all possible endpoints for further messages* are defined (note
      1), use in-only.
    * Else if the binding in use only supports in-only, then* all
      possible endpoints for further messages* MUST be defined.  You
      just can't do *such an interaction *over a fire-and-forget
      transport without saying where you want *further messages* to go.
    * Else if the binding in use supports in-[out] and request-reply, then
          o If *some but not all possible endpoints for further messages
            are defined *(note 1, *note 2 does not apply*), use in-[out].
          o If none is defined, use request-reply.