Re: "notification" pattern for web services

Sadiq,

In your system, is the application that receives the data also a SOAP
server?

Using JMS may be a possibility for us; I need to look into that.

Thanks,

Steve

----- Original Message -----
From: "Sadiq, Waqar" <waqar.sadiq@eds.com>
To: "Steven Gollery" <sgollery@cadrc.calpoly.edu>; <www-ws@w3.org>
Sent: Thursday, January 24, 2002 12:14 PM
Subject: RE: "notification" pattern for web services


>
> 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:46:58 UTC