The following is an example of the OASIS/ebXML Registry Version 2.5 specification’s HTTP interface capability that requests the retrieval of an item (a “RegistryObject”) from an ebXML registry:

http://base_url_of_ebXML_registry/http?interface=QueryManager&method=getRegistryObject&param-id=urn:uuid:a1137d00-091a-471e-8680-eb75b27b84b6

In the above example, the “getRegistryObject” method of the “QueryManager” registry interface is invoked to retrieve the RegistryObject whose UUID (Universally Unique Identifier) is specified.

Assuming that the UUID listed above is that of a WSDL document that is stored in the ebXML registry, one may replace the <overviewURL> in the UDDI tModel shown earlier above with the above HTTP request as follows:

<tModel tModelKey="some_urn">

   <name>My WSDL document</name>

   <description>This WSDL document...</description>

   <overviewDoc>

      <overviewURL useType="wsdlInterface">

         http://base_url_of_ebXML_registry/http?interface=

QueryManager&method=getRegistryObject&param-id=

         uuid_of_WSDL_document

      </overviewURL>

   </overviewDoc>

   <categoryBag>

      --removed for example purposes--

   </categoryBag>

</tModel>

ebXML Registry

The same general concepts described above would apply for the ebXML registry-to-UDDI registry direction. While ebXML registry’s HTTP interface uses UUIDs, UDDI’s HTTP interface uses uddiKeys (which are keys for entities published in UDDI registries). An example of an HTTP request in UDDI format is as follows:

http://base_uri_of_UDDI_node?tModelKey=uddi:tempuri.com:fish:interface

In the above example, the XML representation of a tModel whose key -- uddi:tempuri.com:fish:interface -- is retrieved.

In the ebXML registry, an ExternalLink can be created and associated with a RegistryObject that represents the WSDL document that is stored in the UDDI registry. This ExternalLink would specify the UDDI HTTP request shown above:

<rim:ExternalLink

id="UDDILink"

externalURI="http://base_uri_of_UDDI_node?tModelKey=uddi:tempuri.com:fish:interface">

   <rim:Name>

<rim:LocalizedString value="My WSDL document"/>

   </rim:Name>

   <rim:Description>

<rim:LocalizedString value="This WSDL document…"/>

   </rim:Description>

</rim:ExternalLink>

Tier 2: Local Representations/Publish and Subscribe

While Tier 3 envisions unique representations of Web Services descriptions in UDDI and ebXML registries, Tier 2 additionally envisions the capability to maintain local representations of objects in each registry, with objects duplicated among registries. A registry administrator may prefer this approach to the Tier 3 approach because the administrator would have more control of a local representation of a Web Service description.

However, what if a change is made to an object? How can a registry host that maintains their own local representation of an object be notified of this change? This is where publish/subscribe capabilities can be valuable.

The Vision

In Tier 2, a change made to a Web Services description that is maintained in a UDDI registry would automatically trigger a publish/subscribe notification not only to other UDDI registries that maintain their own local representations of the Web Services description, but also the pertinent ebXML registries. The same concept would apply for the ebXML registry-to-UDDI registry direction.

This scenario is shown in Figure 3

Figure 3. Publish and subscribe scenario

In Figure 3, each trading partner maintains its own version of a WSDL document in its registry. One version is designated to be the master version, while the other is a replica. If any changes are made to the master version, all registries that maintain replicas – regardless of the registry type – would be notified. At that point, the registry users/administrators would decide on the appropriate action to take (e.g., disregard updates or incorporate updates).

The Specifications

Both the UDDI Version 3.0 and OASIS/ebXML Registry Version 2.5 specifications include a publish/subscribe capability (known in the UDDI Version 3.0 specification as the Subscription API, and in the OASIS/ebXML Registry Version 2.5 specification as Event-Driven Notification). In the UDDI Version 3.0 specification, the Subscription API provides clients, known as subscribers, with the ability to register their interest in receiving information concerning changes made in a UDDI registry. These changes can be scoped based on preferences provided with the request. The Subscription API allows monitoring of activity in a registry by registering to track new, changed and deleted entries for various entities, including the core data structures of businessEntity, businessService, bindingTemplate, and tModel (plus others).

In the OASIS/ebXML Registry Version 2.5 specification, the Event Notification Service capability allows an ebXML registry to notify its users and/or other registries about events of interest. Such events may include the modification of a CPP (in which a new CPA may need to be negotiated), or change in life cycle stage of an object.

Unlike Tier 3 which does not require the introduction of any type of middleware mechanism, Tier 2 would require a middleware gateway mechanism to translate between the disparate representations of publish/subscribe notifications between UDDI and ebXML registry.

Tier 1: Seamless Federation of Registries

Tier 1 envisions a seamless federation of registries in which a federation can include both UDDI and ebXML registries, and registry operations can take place with transparency – i.e. with no regard to registry type. All Tier 3 and Tier 2 capabilities would also exist in Tier 1.

The Vision

The federation described in Tier 1 is portrayed in Figure 4.

Figure 4. Federation of registries

In Tier 1, registry operations such as the following could take place:

• Seamless Query: The ability to search for an object in any registry in a federation, regardless of registry type

• Seamless Synchronization: Synchronization of objects between all registries in a federation, regardless of registry type – i.e. a change made to an object in one registry can trigger publish/subscribe notifications to all other registries, regardless of registry type

• Seamless Relocation: Relocation of objects from one registry in a federation to another, regardless of registry type

The Specifications

Both the UDDI Version 3.0 and OASIS/ebXML Registry Version 2.5 specifications include a distributed-registries capability (known in the UDDI Version 3.0 specification as Publishing of Data Across Multiple Registries, and in the OASIS/ebXML Registry Version 2.5 specification as Cooperating Registries). In prior versions of the UDDI Specification, the behavior in which a publisher wished to copy the entirety of a UDDI registry entity from one registry to another while preserving the identical key was explicitly not allowed, because the Version 1 and 2 specifications mandated that only the UDDI node could generate keys. While ensuring that no duplicate keys would ever be generated in a given registry (the rationale behind the mandate), this prevented a publisher from being able to import or export data between registries. In the UDDI Version 3.0 specification, the possibility of publishing an entity to another UDDI registry while preserving the key (known as entity promotion) is allowed. This enables the publishing of data across multiple UDDI registries.

In the OASIS/ebXML Registry Version 2.5 specification, the Cooperating Registries capability enables multiple ebXML registries to participate together in a federation which acts as a single registry. A query of a registry federation will return results as if a single registry were queried. Additionally, objects can be replicated between registries, and relocated from one registry to another.

As with Tier 2, Tier 3 would require a middleware gateway mechanism to translate between the disparate representations of registry operations between UDDI and ebXML registry. Another potential approach is the creation of a single global registry interface mechanism in which registry operations are specified without regard to registry type, and each registry type conforms to this global registry interface mechanism and translates the registry operations into its own native representation.

Web Services and Registries Pilot

In an effort to realize the vision described in this article, I am leading a pilot project in the U.S. Federal CIO Council’s XML Web Services Working Group (http://xml.gov/working_group.asp) that addresses Tier 3 of this vision. Multiple vendors that have ebXML registry and UDDI registry implementations will be participating in use cases (and ultimately a full demonstration) from very simple use cases (e.g. reaching across from one registry type to another to access an object) to more complex use cases (e.g. a complex collaboration scenario that “loops through” registry types multiple times). I anticipate proposing pilots at Tier 2 and Tier 1 in the future.

For more information about this article, or for information about Booz Allen's XML and Web Services capabilities, contact Terry Bjornsen at 703.377.4157 or bjornsen_terence@bah.com, or Joseph Chiusano at 703.902.6923 or chiusano_joseph@bah.com.

References

1. ebXML Registry Information Model Specification v2.5, June 2003: http://www.oasis-open.org/committees/regrep

2. ebXML Registry Services Specification v2.5, June 2003: http://www.oasis-open.org/committees/regrep

3. UDDI Version 3.0 specification, July 2002: http://www.uddi.org/

4. “UDDI and ebXML Registry: A Co-Existence Paradigm”, WebServices.org, April 2003, http://www.webservices.org/index.php/article/articleview/984/

Joseph Chiusano is a Senior Consultant with Booz Allen Hamilton's IT Digital Strategies Team. His XML expertise includes XML schema, Web services, digital security, XML registries, and XML vocabularies. His general technology experience includes such diverse areas as systems architecture, relational database applications design and development, and operating system development.