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

Sanjiva and all,

In fact, our position is that if the SOAP 1.2 extensions mechanism is 
supported, and adequate specification supplied for solicit/response and 
notification, then publish/subscribe can be supported.

In other words, the bits that are needed are the following, all of which 
are amenable to description as features or MEPs:

1) message addressing (source, destination, reply to)
2) message correlation (id, references)
3) multiple recipients/respondents
4) server-initiated operations (solicit/response, notification)

One of my colleagues suggests that all that is needed is the concept of 
asynchronous communication with a logical mulitcast address.  I would 
argue, I think, that the above represent that necessity, in the detail 
necessary for implementation.

1 is needed because, although asynchronicity and multicast are separate, 
that means only that you can have asynchronous messaging that is not 
multicast.  All useful instances of multicast messaging are asynchronous.  
Once you have asynchronous, you must carry addressing information in the 
message, and in the service description.

2 is needed in order to support more than one message in the pipeline at 
once.  Since message responses may arrive asynchronously, and multiply, it 
becomes necessary to correlate the initial message with (zero or more) 
responses to it.

3 I haven't represented as a feature, but have effectively embedded into 
the solicit/response message exchange pattern.  Although notifications may 
have multiple recipients, it hardly matters since these recipients don't 
respond, and the recipients are, in theory, represented by a single 
logical multicast address, which will appear in the service description.  
There is a revised request/response pattern, which permits asynchronous 
behavior, but the assumption that I make there is that there will be one 
client interacting with one server nonetheless.

4 is the model of the publish/subscribe mechanism, in its various forms.  
Messaging systems are fairly easy to describe using this model, which adds 
to the definition of both exchange patterns not only that the server 
initiates, but that the recipient address may represent multiple physical 
processors.  It is also possible to describe this activity as some variant 
of request/response, but the model moves ineluctably away from the very 
simple, easy to comprehend, easy to analogize with a procedure call which 
is currently the connotation of request/response.  I think that this 
connotation is as important as the denotation; we should strive not to 
describe the publish/subscribe model in the same terms that we use for RPC 
or REST.  Neither really leave room for the concept of a 'procedure call' 
or verb that has fully variable return (a solicit response pattern would 
be represented as solicit, response* ... rpc and rest could probably cope 
with solicit, response+, but the possibility of no response, as 
non-exceptional behavior, tends to break both paradigms).

The acute will note that this makes no provision for linking the 
subscription operation (if it exists as something exposed by the service 
to the client, rather than as environmental behavior associated with the 
protocol) to the set of operations associated with a particular service.  
This is entirely intentional; one of my highly experienced messaging 
colleagues insists that the difference between scalable and non-scalable 
messaging systems lies in whether some server has to perform registrations/
subscriptions.  Systems requiring it, he claims, can't scale.  I'm not 
certain that I agree, but I'm not as expert, either.  I can say that 
whatever we do for WSDL, we *cannot* require a subscription mechanism for 
the services, because there may not *be* such a thing in any sense which 
is amenable to description as an operation.  Possibly we could add some 
form of flag attribute (subscriptionFor="bindingQName", perhaps?) but ... 
I don't know that this is in scope for WSDL.

Hope that helps clarify.  *laugh*  It's not that I'm trying to avoid 
putting forward a proposal, it's that we've been working on it, bottom up,
  for a long while, and as a result have a relatively large set of 
documents that folks are no doubt eager to *not* read.  But they do 
represent our collective thinking (no one else was brave enough to stick 
their names on, but the docs have all been reviewed by other folks, 
especially including messaging gurus, before publication) on one means of 
implementing pub/sub in SOAP, and describing the implementation in WSDL.  
The advantage of the pattern that we chose (and that we chose deliberately,
  for this virtue) is that it can be reused in other contexts, and supports 
a wider range of possibilities than a custom pub/sub solution might.

Amy!
On Saturday, November 2, 2002, at 05:20 PM, Sanjiva Weerawarana wrote:

> 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 Sunday, 3 November 2002 20:22:08 UTC