UDDI

version: 1.0
date: 2001-11-07 14:37:45

Overview of Universal Description, Discovery and Integration

A brief introduction to UDDI

UDDI
IBM Alphaworks
IBM Developerworks
IBM Services
WSDL
Stencil Group

What is UDDI?

The Universal Description, Discovery and Integration (UDDI) project is an effort by several major industry players to create a common protocol for interacting with a wide range of companies and non-corporate entities. At it's core, UDDI is a combination of an XML schema and a directory service. The directory service component is a central business registry which serves as a search engine that interfaces with the XML doc. The XML doc contains descriptors for the business information (name, location, etc), the services that business offers online, and technical details of how to interact with the services.

That's all neat-o, but so what?

UDDI is the business complement to technologies such as XML-RPC and SOAP. It allows a company to discover and interact with new partners and to work more efficiently with existing partners. There are already thousands of services that can be transacted over a network (be it the internet, an intranet, or an extranet). UDDI is an attempt to codify those services and help companies describe them to potential clients/partners as well as to help companies find out what's available and where.

How?

UDDI creates a framework for describing any sort of service (peer-to-peer file sharing, http, ftp, IM, accounting, financial quotes, pizza delivery, etc). The registry component provides a form of yellow pages, in which one can search for businesses offering a given service that meet certain criteria (location, price range, business name, etc). Once located, the user can view their UDDI doc and determine exactly what services they offer and see how they will be able to interface with those services. In the case of existing business partners, it will dramatically speed the process of determining how to interact with the Accounts Payable system, for example.

Details, man, I need details

The Schema: Business Info, Service Info, Binding Info/Specs. Like this.

1. The businessEntity element of the schema contains, as noted before, the basics such as business name, address, phone number. Nothing thrilling, but necessary nonetheless.
2. Service Info contains descriptors of the services offered grouped by business process (shipping, purchasing, etc) with additional delimiters such as industry, geographic boundaries, etc. It also contains some basic technical info on each service (what is the URL, support options, routing info, etc)
3. bindingTemplate describes how to actually connect to a service (format, protocol, security, response info, etc). This is the complex part, natch.

Example

Your company currently is in need of market analysis service, and you have an established business relationship with Nu-Perfect America. Rather than calling a sales rep and having a half dozen calls/emails/etc go back and forth trying to figure out if they can provide the specific type of analysis you want and what you need to do to interface with them, you fire up your browser and search for Nu-Perfect America + Widget Trend Analysis. It promptly shows you that they do indeed do what you want, and it provides you with the API information you need to interact with the system. As you already are a client of theirs, you simply pass on the technical info to your developers, who are able to talk to Nu-Perfects software quickly and easily.