Re: [Pub-Sub-Task] Re: Some thoughts on wsdl pub/sub

On Thu, 2002-10-31 at 19:12, Sanjiva Weerawarana wrote:
> 
> Amelia A Lewis <alewis@tibco.com> writes:
> > A specific example: netnews (usenet, NNTP server-to-server transport
> > with variable client access) is a publish/subscribe model (with some odd
> > pieces; it's also store-and-forward, which has a big impact).  A
> > publisher does not know, and cannot know, who will read any given
> > message.  Subscribers do not have to use nntp for access of any sort
> > (they may use a local news spool, for instance), and in any event are
> > not required to perform any operation that looks like "subscribe" to the
> > service.
> > 
> > This is not particularly uncommon in messaging systems.
> 
> Let's be precise- netnews is not all magic like that. The model is
> the following isn't it?

No.

>     - author of news article (event source) writes the article
>     - (s)he publishes the article to a local NNTP server
>     - local NNTP server upstreams it to one or more other
>       servers it knows about
>     - servers publish that article (event) to other servers
>       that are subscribed to it (typically via configuration)
>     - eventually it finds its way to my NNTP server (where I am the
>       event sync)
>     - I read the article

Servers flood fill.  In fact, the mechanism is more of a pull than a
push (message: what do you have?  answer: xyzzy, plugh.  message (after
realizing that I have plugh): send xyzzy).

Subscribers can read from the spool, when available.  They can ask a
server.  If there is no subscription contract, then how does it get
modeled?

> So in this model too I believe there is indeed a subscription
> mechanism. However, its between the different NNTP servers
> and not between the actual event source (the article author)
> and the actual event sync (the article reader). 

I believe that we have different understandings of the workings of
usenet.  It's possible that mine's out of date; I haven't administered a
spool for nearly ten years.  But back when, the concept of a client
subscription propagating beyond the *client itself* had no meaning.

> The only thing the reader cares about in NNTP is that there's
> an NNTP server to which (s)he goes to to download news. That
> service would just have a bunch of request-response operations.

Umm.  No.  This is not at all the mental model of the system, when
considered as an example of publish/subscribe.

We can have the argument interminably that server output/client input
can be modeled as client request/server response simply by changing our
names for the participants, but I very much doubt that anyone will
manage to convince me that request/response is the only thing that the
network needs.  That strikes me as a wholly RPC-oriented kind of
viewpoint (REST-ish as well), but a subset.

Multicast is poorly modeled by request/response, especially given
current semantics.  Bolting on the additional semantics, by pretending
that the 'casting server is actually a client, and the set of clients is
actually a single server that returns zero or more responses, is not, to
my mind, an acceptable model for publish/subscribe.

> > This is not particularly uncommon in messaging systems.
> 
> I'm not a messaging expert, but I imagine that's while applications
> may not directly do a subscribe, the underlying middleware does.

In some cases, the underlying protocol.  See PGM.

One of my colleagues suggests that the problem is modelling "logical
multicast addresses."  That is, sending a message to a single address,
that ends up going multiple places (by magic, as far as I need to be
concerned).

> Now, going back to WSDL- the only thing that should be described
> in WSDL is everything the client (the service user/requestor)
> needs to use the service. If it doesn't need to know that the

Right.  So if the client doesn't need to subscribe, then the
subscription mechanism SHOULD NOT be described (to RFC 2119 it).

> underlying info is delivered via a pub sub mechanism to the service
> provider then there's no event there .. it just sees (probably)
> a request-response operation which it uses to ask the provider for
> the information.

I do not believe that a pure request/response view of the network is
adequate to describe publish/subscribe messaging systems.

Amy!
-- 
Amelia A. Lewis
Architect, TIBCO/Extensibility, Inc.
alewis@tibco.com

Received on Friday, 1 November 2002 10:19:11 UTC