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

"Amelia A Lewis" <alewis@tibco.com> writes:
> 
> 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).

Good - that's even easier .. just a straight request-response then!
Its really a polling type relationship- that can either be modeled
first-class or just as a request response. (I'd be ok with either
approach.)

> 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?

Subscribers send a request to the spool and get a response right?
You're right - no subscriptions at all in this model .. straight
request-response again.

> 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.

I could be out of date too, but I think we're in agreement that
the interactions seem to be straight request-response.

> > 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.

But our problem is not to model the system but to model the 
services involved with the overall system. None of the services
seem to have a pub-sub in this case.
 
> 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.

Not at all- I'm just trying to take the WSDL viewpoint, which is
absolutely that of the client. WSDL is a description of the service
*for the client.* I'm not at all RPC centric (I'm working towards
a proposal to re-do the SOAP bindings to move away from that
notion even), but I'm very focused on keeping WSDL's scope as
being that of describing a service for a client.

> 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.

I'm all for having a first-class pub-sub syntax- what do you
think of what I proposed?

> > > 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.

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).

That's a good description - the question is does that need to be
captured in WSDL or is that just a "multicasting service"?

> > 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).

+1.

> 
> > 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.

I agree .. so let's start with my proposal (or another) and work
towards an agreeable solution!

Sanjiva.

Received on Friday, 1 November 2002 11:25:56 UTC