It's a wide world out there ...

I'm realizing, belatedly, that the discussion of async here has been 
somewhat limited to the realm of request/reply, with some attention paid 
to a simple fire-and-forget one-way message.  I'd like to expand the 
discourse a bit and talk about async messaging in general as I see it.  
My thesis, which should surprise no one by now, is that this universe is 
strictly bigger than request/reply and simple one-way, but looks to be 
covered by the concepts of one-way messaging, message ID, message 
correlation and subsequent destinations -- which IMHO WSA is meant to 
account for, comes very close to accounting for, but does not yet 
completely account for.

Here are a few scenarios I think are worth keeping in mind:

    * Simple multicast/broadcast.  E.g., I blast out stock quotes to all
      subscribers without knowing who they are.  From the sender's point
      of view, this looks like any other simple fire-and-forget one-way,
      but the destination is a (dare I say :-) logical address
      designating the actual subscribers.
    * Multicast/broadcast discovery.  E.g., I send out a "who speaks
      Pig-Latin?" query.  Anyone who receives this is free to send back
      an esponseray to the esponseray EPR I gave.  I collect esponserays
      until I find enough Pig-Latin speakers, or get tired of waiting,
      or otherwise stop listening.  Respondents may, of course, continue
      responding after I stop listening.
    * Request/response/fault/log:  This is basically the well-known MEP,
      but I may also include a logging EPR, to which the server may send
      zero or more trace messages, perhaps even after the response/fault
      has been sent back.
    * Request/response/criticism.  I make a request.  You send back a
      response.  I don't like your response and I tell you so.  You send
      back another response.  I like it and tell you.  We shake hands
      and go away happy.  This generalizes to "extended conversations
      between two parties within a context".  I would expect that all
      the messages in the extended conversation would bear a
      [relationship] to the original message.
    * Full-blown dataflow:  There are no servers, no request/response
      MEPs.  There are just communicating nodes.  Each node understands
      some repertoire of messages, and for each message it understands,
      may produce further messages, delivering them either to endpoints
      of its choosing or to endpoints designated by the incoming
      message.  Disposition of a given message may depend on other
      messages that have previously arrived, further muddying the notion
      of MEP.

All of these bend the familiar concepts of MEP in various directions, 
perhaps to the breaking point, perhaps not.  However, I don't believe 
it's unreasonable to expect a distributed architecture to cater for all 
of them, at least at its core.