After a couple of years of listening to e-business promises, I’ve come to realize that it is very difficult to establish Internet trading partners. Acquiring partners is still a manual process. First, you have to search for businesses with which you can share services and products. Then, you have to find out which Internet interfaces they have before you are finally able to build the Web infrastructure.

A new e-business framework is being developed to change all that. It’s called Universal Description, Discovery, and Integration, or UDDI. UDDI is made up of three components:

• White pages with business and contact names
• Yellow pages with searchable industrial categories
• Green pages with technical information on available Internet services

Companies that wish to establish an Internet trading partner and already have some information about a company (such as a Dun and Bradstreet number or a tax ID) can use the white pages to find services that the potential partner might have. Most often, companies have no idea who might be a potential partner, so companies use the yellow pages to search for a partner. Either way, once a site has been found, you can request the green pages to find out which services are available through a partner.

A Little SOAP Goes a Long Way

I guess you realize that UDDI isn’t really a phone book with white, yellow, and green pages. Rather, all information is handled by a stack of protocols: UDDI (a protocol itself), Simple Object Access Protocol (SOAP), XML, and the common Internet protocols of HTTP and TCP/IP. XML is the obvious way for UDDI to package information; after all, XML is the ubiquitous database of the Internet. (For more on XML and SOAP, see my article “Technology Spotlight: XML: The Language of Confusion” in the March 1999 issue of MC and Eduardo Ross’ “Doing E-business with XML Schemas and SOAP” in the September 2000 issue of MC.) SOAP is the delivery mechanism, and it defines a way to make remote procedure calls between Internet sites.

SOAP was selected as UDDI’s delivery mechanism because it is independent from language and operating system. UDDI is comprised of a couple of basic XML types, which

I simplified to call white, yellow, and green pages, respectively: businessEntity, businessService, and bindingTemplate.

UDDI requests such as find_business are packaged into SOAP envelopes and sent via HTTP. The Web finds a UDDI-compliant site by using a UDDI lookup that is much like a Domain Name System (DNS) request. Once a company registers with an instance of the UDDI business registry service, the company’s UDDI-registered data is automatically shared with other UDDI root nodes and is then available to anyone who needs to discover which Web services are exposed by that company.

So what do you get back from a UDDI find request? Well, XML, of course. In the case of a find_business request with a parameter of say, IBM, you’d get a detailed listing of elements currently registered for IBM that includes information about the UDDI services provided by IBM.

From there, you can drill in and get information about one specific service. For example, if you were to drill in on the UDDI Web service, you could take the businessKey from the returned results and use find_service to look up a service by name. You could then use the service key that is encapsulated in the returned XML packet to get details about a particular service.

Room to Grow

UDDI has been off to a great start. So far, Microsoft, IBM, and Ariba are the major contributors to the UDDI project, and it’s moving fast. The UDDI specification is well designed, but, as yet, it is still a young protocol, so it will have to gain momentum as an Internet standard before it becomes very useful. If you have Internet Explorer 5.x, you can try UDDI today by pointing your browser to http://msdn.microsoft.com/voices/12182000- test.htm. Microsoft usually implements Web technologies before standards are established, so, on my Linux workstation, I can’t access this sample UDDI application. (Microsoft’s example accesses UDDI via JScript and calls to their Microsoft-specific XML parser.)

Besides having to wait for UDDI standards to be ratified, the other issue with UDDI is that it does not, as yet, have specifications that will support full B2B connections without manual intervention. Today, all you can do with UDDI is find a company and its UDDI-registered services. After that, you’ll have to establish contact with that company and agree on the protocol for further information exchange. Those two problems aside, I believe UDDI is a well-designed specification that is sure to become a standard for B2B applications.

REFERENCES AND RELATED MATERIALS

• Ariba's home page: www.ariba.com
• IBM's UDDI Web page: www.ibm.com/services/uddi
• Microsoft's UDDI page: http://uddi.microsoft.com
• Sun's XML Developer Connection UDDI Web page: www.sun.com/software/xml/developers/uddi
• UDDI home page: www.uddi.org

Don Denoncourt is a freelance consultant. He can be reached at This email address is being protected from spambots. You need JavaScript enabled to view it..

---

MC Press books written by Don Denoncourt available now on the MC Press Bookstore.

		Java Application Strategies for iSeries and AS/400 Explore the realities of using Java to develop real-world OS/400 applications. List Price $89.00 Now On Sale