The Web Services world is one in which clients and services find each other and connect without any explicit prior knowledge. In this open Web world, registries play a critical role in client discovery and lookup, as well as service provider registration. When Web Services are written as Java server-based applications, developers need a way to register their services and to do repository search and lookup.
The recent release of the Java Web Services Developer Pack (JWSDP)a collection of tools and APIs for building Web Services based on the Java 2 Enterprise Edition (J2EE)includes an API tailored for registry interaction. The Java API for Registries (JAXR) provides a convenient way for Java developers to use a single simple API to access a variety of XML registries including UDDI and ebXML. In this article, we explore the role played by UDDI and ebXML registries in the Web Services world, and examine some of the details of working with the JAXR to connect with these and other registries.
Registry WorldUDDI versus ebXML
Currently, there are two important registries associated with Web Services: ebXML and UDDI. ebXML is the product of a joint development effort between OASIS and United Nations (UN/CEFACT), whereas UDDI is the result of a collaborative effort by a vendor consortium. Both operate in the Web Services world as repositories of information about Web Services. Both share several common properties, including the following:
Both are based on XML.
Both involve the concept of lookup and registration in repositories.
Both are used by companies to establish software-to-software relationships in a collaborative e-commerce endeavor.
However, there are key differences between the two initiatives; and if you're trying to understand how the Web Services world works, it's useful to understand how UDDI and ebXML differ in fostering Web-based electronic commerce. So let's look briefly at the historical context of each initiative, beginning with ebXML.