Notification and WSDL

[David Hull <dmh@tibco.com>]

I've been puzzling for some time over how best to relate WSN to WSDL.  At first glance, there is potential overlap.  Notably, WSDL 1.1 defines a "Notification" operation in which "the endpoint sends a message."  This is carried over in WSDL 2.0 as the (optional) "out-only" MEP, which "consists of exactly one message."  However, neither WSDL specifies how one might trigger such an operation or designate a destination.  WSDL also lacks a notion of "zero or more messages in succession." For brevity, I will call this a message stream as opposed to, say, a video stream or audio stream.

WSDL 1.1 specifically limits operations to the four given and puts binding of Notification out of scope.  WSDL 2.0 follows this in its pre-defined MEPs, but allows for definition of arbitrary MEPs by extension.

WSN, on the other hand, provides a means of directing a message stream to a given destination, along with some means of controlling an active stream and deleting it either explicitly or implicitly.  It does this via EPRs.  WSN does not attempt to describe a message stream directly in WSDL, except in that a NotificationConsumer MAY implement the NotificationConsumer port type (strictly speaking, this means that it agrees to accept exactly one message of type Notify, or rather, exactly one message per "operation," whatever that may be).  WSN specifically does not define any Web Service with a "one-way" or "out-only" operation.  A NotificationProducer shows itself by advertising the NotificationProducer interface, not by advertising a one-way operation.

It is important to remember that WSN Subscribe is only one way to establish a message stream of notifications -- message streams in general are already in wide use through various mechanisms.  Some current mechanisms include joining a mailing list, subscribing to a JMS topic, joining an IRC channel, establishing a TCP connection and reading an indefinite sequence of messages, joining a multicast group and listening to its traffic, and polling a server.  Even in the absence of WSN, it would be nice if a service producing a message stream could advertise a "notification/multiple" or "out-only/multiple" endpoint in its WSDL, along with binding information on how to receive notifications.

In this view, WSN would be one option for the "how to connect" information in the WSDL binding.  Further, many of the issues we're currently discussing -- security, scheduled termination, QoS, spam mitigation, pause/resume/queuing, push vs. pull, etc. -- appear more and more to be independent of whether a message stream is initiated via a WSN Subscribe operation or some other means.  Different bindings will vary in how to handle all this.  Some issues won't even apply to a particular binding.  It's at least logically possible that a message stream initiated via WSN Subscribe would not need a SubscriptionManager to control it, or that the control operations of SubscriptionManager could be used for message streams initiated by other means.

If we somehow manage to push all these issues out to WSDL binding (where they would still have to be dealt with), what's left in the core?  As I've argued before, there is still the very central issue of the decoupled binding of producers and consumers, and possibly the issue of 1-of-N delivery.

In this view, NotificationProducer and SubscriptionManager still exist (though perhaps not under those names).  The question is how (or whether) to relate these concepts to WSDL's existing but underused concepts of MEPs and bindings.

WSN itself can potentially use out-only port types.  We don't currently have a means of notifying a Subscriber when a Subscription dies prematurely (or expires).  One way to do this would be to include "party to notify in case of my death" endpoint in the Subscribe request.  Another way would be for SubscriptionManager to include an out-only SubscriptionDeath operation for the Subscriber to bind to by any means appropriate.  This could have an "implicit" option meaning "use the address I gave in the Subscribe request."

The two basic mechanisms here -- supplying an EPR and advertising an output operation -- may look very different, but my growing intuition is that they are essentially different facets of the concept of notification.  If this is true, it will be useful to consider carefully how the respective WS-specifications -- WSN and WSDL -- interrelate.