For a while, nobody seemed sure what to make of UDDI. Routinely cited as one of the three foundation standards of web services, it was rarely deployed in real-life implementations.

	express delivery
	• print  • comment
	Two years after the fanfare of its introduction, UDDI adoption levels remain low. But users are beginning to see UDDI directories filling a practical role: Adoption of UDDI is growing among web services pioneers Directory capabilities become more critical as the volume of services increases But UDDI's origins have left design challenges Most users will acquire UDDI as a component of their web services platform
	Glossary terms: UDDI, directory services, B2B, firewall, lookup tool Sponsored links: your text link here

Launched two years ago with the weight of IBM and Microsoft behind it, the Universal Description, Discovery and Integration protocol was originally designed to support a "Universal Business Registry" of B2B e-commerce services.

With web services being deployed either entirely behind corporate firewalls or, at best, between a handful of trusted partners, the notion of a public registry quickly proved irrelevant. Nor did a private registry make much sense when projects were limited to just a handful of services.

But now that early adopters have begun to move on to more complex implementations, they've encountered a need to catalog their business-critical web services — and at last UDDI's directory capabilities are providing tangible benefits.

Ian Bruce, director of marketing at web services infrastructure software vendor Systinet, suggests that this point was first reached in the second half of 2002. Adoption is still low — Bruce says that a "couple of dozen" of the company's users have deployed UDDI out of a total of 200 implementations — but that's set to change. In a survey published in November 2002, carried out in association with the Software & Information Industry Association and Computerworld, Systinet found that under five percent of the 779 respondents had deployed UDDI that year, but almost a quarter (23 percent) would do so in 2003.

Twists and turns

The latest specification of UDDI, version 3, has moved on from its B2B origins, adding features designed to meet users' needs for private registries. These include, for example, procedures for putting security keys into requests, or for enabling information transfer from one private registry to another. That said, the twists and turns in UDDI's evolution have also influenced its design and left some technical oddities.

UDDI defines three registry components, which in layman's terms are akin to the Yellow Pages phone book — or more precisely, to the trio of white, yellow and green pages. The white pages list companies' contact details and the key services they provide; the yellow pages categorize businesses using agreed taxonomies, including where they operate; and the green pages provide the technical data other companies need in order to take advantage of the services on offer.

These three components will become useful to various individuals when organizations start to run between 20 to 50 services, suggests Mukund Balasubramanian, founder and chief technology officer of Infravio. Developers, for example, will require information about services as they're built — what resources went in, what configurations were used and so forth. System administrators will want to look at the services from the perspective of how they were deployed — which servers they're running on, for example, and what the loads are. The business user taxonomy, meanwhile, will help end users find the services they need.

Design shortcomings

But there are design issues that arise from the fact that UDDI was originally created for public deployment and has now been retrofitted to cater for private web services environments. Balasubramanian cites the fact that every service needs an associated business entity, which makes little sense in an internal environment.

While some apparently unnecessary features have been left in, other more crucial elements are still absent. The original conception of UDDI was that the registries would be concentrated in the hands of a small number of large providers, which implied few variations between the different instances and a complete decoupling from internal operational considerations at individual businesses. Brent Sleeper, principal at San Francisco-based consultancy The Stencil Group, points out that this means, for example, that while the latest version of UDDI provides interfaces to underpin the process of publishing from one registry to another, actually managing that process is a separate matter.

Vendor interests

Looking to overcome the potential security and management shortcomings in the UDDI specification, some vendors have posited a role for directory services software from the likes of Novell and Sun. Because these products contain details that identify users — such as email addresses and access privileges — proponents argue that they can provide both security and user management functionality to complement UDDI.

This argument does not appeal to IBM and Microsoft, whose interests would be better served if UDDI sat on top of their own relational databases rather than a hierarchical directory services registry from a third party. And as IBM Software's vice president of emerging technology Rod Smith points out, one of the advantages of UDDI's B2B origins is a built-in predilection for loosely coupled interactions that conventional directory services may not share.

For users, the choice will come down to performance (potentially higher on a relational database), scalability (potentially greater on some directory services) and resource (if they've already invested in directory services software, it makes sense to leverage that outlay).

Into the infrastructure

Increasingly, though, the question of how and when to adopt UDDI will be taken by the vendors rather than their customers. A private UDDI registry is already built into the latest release of IBM's WebSphere web service platform, and other vendors are not far behind.

This may save organizations the trouble of getting their heads round what UDDI is or why it's important, but it will leave questions such as managing service quality and the degree of interoperability with other platforms unresolved. Ironically, those were the very same problems that stopped enterprises from eagerly adopting the B2B hubs of the dot-com boom. UDDI may have secured its place in the web services firmament by sidestepping such issues, but customers won't find it so easy to avoid facing up to them.

More on this topic