Sriram Anand

Subscribe to Sriram Anand: eMailAlertsEmail Alerts
Get Sriram Anand via: homepageHomepage mobileMobile rssRSS facebookFacebook twitterTwitter linkedinLinkedIn

Related Topics: Apache Web Server Journal, SOA & WOA Magazine

Apache Web Server: Article

Best Practices and Solutions for Managing Versioning of SOA Web Services

Patterns and developer techniques for service versioning

Here we note that a complex type of name "VersionDetails" has been created for communicating the service version information to service consumers. The ID will have a predefined format to indicate the service version. Note that adopting this approach would only serve to provide the basis for transferring information to the service consumers. A policy needs to be adopted for managing the implementations of the previous versions of the interface. One approach is to combine this method with the method of identifying versions by namespace. The version ID of the most current interface may be provided to the consumer. Subsequently, the consumer may use this version to use the correct namespace and invoke the most up-to-date WSDL.

UDDI-Based Options Specifically for Web Services
The options discussed above primarily deal with version management in the situation where we are dealing with services that are accessed by consumers directly. This can be done either by providing endpoints to interested consumers or through some manual mechanism that involves a priori knowledge of a particular service endpoint.

The recommended best practice for Web services is to use UDDI directories (see the fourth entry in the References section). This will allow the dynamic lookup of service interfaces and implementations that are tied to specific business areas or other criteria that the service consumer can specify. Specifications for UDDI are maturing and there are some sample UDDI directories available on the Internet, for example, the public directories from IBM or Microsoft. However adoption of UDDI has not come anywhere close to the rates of adoption of Web services. Below we discuss some options for versioning services using UDDI, along with the merits and demerits of those options (see the second entry in the References section).

The UDDI data structure that is used for publishing information on organizations and the services they provide is called a tModel. A tModel represents general concepts that many organizations can refer to in their UDDI registrations. A tModel is identified by a unique key known as the tModelKey. Apart from this, a tModel data structure may contain other elements that are discussed below:

  • authorizedName: Represents the name of the person publishing the tModel
  • operator: Name of the registry operator
  • name: Name of the tModel
  • description: Description of the tModel
  • overviewDoc: References to remote descriptions associated with the tModel, e.g., the URL for a WSDL document residing on a different server
  • identifierBag: Name-value pairs to hold identification criteria
  • categoryBag: Name-value pairs that are used to associate the tModel with a specific taxonomy, e.g., an industry, line of business, or geography
Note that the tModel's overviewDoc field is used to reference a WSDL that conforms to the tModel in question.

A UDDI registry would have a number of tModels available depending on the type of service/business. This can be queried by Web service consumers. The programmatic query would return a collection of tModelInstanceDetails that represents all tModels that match the criteria provided (see the first entry in the References section). Let's examine how we might leverage tModels to support version management.

Option 1
We can create a different tModel for every available service version. This would generate a unique tModelKey for every possible "flavor" associated with a specific Web service. Considering that the industry taxonomy classification would be the same, all these service versions would be retrieved from a UDDI registry. Using this approach, consumers could select the WSDL that is associated with the version that they need.

Option 2
A tModel is associated with a data structure called tModelInstanceInfo that contains some fields pertinent to a specific tModel. This data structure has a field named "instanceDetails" that may be used to store a version number for a specific Web service implementation. However, using this approach for version management does not constitute a best practice and defeats the association between a WSDL and a tModel. UDDI may also be used to deprecate obsolete versions of a service by providing appropriate details in the "identifierBag" field mentioned above.

However, all the methods identified above are by no means very elegant. The first option is reasonably stable, but suffers from a bloat in the number of tModels for dynamic services that have multiple versions. The other approaches represent workarounds at best that attempt to compensate for the gap in the standards.

WS-Addressing for Version Management
The WS-Addressing specification (see the fifth entry in the References section) can be used to provide an efficient solution for tackling issues related to versioning in Web services. As mentioned in the problem background section, three broad scenarios have been identified in relation to version management of services, namely implementation change, implementation correction, and interface change. WS-Addressing can also be used to address scenarios in which the endpoint URL of a Web service changes.

The challenge faced in all three of these scenarios is to make the underlying users of the services aware of the changes made in the service. WS-Addressing can be used to provide an optimized and efficient solution to address the aforementioned issue. In the following section we'll discuss each individual scenario.

Implementation Correction or Implementation Change
In this scenario the implementation or the functionality of the service is changed or corrected. In such a case the client will continue using the service without any knowledge that the service has changed. One of the options is to include a parameter in the method invocation signature (Reference section: option for handling service changes) that denotes the version, but the stated option couples version information with business functionality, which is not an elegant solution. WS-addressing can be used to solve the issue by adding a custom tag to indicate any change in implementation, for instance in Listing 7 a tag named <implementation> has been included in a response message to indicate the change in the implementation logic. Whenever the implementation changes the information pertaining to the specific change is included in this tag for a certain period of time. When there has been no change performed to the implementation of the service, an empty implementation tag is provided. Similarly, the client can include an implementation tag that indicates the last-accessed implementation version, so if the implementation has changed since the last client request the service can send the required information.

Note: It needs to be pointed out that the implementation is a custom-defined tag and hence the usage of this tag must be done only after an agreement between the client and the service.

Interface Change
In this scenario, recall that the interface, i.e., the number of parameters or the type of parameters associated with the interface, changes. In this case an error message needs to be communicated to the client that should also contain information communicating the details of the change. In case a client request does not match the required interface definition, WS-Addressing can be used to tackle the change by including some custom header tags that indicate interface change.

For instance, in Listing 8 a custom tag called <interface> is used to communicate the information related to the change to the client.

Endpoint Change
In this scenario the endpoint of a service is changed and the responsibility of forwarding the request to the new endpoint is delegated to some dummy service for a period of time. In such a scenario the requirement is to communicate the new URL to the existing users.

Figures 2  and 3 show such a scenario. In a traditional approach the dummy service takes the responsibility of invoking the new service and sending the response back to the client. There is no way the new service can send the response directly to the client. Moreover, custom headers need to be added in order to communicate the changed location to the client. Use of WS-Addressing headers can solve the aforementioned issues, and the <from> tag in the response effectively communicates the new URL to the client. Furthermore, the service can send the response directly to the client based on the <ReplyTo> tag of the request message.

We have examined some options for the version control and management of change in Web service implementations. We have examined options that utilize design patterns, best practices, and that also leverage existing technologies such as UDDI. It is perceived that emerging standards in the Web services space such as WS-Addressing may provide some standardized mechanisms for handling service versioning. Until such standards are in place and adopted by popular vendors, some of the options discussed above may need to be used for large-scale service deployments. The emergence and maturity of Web service management platforms may provide some robust functionality in this regard as well. Until the convergence of standards and the stable functionality provided by these products, Web service implementers may be forced to rely on unorthodox mechanisms for change management.


More Stories By Sriram Anand

Dr. Sriram Anand is a principal researcher at Infosys Technologies, Bangalore. Prior to joining Infosys he worked in IT consulting as well as product engineering in the US for over 12 years. His interests include enterprise architecture, service-oriented architecture, and legacy integration and software engineering methodologies. Dr. Anand is experienced in designing enterprise architectural strategy for leading U.S. companies in the financial services, retail, and pharmaceutical domains. He holds a Bachelor?s degree from IIT-Madras with a PhD from SUNY-Buffalo, USA.

More Stories By Krishnendu Kunti

Krishnendu Kunti is a senior technical specialist with the Web Services Center of Excellence at Infosys Technologies, Hyderabad. He has contributed to architecting, design, and testing of Syndeo, an in-house service-oriented platform for enterprise-grade deployment of Web services. His areas of interest are SOA and business execution languages. Currently he is working as a technical lead at a leading financial services company developing data services using SOA.

More Stories By Mohit Chawla

Mohit Chawla is a software engineer with the Web Services Center of Excellence at Infosys Technologies, Hyderabad. His primary area of interest is SOA, with a specific focus on Web services implementations on various platforms. He is also interested in developing applications using emerging WS-* standards. His current is currently focused on SOA-based enablement of legacy systems.

More Stories By Akhil Marwah

Akhil Marwah is a software engineer with the Web Services Center of Excellence at Infosys Technologies, Hyderabad. His current area of focus is Web service implementations using Microsoft Technologies, specifically the MS .NET framework. He is also interested in developing Web service applications using the J2EE stack. He is currently working on areas related to SOA-based enablement of legacy systems.

Comments (2)

Share your thoughts on this story.

Add your comment
You must be signed in to add a comment. Sign-in | Register

In accordance with our Comment Policy, we encourage comments that are on topic, relevant and to-the-point. We will remove comments that include profanity, personal attacks, racial slurs, threats of violence, or other inappropriate material that violates our Terms and Conditions, and will block users who make repeated violations. We ask all readers to expect diversity of opinion and to treat one another with dignity and respect.