Mission Critical Software

In the case of Web services versioning, when dealing with Web services in a mission critical software environment in which downtime cannot be tolerated, both versions of a service may need to be running at the same time. Let us look, therefore, at how to begin to version a service.

How to take a service and move it to the next version? What are some of the things that are required in the process? If, for example, the interface of the service is to be changed, how can one do that effectively?

Mission Critical Software: Namespace Versioning

One of the most common techniques is changing the namespace of a service: versioning via the namespace. One can see, in the example below, the focus on the namespace: the namespace itself includes a version number. (However it is formatted, the namespace includes a version number.) The essential goal here is to take one version of a service and change the namespace so one can tell which version of the service one is working with.

Namespace versioning of Web Services is standard practice in mission critical software environments -- making it simpler to identify which version of the service one is working with.

Namespace versioning of a Web Service is standard practice in mission critical software environments -- making it easy to identify which version of the service one is working with.

There are a couple of clear-cut advantages to this approach. One is that the method makes it obvious exactly which version of a service one is working with. And this method also makes it easy to manage things like schemas when one is dealing with repository tools.

Mission Critical Software: Namespace Versioning "Gotchas"

But there are also a couple of "gotchas" that one must be aware of as well:

Either existing service consumers are going to "break" because when one changes the namespace of a service, fundamentally the document itself is being changed. The document is changed when the namespace is changed. It's as if these then become entirely different services when the namespace identifier for them has been changed. Thus, existing consumers are going to break ...
Alternatively, one will have to in some way explicitly support version compatibility: to support both the Version One and Version Two interfaces -- which may be entirely different. (... separate APIs which must be implemented in the service, even though they're only slightly different.)

Mission Critical Software Environments Need SOA Management

Note: The items in BOLD are required fields. You must supply a valid email address to complete the registration.

First Name
Last Name
Company
Title
Job Category
Industry
Email
Telephone
Address 1
Address 2
City
Country
State/Prov
Postal Code

Mission Critical Software: Challenge of Namespace Versioning

The challenge of namespace versioning in the mission critical software environment, though, is that essentially one is tossing out one of the key advantages of using XML. Unlike traditional distributed systems, XML has a unique property: with XML, one can add content to existing elements without breaking consumers -- so that a consumer and provider can actually be on different versions of a schema provided all that's being done is extending that schema without breaking either end of the wire. This is one of the nice things about XML that didn't exist before with traditional distributed systems, such as CORBA, COM and DCE.

Traditional distributed systems always locked onto the specific version they were talking to. With XML, the version that one designs against needn't be the version that one runs against. In XML schema, this is called the open content model.

Mission Critical Software: Best Practices Around Namespace Versioning

As one examines potential best practices around versioning with Web services in mission critical software environments, they're clearly different than those surrounding traditional distributed systems. One should only use namespace versioning in the appropriate situations: namespace versioning, for example, is a good solution when existing documents are going to be fundamentally altered. But if all that is desired is to add elements or add information to existing documents -- then it is best to take advantage of open content models. It will make versioning practices much, much easier -- and the results simpler to manage over time. Multiple copies of a service are not required, nor are multiple interfaces, etc. It just makes life a lot easier to take advantage of this unique feature of XML. So when versioning for Web services is considered, one ought not to think about the same kinds of models that the organization was previously forced to maintain with traditional distributed systems. Simpler options are available with XML and Web services.

Mission Critical Software: Maintaining Backward Compatibility

There are still times when it is necessary to have two versions of the interface, one for Version One consumers, one for Version Two. And there are a couple of different approaches to implementing this in mission critical software environments. One approach, shown below, is essentially to implement both versions of the interface inside the service itself. When the interfaces are significantly different and there's no way to transform between the two of them, this is really the only option, unless the other option is to totally break all Version One consumers. But since consumers don't typically version on the same life cycle as service providers, it may be necessary to maintain that backward compatibility.

Strategy for backward compatibility in mission critical software environments

Strategy 1 for backward compatibility in mission critical software environments

Strategy 2 for backward compatibility in mission critical software environments

Strategy 2 for backward compatibility in mission critical software environments

But for a consumer that talks Version One, a full transformation can be put in -- for example, an XSLT that will transform the Version One document to a form that is compatible with Version Two.

Mission Critical Software: Advantages of the WSM Intermediary Approach

In summary, there are several advantages to employing the Web service management intermediary to accomplish backward compatibility of versions:

The method allows a situation in which one no longer needs to support the service inside the actual service.
There's no need to support different versions of the interface. So it simplifies a lot of the service development.
No need for special code: just use graphical tools to build these interfaces.
And the approach provides a clear separation of the version dependencies.

Moving on, let us examine the next phase of versioning in mission critical software environments: Web services migration.

For More Information

Discover the secrets of SOA management -- and why mission critical software environments engaged in versioning can't do without it: download the free webinar, SOA Versioning Made Simple