- Service-Oriented Architecture (SOA)
- Extensible Markup Language (XML)
- Universal Description, Discovery, and Integration (UDDI)
- Web Services and Other Technologies
- Phases of Adoption
- Summary
This chapter is from the book
This chapter is from the book
This chapter is from the book
Universal Description, Discovery, and Integration (UDDI)
The vision behind UDDI is to provide a distributed repository that clients can search (during design time and runtime) to find Web Services. Originally launched as a collaboration among Microsoft, IBM, and Ariba in September 2000, the UDDI consortium has since grown to include hundreds of members.
UDDI can be thought of as two major concepts:
The specifications. These standards describe how such repositories should work and include three major concepts: white pages, yellow pages, and green pages. These will be described further below.
The implementations of the specifications. Microsoft and IBM are UDDI operators of two public repositories, called business registries, which are the first public implementations of the UDDI specifications. A company can register at one repository and be confident that the entry will be replicated to the other repository (currently, the entries are replicated every 24 hours). However, for security reasons, any updates must be performed at the repository where the service was first registered. Of course, like everything else that is related to Web Services, the entries in the UDDI repositories are XML data. As mentioned, the business registries are examples of public registries; we will discuss private registries in detail below.
UDDI Categories
A UDDI repository contains entries about businesses, the services these businesses provide, and information on how those services can be accessed. Modeled after a phone book, a UDDI directory has three categories:
White pages contain basic information about a service provider, including the provider's name, a text description of the business (potentially in multiple languages), contact information (phone number, address, etc.), and other unique identifiers such as the Dun & Bradstreet (D&B) rating and the D&B D-U-N-S Number.
Yellow pages include the classification of either the provided service or the registered company using standard taxonomies. Examples include
Standard Industrial Code (SIC)
North American Industrial Classification System (NAICS): a classification scheme specific to the United States, Canada, and Mexico
Universal Standards Products and Services Classifications (UNSPSC): an open global standard used extensively by catalog and procurement systems
Geographic taxonomies: location-based classifications; for example, US-CA indicates a business in California
Green pages contain the technical entries for the Web Services—the address of the Web Service, the parameters, etc.
The entries in a UDDI directory are not limited to Web Services; UDDI entries can be for services based on email, FTP, CORBA, RMI, or even the telephone.
UDDI Data Model
The UDDI data model includes an XML schema that provides four major elements:
The businessEntity element represents the owner of the services and includes the business name, description, address, contact information categories, and identifiers. Upon registration, each business receives a unique businessKey value that is used to correlate with the business's published service. The categories and identifiers can be used to specify details about a business, such as its NAICS, UNSPSC, and D-U-N-S codes—values that can be useful when performing searches.
The businessService element has information about a single Web Service or a group of related ones, including the name, description, owner (cross-referenced with a unique businessKey value of the associated businessEntity element), and a list of optional bindingTemplate elements. Each service is uniquely identified by a serviceKey value.
The bindingTemplate element represents a single service and contains all the required information about how and where to access the service (e.g., the URL if it is a Web Service). Each binding template is uniquely identified by a bindingKey value. l The service does not have to be a Web Service; it can be based on email (SMTP), FTP, or even the fax.
The tModel element (shortened from "technical model" and also known as the service type) is primarily used to point to the external specification of the service being provided. For a Web Service, this element (more specifically, the overviewURL child element) should ideally point to the WSDL document that provides all the information needed to unambiguously describe the service and how to invoke it. If two services have the same tModel key value, then the services can be considered equivalent (thus allowing the requester potentially to switch from one serv-ice provider to another). Here is a useful metaphor: a tModel that can be thought of as an interface for which there can be multiple implementations, presumably from different companies since it does not make sense for a firm to implement more than one service for a given tModel (just as it would not make sense for a single class to implement the same interface in different ways).
UDDI Usage Scenarios
As mentioned earlier, a service-oriented architecture involves three roles: client, provider, and service broker. To illustrate the flexibility of the UDDI model, we'll use the example of the MegaBucks Consortium.
MegaBucks Consortium (a financial consortium) wants to create a standard way of valuing small retail businesses and then publish this information so that its member firms can implement Web Services to conform to that standard. In this example, the consortium operates a private registry (see the next section on types of UDDI registries for more information on private versus public registries). To allow its members to access this standard, the consortium needs to
Produce a WSDL file to define the specifications to which a valuation service should adhere. The provider of the valuation serv-ice would most likely be a member of the financial consortium.
Publish the WSDL file at a public location (for example, www.megabucks.org/valuation.wsdl on its server, or any publicly accessible location).
Create a tModel to represent the valuation service specifications (these specifications are described in the WSDL file mentioned in our first bullet point).
Publish the tModel in its registry. As part of the publishing process, the registry issues a unique key for the tModel (5000X, for example6) and stores the URL of the WSDL file in the overviewURL child element of the tModel element.
Figure 2–6 illustrates this sequence of events.
)
Figure 2–6 Creating a tModel.
A firm that wants to publish a Web Service to comply with this standard (presumably a member of the MegaBucks Consortium) needs to do the following (see Figure 2–7 for the sequence of events outlined in the bullets):
Publish its business to the private registry operated by MegaBucks Consortium.
Publish the Web Service with a bindingTemplate, access point of which is the URL of the firm's Web Services implementation and whose tModel's value (5000X) is that of the tModel published by MegaBucks Consortium. In essence, this member firm is advertising that its valuation service complies with a set of specifications (captured in the tModel) established by a consortium (in this case, Mega-Bucks Consortium).
)
Figure 2–7 Using the tModel.
As mentioned earlier, multiple firms can publish Web Services that implement the same tModel.
A firm that actually wants to invoke the valuation service (e.g., a holding company that buys other businesses) first has to know the value that represents the valuation service (in this case, 5000X) and must use this value to locate the Web Service either statically (by browsing the operator nodes via the Web) or programmatically. If the search results in more than one service, then the client can use other criteria (price, location, etc.) before selecting a provider.
In our example:
MegaBucks Consortium is a publisher (because it is publishing a service—the tModel) and a service broker (because it is hosting a repository that requester firms are searching).
The member firm—the one that is providing the actual valuation service—is the provider.
The holding company is the client.
Figure 2–8 illustrates the requester locating the valuation service and invoking it.
)
Figure 2–8 Locating and invoking a Web Service.
Types of UDDI Registries
UDDI registries can be categorized into two major groups:
Public. Anyone can publish an entry in a public registry, which has no process to ensure the validity of its entries. (The business registries operated by IBM and Microsoft are examples of public registries.) Because an entry is not validated, there may be questions as to whether the business actually exists, whether the services are even provided, and whether the services are delivered at an acceptable level. For these and other reasons, many believe that public registries will not be feasible for a long time.
Private. A private registry is a more likely scenario for the majority of the firms because each firm can enforce certain criteria on an entry before it is published to the repository. There are different variations of private registries including
EAI registry. This is useful for large organizations that want to publish commonly used services by various departments or divisions. Without a central repository, these services are often duplicated. An example would be a service for accessing the human resource legacy system.
Portal UDDI. The registry is located behind a firewall. Therefore, the external users can search for entries, but only the operators of the portal can publish or update the entries in the portal. In a sense, this is the model of the portals today. Users can browse and invoke services (such as stock quotes), but they cannot add new services (although they can personalize the views).
Marketplace UDDI. Only members of the marketplace (typically a closed environment) can publish and search for serv-ices. This type of registry is appropriate for vertical industries. The marketplace operator can establish qualifying criteria before an entry is added to the repository and can then provide additional fee-based services such as certification, billing, and nonrepudiation.