UDDI inadequate for SOA

Written By: Peter Abrahams
Content Copyright © 2005 Bloor. All Rights Reserved.

Universal Description, Discovery and Integration (UDDI) is the registry standard from the Organisation for the Advancement of Structured Information Standards (OASIS) and is well supported by IBM, Microsoft and others. The intent is that it should be used to register web services and, as its name implies, the registration will create a standard description, which will enable services to be discovered and then integrated together. There is no doubt that such a service is necessary to support a System Orientated Architecture (SOA) and early implementations have used UDDI to good effect.

The problem is that the standard does not appear to be sufficiently broad to support the management and governance of the full range of artefacts needed to implement SOA. This is the argument put forward by the ebXML (electronic business using eXtensible Markup Language) technical committee, which has developed a series of OASIS standards.

The initial concern of the ebXML committee was defining standard message formats for electronic business (for example defining the standard parts of an invoice). As part of this standards effort it was obvious that the different artefacts needed to be registered; that is, there needed to be a place where you could discover that an invoice had been defined. But registration alone was not enough, it was also necessary to have somewhere to store the definition – commonly known as a repository. The committee recognised that if the whole lifecycle of an artefact was to be managed then the registry and the repository had to be joined at the hip. If they were not, it would be possible for a change to an artefact (for example, the addition of new field types in the invoice) to be implemented without the registry being aware.

So the committee developed the ebXML Registry standard (version 3 was approved by OASIS in May this year) that defined both the data that is to be held in the registry/repository and the service interfaces required to access this data. The standard was set up so that it was extensible, to ensure that any artefact could be incorporated. This means that besides XML schemas, the registry/repository can support BPEL (Business Process Execution Language), XSLT (eXtensible Stylesheet Language Transformations), WSDL (Web Services Description Language) etc.

WSDL is important to this article as storing WSDL is the prime purpose of the UDDI registry. This means that ebXML can support everything that UDDI can and more. Further, ebXML understands change management by tracking and logging changes, and can notify users of changes.

ebXML has also defined how registries can be federated so an SOA solution can be developed across multiple registries; this is an essential function because the intent of SOA is that services may be provided by multiple suppliers – either different organisations within an enterprise or, potentially, external organisations. The definition of an artefact must be owned and controlled by the producer and therefore must be in a registry/repository controlled by the producer. Therefore multiple registries will be involved in any significant SOA implementation.

ebXML Registry standard is much more extensive than UDDI and provides services that are needed to successfully manage complex SOA implementations. The problem until now has been that UDDI has been making the front-running and there are more implementations of UDDI registries and applications supported by them than ebXML. Users and vendors of UDDI cannot easily switch to ebXML registry.

However, SOA technology can resolve this issue in two different ways and Sun has shown this is possible with their ebXML registry implementation:

  • It is possible to federate UDDI and ebXML registries together with suitable mediation between the two, so that an ebXML user could access information about WSDL held in a UDDI registry.
  • It is also possible to develop a UDDI service interface on the front of an ebXML engine so that a UDDI user could discover a web service whose definition is held in the ebXML registry, without having to make any change to the existing system.

I would expect that as more complex SOA solutions are implemented, more users will recognise the need for the functionality provided by ebXML and they will move to a registry/repository solution that supports both UDDI and ebXML service interfaces.