4.4 UDDI implementations - UBR and otherwise

4.4 UDDI implementations ”UBR and otherwise

UDDI found itself at an interesting and important crossroad in the summer of 2003 ”exactly a year after its custody was transferred over to OASIS. The UBR, now consisting of the four nodes after NTT joined IBM, Microsoft, and SAP as a node operator in October 2002, continues to be real and freely available. Figure 4.15 shows the front page of NTT s Japanese-centric UBR node to complete the set of UBR node screen shots included in Chapter 1 and this chapter.

click to expand
Figure 4.15: NTT Communication s Japanese-centric UBR node.

Despite the no-cost, no-holds-barred, worldwide availability, the UBR s popularity, repute, and applicability are, however, still open to question. As with all things Web services “ related , UDDI has not yet even come close to living up to its once-lofty expectations. On the other hand, the inclusion of a full-function, V2-compliant UDDI service as a standard feature within Microsoft s now flagship Windows Server 2003, which started shipping in June 2003, coupled with Visual Studio .NET s direct support for UDDI search-and-publish functions, gives UDDI a whole new breadth of exposure.

In addition, the availability of Java-based, multiplatform enterprise UDDI servers from the likes of IBM and BEA, as adjuncts to their highly popular application server offerings, gives UDDI even further credibility with application developers. The Java versions, moreover, enable UDDI implementations on UNIX and even iSeries platforms. The Java- and Windows-based enterprise versions of UDDI will certainly help make UDDI more real, tangible , and accessible vis--vis the IT community ” hence, why it is safe to claim that UDDI really is at a crossroad at the time of this writing.

Up until V3, the focus of UDDI implementations revolved around the UBR initiative. However, V3 s explicit endorsement and support for multiregistry environments changes that in a profound manner. Over the next couple of years , the emphasis is going to shift toward enterprise UDDI registries, both private and semiprivate, and their interaction with the UBR. Consequently, before venturing any further, it is best to characterize the features of the key UDDI implementation types, in tabular form, so as to serve as a framework for the remainder of this section. This is done in Table 4.2.

Table 4.2: Features of Key UDDI Implementation Types

Public UDDI Registries

Enterprise UDDI Registries

UBR Business Registry

UBR Test Registries

Private Registry

Semiprivate, Shared Registry


Global, unrestricted visibility to services available from businesses, organizations, and individuals from around the world

A test-bed version of the UBR provided at some UBR nodes mainly to provide software developers with a means to accurately try out the working of the UDDI APIs

  1. Internal catalog, for use by in-house software developers of available (and approved) Web services that may be used in new applications

  2. Test bed for use by in-house programmers developing programmatic access to the UBR

  3. In the case of large multinational, multidivisional enterprises as a standardized, in-house directory, categorized by taxonomies, of all available services ”Web or otherwise

  1. List of Web services approved for use in b2b e-business applications being developed by or for use by members of this group of partners

  2. Standardized list of all services, categorized by taxonomies, being offered by the various members that make up this partnership

Accessed via:




Behind firewalls:




No charge at present

UDDI server functionality typically included with a larger server product


UBR node operators

Private, in-house


Likely to be multinode:





4.4.1 The UDDI Business Register

The UBR is the public face of UDDI. In reality it was to be the be-all and end-all of what UDDI was all about. Though a UBR, per the original expectations, has now been in continuous operation for nearly 3 years, on a no-charge, open-to-all basis, it is fair to say that the UBR is still a little-used novelty ”only appreciated by a select, Web services “centric cognoscenti. It is still far from being the oracle for e-business-related services that it was supposed to be.

In its defense, it is only fair to note that following the dot.com debacle, the spread of e-business slowed down dramatically in mid-2001 ”just as UDDI and UBR were trying to gain momentum. Then there were 9/11 and the resultant economic downturn, particularly severe in the high-tech sectors ”as well as a huge, overall increase in cautiousness related to all security- and privacy-related issues. The ongoing epidemic of viruses, Internet attacks, relentless spam, and security exposures on Windows platforms justifiably fuels this under-siege mind-set .

Against this background, the UBR was and still is an unknown. Businesses are leery about disclosing too much information about themselves to strangers. They especially do not want to publicize too many electronic links into their organization. The original free-world climate within which the UBR was conceived has changed ”irrevocably!

This security-inspired, technological xenophobia, however, is not the only reason why the UBR has not flourished. The UBR is bereft of leadership. OASIS, true to its charter as a standards body, wishes to stay aloof from UDDI implementations ”even if it is the egalitarian, not-for-gain UBR. There is no explicit reference to UBR on OASIS s UDDI-related front page. Instead, there is a misleading and obscure reference on the top navigation bar that says Register ”with an exclamation mark in front of it, as shown in Figure 4.16. Clicking on that then takes you to a page that is headed Register. If you are just looking to sample and evaluate the UBR, this process is confusing and intimidating to say the least.

click to expand
Figure 4.16: The Register tab on the OASIS UDDI front page, which will take you to a page that shows how to access one of the UBR nodes.

Typing in http://www.uddi.org in the hope that doing that would get you to the UBR does not work either. This intuitive URL takes you to the OASIS UDDI front page discussed previously. Also, http://www.ubr.org is currently for sale! That about sums it up! Doing a search for UBR with, say, Google, does produce results ”but nothing that immediately says: This is the global, no-charge, open-to-all, standards-based UBR. Instead, you get references to particular UBR nodes ”typically starting with Microsoft s UBR node, at uddi.microsoft.com, given that most search engines use a weighting mechanism for ranking search results based on the how many links to this site have we seen criterion, and Microsoft, in general, happens to be a heavily visited site.

The URLs for the various UBR nodes (e.g., uddi.microsoft.com, uddi.ibm.com, and uddi.sap.com) are another problem. The .com suffix detracts from the service-oriented theme that the UBR should project. Though one of the express goals of the UBR is to promote e-business, the .com connotations ”especially when juxtapositioned against names such as Microsoft, IBM, and SAP ”can understandably create some level of paranoia about how information maintained in the UBR may get exploited in the future. Then, as if to add insult to injury , typing in uddi.ntt.com results in a page not found error. Instead, to get the NTT node, you have to enter http://www.ntt.com/uddi.

The NTT node, as shown in Figure 4.15, is predominantly in Japanese and moreover appears to have button ads for other services and vendors . Overall, one can excuse an average business person from being suspicious of the UBR. The UBR, today, comes across as a Big Brother is watching you “type directory maintained by market superheavyweights. The UBR would be so much easier to swallow if it were indeed run by OASIS or an equivalent consortium as a uddi.org entity.

Ironically, however, another factor impacting the UBR is the lack of UDDI-related commercialization. To date, nobody, including IBM, Microsoft, or SAP, has made much money on Web services, UDDI, and, by implication , the UBR. UDDI- and UBR-related ROI have to be in the negative territory. This explains why the UBR, at present, is not as slick as one would expect ”particularly in comparison to large search engines such as Google. First, a year after V3 was released, all of the UBR nodes were still at V2 levels. Given that it is V3 that permits cooperative coexistence of multiregistry environments, the lack of V3 support also has a dampening effect on enterprise-level implementations.

The bottom line is that the UBR has yet to show its true promise and potential. The UBR, overall, does set out to fill a noticeable void in today s global trading community ”not just for Web services, but as a global repository of all available services. One hopes that as the UDDI message becomes better known within enterprises, thanks to the enterprise UDI implementations, the popularity of the UBR will increase ”even if it is, to begin with, just to enumerate traditional services not associated with Web services. In the interim, the primary pros and cons of the UBR are summarized in Table 4.3.

Table 4.3: Pros and Cons of the UBR



  1. Standards based, open service

  2. No charge (at present) and available to all without discrimination

  3. Global, Web browser accessible service

  4. Published API-based programmatic access

  5. Powerful, extensible architecture that permits complex queries

  6. Multinode implementation fosters redundancy

  1. Still lacks visibility, not to mention credibility

  2. No checks on the validity, accuracy, or completeness of the entries

  3. Lacks consistency across the nodes

  4. Predominantly English oriented, with the NTT node being Japanese

  5. No perceived driving force

  6. Unintentionally succeeds in projecting a highly commercialized sinister image, though it is essentially a not-for-profit service

  7. Has yet to cogently quell security and integrity issues that businesses may have

4.4.2 UDDI enterprise registries

The growing interest in private and semiprivate UDDI registries echoes a fundamental ground shift that has occurred in the Web services world. When originally conceived, Web services, as testified by the all-important word Web in the name , were going to be all about standards-based software functionality available over the Web. Web services were the software methodology sector of the Web-based, the whole world is the market, free-trade zone that transcended geographic, political, currency, cultural, and economic boundaries. Well, this utopian dream of application developers around the world, gainfully collaborating with each other over the Web, is not going to happen as quickly and as easily as originally envisaged.

There is too much mistrust and foreboding in the post-9/11 business world. In addition, the constant state of high alert in which businesses now have to operate when it comes to IT-related attacks, thanks to the never-ending news about various security flaws in heavily used software, further exacerbates all concerns regarding the security, privacy, and protection of all corporate assets. Consequently, more and more enterprises are looking at Web services as a technology they want to use either strictly in-house or just with trusted partners. Rather than Web services, it is now becoming intranet services or extranet services.

This situation is responsible for the increased interest in enterprise registry. Enterprise registry enables enterprises to faithfully recreate the entire Web services operational model ”albeit now purely on an intranet or extranet basis. The in-house corporate phone book analogy immediately and obviously comes to mind. With private registries, enterprises can maintain their own listings of services, per the UDDI model ”whether for Web services or otherwise. They will have total control of the access, administration, and security aspects of these in-house registries. They can be maintained on a strictly need-to-know basis.

Only those who are actively involved with particular projects need to even know that an enterprise has an in-house UDDI Registry. Just as with information listed in a corporate phone book, most enterprises will not want the contents of their private UDDI registries known to outsiders. As with other sensitive corporate information, there will be rules, policies, and procedures as to how information contained in a private UDDI Registry is treated.

Private and semiprivate UDDI registries can be a major boon for in-house software developers ”particularly as they transition toward a Web services “centric software development model. These registries provide them with a standard mechanism for cataloging the new Web services they develop. No longer will they have to rely on e- mails , departmental meetings, and word of mouth to disseminate, plus acquire, information about the in-house Web services now offered. They can gainfully use the in-house registry ”in exactly the same way that UBR was originally intended to be used as the self-advertising mechanism for Web services.

Private and semiprivate registries can also be the staging posts for automated, programmatic, Publish API set “based entries into the UBR, once the UBR nodes, as well as the enterprise implementations, are all at V3. As previously mentioned, IBM, Microsoft, and SAP offer test registries alongside their business registries for programmers who wish to test their software against a real, live UDDI implementation. However, using one of these test registries still means going outside the firewall, so the enterprise implementations, especially those that can be realized to be extremely economical using the bundled-in UDDI server inside Windows 2003, will satisfy an important need. Programmers like to try out their software. Now they have a real emulation that they can beat on, behind the privacy afforded by firewalls, to their hearts content, before they have to trot their efforts out into the glare of the Web.

Private and semiprivate registries also allow programmers to have the option of developing truly dynamic, don t bind until run time applications based on Web services. Remember that the whole Web services model is contingent on invoking and binding with the necessary Web services modules at run time. Web services are an RPC mechanism. UDDI, through the bindingTemplate entities, can maintain all necessary invocation parameters for a Web service. Given this framework and the invocation pattern inquiry scheme supported by the UDDI Inquiry API set, it is possible to write new applications that only invoke Web services via their UDDI entry. This means that the actual Web service invoked could change as new Web services are added to a UDDI Registry. With enterprise registries, developers, when applicable , could exploit this highly dynamic Web service invocation model.

The bottom line here is that enterprise UDDI registries, as with employees -only intranet or partners-only extranet portals, are here to stay. In today s security-obsessed corporate culture, they fulfill an important need for providing full UBR compliance within the privacy and security afforded by a firewall. The sponsors of UDDI recognize this need ”hence, the support for multiregistry environments in V3. All that is required now is for the UBR as well as enterprise implementations to be based on V3 so that the interoperability envisaged by V3 can be a reality.

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