Talking about EJB and JNDI, we have to distinguish between service and application types of the versioning models. For applications, version control can be done at the build and deployment stages via, say, Manifest files specified in the application archives (Graham Hamilton of Sun Microsystems offered more information about versioning and dependency mappings for Java applications at the last JavaOne conference). For services, we have no more choices than we discussed before - controls on every invocation or controls at the lookup of the EJB reference (Home interface). Since the former may be ineffective, we'll concentrate on the latter.

The deployment descriptor of an EJB or an RMI service defines a JNDI name that the component reference is bound to. Looking at the name structure, one can easily find that a JNDI name represents a hierarchy of names. This means that a lookup operation performed, for example, by a Service Locator module (see Service Locator pattern) can explicitly navigate along the name-tree instead of making a single call on the composite JNDI name. So the JNDI name may have an immutable version part and a changeable version part. The Home interface or service reference binds to the changeable version part, which is a child of the immutable service part in the naming hierarchy. The example in Figure 2 demonstrates the version name hierarchy for the following versions:

Thus, doing a lookup operation, the client's Service Locator represents the immutable service part of the JNDI name to the PEC. The latter navigates to all the children of the immutable service part - the names in the changeable version part - combines possible version expressions, and challenges them against the VCP. The service reference bound to the first found 'matching' combination of version names is returned. The client's code can cache the reference and reuse it in consecutive RMI service invocations or for narrowing the Home interface reference to the EJB Object interface references.

If a service provider discards an RMI service, the service invocation returns an exception. It's recommended to make at least one attempt at obtaining another RMI reference under the previous VCP before reporting an error (because the service may be redeployed). If the EJB is redeployed under the same JNDI name, narrowing always returns the current reference to the Object interface transparently to the client. If the service invocation fails under the same VCP, it may mean that the previous version isn't supported anymore. So the client has to do a business review of the new version of the service and, if possible, adjust its VCP.

Conclusion
This article promotes the idea of a SOA client viewing a SOA service as a monolithic entity with an easily interpreted compound version. A compound version can hide multiple versions of service components and separate versions of elements of the Web Services representing the service interface. The proposed version model and an approach to the version control based on the client's version policy open a way for flexible version management even for changes in the SOA services that aren't backward compatible. Compound version specification is illustrated for a UDDI and a directory structure. The example shows two ways of applying the policy enforcement mechanism and promoting policy control at the service registry for service lookup operations.

References

• UDDI Core tModels. www.uddi.org/taxonomies/Core_Taxonomy_OverviewDoc.htm
• Liang Yu. "Understanding UDDI's tMode." www.codeproject.com/soap/understandingTModels.asp
• Kyle Brown and Michael Ellis. "Best practices for Web Services Versioning." www-128.ibm.com/developerworks/webservices/library/ws-version/
• Chris Peltz and Anjali Anagol-Subbarao. "Design Strategies for Web Services Versioning." http://webservices.sys-con.com/read/44356.htm
• Kirk Allen Evans' Blog. "Versioning Web Services." http://blogs.msdn.com/kaevans/archive/2004/12/03/274271.aspx
• Heather Kreger. "A Little Wisdom about WSDM." www-128.ibm.com/developerworks/webservices/library/ws-wisdom/
• Thomas Erl. "The Principles of Service-Orientation Part 2 of 6: Service Contracts and Loose Coupling." http://searchwebservices.techtarget.com/tip/1,289483,sid26_gci1171966,00.html
• WSDM-MOWS 1.0 specification, Draft. www.oasis-open.org/committees/download.php/5664/wd-wsdm-mows_versioning_change_2.23.04a.doc
• Don Smith. "[Web] Service Versioning Guidance." http://blogs.msdn.com/donsmith/archive/2006/01/31/520338.aspx
• Rocky Lhotka. "A SOA Versioning Covenant." www.theserverside.net/news/thread.tss?thread_id=33434
• Service Versioning. http://orchestrationpatterns.com/serviceVersioning?PHPSESSID=4dee379138a5d1f6b59e02468f2ef0ec
• Dragos Manolescu and Boris Lublinsky. SOA Enterprise Patterns - Services, Orchestration and Beyond. Book Draft. http://orchestrationpatterns.com/files/ServiceVersioning.pdf
• Java Futures at JavaOne: www.theserverside.com/news/thread.tss?thread_id=40569

• Music and SOA: Theory and Practice