Wednesday August 8 2001

Versioning of Web Services

Solving the Problem of Maintenance

Romin Irani

Printer-friendly version

Every day, we hear of vendors announcing toolkits that serve to make the building of Web Services effortless. Organizations are, however, in different stages of the Web Services implementation phase - many organizations are awaiting other organizations? reactions; a few have already announced availability of Web Services. Nevertheless, the majority of organizations, especially those with established products and a large customer base, are asking very specific questions about this new programming model. One of these questions is: How do we maintain different versions of Web Services for different customers? In this article, we will define the common problem of versioning and attempt to find some solutions with respect to Web Services.

Exposing a Product as a Web Service

Let us first recap the Web Services programming model as it stands today. We will look at it in the context of an organization which we will call TectERP. TectERP provides a mini-ERP system. An ERP (Enterprise Resource and Planning) system is a software package that streamlines the flow of information in a company; that is, for instance, information regarding finance, human resources, accounting and customer data.

Take a look at the diagram shown below:

TectERP provides a Sales Order Module, a Purchasing Module and an Inventory Module as part of its mini-ERP package. The organization decides to Web Service-enable their latest distributed version as a group of integrated Web Services, which provide their entire functionality over the Internet. In short, it defines appropriate WSDL interfaces that hookup to the modules in its ERP package. TectERP publishes these interfaces in a UDDI registry, so that other organizations can discover and use them. Organizations that find the TectERP system on the UDDI registry and that want to use it can locate the TectERP WSDL interfaces and invoke them via SOAP.

The above paragraph describes a common Web Services programming model which is prevalent today. However, it is important to note that UDDI is not the only way to publish WSDL schemas. An organization can also publish its Web Services at a Web Services brokerage firm, such as http://www.salcentral.com/ and http://www.xmethods.net/.

The issue of Versioning

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.

In this section, we will look at versioning in relation to our sample organization TectERP. We will first consider TectERP?s existing product and customers and then discuss the implications of Web Service-enabling the latest version of TectERP?s distributed product; that is, the potential advantages and disadvantages that this change will bring. Finally, we will look at how TectERP can maintain different versions of its Web Service-enabled product. We will stress the problem of versioning in a Web Services environment and also discuss possible solutions.

Step 1: TectERP - Existing Product and Customers (Analysis Stage)

Let us assume that TectERP is an established organization, and that, before it ventured into the Web Services world, it had already deployed its distributable (non-Web Service-enabled) solution at several customer sites. During the course of its product history, TectERP?s package has developed and new versions and upgrades have been released, as shown below:

• Version 1.0 was released in 1995,
• Version 1.1, early 1996,
• Version 2.0, 1998, and so on, until the latest version, Version 5.0, was released in 2001.

TectERP's package is used by fifteen customers worldwide. Twelve of its customers have, in fact, upgraded to the latest version of the software, that is, Version 5.0. One customer still uses Version 1.1, and has decided not to change version, due to the costs involved in upgrading his her systems and integration services. Two other organizations are also using earlier versions, as they are happy with the product and don?t feel any need to upgrade to the latest version.

Just like any other business, TectERP faces the dilemma of not only continuing to improve on the latest version of its product, but also having to maintain its older versions, as customers are still using them. Furthermore, TectERP is working on a couple of heavy customizations of its product for two new customers, which means that these customized versions will be quite different from the baseline versions.

It is, however, important to note that in TectERP's case, the organization has a very small customer base (fifteen customers) and, so, it might still be possible for it to support, not only its different versions, but also customized versions. If the number of customers increases, TectERP would find it both financially and technologically challenging to maintain different versions for all its clients. In such situations, common today, TectERP would enter into contractual agreements with its customers which stipulate that a certain version would not be supported after a certain date and that the customer would be forced to start using a later version.

From this, we can conclude that organizations find it increasingly hard to maintain different versions of their software. When an organization, such as TectERP, decides to expose its product as a group of Web Services, it is likely that it will come across the problem just out-lined.

Step 2: Web Service-enabling a Product (Implementation Phase)

We will now look at what happens when TectERP decides to Web Service-enable the latest version of its product. Its Web Services implementation phase will follow the general Web Services programming model, discussed above. According to this model, TectERP defines its interfaces using WSDL and publishes those interfaces in a UDDI registry or a service brokerage, such as http://www.salcentral.com/ and http://www.xmethods.net/.

We can make the following observations:

• Now that TectERP is moving its product from a distributed version to a centralized Web Service model, the functionality does not have to be packaged in distributed versions. Thus, the characteristics and definitions of the version that will be Web Service-enabled could change. This is to say, that there might not be a literal translation of the modules into Web Service interfaces. It makes sense to aggregate some of these modules, and present a, sort of, fa硤e WSDL interface.
• As we have pointed out, TectERP, like other organizations, faces problems trying to maintain different versions of its products at customer site. By exposing its product as a Web Service, TectERP has now managed to centralize it. This means that whenever TectERP makes any changes to its software, for instance, via upgrades or bug-fixes, those changes can be done without problem, as only the centrally located product version needs to be changed. All customers can automatically get the latest upgrades of the product. Both TectERP and its customers benefits from this; it will be time-saving for TectERP, and its customers will always have access to the latest version of its product.
• We have noticed that there are several customized versions of TectERP?s product, developed for different customers. Due to centralization of its product, it will be much easier to support and maintain these customized versions.
• A clear disadvantage with the out-lined development of TectERP's product is that, by maintaining its product at a central place, TectERP might face problems customizing the software on a global scale, adapting it to, for instance, different geographical areas, time zones, policies and tax rules.

Step 3: The Versioning Problem (Maintenance Phase)

So far, we have looked at how TectERP has Web Service-enabled its software. We have seen the potential advantages of Web Service-enabling for an organization. However, as soon as TectERP?s software is available as a group of Web Services, and its customer are consuming it as that, TectERP needs to plan its software upgrade very carefully. We will now turn to some of the problems with regard to maintenance of the software as Web Services, and suggest possible solutions.

Upgrading a Web Service

How does TectERP go about upgrading its Web Services? The managers at TectERP are aware of the commercial value of maintaining a consistent service for its customers, and the negative business consequences of frequent service disruptions. To avoid breaking the integration points of its customers with its software package, TectERP?s development team makes sure that all the existing WSDL interfaces remain the same, and that the functionality is consistent. TectERP might introduce some new interfaces in its latest version, but at the same time it wants to maintain both the new and old versions with their respective WSDL interface definitions.

Speaking from an implementer?s point of view, the SOAP protocol, currently, offers the SOAPAction/URI fields, that can be, appropriately, populated to accommodate different versions. The implications of this are that TectERP will have to maintain different versions of its WSDL files. TectERP could, however, also use a Service Broker implementation on its site, which would receive the same requests and channel them to the right versions of the modules.

Notifying Users of upgrades

Every software product goes through its normal lifecycle of newer versions and upgrades. An easy way to deal with the problem associated with upgrading a Web Service is to, simply, notify the users of the upgrade. But what do we mean by users? Do we mean the applications that use our service, or do we mean appropriate personnel in our customer organizations, who could then take necessary action?

It is often mentioned, in Web Services documentation, that calling applications can easily adapt themselves to changing interfaces, by downloading the latest WSDL interfaces and adapting its interface appropriately. But this is not always possible. In case TectERP changes its WSDL drastically, it needs to employ a Service Broker architecture at its end, which scans incoming requests and informs the older interface invocations of incompatibility, by giving an appropriate response. At the same time, organization can make use of services provided by Web Services brokerages, such as http://www.salcentral.com/, which provide services that can dynamically scan WSDL schemas looking for changes in their structures. Once a change is found, the service emails (or sends an SMS message) stating that a change has occurred. For further details on this, use the following links: www.salcentral.com/watchx/run.asp and http://www.allesta.com/.

Web Service Customization for specific customers

We can also imagine cases, where an organization is interested in using TectERP?s package, and studies its WSDL interfaces via an UDDI registry, but finds that the interfaces and functionality do not appropriately match its needs. At the same time, however, it is interested in using the TectERP package, provided specific changes are made to its functionality and interfaces. TectERP is interested in increased revenue, and decides to customize its service and modules to fit the needs of this particular organization. With a number of similar cases, TectERP will end up with many different customized versions of its product, adapted to several customers? different needs.

In such situations, TectERP will have to create customized WSDL definitions and receive the requests on different URLs, for its individual customers. TectERP will be better off not publishing those WSDL definitions to a public UDDI registry. It is important to note that each one of TectERP?s customers using customized versions of its product has now access to two WSDL Schema definitions. The first one is the basic schema, of which the organization only uses parts, and the second one incorporates the additional customizations done, specifically, for it. Having two schemas reduces the potential risk that the Web Service will fail to work.

Discontinuing Support of older versions of the Web Service

What if an organization using TectERP?s Web Services wants to use an old version of them, instead of a newly released version? And what if TectERP decides not to support an older version of its Web Services?

The answers to these questions are business-related rather than technical, and the situations can be best prevented, if they are dealt with in a contract, for instance, a Service Level Agreement, that is signed between TectERP and the customer, before the customer can start using the Web Service. If questions like these are not clarified in an initial contract, TectERP might be under obligation to continue supporting old versions of its Web Service.

Conclusion

In this article, we have attempted to highlight problematic versioning issues that an organization will face when it exposes one of its applications as a Web Service. We have considered different situations, and tried to suggest possible approaches to each of them. SOAP provides us with SOAPAction/URI fields via which we can support different versions of our Web Services. But for an organization with a large customer base, supporting different versions is, to a large extent, becoming organization-implementation specific. There is little in the Web Services standards that attempts to address the problem of different versions of a Web Service. We have to decide whether this is a question that should be dealt with by standardization bodies, by vendors of Web Services platforms, or by Web Service providers themselves.

Versioning issues will cause problems for several organizations, and could become a stumbling block in the path of widespread Web Services acceptance. Versioning issues need to be considered by, not just people making decisions for their companies to tread the Web Services path, but Web Services architects and developers who need to be equally aware of their implications.

Readers of this article may also be interested in reading: Business Architecture for a Web Services Brokerage.

Romin Irani is a Senior Software Engineer at InSync Information Systems, Inc in Fremont, California. He is also the co-author of Professional Java Web Services from Wrox Press.

Printer-friendly version

Keep up to date with all the new articles and features on Web Services Architect:
Register for e-mail updates