Effective WSDL service versioning in WSRR

WebSphere Services Registry and Repository (WSRR) is IBM’s tool for SOA governance. From technical perspective, the tool focuses on 2 kinds of services: WSDL services and SCA modules. WSDL services in WSRR are associated with WSDL documents (physical files serving as a vehicle for WSDL XML). Services and documents may be versioned. The concept of versioning is fairly important in WSRR, which is to be expected of a governance tool. Each object governed by WSRR, including services, is equipped with a version attribute, which makes up part of its identity. WSDL services are identified by name, namespace and version. Sounds great, but let’s take a closer look at the way versions work in WSRR and how it helps enable service governance. I will concentrate on WSDL services. SCA module versioning is a bit different since a SCA module may have a version number “baked in”.
Normal service lifecycle contemplates changes in service interfaces expressed in WSDL. Some changes are backward-compatible and some are not. Imagine you have a service that is widely used within your organization. If a change is needed that is not backward-compatible, it would not be a good idea to simply replace old service with new one without notice. Frequently organizations adopt a versioning scheme that adds version number (possibly in a form of a timestamp) to service namespace. This helps clearly define which version of the service is in use. This approach is advocated in IBM developerWorks article “Best practices for Web Service versioning”.
For example, you might have an AccountLookup service that has just undergone non backward-compatible upgrade. Old service may have been AccountLookupService in namespace “http://www.acme.com/services/accounts/2010/03” and new one is in namespace “http://www.acme.com/services/accounts/2010/12”. This works well for all concerned, but because of different namespaces, these 2 services will not be recognized as the same service. The value of version attribute does not matter. You have 2 completely different WSDL services in WSRR. How do you tell WSRR that 2 WSDLs represent 2 subsequent versions of the same service?
For a solution, look outside the pure technical realm of governance. WSRR defines several non-technical concepts that assist in establishing governance: Business Capability, Business Service, Business Application. To understand why one would use these concepts, let’s remember the SOA mantra that every service exists to fulfill business purpose. SOA is a business-IT initiative and Service-Oriented Architecture can not exist without service identification. Once AccountLookup service has been identified, business function it carries out should be documented. This holds true for all services, whether newly developed from business requirements or pre-existing IT capabilities being exposed as a service. In WSRR terms, recognizing business function means defining a Business Service.
Business Service in WSRR may have a charter or other documents attached to it. And naturally you can associate any number of WSDL services with a business service.
So here is a recipe for service versioning in WSRR:

  1. Once a service has been identified, create a Business Service definition in WSRR. It will represent the business function of the WSDL service
  2. Each WSDL version,once loaded in WSRR, should be associated with a Business Service that will serve as its container

One interesting corollary of this approach is that it effectively marginalizes the value of version attribute for WSDL documents and services. You may still use it, e.g. to relate to version number of WSDL document in an external document repository. However, I do not expect to see it as identity differentiator for WSDL services: there will be no WSDL service in WSRR with same name and namespace, but different version numbers. I do not see this as a problem, though.

My Prolifics colleague Rajiv Ramachandran suggested an enhancement to this versioning scheme: add “previous version” and “next version” relationships to WSDL services and make all versions of the same WSDL into a double-linked list. This will make it possible to easily navigate the successive versions of the same service from the latest to the oldest and reverse.


Comments are closed.

%d bloggers like this: