The UDDI project revolves around making the promise of service-centric computing real and achievable so that more and more companies can take advantage of it. Many businesses today use the Internet as a means to reach their customers and suppliers in an effective way. Reaching new customers and integrating supply chains in real-time has been made possible by the reach and simplicity of the Internet-based communication medium. An Internet-based business model is a vital part of business strategy of these businesses.

The use of Internet (and World Wide Web [WWW]) today, however, is limited in several ways:

The potential of Internet-based business models is not fully exploited as a result of these issues. UDDI.org and the UDDI project aim at addressing these issues and provide specifications to various solution components that resolve them.

UDDI proposes to create a “directory of business services” that provides listings of services, applications, and other software components developed to facilitate intercompany communication at the system level. This directory, conceptually built on but smarter than the real-life Yellow Pages, can provide a standardized way to discover new business entities. It facilitates companies to describe their services at an API-level and at the business-process level so that they can be discovered by potential trading partners with compatible business models and processes. Once discovered, the trading partners can quickly form a system-level communication channel (along with human-level engagement) to affect the new partnerships rapidly. Eventually, this can lead to lowered barriers for a company to participate in the global economy.

The UDDI project members had planned to hand over the UDDI specifications to a standards body after the third revision. As per that plan, the ownership for the specification has been transferred to Organization for the Advancement of Structured Information Standards (OASIS) in 2002.

The “public UDDI infrastructure” that is supported by the above three operators is the public instantiation of the UDDI specification. Together, these sites create a uniform view of all the businesses that are registered within UDDI infrastructure. This infrastructure is called the Universal Business Registry (UBR). The registries that are part of the UBR operate in unison, and are a replica of each other for basic registry information. It is possible to create UDDI sites that are not part of the UBR. As noted earlier, the Systinet UDDI instance is not part of the UBR.

Any UBR site primarily provides basic functionality for a business to participate in the registry:

While the UBR sites are meant to be used, primarily, in a programmatic way, all UBRs provide browser-based interactivity. This can be used to explore UDDI functionality. In Section 5.2.2, we discuss general UBR functionality using Microsoft’s UBR instance. Other UBRs provide similar functionality as well. Typically, the browser-based functionality is a subset of overall programmatic functionality.

The Microsoft UBR instance can be used for registering, discovering, and browsing a business or a service. Anyone can browse (look up information in) the UBR, but in order to add information to the registry the user must first register as a publisher. The registration is based on Microsoft Passport service. The URL https://uddi.microsoft.com/register.aspx provides user registration which is based on an email address. Figure 5.1 shows the registration of the email address: [email protected]. Note that the email address provided must be a valid email address. Registration cannot be completed until the email-based step is completed.

Figure 5.1. User registration with Microsoft UBR.

After successful registration, an email is sent to the email address and the user can provide additional information such as username. Clicking on the link provided in the email completes the registration process. To verify successful registration, login at the Microsoft UDDI site.

Registering a Business

A registered user can add a business entity within the UBR. Business entity registration consists of providing details about the company it represents. To register a business entity, click on the add business link after user login. Figure 5.2 depicts the registration for a business — Inside Webservices.

Figure 5.2. Adding a business with Microsoft UBR.

Business registration typically includes the name of the business as well as a free-formatted string description. The description for Inside Webservices is “Get up-to-date information on Web services technologies.”

Upon successful registration of a business, several new options to register services and other business attributes appear as shown in Figure 5.3. The user must click on the Publish button to publish the business to the site. This process includes validation and usually takes less than a day.

Figure 5.3. Successful addition of a business with Microsoft UBR.

Any user can discover any business registered with the UBR. This includes the businesses registered by other users as well. Figure 5.4 depicts the discovery of the business entity Inside Webservices. Figure 5.5 shows the successful discovery of the business. Note that this search is case-insensitive and that wildcard searches are supported. The underlying UDDI APIs provide both case-sensitive as well as case-insensitive search mechanisms.

Figure 5.4. Finding a business with Microsoft UBR.

Figure 5.5. Successful search of a business with Microsoft UBR.

Discovering a Business

A successful business discovery is presented with a URL for the found business entity. Clicking on the link takes us to the information about the business entity as shown in Figure 5.6.

Figure 5.6. Details for a registered business.

The information provides several key data items about the discovered business.

Examples of this key data are the name of the business, any contact information, if added, and the field Business Key.

Every registered element, such as a business entity, a service, or a service interaction model, in a UDDI registry is assigned a universally unique identifier (also called a UUID). The Business Key shows the UUID for a business. The UUID for the business Inside Webservices is: 735F7664-930F-4D8C-80A6-0A9B154162A3. A UUID uniquely identifies any element in the UBR infrastructure. The UUID key for a service is called Service Key. This mechanism ensures that UBR-registered elements can be uniquely addressed during discovery and interaction.

Regardless of which element is being assigned a UUID key, the underlying concept for all of them is the same. A UUID is a 128-bit value that is either guaranteed to be unique or extremely likely to be unique until 3400 A.D., based on the choice of algorithm. One advantage of the UUID scheme is that it does not require a central authority to generate the keys. Hence, it is a very attractive scheme to allocate unique identifiers in a distributed environment such as the UDDI UBR. UDDI has adopted the 8-4-4-4-12 Hex representation of the UUIDs.

Note

The UDDI Operator Council does not mandate any specific algorithm for generating UUIDs. However, if required, it may review the algorithm used by a UBR participant. Several UUID generation algorithms are described at:

http://www.ics.uci.edu/pub/ietf/webdav/uuid-guid/draft-leach-uuids-guids-01.txt

The successful search of a business entity also provides a discovery URL that can be cached for future reference. Clicking on that link returns the full UDDI XML representation of the business entity it represents. Some of the information fields shown are private to the entity that registered it (registration owner). This information is not publicly visible.

Registering a Service

Once a business entity is registered, services can be added to its portfolio. One business entity can register several services. Figure 5.7 shows the registration of the service Learn UDDI under the business Inside Webservices, while Figure 5.8 depicts successful service registration. Note the additional information such as the service classification and binding that is maintained within the UDDI registry.

Figure 5.7. Adding service to a business entity.

Figure 5.8. Successful search of a service with Microsoft UBR.

Binding a Service

The service registration so far concentrates only on certain informational elements such as name and description. However, for the registration to be useful, the information to access the service is also necessary. Such service bindings can be used to interact with the service using the appropriate communication protocol.

In UDDI terms, such a binding is called a bindingTemplate. BindingTemplates denote access points for registered services. For a service, there could be several access points possible. For example, a service might be accessible via email, through a Web page, or via the File Transfer Protocol (FTP). Figure 5.9 shows how to add a binding for a service. In this case, a mailto binding is added to the service Learn UDDI.

Figure 5.9. Adding binding to a service.

These are the minimum steps required to list a service in a UBR. Advanced features provided by the UBR are discussed throughout the book.

A company interested in joining the UDDI community can register itself and its services in the UDDI registry. In Section 5.2.2, we discuss a simple example to do that. Usually, a fair amount of technical and business expertise is needed to register a complex business and its service portfolio. While it is possible for some companies to have the necessary expertise in-house, several companies may not have it. This could potentially slow down the adoption of UDDI.

To address this issue, a class of companies, called UDDI Registrars, has emerged. A UDDI registrar is a company that can perform the registrations on behalf of other companies. A registrar acts as a “consultant” to a company or business that wishes to list itself and its services in the UDDI registry. Such consulting would typically include:

UDDI registrars are functionally analogous to companies such as Register.com, Inc. (http://www.register.com). Register.com provides the basic services required to register a new Internet domain with the Internet Corporation for Assigned Names and Numbers (ICANN) — the corporation that oversees the management of the Internet domain name system. Besides the domain name registration, Register.com also provides other value-added services, such as domain hosting and Web page designing, through its partners.

There are several companies that are currently acting as UDDI registrars. Promi-nent among them are Peregrine Systems and Riskebiz Internet Services Inc. In the future, more companies are likely to play the role of registrars as UDDI becomes more popular among businesses worldwide.

Figure 5.10. Successful addition of service binding.

To bring uniformity among various UDDI operators, and to ensure high availability of the UBR, the UDDI project has defined a specification for potential UDDI operators. The UDDI Operator’s Specification provides the details on several operational aspects of the UDDI registry instance. Some important aspects of this specification are:

The operator council is comprised of the UBR operators. This group deals with the operational aspects of the UBR — such as uptime, compatibility, and interoperability. The council owns the UDDI Operator Agreement that defines the stipulations that all UBR operators must abide by. It also administers the UBR testing plan. This plan ensures that all UBR sites operate cohesively as part of the UBR cloud. A secondary purpose for the UDDI Operator Council is to be the first implementer of the specification and provide feedback to the UDDI Working Group. This feed-back not only adds to the over all quality of the current specification, but also guides future versions.

A programming language provides the means to communicate data among various components of an application. The most commonly used mechanisms are passing parameters through function calls and object serialization. Technologies such as Common Object Request Broker Architecture (CORBA) also facilitate data communication between objects that are deployed across different computers — a technique called Remote Procedure Call (RPC). This type of programming model is called Network Object Model (NOM).

The DEM programming technique is different from NOM. It models the interaction between two “objects” as an exchange of a series of structured text documents, rather than chunks of data laid out in some language-specific format.

The DEM-based application design has several advantages over their NOM-based counterparts. Since a structured document can be parsed and understood by virtually any language, it is possible to facilitate interaction between any two objects (or applications) written in potentially incompatible languages. Table 5.1 provides comparison between the two techniques.

As can be seen from this comparison, the DEM programming model is more suitable for intercompany interactions that are normally long-lived (completed over a long period of time) and happen across multiple firewalls on various platforms. At the root of the DEM model is a structured document. The extensible Markup Lan-guage (XML) has become a de facto standard for creating such documents.

The UDDI programming APIs are essentially the XML schemas for interacting with the UBR. Unlike typical programming APIs, the UDDI APIs provide the schemas for XML-based request and response documents. These APIs dictate how the XML document should be formatted to interact with the UDDI registry. For example, here is the syntax of the find_business API that is used to discover a business that matches certain criteria.

<find_business [maxRows="nn"] generic="2.0" 
               xmlns="urn:uddi-org:api_v2" > 
     [<findQualifiers/>] 
     [<name/> [<name/>]... ] 
     [<discoveryURLs/>] 
     [<identifierBag/>] 
     [<categoryBag/>] 
     [<tModelBag/>] 
</find_business> 

We discuss individual tags such as categoryBag in greater detail in Chapter 7–9. However, at this point, it is important to note the nature of the UDDI APIs. These APIs also require that the XML document is, in fact, sent as a Simple Object Access Protocol (SOAP) message. The SOAP technology, which facilitates the RPC mechanism in the DEM world, is conceptually much the same as the traditional RPC mechanism in the NOM paradigm. Appendix G provides a summary of SOAP technology. The UDDI API specification further stipulates that the SOAP message be sent over the Hypertext Transfer Protocol (HTTP). Thus, the SOAP message over HTTP forms the fundamental transport protocol for any UDDI related interaction. A UBR instance, hosted by any operator, can understand and will respond in only a SOAP encoded message over HTTP.

The UDDI API specification has undergone changes as more and more functionality is added and changes are made to existing APIs. The first specification Version 1.0 was released in September 2000. The Version 2.0 specification was released in June 2001. The UDDI Working Group released the Version 3.0 specification in July of 2002.

This book deals primarily with the Version 2.0 specification, since that is the specification implemented by all existing UBR instances. Discussion of Version 3.0 has been included in Chapter 14.

The UDDI APIs are classified in two main categories:

The Inquiry APIs, as the name suggests, are APIs used for querying a UDDI registry. The query can be used to discover either a business or more specifics about services offered by a specific business. The Publish APIs, on the other hand, are used to publish information about a business or its services.

The information published about a company (and its services) is at the center of effective participation of that company. The Inquiry APIs search the published information in order to return the appropriate businesses or services. Thus, registration owners must ensure sufficiency and accuracy of registration information. Registration information can be categorized in three ways:

This type of categorization can be likened to their namesake in a phone directory.

The business entity Microsoft Corporation, is already registered at the Microsoft UBR site and is discoverable by any user. Figure 5.11 depicts the organization of this business entity.

Figure 5.11. The Microsoft Corporation business entity.

The business entity is the overarching element that has several elements, such as services, registered underneath. The business entity and the contact information form the White Pages section. The services themselves are part of the Yellow Pages category. Information pertinent to the Green Pages section, such as bindingTemplates and tModels, can also be found wherever applicable. For example, look at the Home Page service. The registered information is as follows:

UDDI4J provides a set of Java APIs to interact with a UDDI registry. It is not the only Java API available today, but it is likely to be a dominant API due to endorsement from IBM and HP. The UDDI4J is an ongoing open source project. The programming examples provided in this book primarily use the UDDI4J APIs. We discuss these APIs in more detail in Chapters 7–9.

The Java community also provides an answer to the need for Java APIs for a UDDI registry. The Java APIs for XML Registries (JAXR) effort, however, is an overar-ching initiative that aims at providing a uniform set of APIs for all XML registries including UDDI and ebXML. The JAXR APIs are currently available as an early access release.

The .NET framework, announced and championed by Microsoft, provides support for the UDDI initiative. The .NET platform provides the Microsoft UDDI .NET SDK that helps in building UDDI client-side components using the .NET technology. The SDK provides APIs for languages that run in the .NET runtime.

While the UDDI registry can be used to register any services, it has been developed primarily with Web services in mind. Thus, to effectively use all the features available in UDDI, a good understanding of Web services technology is helpful. A complete in-depth discussion on Web services is beyond the scope of this book. In the next chapter, we provide a brief overview of the Web services concepts and the technologies used to develop them.