| The Universal Description, Discovery, and Integration standard (UDDI) is the technology for publishing and finding information about Web services that a business provides. Its goal is to enable companies to find one another electronically and thus facilitate e-commerce. Conceptually, UDDI can be compared to a telephone book's white, yellow, and green pages: -
The "white pages" contain information such as name, business identifiers, and contact information. -
The "yellow pages" include information such as industry codes and product classifications. It also contains the descriptive information about the services that the business makes available. -
The "green pages" provide the technical information about services that are exposed by the business. It contains the registering information about the URL or email address (or other address, such as telephone number) through which each type of service is accessed. The green pages also contain the references to information about interfaces and other properties of a given service. These service properties describe how a particular software package or technical interface functions. Technically, UDDI specifications consist of two things: -
An XML schema for SOAP messages that provides the necessary data structure to store the different kinds of information about a business. -
UDDI API specification. These APIs enable programmers to publish and find information about Web services in a registry. The applications use SOAP messages to both find and publish data in a UDDI-compliant service registry. UDDI Data Structure Types The UDDI XML Schema provides an information set for a Web service that includes the following types of information: Each piece of information is stored in one of the five XML data structure types that encompass the complete information about a Web service. Figure 2.3 shows the five data structures and how they relate to each other. The following sections examine them in more detail. 
The businessEntity Element The information about a business is stored in the businessEntity element. The information set consists of the unique identifier for the business, the name of the business, a description of the business, a list of categories and identifiers that describe the business, and a URL pointing to more information about the business. All this information is stored under different elements of the businessEntity element. The businessEntity element contains the businessService, bindingTemplate and tModel elements. Conceptually, you can think of businessEntity information as the yellow page entry for the organization. This enables applications to search for businesses by industry, product, or geography. The businessService Element Analogous to information contained in the green pages, this data structure contains information about the business services offered by the business entity and the technical descriptions of the Web services. The businessService structure represents a logical service classification; that is, it represents the Web services that are related to a business process or service category. The bindingTemplate Element The bindingTemplate entity data structure contains the actual technical Web service descriptions. These are the actual pieces of information that an application program uses to connect to and execute a Web service. This information includes the URL, binding key, and tModelInstance details. The tModel Element The bindingTemplate entity provides the technical information needed to execute a Web service. However, simply knowing the URL is only one part of the deal. The invoking application also should know other technical details, such as the format of the data supported by the Web service, protocols, security issues, the format of the response, and so on. Such technical specifications are represented by the tModel element. The tModel element contains the pointer to technical specifications. Therefore, by referencing to a specific tModel, a Web service guarantees that it is compatible with the technical specifications as laid out in the referenced tModel. The publisherAssertion Element A single businessEntity is often not sufficient to represent all the business processes performed by large organizations. Therefore, such businesses publish many businessEntity structures. However, because they are part of the same business or enterprise, they are related. The publisherAssertion entity provides the capability by which one business can make visible in a UDDI registration its relationship with another business entity. UDDI APIs The UDDI specification provides two categories of APIs: the Publish API and the Inquiry API. The Publish API The Publish API enables the publication and management of information contained in a UDDI-compatible registry. It consists of four save_xxxx functions and one set_xxxx function to save each of the five data structures. For example, there is a save_binding() method, in which the complete information set contained within the bindingTemplate element can be saved or updated. Correspondingly, there are five delete_xxxx functions for each of the data structures. For example, the bindingTemplate information for an organization can be deleted using the delete_binding() method. Other than the save and delete functions, there are five other function calls that help you publish information in a UDDI-compliant registry. The Inquiry API The Inquiry API provides the capability to query UDDI registries. There are two types of API calls: those that enable you to find businesses, Web services, and specifications, and those that help you dig into the specifics. The find_xxxx functions fall into the first category, and the get_xxxx APIs fall into the second. For example, the find_binding() method returns a bindingDetail message that contains the bindingTemplate structures matching the criteria specified in the argument list. NOTE To learn more about the Publish and Inquiry APIs, see http://www.uddi.org/pubs/ProgrammersAPI-V2.00-Open-20010608.pdf.
| 
Print 
E-Mail 
Add Note 
Add Bookmark
