Intelligent Enterprise

Better Insight for Business Decisions

RSS
Webcasts
Whitepapers
Subscribe
Home

January 1, 2003

Closed Loop

A Different Perspective

I normally wouldn't jump into a fray such as this, but much of what Michael J. Hudson has written [in "UDDI at Midnight," Aug. 12, 2002] is simply incorrect.

First, UDDI [Universal Description, Discovery, and Integration] has been transferred to an SDO (OASIS). I would characterize OASIS as a standards-setting body.

The [public] UDDI Business Registry referenced within the article and available from Microsoft, IBM, and SAP is a single, logically centralized but physically decentralized registry. The data is replicated between the nodes. Within the UDDI specifications, various valid use cases include private, semiprivate, and public registries.

Second, although I go to Google for information and valid links to initiate research, I don't go to find Web services. I go to UDDI. To be confident that I have the requisite information, I need the specifications required to comprehend and then access Web services. The WSDL file (indexed in UDDI) typically provides most — but not all — of [these specifications]. I may get this information in a series of run-time steps or as multiple steps involving both development time review and run-time checking.

Google doesn't standardize a service provider's results listings. My goal is B2B automation and to do this, I need a standards-based set of details available. Because I may not have an established trading relationship with that provider yet, I can find the provider and the requisite details in a UDDI registry.

I'll be honest with you, a UDDI-to-Google feed is possible. With the latest Publish/Subscription capabilities, this data set could be updated regularly and delivered to Google with the listing verified and scrubbed before being presented to the user.

Finally, JAXR isn't a registry. It's a Java API that lets you effectively "bridge" UDDI-based registries and registries based on the OASIS ebXML registry specification.

Joel Munter
Sr. Staff Engineer, Web Services Standards
Intel Corp.
Chandler, Ariz.

Hudson responds:

Thanks for your response to my article. Although I don't see how any of my statements were factually incorrect at the time of writing, I will try to address each of your concerns.

First, when I wrote this column in May 2002, UDDI had not been submitted to any standards organization. OASIS started the creation of a technical committee to review the UDDI specification for standardization on Aug. 28, 2002 — a good four months after I wrote the column and two weeks after it was published. And although the introduction of UDDI to a standards body does give the specification more legitimacy, OASIS's stamp of approval on v.3 of the specification is still up to two years away.

However, standards only give a specification consistency. They guarantee neither validity nor acceptance. For instance, a number of SGML-related standards such as DSSSL sound like great ideas but hardly have been used. One main problem for many of these standards is their unnecessary complexity. I believe that the reason XML and some of its kin worked so incredibly well is their sheer simplicity.

In any case, from my own experiences, stories from colleagues, and reading others' experiences with UDDI (www.internetwk.com/WebDev/INW20020731S0001), I haven't seen any decent adoption of UDDI registries. I know of only four public registries — two of them from UDDI founders, Microsoft and IBM. Another founder, Ariba, has decided against creating a registry, and Hewlett-Packard ceased operations of a UDDI directory it was creating in late September.

In terms of registries being used within private and semiprivate scenarios, there's an assumption that businesses using these registries already have existing relationships. If so, why would a business waste time and effort configuring UDDI and setting up a complicated ontology, when contacting its business partners directly and asking for a document covering all of their available Web services and associated WSDL files is much easier?

Unfortunately, a UDDI registry doesn't facilitate the automation of the dynamic execution of Web services that it finds. For example, you can't go to a UDDI registry, find all the weather-related Web services, and then execute one of those Web services without someone figuring out the semantics of the ontologies, what the technical bindings from the WSDL file actually mean, and coding the actual Web service client that interacts with this service. What possible ROI can you glean from dealing with the complexities of the UDDI spec, either buying your own registry or paying to participate in some other registry, figuring out how to express the semantics and relationships of the Web services you want to provide, expressing those relationships in a set of ontologies, and having that information imported into your UDDI registry?

These tasks are too much work when no real automated benefit will be seen from them. Partnering with the Web service provider or using a number of other already existing search technologies is much simpler. Standards exist to create cross-enterprise interoperability in an environment of heterogeneous systems. I've already stated the lack of success of public registries. Thus, if UDDI is only going to be used in private or semiprivate registries where each business partner already has mechanisms for interoperability, why do I need this standard for distributing my Web services?

On top of this, UDDI doesn't support distributed searches or abstract querying. UDDI has no way to ensure service quality or availability. And if you decide you want someone to pay to use your Web service, how exactly does UDDI enforce payment? In the end, you need to add a number of other pieces that address these concerns as well as security and alerts. The standardized interface to your UDDI registry is rapidly acquiring proprietary hooks that your UDDI registry client has to deal with. So why do we need this standard as well as a multitude of other complex standards that are coming down the pike?

Regarding Google, I was referencing the current set of Web services that Google provides to execute personalized searches. If I want to know more about these Web services, I don't need to visit some UDDI registry that Google or some other corporation set up (I don't even know if or where it's registered). Instead, I simply go to www.google.com/apis. From there, I can easily obtain the information I need to develop a client to access Google's Web services without ever dealing with UDDI complexities.

In the same vein, Amazon recently announced a set of Web services for its associate partners — a great example of a private or semiprivate scenario. It doesn't use a UDDI registry to store and distribute its Web services. Instead, the relationship already exists between Amazon and the associate partners, and those partners simply go to a private Web site to obtain information about those Web services. And to top that, Microsoft, a founding member of UDDI, has a mapping and direction service called MapPoint, which companies sign up to use. And as far as I know, no one is using a UDDI registry to access or find out about these Web services.

In the end, Google has been the most innovative company when it comes to search technologies. It currently provides corporate-level search products, as well as public searches for images, Usenet groups, and even news stories. As you suggested, you don't have to go too far to imagine that Google could easily provide a searching mechanism for Web services, but I have strong doubts that this service will use the current incarnation of the UDDI specification.

And finally, I never said that JAXR itself was a registry. In fact, I explicitly stated that JAXR is "Sun's standard Java interface for XML registries." What's the difference between my statement that JAXR could be used to "wrap [itself] on top of the UDDI API" and your statement that it acts like a "bridge" to UDDI-based registries and ebXML? UDDI is essentially nothing more than an interface and a set of best practices on how to go about implementing that interface. In the same vein, that's all JAXR is as well.

In conclusion, I'm sorry that you disagree with my assessment, but I hope that I've addressed each of your points thoroughly. If you have any other thoughts and comments, don't hesitate to contact me.