XMLP, async etc.

As I slowly start to swap back in from my vacation -- during which I was
completely offline for longer than I've been in years -- I've started
thinking about async SOAP, re-chartered XMLP, our decision tree/matrix,
and various and sundry.  Before I got too far back into the details, I
wanted to take a relatively fresh look at the overall picture.  For
whatever it might be worth, here's what I'm thinking at the moment.

    * We need a SOAP one-way MEP (OK, so that's not exactly earthshaking)
    * The semantics of this should be very simple:
          o The sender sends a message to the receiver
          o The receiver MAY receive the message
          o The sender MAY learn that the message definitely arrived, or
            that it definitely didn't, or it may learn nothing
    * Even the last point looks a little heavy.  Probably the MEP
      definition should make no statement about what the sender might
      learn.  In any case, actual mechanisms for the sender to find out
      what happened are definitely out of scope.
    * There should be bindings of SOAP one-way to each half of an HTTP
      request/response, that is, SOAP one-way over HTTP request, and
      SOAP one-way over HTTP response.  This would enable some of the
      variants we've discussed, including but not limited to the
      cell-phone-pulling-requests scenario.
    * Optionally, the existing SOAP request-reply could be recast as two
      one-way MEPs, one over the request and one over the response. 
      This would make the existing request/response a special case of
      the general request/response (level-other-than-SOAP) MEP.  The
      exact factoring would be to separate the distributed state machine
      description from the transport of the incoming and outgoing messages.
    * There would still be the issue of ACK messages.  As I see it,
      there are two approaches, which  might each be correct depending
      on the context.
          o A (level-other-than-SOAP -- "LOTS"?) request/response
            consists of a SOAP request/response, plus an optional SOAP
            one-way.  The SOAP response may be an ACK message.
          o A one-way MEP over HTTP request (or similar request/response
            oriented transports) MUST produce either a response (reply
            or fault) or an ACK.  I'm liking this better.  I've argued
            that this doesn't allow for, say, [message id] in ACKs, but
            see the next item.
    * It would be really cool if we could layer SOAP over SOAP.

That last requires a bit of detailed explanation (meaning that my
vacation is now officially over :-)

Suppose I want to be able to send a stream of notification messages with
security and reliability each handed at the SOAP level (WSS and
WSRmumble), the transport level (SSL/TCP/whatever) or not at all.  The
nine possible combinations look pretty much the same to the application
logic.  What I'm grasping at here is a binding of the one-way MEP to
another SOAP one-way MEP such that arbitrary SOAP processing can take
place between the layers. E.g.,

   1. The sender's application logic produces a SOAP message to be sent.
   2. This SOAP message has sequence numbers etc. added, gets encrypted
      and signed, and is resent if needed.  Or it may be batched with
      other SOAP messages, or whatever, depending on what the deployment
      needs and what the transport binding supplies.
   3. Whatever SOAP messages result from step 2 are sent over some
      binding of the one-way SOAP MEP.
   4. Messages received are decrypted, signature verified, acked,
      unbatched, etc.
   5. The receiver's application logic receives messages.

The point is that steps 1 and 5 together look like a SOAP one-way MEP,
and step 3 looks like a SOAP one-way MEP.  In the general case, though,
there may be no simple relationship between them.  Steps 2 and 4 may
batch messages, retransmit, or both.  Nonetheless, we can specify the
relationship between the two levels, and we ought to be able to layer
that relationship by composing, say, reliability, batching and security.

Steps 2 and 4 smell quite a bit like intermediary processing, and they
may be, but intermediaries alone don't capture linkages like the need to
decrypt what you encrypt and so forth.  It would be nice to say
something like "The WSS binding of the SOAP one-way MEP sends a message
by encrypting it, signing it, attaching wsse: header information, and
sending it via another binding of the SOAP one-way MEP. It receives
messages by receiving them from another binding of the SOAP one-way MEP,
verifying and decrypting."

One use case driving this looks something like this:

    * A cell phone makes an HTTP request to an HTTP server.
    * Back comes a SOAP message HTTP response, encrypted, signed and
      carrying the appropriate WSS tokens.
    * Inside the body of the SOAP message is a series of request
      messages, each in the form of a SOAP envelope.
    * The cell phone processes the requests.
    * At some point, it has some, but perhaps not all, of the responses
      ready.
    * It batches up those responses into a SOAP body, signs, encrypts
      and attaches security tokens.
    * It sends the result to the server as an HTTP request.  (Actually,
      this might also include some request messages for the HTTP server,
      and/or one-way messages.  Similarly, the original HTTP request
      might have contained one-way messages.)
    * The server decrypts, verifies and unbatches the responses, most
      likely using [message id] to correlate them with their requests.
    * The server batches up zero or more further requests, encrypts,
      signs, etc.
    * And so forth.

What we have here are two separate SOAP message flows.  There is an
application level flow of (parenthetical comment aside) requests to and
responses from the cell phone.  There is also a SOAP message flow of
HTTP requests and responses.  The two are completely independent in both
direction and number.  The application level flow is asynchronous and is
best seen as a composition of one-way messages, one for each request and
for each response.  The transport-level flow may or may not be a
sensible example of the SOAP request/response MEP.  In either case, it
can also be seen as a series of one-way messages.

I believe that the approach I outlined above is flexible enough to cover
such a case.  If so, I'm quite confident it's flexible enough to cover a
large array of scenarios we haven't even thought of yet.  I'm also
convinced that the existing MEP framework will not handle a case like
the above easily, even in the case where the application-level flow is
purely request/response.