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.

Security for WESB services: WSRR as a good-governance alternative to LDAP groups

Quite frequently, access to Enterprise Services is secured based on individual user, but on requesting application (department, organization, org unit, etc). If one or another application in your company consumes an Enterprise Service, you may not be particularly interested in the identity of individual user behind a screen who clicked a button on an internal Web page, resulting in Web application making a call to mainframe behind the scenes. Knowing that the call came from a known internal application may be enough. In fact, often times there will be no individual user at all: the service call may be coming from a batch or unattended process.

If your Enterprise Service is hosted on WebSphere Enterprise Service Bus (WESB), how do you configure security (authentication/authorization) for this scenario? One obvious option is to leverage standard security mechanisms of WESB, which are effectively J2EE based. Create an ID for each requester application in your enterprise LDAP and use standard role-based access control to authorize access. Normally, you will create an LDAP group for each services access role and assign application IDs to those LDAP groups. This approach is simple and familiar to enterprises. But I can see one shortcoming: governance is often difficult to establish.

Defining access policies for enterprise services is responsibility of Enterprise Architects. But it is difficult to do this using LDAP. In a typical enterprise, processes for governing LDAP security changes are geared toward end user access. Roles, personnel involved, tools, ticket approval systems – everything is set up to deal with end user accounts. Enterprise architects are not involved in this process and would not be comfortable with security tools, because individual account maintenance is not their responsibility. Looking at the problem from the other side, security administrators may not even want to give Enterprise Architects access to account data that is required to effectively govern service account roles.

One possible solution to the governance dilemma is to use a true service governance tool, such as WebSphere Service Registry and Repository (WSRR). WSRR comes with a prebuilt governance templates in “Governance Enablement Profile”, including definition of SLA. If you establish an SLA between each service consumer application (department, etc) and consumed service. Then, in WESB (or WPS), you can insert “SLA Check” mediation primitive before actual invocation of a service. SLA Check primitive is new to WID/WESB/WPS version 7.0. It is very simple: it consults configured WSRR instance to determine whether there an SLA for particular service exists (for a particular user and in a particular context) and returns a simple yes or no. Now your service access is under control of WSRR, which Enterprise Architects understand and (hopefully) use daily. Service access is governed by the same tool as all other aspects of the service.

Problem solved? Unfortunately, WSRR solution has several shortcomings of its own:

  • LDAP-driven security is declarative, but WSRR-driven requires SLA Check primitive to be inserted (is programmatic)
  • Out of the box SLA lifecycle is quite evolved and requires several document types to complete. It is likely too complex for a simple task of service authorization
  • Establishing an SLA for every consumer-service pair is a lot of work.

All in all, I would recommend using SLA Check for service authorization if you highly value service governance, are unsatisfied with LDAP governance tools and process and prepared for the task of creating a massive number of SLAs. Otherwise, LDAP role-based security is still a more reasonable choice.

WSRR: WS-I validator and loading WSDL files

To WebSphere Service Registry and Repository (WSRR) practitioners, I’d like to recommend this excellent developerWorks article explaining how to leverage WS-I compliance validator that is part of that software. Among the things you will learn: how to make this validator enforce arbitrary restrictions expressed in Schematron.

Just one thing to keep in mind: this article was written for WSRR 6.2 and you will not be able to reproduce the scenario in this article with default settings of WSRR 6.3 (original or with Fixpack 1). This is because MAKE_GOVERNABLE event will not fire for WSDL documents containing endpoint definitions in default setup. I recommend that you replace MAKE_GOVERNABLE with CREATE event in sample code – then it will work.

Here’s how the story unfolds. When you load a service document (a WSDL document or a SCA module) into WSRR, a complex sequence of actions is taken by the software behind the scene. WSDL document is validated. The document is parsed and concepts relevant to WSRR are identified. Those include service, port, binding, operation, message and endpoint definitions, XML schema elements and types. All these objects are linked together. As these objects are created, configurable modifier kicks in to enable governance and initiate appropriate lifecycle. Once one item in a collection of linked objects has governance enabled, all other linked items are pointed to the same governance record. From that point on, they are governed together: it is not possible to enable governance separately for any other item in the linked collection.

Configurable modifier named “Triggers” contains the following fragment:

<!-- Mapping to push the relevant items through the Service Endpoint Lifecycle -->
<model-type model-uri="http://www.ibm.com/xmlns/prod/serviceregistry/v6r3/ServiceModel#ServiceEndpoint"/>
<model-type model-uri="http://www.ibm.com/xmlns/prod/serviceregistry/v6r3/ServiceModel#MQServiceEndpoint"/>
<model-type model-uri="http://www.ibm.com/xmlns/prod/serviceregistry/v6r3/ServiceModel#SOAPServiceEndpoint"/>
<model-type model-uri="http://www.ibm.com/xmlns/prod/serviceregistry/v6r3/ServiceModel#ExtensionServiceEndpoint"/>
<configuration name="InitiateEndpointLifecycle"/>

And configurable modifier named “InitiateEndpointLifecycle” includes this:

<?xml version="1.0" encoding="UTF-8"?>

<action-configuration xmlns="http://www.ibm.com/xmlns/prod/serviceregistry/Actions"
xsi:schemaLocation="http://www.ibm.com/xmlns/prod/serviceregistry/Actions Actions.xsd">

<!-- Transition the selected object into the SLA Lifecycle -->
<make-governable-action uri="http://www.ibm.com/xmlns/prod/serviceregistry/lifecycle/v6r3/LifecycleDefinition#InitiateEndpointLifecycle"/>


These 2 modifiers are both enabled in Governance Enablement profile. Putting all this together, if a SOAP Service Endpoint is found in WSDL document, a SOAPServiceEndpoint object will be created and endpoint lifecycle will be initiated. WSDL document itself will be linked to the governance record of the SOAP Endpoint. It will not be possible to enable governance on the WSDL document separately.

Indeed, when a sample WSDL is loaded, we see exactly this effect. When I click on newly loaded WSDL document and proceed to the Governance tab, I see the following:

Governance Tab of WSDL document

Governance Tab of WSDL document

If I click on the “Root governance record” link, it takes me to the SOAP Service Endpoint:

SOAP Endpoint governance tab

SOAP Endpoint governance tab