Versioning of Web Services: An UDDI Subscription-Based Approach, Page 2
UDDI subscription-based approach
Until UDDI V3, there was no standard way that clients will be notified about the changes in the UDDI Registry. UDDI v3 has a built-in feature called Subscription that can be utilized to notify the Web services changes to the subscribed clients.
According to the UDDI V3 specification, "Subscription provides clients, known as subscribers, with the ability to register their interest in receiving information concerning changes made in a UDDI registry. These changes can be scoped based on preferences provided with the request."
Subscription API allows monitoring the data in the registry in two ways:
- Asynchronous, using the notify_subscriptionListener API
- Synchronous, using the get_subscriptionResults API
Clients have to follow the following steps to receive their notifications:
- Clients have to register the subscription for the Web services of the product using the save_subscription API by supplying the subscription filter.
- Clients have to specify the notification interval (how frequently they want to receive the changes to the Web services notifications) and the brief attribute as "true" along with save_subscription API in order to get the notifications related to Web services (product) changes asynchronously.
- Clients have to implement the notify_subscriptionListener API and expose a Web service to receive the notifications Web services changes.
Once the above steps are followed, the clients will receive the notifications to changes in the subscribed Web services.
Solution to support multiple versions of service requests
Once the clients are able get the notifications about the changes to the Web services, clients will send the SOAP Message requests confirming to the new WSDL apart from sending SOAP Message requests confirming to the old WSDL document.
The Server should be capable of handling the requests from the old clients as well as the new clients. To handle both the requests, the server has to intercept the SOAP message and find the request, then route the request to the appropriate service. A SOAP Message Handler could be used to intercept the message.
A SOAP message handler intercepts the SOAP message in both the request to and response from the Web service.
Service providers—organizations—have to implement the SOAP Message Handlers to process the requests from the existing clients as well as the new clients. Service providers have to intercept the SOAP Messages (using SOAP Message Handlers) and invoke the operation based the client request (new version or old versions) and return the response to the Client.
Refer the article in Web Services Journal that I wrote to know more about "Intercepting SOAP Messages."
By using the UDDI Subscription and SOAP Message handler, it is possible to support the versioning of Web services.
UDDI Specication: http://www.uddi.org
SOAP Specification: http://www.w3.org/TR/soap
About the Author
Aravilli Srinivasa Rao holds a Master's degree in Computer Applications and works as a Software Analyst for Hewlett-Packard. He has eight years of experience in J2EE, Web Services (UDDI, SOAP, and WSDL), and mobile technologies (J2ME and IMode). He is currently involved in the architecture, design, performance tuning, and bench marking of J2EE Applications.