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

Are you suggesting that we (the async TF) consider these as additional 
usecase to support/flush out the details of OR are you suggesting that 
these are interesting usecases that WS-Addressing should enable?

IMHO, WS-Addr should certainly enable such usecase. Wrt whether the TF 
should consider these usecases I think we should be careful as to how 
far we want to go in figuring out the details of various interesting 
async usecases. Specifically we should be mindful of work going on in 
WS-Notification TC and WS-Eventing spec, as well as how much we would be 
treading in the BPEL space (we are already doing that with the callback 
usecase -- although I think in the callback usecase, because it is so 
simple and common/wide-spread, IMHO we are justified in considering it).

-Anish
--

David Hull wrote:
> 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.

Received on Thursday, 17 March 2005 03:45:59 UTC