W3C home > Mailing lists > Public > www-ws-desc@w3.org > November 2002

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

From: Amelia A Lewis <alewis@tibco.com>
Date: 01 Nov 2002 12:09:03 -0500
To: Sanjiva Weerawarana <sanjiva@watson.ibm.com>
Cc: "WS-Desc WG (Public)" <www-ws-desc@w3.org>
Message-Id: <1036170544.11901.42.camel@xerom>

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 Friday, 1 November 2002 12:09:26 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 7 December 2009 10:58:21 GMT