Re: [wsn] Notification and WSDL

[Steve Graham <sggraham@us.ibm.com>]

David Hull <dmh@tibco.com> wrote on 08/25/2004
04:53:13 PM:

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

<sgg>Per
WS-I Basic Profile 1.1:

.5.2 Allowed Operations

Solicit-Response and Notification operations are not well defined by WSDL 1.1; furthermore, WSDL 1.1 does not define bindings for them.

R2303 A DESCRIPTION MUST NOT use Solicit-Response and Notification type operations in a wsdl:portType definition.

Therefore, I am very nervous about violating WS-I BP 1.1, without really compelling reasons.

With respect to WSDL 2.0, we should consider this when we consider WSDL 2.0 related items.

</sgg>

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

<sgg>
Advertising which "message stream" (your term, not mine) in static WSDL is problematic for several reasons:
a) the set of possible streams may change over the course of the lifetime of the Web service or WS-Resource
and
b) WSDL 1.1 is extremely awkward way to describe this. You would need to define the xsd type of the message,
 the wsdl:message and wsdl:part elements, then the wsdl:operation and the wsdl:output element.  This is too much.
c) WS-I BP 1.1 forbids notification and solicit-response MEPs in wsdl 1.1 portTypes.

</sgg>


>
> 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).
<sgg>
WS-ResourceLifetime suggests a standard subscription topic for expiration (or death) of Ws-Resources, why can't
this be used for Subscriptions?

</sgg>



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