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

Hi Amy,

I *think* I may understand your viewpoint. The only way
I'll really understand is if you could send a proposal for
what TIBCO would like to see w.r.t. pub/sub in WSDL. I have
already made an initial proposal.

Let's get all the proposals on the table and figure out a
path forward!

Sanjiva.

----- Original Message -----
From: "Amelia A Lewis" <alewis@tibco.com>
To: "Sanjiva Weerawarana" <sanjiva@watson.ibm.com>
Cc: "WS-Desc WG (Public)" <www-ws-desc@w3.org>
Sent: Friday, November 01, 2002 11:09 PM
Subject: Re: [Pub-Sub-Task] Re: Some thoughts on wsdl pub/sub


>
> This is absolutely *not* request/response.
>
> On Fri, 2002-11-01 at 11:23, Sanjiva Weerawarana wrote:
> > "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.)
>
> Nope.  The sender solicits responses.  How the solicitation is delivered
> is not a part of the service description (it's the protocol).  Multiple
> clients receive the solicitation (by reading the spool) and respond.
> The spool is not a service.  The spool *should not* be described as a
> service.
>
> > > 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.
>
> Again, not at all request/response.  The original message is a multicast
> solicitation, which needs description in the WSDL as an operation, one
> which solicits responses.
>
> > > 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.
>
> We are in inutterable and complete disagreement.  There is no network
> model that I find more limiting and constraining than one that
> introduces phantom servers so that everything can be modelled as
> 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.
>
> There is no service associated with the spool.  The service is
> associated with the sender.
>
> > > 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.
>
> Agreed completely.  For which, in modelling nntp/usenet news, there is
> no need (indeed a need *not*) to introduce a phantom server representing
> the news spool, so that the client can somehow simulate a subscription
> and can pretend to do request/response when it is merely the completion
> of a message solicitation delivery.
>
> > > 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?
>
> As previously stated, by myself and Don, it appears to be an event
> notification model, in which the sender is always aware of who the
> recipients are.  It does not allow us (TIBCO) to model our messaging
> systems (which is the reason that we're involved here; our customers
> want to be able to use messaging, and SOAP, and even to model non-SOAP
> messaging in WSDL ... the proposal does not allow it, because it does
> not model the operations of 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.
> >
> > PGM?
>
> Pragmatic General Multicast.
>
> > > 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"?
>
> Is the suggestion here that a multicasting service does not need to be
> captured in WSDL?  It's what our customers want.
>
> TIBCO's viewpoint, from an unofficial source: we have a strongly vested
> interest in the development of messaging services; this is the
> foundation on which the company was built.  TIBCO acquired Extensibility
> (I'm more of an XML geek than a networking geek these days) as part of a
> commitment to make those systems (and others that grew naturally out of
> the messaging focus) interoperable.
>
> The big win of SOAP and WSDL, the key selling point, the reason that our
> customers want it, and not just over HTTP, is because it is
> interoperable.  We're replacing proprietary stuff with interoperable
> stuff, because we think we're smarter than everyone else and can
> continue to make the wins even without the crutch of proprietary
> formats.  The XML vision, if you will.
>
> SOAP 1.1/WSDL 1.1 provide adequate definition only for synchronous
> request/response SOAP over HTTP (videlicet the archives of
> soapbuilders).  In investigating SOAP 1.2, the same seems to be the case
> for the core specification, but there is an important addition, the
> extensibility mechanism.
>
> We spent a strong effort on understanding, then implementing the
> extensibility mechanism, in order to show how publish/subscribe (in
> something of a corner case, email mailing lists, chosen because most
> folks are familiar with email rather than because it is an outstanding
> example of the pub/sub model) can be represented using the SOAP 1.2
> extensibility mechanism.
>
> Taking that work forward, we want to be able to describe SOAP 1.2
> extension elements in WSDL 1.2.  Ideally, we'd like to see a feature
> mechanism that can describe stuff other than SOAP in WSDL.  But in our
> view, these things are rather related, because the only way we have
> found to describe the classic mechanisms of the publish/subscribe model
> (called solicit/response and notification operations in SOAP/WSDL
> discussions) is by providing those using the extensibility mechanism.
> And then focussing on how to describe those extensions in WSDL.
>
> >From the client point of view, in the pub/sub model, there are sets of
> operations, requesting a response (often an optional response) or not.
> These operations are characterized by dispatch to a particular address
> (logical multicast address).  "Subscription" to that address may be my
> means of contacting a server and registering, or it may be by using a
> filter on the traffic passing through this particular node of a
> distributed system (no notification to anyone, just a configuration
> change on the client).
>
> >From this, we want to see an explication in SOAP 1.2 of solicit/response
> and notification, and we'd like to see a means of describing both in
> WSDL, in a fashion that is generally interoperable.  Since subscription
> may or may not be required *as an operation on a server*, it seems that
> 1) it should not be required of a pub/sub WSDL description, and 2) the
> link between the subscription (if it is an operation) and the portType
> or binding representing the service (with its collection of
> solicit/response and notification operations) is out of scope for WSDL
> (it should be the province of BPEL, for instance, which has the power to
> describe operations not only as a set, but as a sequence, and even as a
> flow-controlled set of choices).
>
> A further nuance is introduced (even in the case of network news, for
> instance) in that the service description may be describing the clients
> as playing both roles.  That is, a subscriber is defined as one of the
> readers of a known logical address (subscription managed somehow; maybe
> another operation in the WSDL *is* the subscription mechanism, but maybe
> all that the subscriber needs is a name and a protocol).  In one
> implementation, there may only be one publisher, the service.  In
> others, every subscriber may be a potential publisher, adopting the role
> of service when they send a solicitation or notification to the
> specified logical address.
>
> Does that help to clarify the goals that we have in view for a WSDL
> pub/sub description?
>
> Amy!
> --
> Amelia A. Lewis
> Architect, TIBCO/Extensibility, Inc.
> alewis@tibco.com

Received on Saturday, 2 November 2002 17:23:15 UTC