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

WSN has just such endpoints wired into the Notify message (specifically, 
a Notify message may contain an EPR for the subscription that produced a 
message and for the notification producer that produced the subscription).

It's certainly worth considering having these as MAPs (and thus as SOAP 
properties generally manifested as headers).

Rogers, Tony wrote:

> 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 <mailto:tony.rogers@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.