4.1 The rationale and motivation for UDDI

4.1 The rationale and motivation for UDDI

UDDI was conceived at the time that the dot.com frenzy was building to its crescendo. E-business seemed unstoppable as the long-sought-after panacea for expediting and streamlining commerce. Against this backdrop, UDDI was initially envisaged as a standards-based, vendor-neutral mechanism for globalizing and simplifying Web-based, electronic b2b interactions. UDDI would automate many of the discovery and integration aspects of an eventual e-business transaction ”particularly those having to do with locating the appropriate partners (e.g., suppliers in the case of an SCM scenario) and the mechanisms by which these potential partners conduct business.

UDDI would eliminate the guesswork and chance that was then an inherent part of e-business, given the lack of globally accepted directories for listing e-business participants . The main issues that UDDI intended to address included the following:

  • How an enterprise, whether a business or organization, identifies other enterprises around the world that may be able to provide it with necessary services (or goods)

  • How enterprises could describe themselves and the services they offered in a structured, systematic manner so as to attract prospects interested in such services

  • How an enterprise could sift through and narrow down its list of prospective service providers to those that best fit its needs, based on specific criteria, given that unbounded searches on the Web could produce very large and unwieldy lists of results, considering the millions of enterprises that maintain a high-profile presence on the Web

  • How one could obtain an accurate, detailed description of the services being offered by a selected enterprise

  • How one could determine the mechanisms available for conducting e-business transactions with a selected enterprise

  • How one could realize all of the above using programmatic interfaces ”rather than having to do all of this manually using a user interface

UDDI strived to be as generic, inclusive, and flexible as possible when it came to the services it would accommodate. Though it wanted to promote Web services, it went to great lengths to ensure that its scope would not be restricted just to Web services. It wanted to facilitate all possible means of b2b, with Web services being just one, albeit a very strategic one, of the available mechanisms. The UDDI-based search and discovery process can thus be gainfully used, in theory, to realize the means for achieving any and all types of e-business transactions ”hence, the reason why UDDI and the UBR are not limited purely to Web services.

Consequently, there is nothing to preclude a business that offers no Web services whatsoever from still publicizing the services it does offer (e.g., mail order service, consulting services, shipping services, import/export expertise, or financial services) on the UBR. This unalienable fact that UDDI is not restricted to just Web services is something that one should always keep in the back of one s mind when dealing with Web services “ or UDDI- related issues.

The obvious question at this juncture is why the UDDI instigators, in particular IBM and Microsoft, did not pursue the option of extending the then-rampant Internet search engines (e.g., Yahoo!, Alta Vista) to include the envisaged UDDI functionality. Another option would have been to try to enhance one of the then-nascent e-business service registries, such as the ones being promulgated by WebMethods or CommerceOne, to fulfill the UDDI goals. The cynical and first blush answer to this would be that both these superpowers in the IT world, much to their chagrin, had no skin in search engine technology or in e-business registries. However, to be fair, search engine technology, then as it still is now, was unregulated, proprietary, and not based on any accepted standards other than HTML and URLs. The e-business registries were also proprietary and too closely associated with specific vendors .

The UDDI instigators wanted UDDI to be as standards based as Web services. Standards compliancy and, through that, vendor neutrality and platform independence were the main planks of the Web services platform. To sustain this value proposition, UDDI, as an enabling technology for Web services, also needed to be entirely standards compliant. In addition to the absence of relevant standards that governed their operation, some of the other key factors that made search engines unsuitable for the purposes of UDDI included:

  • Search engines devoted all their efforts to locating and indexing just the URLs of the Web pages that contained keywords of interest. Search engines did not make any effort to identify other identification or contact information such as e-mail addresses, FTP sites, or even phone numbers . Search engines, even today, are very HTML-centric and URL specific. UDDI was seeking a more generalized search-and-discover mechanism.

  • Search engines specialize in doing free text searches against unstructured data, whereas UDDI wished to promulgate structured data models.

  • Search engines, in general, do not offer a no-charge, self-service, publishing mechanism whereby enterprises or individuals can enter specific information that they wish to publicize.

  • Search engines, even today, do not typically offer programmatic access to the services they offer.

  • Search engines have yet to become XML savvy.

Given all the previous limitations of search engines, it is understandable that the UDDI instigators wanted to create something that was considerably more compatible and consistent with the methodologies that they were in the process of introducing for Web services ”in particular, SOAP and XML. At this juncture SOAP had just been introduced, so there were no SOAP-related standards per se that might have been of relevance for realizing UDDI. Therefore, there really was no other viable option than to create UDDI from scratch around SOAP and XML schema ”and then put it forward as a proposed standard. That is exactly what happened .

At this point, those who are familiar with other directory schemes may be wondering, quite legitimately, why the OSI directory standard X.500 or the Lightweight Directory Access Protocol (LDAP), its equivalent in the TCP/IP world, could not have been used to achieve the goals of UDDI. The reality here, however, is that UDDI is meant to be at a higher level, a more logical level, than these two directory setup and directory access “oriented standards.

The parallel here is that of SOAP being developed as a transport- agnostic messaging scheme that can be used on top of HTTP, RPC, TCP, SMTP, FTP, message queuing, and so forth. Similarly, UDDI set out to define XML schema-based data models and APIs that generate SOAP messages, which, in theory, could be implemented on top of a standard directory scheme. Thus, it is indeed possible to build a fully conformant UDDI Registry on top of LDAP or X.500 ”and there are indeed specifications on the Web as to how such implementations can be realized. BEA even offers an enterprise implementation solution built on top of LDAP. That said, it is common knowledge that the UBR nodes, at present, are implemented using popular relational database systems (e.g., DB2 in the case of IBM).

Given this background, the advantages that UDDI bestows upon the global business community at large can be summarized as follows :

  1. Provide businesses, organizations, and even individuals with an unprecedented, no-charge, totally egalitarian mechanism to showcase all of their services in a systematic way to the entire world ”thus enhancing their market reach, competitiveness , marketing efficacy, and overall business prospects

  2. Provide a very structured and consistent mechanism for locating and obtaining necessary details about pertinent services available on the global market

  3. Facilitate businesses in identifying prospective b2b partners

  4. Enable service providers and services to be registered, as well as located and invoked, using standardized, programmatic interfaces, thus bolstering the electronic infrastructure for the next generation of e-business

  5. Simplify and streamline e-business-related software integration by ensuring that access to all of the pertinent technical information is available over the Web via a standard mechanism

Web Services[c] Theory and Practice
Web Services[c] Theory and Practice
ISBN: 1555582826
Year: 2006
Pages: 113

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net