sapienti sat: Making SOA Ready for the Enterprise

Why is it so hard for Governance products to do Service Versioning right?

In almost every SOA Governance-related RFP that I have come across service versioning appears near the top of the list right after security and monitoring have been dealt with. And the requirements are fairly consistent (as outlined below), why then some many Governance offerings have gaping holes in this area? I have heard vendor responses ranging from “we can capture version number as metadata” or “you can register several versions of a service separately and use ESB to route between them” to the extreme “there is no need to version services – if anything visible to the client changes, you just register a new service”. None of which seems to be useful to an organization that want to stick with SOA after the pilot project was declared a success. I think I have found the underlying cause, but let me first start with the

Basic Service Versioning Requirements

1. It should be possible for providers to publish and consumers to use multiple versions of the same service at the same time.
2. They should be clearly identifiable as versions of the same service.
3. It should be possible to designate the default version of a service, which will be invoked if no specific version has been requested. Default version doesn’t necessarily have to be the latest one.
4. It should be possible to designate compatibility relationships between service versions. “Version A is compatible to version B” means that A can process requests intended for version B and return responses that the client of B will understand. In other words it is safe to route to A requests intended for B.
5. Clients can request specific versions explicitly by passing version number with the request or implicitly by using the request that can be resolved to a specific version.
6. If explicit version number is not provided and implicit resolution fails, requests will be routed to the default version.
7. If requested version can be identified and that version is available, request will be routed to that version.
8. If requested version can be identified and that version is not available, but there is another version that is designated as compatible to it, request will be routed to the compatible version.
9. If requested version can be identified, that version is not available and no compatible version can be found, the request will be rejected.
10. Behaviors described in #1 through #9 should be available declaratively (through configuration, not coding).
11. It should be possible to implement custom versioning aspect that would be able to enhance or override behaviors described in #5 through #9. For example if requested version is unavailable and no compatible versions have been specified, such aspect instead of rejecting the request can transform it to a form that can be understood by one of the available versions. A corresponding transformation of the response would occur on the way back.
12. The system should advertise the WSDL corresponding to the default version, however clients should be able to view and retrieve WSDLs for all currently active versions.
13. The system should distinguish between non-disruptive (adding a new service version or retiring a version for which a compatible version exists) and potentially disruptive (retiring deprecated version, changing the default version, changing existing version numbers) actions. The versioning mechanism should be integrated with the change management mechanisms such as Lease and Notifications and should be able to trigger corresponding functions following a potentially disruptive action.
14. When user designates version as compatible to another, the system should be able to perform basic validation (check for missing operations, incompatible massages, etc.).

Nothing too difficult or complex, isn’t it? Why is it then so hard to come by a solution that meets most of these requirements? My theory is that

Registries are to blame!

Here is now – in the registry information models (both UDDI and ebXML Reg/Rep) Service is on the top of the food chain amongst the functional components (services can belong to an Organization, but the latter is purely a business entity encapsulating people and contact information) representing both primary and highest level entity. But in order to provide the capabilities described above one need to have a primary entity representing individual invokable versions and a higher-level construct (uber-service if you will) that will represent the logical service with all the versions and relationships between them. It does not seem possible to map such model to UDDI or ebXML RIM and remain “standards compliant”. This is why you will not find adequate support for logical service versioning in registry-centric products. They can version things: WSDLs, schemas, policies, etc but not the SOA Services, as defined here. The run-time centric solutions in theory do not have this handicap, but most of them joined various interoperability frameworks pushed by the registry vendors, to be able to check off the compatibility boxes and had to adapt their information models to those defined by the registry standards. This is why when designing SGF we decided to stay away from all the “standards” existing in or around SOA space and define our Governance Information Model based on the analysis of the problem domain and typical customer requirements, rather then various legacy compatibility considerations. The versioning-related part of the resulting model looked like this: Where:

• ServiceOffering represents the entire consumable service form the client’s perspective with all the functional and non-functional properties;
• ServiceComponent represents just the functional part with all the versions, virtualizations and refinements;
• ServiceVersion a single virtualized version, which in turn is an aggregation of individual Operations.

Needless to say that a governance solution based on such model can easily meet all of the versioning (and many other) requirements.