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

RE: "notification" pattern for web services

From: Sadiq, Waqar <waqar.sadiq@eds.com>
Date: Thu, 24 Jan 2002 14:14:37 -0600
Message-ID: <9C79F2D39765D411B18900508BE326A20A11559E@USPLM208.txpln.us.eds.com>
To: Steven Gollery <sgollery@cadrc.calpoly.edu>, www-ws@w3.org

Hi Steven,

We have implemented something similar.  We actually have a publish service
and a subscription service.  The publish and subscribe services actually use
JMS implementation underneath the cover but it could be any other pub/sub
mechanism.  These are two generic services which are able to publish or
subscribe to messages which are composed of string data.  In out case, the
application data is serialized to XML string so that works well.  Anyway,
the following wsdl portion represents the interface available to a client
application interested in publishing data.

<message name="publishMessageRequest">
   <part name="channelName" type="xsd:string" />
   <part name="messageData" type="xsd:string" />
</message>


<portType name="PublishServicePortType">
   <operation name="publishMessage">
      <input message="tns:publishMessageRequest"/>
   </operation>
</portType>


On the subscriber side, the subscription service exposes the following
interface:

<message name="registerSubscriberRequest">
   <part name="channelName" type="xsd:string" />
   <part name="clientUri" type="xsd:string" />
   <part name="clientNamespace" type="xsd:string" />

</message>

<message name="unregisterSubscriberRequest">
   <part name=" channelName " type="xsd:string" />
   <part name=" clientUri " type="xsd:string" />
   <part name=" clientNamespace " type="xsd:string" />
</message>


<portType name="SubscriberServicePortType">
   <operation name="registerSubscriber">
      <input message="tns:registerSubscriberRequest"/>
   </operation>

   <operation name="unregisterSubscriber">
      <input message="tns:unregisterSubscriberRequest"/>
   </operation>
</portType>


 The application receiving the data (which just registered with the
subscriber service) has to implement the fllowing interface:


<message name="processRequest">
   <part name="channelName" type="xsd:string" />
   <part name="messageData" type="xsd:string" />
</message>


<operation name="process">
   <input message="tns:processRequest"/>
</operation>


This has worked fine for us.  Unfortunately, for a generic publish/subscribe
service, it is not quite easy to provide a rich choice in terms of the kind
of data that can be delivered.


_______________________________________________
Waqar Sadiq
 
EDS EIT EASI - Enterprise Consultant
MS: H3-4C-22
5400 Legacy Drive
Plano, Texas 75024
 
phone: +01-972-797-8408 (8-837)
e-mail: waqar.sadiq@eds.com
fax: +01-972-605-4071
_______________________________________________
 
 

-----Original Message-----
From: Steven Gollery [mailto:sgollery@cadrc.calpoly.edu] 
Sent: Thursday, January 24, 2002 12:03 PM
To: www-ws@w3.org
Subject: "notification" pattern for web services

In several documents, I've seen references to providing web services
that follow the notification (or publish/subscribe) pattern, but I've
never seen any sample code. I can see a way to do it using socket
connections for the notification, but obviously there are going to be
many situations where this won't work.

Does anyone know where I can find code implementing a publish/subscribe
web service? The scenario I have in mind is: (1) the web service
advertises that it can provide information about a given set of topics;
(2) clients connect to the web service and subscribe to particular
topics; (3) other clients publish information about some topic by
sending that information to the web service; (4) the web service sends
the information to all the clients that subscribe to that topic. This
has to work regardless of whether the clients are behind a firewall, and
it would also be nice if there was some way for browser-based clients to
participate.

If building a publish/subscribe system using just web services is
impractical in the general case, I'd also be interested in other ideas
that would play well in a system that is primarily based on web
services.

Thanks in advance,

Steven Gollery
sgollery@cadrc.calpoly.edu
Received on Thursday, 24 January 2002 15:14:47 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 3 July 2007 12:25:39 GMT