Overview/comparisonWithUDDI
From Omar Wiki
Contents |
Overview
This page describes how ebXML Registry-Repository standard relates to or compares with UDDI registry standard.
Comparing ebXML Registry-Repository to UDDI is like comparing apples and oranges. They are very different in their original vision and subsequent design centers.
Original Vision Comparison
UDDI Vision
The original vision of UDDI was that of the Universal Business Registry (UBR). The UBR was a public registry that was open to every one to publish their business and the servies they offered. It was an online version of the yellow and white pages. The idea was that busineses would automatically use services they find listed in the UBR. Time has proven that the original vision of the UBR was quite flawed and the UBR was evetually shutdown on January 12, 2006. A more candid assessment is found in the following:
- Microsoft, IBM, SAP To Discontinue UDDI Web Services Registry Effort
- You Only Live Twice - The Death and Life of UDDI
- What the Liberty Alliance could learn from UDDI
- Is This The Decline of Public UDDI Business Registries?
UDDI, to its credit, has been trying to reinvent itself as its original vision has failed. Since then it has jockeyed for positioning as the following:
- Internal Web Service Registry
- SOA Governance platform
- A registry of ebXML Core Components
ebXML Registry Vision
The original vision of ebXML Registry has never shifted even slightly, since 1999. The ebXML Registry is designed for secure, federated information management of large amounts of complex information using standardized and extensible metadata. Its vision is to be use case and content agnostic. It is designed for extensibility in every dimension.
In summary, the ebXML Registry vision is to provide generic, extensible, secure, federated information management.
Design Center Comparision
Below is a high level summary compating the design centers of the two standards.
| UDDI Registry | ebXML Registry and Repository |
|---|---|
| Has no repository. Cannot store content. Can only store metadata about (or pointers to) content. | Has an integrated Registry and Repository. Can store content as well as metadata |
| Design center is to be like a yellow/white pages for listing businesses and services | Design center is to provide secure, federated information management of any type of artifact |
| Protocols and information model is focused and specific | Protocols and information model is generic and extensible |
| Supports multi-registry topologies using replication of every transaction to all participating registries. | Supports multi-registry topologies using lossely coupled federations with optional selective replication |
Feature Comparison
A comparison of features offered by UDDI Registry and ebXML Registry and Repository is available at the end of the following white paper:
EFFECTIVE SOA DEPLOYMENT USING AN SOA REGISTRY REPOSITORY: A Practical Guide
Adoption and Market Acceptance
There are several different criteria to measure adoption of a standard and its acceptance in the market place. Much too often, the only criteria considered is vendor support. This may give a skewed impression of adoption.
Deployments
For a partial list of deployments of ebXML registry-Repository see here. Note that these are a subset of deployments for only one implementation of ebXML Registry. Deployments by Adobe and other vendors are not included.
The author does not have a lot of data on major UDDI deployments. Please feel free to add below:
- DISA Service Registry
Adoption By Verticals and Other Standards
In terms of adoption by entire verticals and other standards ebXML Registry has the following adoption:
- Open GIS - Geo-spatial
- IHE-XDS - Healthcare, Electronic Medical Records
- sdmx.org - Managing debt statistics for the IMF and World Bank
- RosettaNet, eBusiness Process Standards - Manage RosettaNet technical dictionary including business processes and related artifacts.
The author does not have a lot of data on adoption of UDDI by Other verticals and standards. Please feel free to add below:
- WS-I Basic Profile specifies UDDI as an optional requirement
Profiles of Standard
An important measure of the success of a standard is the degree to which profiles specifications have been created for the specifications defin ed by the standard.
UDDI has taken the approach of non-normative "Technical Notes" which are essentially tutorials on how to use UDDI in various situations.
ebXML Registry has taken the approach of formal profiles of its specification as normative specifications in their own right. There is a fast growing list of such normative profile specifications for ebXML Registry standard.
It should be noted that UDDI TC is considering a name change for their Technical Notes to profiles based on ebXML Registry taking a profile centric approach to formal extensions:
- http://lists.oasis-open.org/archives/uddi-spec/200509/msg00013.html
- http://lists.oasis-open.org/archives/uddi-spec/200509/msg00015.html
- http://lists.oasis-open.org/archives/uddi-spec/200509/msg00016.html
It should be noted further, that the difference between "Technical Notes / Best Practices" and "Profiles" is not merely two names for the same thing but something far more significant.
"Profiles" are formal normative specifications where as "Technical Notes / Best Practices" are not.
Adoption By Geography
UDDI has greater success in the US while ebXML Registry-Repository is more successful is Europe and Asia. ebXML Registry-Repository is seeing a significant upsurge in demand within the US and Canada since 2005.
Vendor Support
UDDI has a clear lead in vendor support. It is supported within the products of several large vendors including Microsoft, IBM, Oracle, SAP, BEA, Sun etc.
ebXML Registry is supported within the products of fewer vendors in comparision. These include Sun Microsystems, Adobe, Infravio and several smaller companies. However, as of 2006, the situation is changing with IBM deciding to build an Electronic Medical Records product on top of freebXML Registry and in April 2007 IBM publicly stating that UDDI is an inadequate registry standard.
Open Source Implementations
Open source implementations of a standard are an important indicator for adoption because they are community driven efforts that operate in a frictionless and agile environment.
ebXML Registry-Repository is supported by the freebXML Registry open source project which provides a royalty free implementation of the standard. This implementation is also available as a product from Sun Microsystems in form of Sun Service Registry. The project has a growing community of about 300 members and a developer community of about 30 individuals. The project has been around since 2000 and has widely deployed in major government and private sector entitities.
UDDI has jUDDI which is a project at Apache which has a developer community of 5 individuals. The size of the user community is unknown.
API Support
Both UDDI and ebXML Registry-Repository standards are supported by Java API for XML Registries (JAXR). This is the industry standard API within the Java platform for registries and repsitories. The JAXR API is a direct mapping of the ebXML registry standard. As such it is the one and only standard API for the ebXML Registry standard. The API defines two levels of conformance. Basic features defined by JAXR Level 0 API is required with UDDI and ebXML Registry. However, advanced features defined by JAXR Level 1 API are only required with ebXML Registry.
There is another API called UDDI4J that has been popular with those developers that felt that JAXR did not provide a direct mapping to UDDI. The UDDI4J API is an open source implementation and is not an indusry standard API.
Conclusions
Is the Functionality Gap Converging
Since their beginnings there has been a significant functional gap between UDDI Registry and ebXML Registry-Repository standards. This is not simply a case of a better moluse-trap. ebXML Registry was designed for solving a fundementally different problem than UDDI as decsribed in the overview section.
Yet, there is a common misconception that UDDI standard has been closing the functional gap with the ebXML Registry-Repository standard over the years. The actual reality is that with each version of the standards the functional gap has widened even further in favor of ebXML Registry-Repository standard.
This was particularly true with version 3.0 where UDDI 3.0 was adding basic security features, such as digital signatures, that have been in ebXML Registry-Repository standard since version 1.0, while ebXML Registry-Repository 3.0 was adding significant new features such as federation, versioning, Role Based Access Control (RBAC), content validation and cataloging, content-based event notification. In addition it added alignment with latest standards such as Web Services Security: SOAP Message Security 1.0, Web Services Security: SOAP Message with Attachments (SwA) Profile 1.0, WS-I: Basic Security Profile 1.0, and WS-I: Basic Profile 1.1, in addition to SAML 2.0 and XACML 1.0.
Will ebXML Registry Be the Next BetaMax
The Sony Betamax analogy has often been cited regarding ebXML Registry by its detractors. They have also said that a better mouse trap does not win the market.
As was stated in the very beginning, comparing UDDI and ebXML Registry is comparing apples and oranges. ebXML Registry-Repository is not simply a better UDDI. It is fundamentally different. To use the betamax vs. VHS analogy it is like comparing the VHS recorder with a recording studio that is capable of recording, editing, sharing just about any kind of digital media.
ebXML Registry as a standard has strong support from user companies like Boeing as well as vendor companies like Sun Microsystems and Adobe. Its leadership has remained constant and its progress has been steady over the years. It has reached the maturity of being recognized as an ISO standard (not so for UDDI). It has active work items and formal liaisons with several other standards groups within and outside OASIS. It is executing on a long term roadmap of planned features and delivering them with a new release about every 2 years.
In summary, ebXML Registry-Repository as a standard is healthy and is not about to disappear any time soon.
Which Standard Should You Choose
That would depend upon your requirements. For simple publish and discovery of services UDDI may suffice. But if you need to manage and govern large amounts of information that has intricate relationships and if you need to link with other information stores like yours then ebXML Registry-Repository is a better choice. Here is some guidance on when to use ebXML Registry-Repository.
It is often the case that deployments start out with simple requirements and overtime these requirements get more complex. ebXML Registry-Repository can handle the simples to the most complex requirements for secure, federated information management.
Lastly, if you really wish to leave nothing to chance then choose a product that supports both UDDI Registry and ebXML Registry-Repository standards in a single service.
Here is a SOA Registry-Repository White Paper that provides detailed guidance to help you make an informed decision.
