Developer.com content and product recommendations are editorially independent. We may make money when you click on links to our partners. Learn More.
Versioning of a product means maintaining different versions of it. In a real-world scenario, an organization creates different versions of its software; it releases new versions of its product and upgrades to its current versions. Supporting multiple versions of the product through Web services is different than the traditional method of supporting the multiple versions of the product. This is due to the nature of Web services, which are loosely coupled.
This article explains how to expose products as Web services and how to achieve versioning of Web services using the UDDI subscription.
Introduction
Web services are developed using SOAP as a transport layer, WSDL as a description language, and UDDI as a service registry. Most organizations are ready to expose their products as Web services to the public UDDI Registry or private UDDI Registry. The main concern is how they can support different versions of the products through Web services. There is no standard so far to achieve the Web services versioning and there is no product available so far that directly supports Web services versioning.
Exposing Products as Web Services
The following steps are typically involved to enable a product as Web services.
- Generate WSDL files from the existing components (EJB, Java classes, JMS queues or Topics, and other components). (Most of the SOAP Servers (such as Apache Axis) or Application Servers (Weblogic or Web sphere) supplies tools to generate WSDL documents from the existing components.)
- Deploy the Web service in the SOAP/Application Server by generating and using the server-specific deployment files.
- Publish the Web service in the UDDI Registry (Web services are published as tModels in the UDDI Registry) OR
Register the service through the service brokerages such as Xmethods or SAL Central.
Invoking Web Services-Enabled Products
Clients will execute the following steps to consume the Web services:
- The client will search the UDDI Registry to find the Web services. The client’s finds tModel in the UDDI Registry and gets the Location of the WSDL document. OR
The client finds the WSDL document in the service brokerage registries. - Web services clients create the SOAP messages confirming to WSDL document.
- Invoke the Web services by sending the SOAP requests.
The above process works well as long as the exposed Web services or the products represented by them are not changed. Once the new version of the product is available, the organization has to generate the Services descriptions (WSDL documents) for the product and deploy the upgraded or changed Web services and publish the services in UDDI.
Issues with Versioning of Web Services
The following issues need to be solved when an existing version of the product that is exposed as Web service is changed or a new version is deployed:
- Client Notification: How to notify the existing clients that the Web service is changed
- How Support for multiple versions of Service Requests: As there would be clients interested in consuming older versions as well as newer versions of the service, the server side has to handle multiple types of SOAP message requests
Solutions to Web Services Versioning
Solution to notify clients about changes to the Web services
The first issue is how to notify the existing clients that the existing Web service has changed. There are two approaches to solve this issue. One of the approaches is through services brokerage and the other one is through UDDI.
Service brokerage approach
Service brokerages use different mechanism to send about the changes to the Web service. For example, SAL Central sends e-mail and SMS notifications about the changes to the Web services. But, it may not use the standard way of receiving the notifications because different service brokerages will implement different ways to notify the changes.
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.”
Conclusion
By using the UDDI Subscription and SOAP Message handler, it is possible to support the versioning of Web services.
References
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.
