RE: It's a wide world out there ...

Your first example made me think: perhaps the wsa: headers on the broadcast
message might include an EPR for "unsubscribe" (AKA: SpamMeNoMore). They
might also contain an EPR for "more details" (AKA: SpamMeHarder!) - could be
useful for stuff like sending out headlines, and allowing subscribers to ask
for more detail on one or more headlines. And there could be a FaultTo EPR
for things like "addressee unknown". This example rather lends itself to an
unconventional set of headers.
 
Tony Rogers
tony.rogers <mailto:tony.rogers@ca.com> @ca.com

  _____  

From: public-ws-async-tf-request@w3.org
[mailto:public-ws-async-tf-request@w3.org] On Behalf Of David Hull
Sent: Wednesday, 16 March 2005 15:26
To: public-ws-async-tf@w3.org
Subject: 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.