Registries Galore

How many registries do you need to support an SOA infrastructure? I would like to think that the answer is two, one for development and one for production, but I am afraid that this is hopelessly optimistic.

Firstly, you may need to support more than just two phases in the development cycle, so we may need design, development, system test, stress test and production registries. This is not too bad as we understand how to manage change management and promotion to production.

The next reason for multiple registries is that different organisational units of an enterprise will want to control the services they develop; if there is a registry that is the obvious point of control. So we will have a set of registries for each fiefdom. UDDI v3 recognises the need to support federations of registries but the processes and the management controls required are in their infancy. In this cycle of SOA development there will be a need for a lot of manual control and integration.

However the number of registries will be further multiplied by the need to use registries from different vendors. On the UDDI.org site there is a list of a dozen registries. All of these registries support one or more versions of the UDDI standard and most of them also support extra functionality, which may be a positive thing but it also creates problems (as Robin Bloor indicated in his weekly blog). The extra functionality is used by the vendors’ application development, business process management, enterprise server bus, and similar products. This means that to use that product requires the vendor’s registry. It is highly likely that a mature SOA environment will use products from multiple vendors and therefore require multiple registries.

So if you have four phases of development, three relatively independent organisational units within the enterprise and an average of three vendors per unit, then one enterprise will have close to forty registries. The need for a flexible registry interchange service is apparent.

Discussions I have had in the last few weeks have highlighted this problem:

• I wrote an article ‘UDDI inadequate for SOA’ following a briefing from the OASIS ebXML technical committee that described their registry/repository and how UDDI functions can be built on top of it. Sun has an implementation of this standard and products that use all the extra functions that ebXML provides.
• Systinet has a UDDI v3 implementation that is being imbedded by (amongst other vendors) BEA, in Aqualogic, and by Oracle, in Fusion. Systinet has now announced a significant extension to the registry, code-named ‘Blizzard’. The extensions will support contracts, policies, lifecycle management and governance. The extensions are important and will be used by the vendors to support more complete SOA solutions.
• IBM has its own WebSphere UDDI v3 Registry which is shipped as part of WebSphere Application Server – Network Deployment. All of its related products such as the ESB and Process Manager will use this registry by default. It is just a UDDI v3 registry without any extensions so it may be possible to replace it with another standard registry, but I would not want to be the first to try.
• Finally, and very recently, Fujitsu and Software AG have announced the joint development of CentraSite. The first release is UDDI v2.4 registry but early next year they plan to deliver a UDDI v3 version. CentraSite has been developed to support business process management and integration products from the two partners. There are extensions that enable dependencies between services to be captured; this should be a considerable benefit in the future as it will provide impact analysis of changes to services. The latest versions of the BPM and integration products from both partners will require the extensions and so will only be able to work with the CentraSite repository.

The extensions provided by the different vendors are useful and will be appreciated by the user. Unfortunately however, the extensions are unlikely to become standardised in the foreseeable future, so the answer of “two” that I gave to my original question: “how many registries do you need to support an SOA infrastructure?” is also unlikely to be true even in the unforeseeable future.