How registry is implemented can spell the difference between success and failure in an enterprise SOA — but there's disagreement on what works best.

	express delivery
	• print  • comment
	Early adopters extend registries beyond the core UDDI standard to provide vital SOA governance and information sharing: The core role of a registry is to enable service reuse Sabre has added marketing and governance functions For some, it's a system of record for service policy Level 3 stores developer documentation in the registry Interoperability of federated registries may be problematic
	Glossary terms: registry, UDDI, WSDL, OASIS, WS-I, lookup tool Sponsored links: your text link here

If the goal in implementing a service oriented architecture is to enable reuse, then at its core there must be a registry to store information on the services intended for reuse. Early versions of UDDI, the core standard for registry in a web services-based SOA, likened this to looking up numbers in a 'yellow pages' directory. But the phone book analogy doesn't do justice to the extent of information an SOA registry needs to store if it is to deliver meaningful productivity and competitive edge.

The challenge is not so much in understanding the basic function of the registry itself. That's now widely accepted, particularly as the core UDDI specification reaches maturity, addressing some of the concerns of the early gainsayers. The challenge lies in areas such as in organizing the registry so different user communities have access, solving any governance issues that emerge, and mapping business taxonomies to an SOA model. These are all increasingly important as IT organizations become more decentralized and the architectures they support more distributed.

Take the example of Sabre, the global travel technology and service provider. Having replaced aging APIs with web services for its service offerings, it now uses Infravio's xRegistry not only for governance — performing functions such as asset control and reporting — but also as a marketing vehicle, making use of various applications that Infravio has built on top of the basic registry.

Jim Bole, VP of products at Infravio, says: "The marketing organization has a lot of control over how customers interact with Sabre. The taxonomies and groupings we offered gave them the opportunity to use a representation of the infrastructure in an offering to a customer."

He adds: "They effectively use it as a bridge between business and IT: apply a business face to it, reorganize it, and turn it into an offer to the outside world." The key here is the ability for the registry to offer up different functionality to various classes of user. This is a facility other providers also offer, such as the business service console and advanced classification management in the latest Systinet Registry 5.5. Bole points out that getting this right means doing more than just recasting the user interface — it has to permeate throughout the application.

"Different constituents of the environment interact with the registry in different ways," he says. "IT wants to approve and predictably configure, load manage and provision services. Operations management wants to see performance and service level agreements. And consumers want to shop for services, and express their interest in some way."

Developer efficiency

Although Sabre's experience of registry only came once it externalized its use of web services, the application of a registry is equally significant on inward-facing projects, particularly in improving the efficiency of developers. One multi-billion dollar global technology corporation using Systinet's Business Service Registry found it had six different groups developing similar services and not sharing any of the fruits of these labours.

Helping an organization get its arms around what is out there is one of the most basic functions of the registry. The Systinet customer initially had 40 web services in operation, but is now close to 100 and is finding more every day as further business units start using the registry. "We feel the Systinet Registry is the cornerstone of our SOA infrastructure, and all else should follow," says the customer. "Now we're working on adding web services management and security."

But others question whether registry should be at the center of management, pointing out that it has a number of limitations. While a UDDI directory may contain information on contracts, for example, it has to integrate to a management product to enforce these. "UDDI doesn't have anything to do with management. The registry only manages pointers to data; it doesn't store data, it tells you where to find the data", says Paul Lipton, senior technology strategist at CA. "The thing people most often use UDDI for is to find the WSDL, information on what the web service is, how you use it and how you communicate with it."

When it comes to governance, too, UDDI as the so-called "system of record" elicits mixed views. It's clearly important to decide who is responsible for the service, what access rights will be given and whether maintenance is the responsibility of the security officer or IT. This is something that can be automated to an extent through use of a UDDI registry, but much of the information storage and process management involves extending beyond the core UDDI specification.

At a pre-publishing, design-time phase, organisations might also want, for example, to ensure services that are in the registry conform with WS-I standards and corporate schemas and append certain documentation. A registry is agreed to be a good place to store this data, which can then be used by others when developing applications that will make use of the services. Systinet customer Level 3's registry, for example, outlines what services are capable of; what service levels are offered; what the meaning of the different elements are; how much they cost; and what help documentation there is (read more about Level 3's registry implementation in the March 2005 issue of Loosely Coupled monthly digest).

Runtime governance

The role of registry in the post-publishing, runtime phase is more contentious. Sam Boonin, VP of marketing at Blue Titan, says: "The UDDI spec is ill-suited as a platform for runtime SOA govenance. It requires stringent adherence to tModels." The issue about rendering everything in the spec's modeling language is a serious weakness for UDDI's wider applicability and has been highlighted by early adopters.

Other early SOA implementations have tended to neglect registry, precisely because the UDDI specification wasn't widely accepted. Guljit Khurana, VP of product technology at webMethods, says: "One of the lagging areas of the early spec was it was rather unwieldy for users. We use UDDI as the registry in the background, but users don't have to touch UDDI."

Those early weaknesses have been addressed somewhat in version 3 of UDDI currently being voted on by members of OASIS, which oversees the UDDI specification. Partick Gannon, president and CEO of OASIS, says earlier versions of the spec may have been premature, making them less relevant to the real-world needs of early adopters. "If you look at UDDI, version one or two did not achieve broad adoption. If you compare that to ebXML, by version two things were so solid that we had several implementations around the world. It's like the tortoise and the hare; you can be first out of the gate but if you don't meet true business requirements [there's no advantage]."

Khurana adds: "UDDI is certainly gaining momentum, we have two customers interested in moving to UDDI; but from a metadata perspective a number of people want to go a lot further." In the meantime, too, other developments have been taking place. Blue Titan instead uses a metadata repository which can be rendered as UDDI but others are pursuing different standards proposals, such as WS-MetadataExchange, which is being proposed by IBM and Microsoft.

The limitations of the spec are a common refrain in reaction to UDDI — and even registry specialists like Systinet and Infravio point out they tend to focus on what they can add on top of the core specification. David Butler, VP of marketing at Systinet, says: "What we've learnt is that UDDI is not everything. UDDI is necessary but insufficient. A registry without UDDI is not going to work in an SOA. But where it lacks is the ability to map the business into the overall SOA model."

Another complaint is that it is only a repository for information on a very small piece of the stack. Lipton says that SOA management products tend to pass the information on through an SNMP trap, "handing the problem off to the grown-ups" such as CA Unicenter or another vendor's systems management product.

In fact, Graham Glass, CTO of webMethods, speaking at last November's XML and Web Services conference, highlighted this disconnect with everything outside of the services environment as one of the key weaknesses in SOA. "We think UDDI is a good specification. But if you create a shopping list of all the parts of your IT infractructure — services, schemas, business processes, portlets, workflows and databases for example — if you try to do all this in UDDI it would be very hard."

Glass called for UDDI to widen its scope and embrace some of the emerging standards in the semantice web such as RDF.

Federated registries

So much for the future. One final practical consideration that registry users need to get hold of today is the need for federated registries, which has helpfully been addressed in the latest UDDI spec through a root-and-affiliate topology. A joint demonstration at a Gartner web services conference in December proved interoperability between a number of different UDDI registries, including IBM, BEA and Systinet.

Lipton says there will always be a number of registries around, perhaps even from different departments of the same company and integrating between them is key. He gives the example of CA's big proof point at Microsoft Mappoint, where the user has its own registry. "Everybody wants to be the godlike, one and only registry — but in reality people will have more than one."

He concludes: "It's more complicated than to string a single thing in the middle that everybody has to go to and say: "Mother may I?" That's not very peer-to-peer or distributed — that's so 1980s client/server."

More on this topic