UDDI: Publishing and Discovering Web Services
After you have defined the data in the messages (XML), described the services that will receive and process the message (WSDL), and identified the means of sending and receiving the messages (SOAP), you need a way to publish the service that you offer and to find the services that others offer and that you may want to use. This is the function that UDDI (universal distribution, discovery, and interoperability) provides.
The UDDI framework defines a data model in XML and SOAP application programming interfaces (APIs) for registering and discovering business information, including the Web services a business publishes. UDDI is produced by an independent consortium of vendors, founded by Microsoft, IBM, and Ariba, to develop an Internet standard for Web service description registration and discovery. Microsoft, IBM, Hewlett-Packard, and SAP are hosting the initial deployment of a public UDDI service, which is conceptually patterned after DNS, the Internet domain name service that translates Internet host names into TCP addresses. In reality, UDDI is much more like a replicated database service accessible over the Internet.
UDDI is similar in concept to a Yellow Pages directory. Businesses register their contact information, including such details as phone and fax numbers, postal address, and Web site. Registration includes category information for searching, such as geographical location, industry type code, business type, and so on. Other businesses can search the information registered in UDDI to find suppliers for parts, catering services, or auctions and marketplaces. A business may also discover information about specific Web services in the registry, typically finding a URL for a WSDL file that points to a supplier's Web service.
Businesses use SOAP to register themselves or others with UDDI; then the registry clients use the query APIs to search registered information to discover a trading partner. An initial query may return several matches from which a single entry is chosen. Once a business entry is chosen, a final API call is made to obtain the specific contact information for the business.
Figure 2.5 shows how a business would register Web service information, along with other, more traditional contact information, with the UDDI registry. A business first generates a WSDL file to describe the Web services supported by its SOAP processor (1) and uses UDDI APIs to register the information with the repository (2). After a business submits its data to the registry, along with other contact information, the registry entry contains a URL that points to the SOAP server site's WSDL or other XML schema file describing the Web service. Once another business's SOAP processor queries the registry (3) to obtain the WSDL or other schema (4), the client can generate the appropriate message (5) to send to the specified operation over the identified protocol (6). Of course, both client and server have to be able to agree on the same protocol—in this example, SOAP over HTTP—and share the same understanding, or semantic definition of the service, which in this example is represented via WSDL. With the widespread adoption of these fundamental standards, however, this common understanding of WSDL seems ensured.
Figure 2.5 The UDDI repository can be used to discover a Web service.
Next >> ebXML |
