Markers and SOAP headers

In most of our discussion, we've been assuming that an HTTP server
should return some form of 2xx message without a SOAP body in cases
where the actual response is being sent elsewhere.  I believe this will
work much of the time, but I'm now more convinced it won't work in all
cases.  For the sake of concreteness, assume the MEP in question is
robust in-only and the [fault endpoint] has an anonymous [address]
component.  Then a 2xx message is insufficient if

    * Traffic is meant to be secured.  In this case, the empty 2xx
      marker reveals information (namely that there was no fault), while
      an encrypted SOAP message response doesn't.
    * A reliability mechanism is in use.  In this case, the response
      needs to carry the usual sequence number headers.  It's a little
      difficult defining the exact circumstances where this matters, but
      it would generally be in the context of a series of operations
      done in a single reliability context.  I believe the cases to
      distinguish are
         1. The server fell over before sending back the marker message.
         2. The server thinks it sent back a marker message, but the
            back-channel was cut off before it could arrive.
    * (previously mentioned) The underlying transport provides a back
      channel but no mechanism for correlation (and the client cares
      about correlation).  In this case, the client needs to know which
      request the marker message pertains to.
    * (maybe) The [fault endpoint] had a non empty [reference
      parameters] along with the anonymous [address].  There is actually
      a modeling question here, namely whether the marker message is
      coming back on the transport's back-channel, or whether it is
      addressed to the [fault endpoint].  This can be argued either
      way.  Hopefully we can decide based on other factors.

This doesn't mean we can't use 2xx responses in the common case.  We
just have to define that as a transport-level optimization of a SOAP
marker message with no special headers.

Received on Thursday, 9 June 2005 14:30:18 UTC