Re: [wsn] What do notifications look like?

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

David Hull <dmh@tibco.com> wrote on 08/26/2004
02:38:01 PM:

> (This is a shorter and more concrete intro to the general WSDL issue
from my 
> previous message).
> 
> If I produce notifications, how do I tell potential consumers what
they look like?
<sgg>
Implement the wsnt:Topics resource property.
 Requestor can do a GetResourceProperty on this rp, examine the contents
determine which topics are supported,
inspect the topic metadata (ws-topics) for more information.

</sgg>

>
> One approach (taken from the WSRF interop scenario document :-) is to say something like "
> [...] the notification message generated will contain:
>    <widget:TestNotification/>"
> in a text document.
> This seems somewhat informal.  The obvious machine-readable format is WSDL.  If I
> produce, say, stock quote notifications, I should advertise a Notification
> operation with an appropriate message type.  Note that this WSDL is associated with
> the producer and not with the consumer.
<sgg> and per my response to your last email, I am against requiring the use of
Notification MEP because it violates WS-I BP 1.1 </sgg>

> Also note that the WSDL need not be associated with a service that handles
> Subscribe operations.  There are two reasons for this
> 1. There is no reason to require that WSN be the only way to subscribe to
> notifications advertised in a WSDL -- the binding might just as well give
> information for some native MOM.

<sgg>I thought that non-web services interactions are outside the scope of this TC.

</sgg>

> 2. Even if WSN is the mechanism, the WSN "NotificationProducer" might not be the
> same service as the, erm, producer of notifications.
<sgg>How does the requestor know, and why does the requestor care that these components are different.  The
requestor goes to an NP, says to it, hey you, I am interested in getting messages from you at this given topic.
The fact that the NP delegates to another component is encapsulated away from the requestor.

</sgg>

> This seems like further evidence that "NotificationProducer" is actually more like
> "SubscriptionFactory," and it even gives a place to put the GetCurrentMessage
> operation: A (proposed) NotificationProducer advertises a Notification operation
> with a given message type, and may also advertise a GetCurrentMessage
> Request/Response operation with the same message type as its response.  The binding
> information for the Notification operation might include and endpoint for a
> (proposed) SubscriptionFactory implementing WSN, or it might specify some other mechanism.
<sgg>It should come as no suprise that I disagree.

</sgg>