Controlling Version Compatibility
As I mentioned, we're looking at the SOA service versioning from the client's perspective. The version control procedure may be easier understood if we assume following principles:

1)  A client engages a SOA service on the basis of a Service Level Agreement. That is, a SOA service represented by, for example, its Web Service interface, is invoked not when WSDL is available but when the client is fully aware of the service behavior and conditions. The latter includes a service version model and the corresponding interpretation of currently available service functionality. I'm happy to note that Thomas Erl also supports the concept of a versioned SLA that may include separate information about the endpoint, service, and interface. I discussed SOA service SLA in another article published in SOA Web Services Journal (vol. 6, issue 5).

2)  The compatibility between client needs and service functionality is expressed via a Version Control Policy (VCP). It's a set of rules that decide whether a particular version of the service is adequate to the client's needs and can it be used according to the SLA. The simplest case of the VCP is a single-rule policy saying that the service version has to be matched (be equal) to the version identifier represented in the client's request. You, probably, recognize the traditional API version usage in this case.

3)  The service version change doesn't automatically modify the VCP. To accumulate a backward-incompatible version change, the rule(s) in the VCP have to be explicitly changed. It's assumed that the VCP is written in a way that it can automatically cover backward-compatible version changes.

For the sake of simplicity, let's assume that the version elements are numeric. Other syntaxes are also possible but require additionally defined "operations" of the version element values. So, our example of a service version is 1.3.12.123456789045678905678 and the client's VCP rules are:

• Rule 1: IF srv 'EQ' 1
• Rule 2: IF nbc 'LE' 2
• Rule 3: IF bwc 'GE' 9
• Rule 4: IF rel 'GE' 123456789045678900001 where 'EQ,' 'LE,' 'GE,' 'LS,' 'GT,' and 'NE' are Boolean expressions such as "equal," "less-and-equal," "greater-and-equal," "less," "greater," and "not-equal" respectively.

1)  The client may not use the service of a particular version;

2)  The client's VCP has to be reviewed and rule(s) have to be adjusted to accept the service version. It's important to notice the adjustments may be done only if the new version meets the client's business requirements.

In some cases, the client's business requirements get into conflict with new service version and the client should continue using the previous version of the service. At the same time, if the client team knows what business features are to be provided in the coming/future versions of the service, the VCP can be set in a way that permits service invocation even when the new versions aren't backward compatible. For example, Rule 2 may be redefined as nbc 'LE' 5. That is, the current and two consecutive service changes that aren't backward compatible meets and will meet the client's business requirements. With such a VCP, the client can work without interruption even when versions change.

Thus we deal with the service version and the VCP. The service version belongs to the service; it may be accessed at the point of service announcement/registration. For example, for the service with a Web Service interface, it may be a UDDI; for a RMI interface, it may be an RMI registry; for other services, it may be JNDI/LDAP, or the CORBA directory service, or Microsoft Active Directory, or others. The VCP belongs to the client. To control policy preservation, we need a policy enforcement component (PEC). The PEC belongs either to the client or to the point of service invocation/announcement/registration. Irrespective of location, a client can register its VCP for a particular Service with a PEC.

Hopefully, you'd agree that SOA service invocation from a business perspective is a little bit more complex than just WSDL discovery with this or that version of the endpoint. To simplify a SOA service control, the PEC could always be set at the announcement/registration point and might be implemented as a PEC service. If a request for service returns something like a "not available" exception, it means there's no version of the service meeting the related VCP; the client might have to evaluate/consider a new version and adjust the VCP.

An independent PEC-based approach differs from the so-called "Service Versioning Covenant" model. The latter assumes that every service has its covenant, which governs all coming requests (messages and method calls) with regard to version compatibility. The covenant controls whether the request is done for the available version and simply refuses mismatching requests. The client doesn't have information about what version of the service component is behind the interface. The consequences are: the performance of the client requests degrades due to repeated controls, the client never knows if the next request will be denied due to a change in the service version, the client never knows if the new service version is suitable for it. Moreover, since every service can have different cycles for version changes, a service composition (a structure of services working with each other according to a scenario) may become broken at any moment. Thus, such a service-centric version control appears inefficient.

Version Control Layout
Figure 1 shows two ways of controlling the version of the service. The first way the service reference is obtained from the Service Registry and invoked. The PEC intercepts every invocation call. The PEC has to acquire the service's version from the service provider, apply a related VCR, and decide if an invocation is permitted. Since all service providers are free to define their own version models and mechanisms for accessing version information, the PEC has a quite challenging task. Plus, an in-call control degrades call performances.

The second way the PEC works in the Service Registry. The PEC validates the version information of the service at discovery time and returns the first version that satisfies the VCP. It's important to note that version control doesn't substitute for a functional search. If a functionally suitable service is found and the client has a related VCP, the PEC challenges the service version. However if the client doesn't have a VCP for the service, it's not recommended to engage the service based just on functional matching because of unknown business and technical risks.

Executing the PEC at the service registry level allows for the unification and formalization of the compound version model and version control mechanism. Unified rules and version formats can be shared between all users and vendors of the service registry. Validation of the version before service invocation works for in-call performances and prevents wasting resources on incompatible calls. So, let's see what we can do for a service registry to represent a compound service version.

Finding the Version of the Service
Released SOA services are usually registered in different registries as mentioned. For example, assume we have an EJB-based service. The service has two interfaces - Web Service (J2EE 1.4) and RMI/IIOP; the Web Service interface is registered in a UDDI and the RMI/IIOP is registered in a JNDI directory. To a client it's the same service providing the same business function so there should be an interface-independent service version available in both the UDDI- and JNDI-based registries.

As we know, UDDI has a special structure that permits registering the interface, usually defined by the <overviewURL> element, separately from registering the service component defined by the <businessEntit> element. Binding between the service component and its Web Service interface is specified in the <bindingTemplate> element, which is hidden inside the <businessEntit> element. Such a model causes discovery issues not only for the Web Services themselves but appears as an error-prone approach to SOA services because it allows registering the interface without registering the service component. Looking at a service registry from the client's perspective, the service features and the SLA are the primary interests while the service interface and the vendor name are secondary. Unfortunately, we don't have a real alternative to UDDI so far.

Using a UDDI taxonomy, i.e., its tModel concept, we can create and, via the UDDI API, register as many version entries as we need for a particular SOA service. The version entry may carry additional information about its state like "current" or "deprecated." Every vendor can specify its version namespace and use "version name" and "version information" accordingly. Since a VCP is created for a particular service, the client is aware of related version namespace and the version information can be actively utilized. Listing 1 is an example of a version namespace definition in a UDDI.

When the service version is in the UDDI, both the service component entry and its interface entry have to refer to the "uuid:whatever_key_for_theCompanyName_version_entry" and specify their version in the <keyedReference> element of the <categoryBag> element. Listing 2 offers an example of a version reference in an interface entry.

The definition of a version namespace allows a vendor to provide a strong naming convention regarding the keyName and keyValue. Until it is standardized, we can expect different vendors to define the different version namespaces the clients have to deal with differently. At least, for one company, the version namespace may be unified at the enterprise level and simplify the life of enterprise clients.

In spite of the version namespace definition, we inherit the UDDI problem and encounter the risk of having only one entry with a certain version value instead of two - for the interface and for the service component - in the service registry. I suggest this risk can be mitigated by a PEC service until a UDDI provides an appropriate control.

• Music and SOA: Theory and Practice