- From: Sadiq, Waqar <waqar.sadiq@eds.com>
- Date: Thu, 24 Jan 2002 14:14:37 -0600
- 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 UTC