Browse Prior Art Database

Selective Publish/Subscribe Utility for Web Services

IP.com Disclosure Number: IPCOM000031628D
Original Publication Date: 2004-Oct-01
Included in the Prior Art Database: 2004-Oct-01
Document File: 2 page(s) / 43K

Publishing Venue

IBM

Abstract

This invention disclosure describes an extension to the capabilities of a Web Services repository to enable selective Publish/Subscribe operations. Interested parties will have the ability to subscribe to a service, specifying details about the service calls they would be interested in receiving. Later, when the service is invoked, instead of the Publish/Subscribe utility fanning out the request to ALL subscribed clients, it would instead only be fanned out to those who have registered an interest in that specific request.

This text was extracted from a PDF file.
This is the abbreviated version, containing approximately 52% of the total text.

Page 1 of 2

Selective Publish/Subscribe Utility for Web Services

Presently the majority of Web Services are point to point in nature. That is directly accessed one at a time from 'Service Requestors' or Clients. The Service Requestor will find the details of the Service, and invoke a request to that service. So in order to have any interaction with the Service, the clients have to make the request (and be the initiator of the communication).

    Web Services have largely been used in a remote procedure call environment, but increasingly there is an interest in using it as a programming model for simple messaging. Extending this, the technology of Web Services could easily work as well in a publish/subscribe environment. In this case, the clients would create a Web Service, conforming to a WSDL definition, and register themselves with the publisher. In this case, instead of the request going to a single client it would be fanned out to all those who had subscribed.

    An addition to this is to use Web Services in a Selective Publish/Subscribe system. This would mean the Clients, when subscribing to the service, would specify details about the service calls they would be interested in receiving. This means that when the service is invoked, instead of fanning out the request to ALL subscribed clients, it would instead only be fanned out to those who have registered an interest in that specific request.

One way in which this could be useful is:

    Consider a Motor Insurance Company. The company has a list of Assessors who are responsible for assessing the damage to a car in the event of someone making a claim on their policy. At the moment, contacting the Assessors to request them to carry out some work may all be done manually on an individual basis. This would require contacting each assessor in turn to find out who the cheapest would be then contacting that assessor again to ask them to carry out the assessment. Using this invention, the Insurance company could write a Web Service something like "PublishDetailsToAssessors" to allow Assessors to bid for a particular piece of work. This Web Service is described in WSDL. Any Assessors now wishing to receive the messages (describing potential new jobs) can get the WSDL document describing that service and create a client, then register that client with the Service.

    And with the invention, in the subscription information they would specify information such as the web location of their service along with information such as what type of car they specialise in, their postcode, etc etc

    Now, when a customer makes a claim, the details of that customer, including the location of the car to be assessed, make of the car, etc can be fed into the Web Service. The Web Service can now publish those details to Assessors registered with that...