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.
IE 7
Firefox 2.0
