A search is a search, even if it happens to disclose nothing but the bottom of a turntable.
UDDI is in effect the publicity arm for Web services. It satisfies the self-advertising mandate of Web services. It is a standardized process to publish and discover information about Web services (as well as other services) programmatically or via a graphical user interface, which would typically be Web based. OASIS, which took over the stewardship for this technology as of July 2002, has a subheading in the UDDI.org section of its Web site that states: Universal Description, Discovery, and Integration of Web Services. Appending the two crucial words Web services to UDDI makes the goal of UDDI that much easier to perceive and appreciate.
A banner on that same OASIS Web page succinctly and elegantly highlights what UDDI is all about by saying: UDDI is a key building block enabling enterprises to quickly and dynamically discover and invoke Web Services both internally and externally. UDDI as such is a universal, totally open , platform-independent mechanism for describing, discovering, and integrating (i.e., consuming) Web services, though it can also be used to describe and advertise non-Web services “ related services (e.g., the 1-800 toll-free, mail-order telephone number for a traditional brick-and-mortar business).
The mission of UDDI is to provide a standard, uniform service, readily accessible by applications via a programmatic interface or by people via a GUI, for describing and locating the following:
Business and organizations that offer various services ”Web services being one such service
Meaningful description of the services being made available by the businesses and organizations listed as service providers
Technical information as to how to locate, access, and utilize a particular service
As with all things related to or inspired by Web services, UDDI is highly XML-centric. The core information model used by UDDI, irrespective of the kind of service being described, is based on an XML schema. This UDDI XML schema deals with the following four types of key information as it relates to service providers and the services they offer, whether Web services or otherwise :
Business information pertaining to a business or organization providing one or more services ”which, in the context of the UDDI model, is referred to as the businessEntity
Sets of related services (e.g., a set of Web services concerning purchase order processing and another set concerning online inventory checking) being offered by a previously described business or organization ”which are referred to as businessService elements
The binding information necessary to invoke and make use of a particular, previously described, service (whether a Web service or otherwise) ”referred to as a bindingTemplate element
More technical information (or even a technical blueprint) about a service, over and above the binding information necessary to connect to it, such as pointers to detailed specifications, protocols used by the service (e.g., SOAP, HTTP, or SMTP in the case of a Web service), and possible type classification for that service ” which is known as a technical model (tModel)
There is a prescribed hierarchy among these four data structures. This hierarchy is shown in Figure 4.1. These four core data structures have been a part of UDDI from the start. They form the nucleus of what UDDI is all about. Two other data structures have been added since, one in UDDI Version 2 and the other in Version 3. These two data structures deal with:
Relationships between business or organization entities (e.g., certification, alliances, membership, trading partnerships, and so forth), asserted to by one or both of those entities. This data structure, referred to as publisher Assertion, was introduced with UDDI Version 2.
Standing orders subscribed to by companies, organizations, or individuals requesting automatic notification in the event of a change to specific entities within the UDDI registry. This data structure, used for such automated change notification, which was introduced with UDDI Version 3, is referred to as operationalInfo. It is used, at present, to provide a change-order subscription mechanism. Consequently, this data structure is also sometimes referred to as subscription.
Figure 4.2 extends the data structure hierarchy shown in Figure 4.1 to show how these two additional structures come into play.
The UDDI specification per se describes the XML schema for this information model, SOAP messages to transport the XML-based information, and a set of APIs to manipulate and manage the UDDI data. There are two key APIs: the UDDI inquiry API, which can be used to search or browse through the information contained in a UDDI Registry, and the UDDI publication API, which enables programmers to create or delete the information structures within a UDDI Registry. Invoking a UDDI API results in one or more SOAP messages being generated. There are about 40 inquiry and publishing functions “related SOAP messages that can be generated against a UDDI-compliant registry by the UDDI inquiry and publishing APIs.
UDDI, however, is not just a sterile specification. The UDDI instigators ”namely, Ariba, IBM, and Microsoft ”made sure that there would also be publicly accessible sets of implementations of the UDDI specification. They also made sure that other companies would actively buy into the UDDI initiative. They were successful in that endeavor, too.
In September 2000, when UDDI was initially unveiled, it was endorsed by about 30 blue-chip companies, including Sun, Compaq, Dell, American Express, Merrill Lynch, and Nortel Networks. Today this number is in excess of 200. UDDI is also a standards-based interoperable service available for free on the Web ”with both a user-friendly graphical interface and a programmatic interface that conform to the UDDI APIs.
The two pivotal standards exploited by UDDI are XML and SOAP. Note that WSDL is not one of the prerequisite standards used by UDDI. In reality there is no formal relationship between UDDI and WSDL. They do, however, complement each other. Given that WSDL can be used to describe the interface of a Web service, there is obviously a role that WSDL can play vis--vis UDDI. The tModel for a Web service could thus point to a WSDL description, as could the bindingTemplate.
UDDI enables enterprises, individuals, and software applications to quickly, easily, incisively, and dynamically locate and obtain Web services, as well as other services. Though originally intended as a global public service available via the Web, the UDDI specification does not preclude private and semiprivate implementations. The global public UDDI service, referred to as the Universal Business Registry or as the UDDI Business Registry (UBR), has been in operation since late 2000. The information maintained in the UBR can be accessed programmatically using a UDDI API, or via the Web-based user interface. Figure 4.3 shows SAP s Web-based user interface to the UBR. The equivalent Microsoft and IBM interfaces to the UBR are shown in Figures 1.7 and 1.8.
The UBR was originally run by the three companies that collaborated to develop the initial UDDI specification, which was published in September 2000 as Version 1.0. Today, the URB is being run by IBM, Microsoft, NTT Communications, and SAP ”with Ariba, sadly, no longer involved. H-P, which was supposed to take Ariba s place when Ariba opted out, is also not a UBR player right now ”partly due to the distraction of its merger with Compaq and partly to preclude the concept that the UBR was a wholly U.S. operation. In addition to the public Web-centric UBR, there is now also the concept of intranet UDDI implementations that serve just one enterprise, as well as extranet UDDI implementations that serve a group of enterprises collaborating with each other as partners .
Microsoft s new Windows Server 2003 includes a full-blown enterprise UDDI capability for realizing intranet or extranet implementations. IBM also offers a similar capability in its new WebSphere Application Server Network Deployment (WAS ND) V5 ”which has subsumed the previously available WebSphere UDDI Registry offering. In addition, UDDI-related development tools, some of which include private UDDI registries, are available from a wide variety of other vendors , including BEA, Sun, Novell, Fujitsu, IONA, and Cape Clear Software.
With the ready availability of these products and tools, there will now be a surge in intranet and extranet UDDI implementations as businesses and organizations gingerly start to evaluate the potential and power of Web services by using them in-house and in conjunction with trusted partners for pilot projects. Enterprise UDDI registries will enable these not-ready-for-prime-time-as-yet Web services to still be properly categorized and represented, using standard UDDI mechanisms, within the privacy of intranets and extranets. Recognizing the appeal and applicability of enterprise UDDI registries, the latest UDDI specification, namely, Version 3, sets out to specify the concept of UDDI registry interaction (i.e., how private UDDI registries can coexist and interoperate with the public UBR).
UDDI, given what it sets out to do, is a directory. It is a directory of businesses and organizations that provide various services. Thus, it is not surprising that UDDI is invariably thought of as a kind of electronic telephone directory ”particularly an electronic yellow pages of sorts. In reality, UDDI is more, much more, than just a yellow pages directory that is organized purely by service type. UDDI also is a white pages directory in that it lists service providers by name . Consequently, the information contained in UDDI is best thought of as being divided into three distinct categories, referred per telephone directory parlance as the following:
The white pages contain descriptive information about businesses and organizations providing various services. The business or organization name and a textual description of what they are will be included, where appropriate, in multiple languages. Contact information for that entity will also be included in terms of contact names , phone numbers, fax numbers , e- mails , and URLs. It will also list any known industrial identifiers, such as a Dun & Bradstreet (D&B) D-U-N-S nine-digit identification sequence, which uniquely identifies a particular business. The Thomas Registry identification scheme is another option.
The yellow pages, on the other hand, categorize businesses and organizations per industry-standard taxonomies. At a minimum, businesses and organizations will be categorized in terms of their industry, the products and services they offer, and their geographic location. The North American Industry Classification System (NAICS), which has superseded the U.S. Standard Industrial Classification (SIC) system, is one of the taxonomies that can be used to specify industry classification. Similarly, the United Nations Standard Products and Services Code System (UNSPSC) can be used to specify product/service classifications. UDDI is also innately extensible. Thus, it permits the use of new taxonomies provided that all users of the UDDI Registry have a means of interpreting the classification scheme used.
The green pages are where the technical information needed in order to use an available service is catalogued. The green pages, in effect, contain the information contained in the bindingTemplate and tModel data structures for a given service ”as listed in a businessService entry (as shown in Figures 4.1 and 4.2). To wrap up this phone book analogy, note that the white pages contain the information found in the businessEntity data structures of a UDDI Registry, whereas the yellow pages categorize, per accepted taxonomies, the information maintained in the businessService data structures. The green pages, then, augment the entries in the yellow pages by including the information found in the bindingTemplate and tModel structures for that particular service. Figure 4.4 depicts the UDDI information content in terms of the phone book model, whereas Figure 4.5 correlates the phone book model to the UDDI information hierarchy shown in Figure 4.1.
The bottom line here, for the time being, is that UDDI in general, and the public UBR in particular, are cornerstones of the overall Web services initiative. Given that it provides the search mechanism for locating applicable Web services, the eventual success and popularity of Web services are obviously going to be contingent, to a large degree, on the efficacy of UDDI. Given that the deployment and adoption of Web services have yet to live up to expectations, it is not surprising that the UBR, at present, is not brimming with germane entries.
Nonetheless the volume, the categories, and the amount of information per entry has been slowly but palpably growing since the summer of 2002. The availability of full UDDI functionality, as a standard, no-charge feature within Microsoft Windows Server 2003, will further increase UDDI awareness and promote enterprise-level implementations. Based on these trends, one has to assume that by 2010, professionals in the business community will often stop to ponder how they used to locate businesses and services prior to the advent of UDDI ”in much the same way that percipient people today often wonder : How did we manage to do that before the Internet?