Adding UDDI to directories

Some time back I quoted Stu Bailey, founder and CTO of InfoBlox, who described Universal Description, Discovery and Integration as "DNS on steroids." I've also called the UDDI initiative a very good description of a directory project. But UDDI seems to have become so hopelessly interconnected with the current rage for " Web services " that some can't envision Web services without UDDI.

<aside> The machine hosting Web services is called a " Web services server. " I guess that's so you won't confuse it with the ordinary, garden variety " Web server. " </aside>

Evidently though, there's still some hope for the ultimate victory of rational thought. Two bright young things (Bruce Bergeson and Kent Boogert) at Novell have offered an Internet Engineering Task Force Internet-Draft entitled "LDAP (Lightweight Directory Application Protocol) Schema for UDDI" (see it at www.rfc-editor.org/internet-drafts/draft-bergeson-uddi-ldap-schema-00.txt ).

According to the abstract, it defines the schema for representing UDDI data types in an LDAP v3 LDAP-enabled directory. It defines schema elements (objects) to represent all of the UDDI data types - a businessEntity, a businessService, a bindingTemplate, a tModel, and a publisherAssertion. Each is accompanied by the various attributes allowed or mandated by the UDDI spec for the object.

Of course, that's the easy part. We've seen that the UDDI " registry " (the name for the datastore in the UDDI spec) is very similar to a modern directory, so porting the data types to directory objects shouldn't be that difficult. Building a UDDI front end for the directory - that'll take a little time.

It's not that building the UDDI interface is particularly difficult. The specification is contained within the API set published by the UDDI organization (www.uddi.org). But just as it took a while to add an LDAP-enabled front-end to existing directory services when LDAP became all the rage, so to the drudge work of adding UDDI enablement will take a while.

The amount of drudgery can only be appreciated if you visit the UDDI Web site and download and read the specifications which, for some reason, are only available in PDF or Microsoft Word format. Whatever happened to HTML? For Version 2 of UDDI you'll need:

* UDDI Programmer's API Specification (the programming interface exposed by the registry).

* UDDI Data Structure Specification (the details of each of the XML structures associated with the approximately 30 SOAP messages used to perform inquiry and publishing functions against the registry).

* UDDI XML Schema.

* UDDI Replication Specification (programmatic interface required to achieve complete data replication between UDDI Operators).

* UDDI XML Replication Schema (not data replication, but XML replication).

*UDDI XML Custody Schema.

* UDDI Operator's Specification (not the person, but the organization operating the node).

Of course, if you also want to be UDDI Version 1 compliant, there are another three or four specs to assimilate. That IS drudge work. But UDDI evidently isn't going away, so we will have to accommodate it. Somebody better get busy.

Dave Kearns is a writer and consultant in Silicon Valley. His most recent book is "Peter Norton's Complete Guide to Networks" published by SAMS. Dave's company, Virtual Quill, provides content services to network vendors: books, manuals, white papers, lectures and seminars, marketing, technical marketing and support documents. Virtual Quill provides "words to sell by..." Find out more at Virtual Quill or by e-mail at info@vquill.com

Directories archive
Past newsletters.