Web ServicesUDDI V3 Subscriptions, Part I

UDDI V3 Subscriptions, Part I

Developer.com content and product recommendations are editorially independent. We may make money when you click on links to our partners. Learn More.


Universal Description, Discovery, and Integration (UDDI) technology is becoming the lingua franca for Web services publishing and discovery mechanisms. UDDI V2 specifications have been promoted as OASIS standards. UDDI V3 specifications are UDDI Spec TC Committee specifications under OASIS.

In the first part of this article series, I will discuss the UDDI V3 Subscription mechanism, which is a powerful V3 feature. I assume readers are aware with the UDDI technology and XML schemas.

What Is a Subscription?

Subscriptions in UDDI are a way of getting up-to-date information from the registry through a set of APIs defined in the UDDI V3 specification. Subscription ensures registry users the information they are looking for is current and up-to-date. There are two types of subscription mechanisms that are supported by the specification:

  • Synchronous requests
  • Asynchronous notifications

Subscribers make synchronous request using the get_subscriptionResults API to the UDDI registry based on the filtering criteria specified in the subscription. The UDDI server responds with the registry data to which the subscriber is interested.

Subscribers can opt to receive asynchronous notifications from the UDDI registry by implementing the subscription listener interface. The UDDI server sends notifications to the subscribers via calls to the notify_subscriptionListener API.

UDDI V3’s subscription mechanism helps its subscribers to subscribe themselves to the core UDDI data structures that are registered in the UDDI registry.

The data in the registry that can be monitored with the help of this mechanism are:

  • businessEntity
  • businessService
  • bindingTemplate
  • tModel
  • related businessEntity
  • publisherAssertion

With the help of this functionality, subscribers can track the activity of the registry data, thus keeping abreast of the latest developments in their business.

Subscription APIs

There is a set of APIs defined in the UDDI V3 specification that describes how to interact with the UDDI registry content.

  1. save_subscription
  2. get_subscriptions
  3. get_subscriptionResults
  4. delete_subscription
  5. notify_subscriptionListener

These APIs are carefully designed to cater the needs of the subscribers who use them to the fullest extent possible. The first four APIs are synchronous in nature. The notify_subscriptionListener API is a client API that is responsible for receiving asynchronous notifications.

XML Schema Definition for Subscription APIs

XML Schema Definition (XSD) for the subscription APIs helps you to understand better about the API functionality and usability. Listings 1 through 6 define the XSD for the subscription APIs.

<xsd:element name="subscriptionKey" type="uddi_sub:subscriptionKey"
<xsd:simpleType name="subscriptionKey" final="restriction">
  <xsd:restriction base="xsd:anyURI"/>

<xsd:element name="subscriptionFilter"
<xsd:complexType name="subscriptionFilter" final="restriction">
    <xsd:element ref="uddi:find_binding"/>
    <xsd:element ref="uddi:find_business"/>
    <xsd:element ref="uddi:find_relatedBusinesses"/>
    <xsd:element ref="uddi:find_service"/>
    <xsd:element ref="uddi:find_tModel"/>
    <xsd:element ref="uddi:get_bindingDetail"/>
    <xsd:element ref="uddi:get_businessDetail"/>
    <xsd:element ref="uddi:get_serviceDetail"/>
    <xsd:element ref="uddi:get_tModelDetail"/>
    <xsd:element ref="uddi:get_assertionStatusReport"/>

<xsd:element name="notificationInterval"
             type="uddi_sub: notificationInterval"
<xsd: simpleType name="notificationInterval" final="restriction">
  <xsd:restriction base="xsd:duration"/>

<xsd:element name="maxEntities" type="uddi_sub:maxEntities"/>
<xsd:simpleType name="maxEntities" final="restriction">
  <xsd:restriction base="xsd:int"/>

<xsd:element name="expiresAfter" type="uddi_sub:expiresAfter"
<xsd:simpleType name="expiresAfter" final="restriction">
  <xsd:restriction base="xsd:dateTime"/>

<xsd:element name="brief" type="uddi_sub:brief"
<xsd:simpleType name="brief" final="restriction">
  <xsd:restriction base="xsd:boolean"/>

Listing 1: XML Schema definition for subscription parameters.

<xsd:element name="save_subscription"
<xsd:complexType name="save_subscription" final="restriction">
    <xsd:element ref="uddi:authInfo" minOccurs="0"/>
    <xsd:element ref="uddi_sub:subscription"

<xsd:element name="subscription" type="uddi_sub:subscription"
<xsd:complexType name="subscription" final="restriction">
    <xsd:element ref="uddi_sub:subscriptionKey" minOccurs="0"/>
    <xsd:element ref="uddi_sub:subscriptionFilter" minOccurs="0"/>
    <xsd:element ref="uddi:bindingKey" minOccurs="0"/>
    <xsd:element ref="uddi_sub:notificationInterval" minOccurs="0"/>
    <xsd:element ref="uddi_sub:maxEntities" minOccurs="0"/>
    <xsd:element ref="uddi_sub:expiresAfter" minOccurs="0"/>
  <xsd:attribute name="brief" type="uddi_sub:brief" use="optional"/>

Listing 2: XML Schema definition for save_subscription API.

<xsd:element name="get_subscriptions"
<xsd:complexType name="get_subscriptions" final="restriction">
    <xsd:element ref="uddi:authInfo" minOccurs="0"/>

Listing 3: XML Schema definition for get_subscriptions API.

<xsd:element name="get_subscriptionResults"
<xsd:complexType name="get_subscriptionResults"
    <xsd:element ref="uddi:authInfo" minOccurs="0"/>
    <xsd:element ref="uddi_sub:subscriptionKey"/>
    <xsd:element ref="uddi_sub:coveragePeriod"/>
    <xsd:element ref="uddi_sub:chunkToken" minOccurs="0"/>

<xsd:element name="coveragePeriod" type="uddi_sub:coveragePeriod"
<xsd:complexType name="coveragePeriod" final="restriction">
    <xsd:element ref="uddi_sub:startPoint" minOccurs="0"/>
    <xsd:element ref="uddi_sub:endPoint" minOccurs="0"/>

<xsd:element name="chunkToken" type="uddi_sub:chunkToken"
<xsd:simpleType name="chunkToken">
  <xsd:restriction base="xsd:string">
    <xsd:maxLength value="255"/>

Listing 4: XML Schema definition for get_subscriptionResults API.

<xsd:element name="delete_subscription"
<xsd:complexType name="delete_subscription" final="restriction">
    <xsd:element ref="uddi:authInfo" minOccurs="0"/>
    <xsd:element ref="uddi_sub:subscriptionKey"

Listing 5: XML Schema definition for delete_subscription API.

<xsd:element name="notify_subscriptionListener"
<xsd:complexType name="notify_subscriptionListener"
    <xsd:element ref="uddi:authInfo" minOccurs="0"/>
    <xsd:element ref="uddi_sub:subscriptionResultsList"/>

<xsd:element name="subscriptionResultsList"
<xsd:complexType name="subscriptionResultsList"
    <xsd:element ref="uddi_sub:chunkToken" minOccurs="0"/>
    <xsd:element ref="uddi_sub:coveragePeriod"/>
    <xsd:element ref="uddi_sub:subscription"/>
    <xsd:element ref="uddi:bindingDetail" minOccurs="0"/>
    <xsd:element ref="uddi:businessDetail" minOccurs="0"/>
    <xsd:element ref="uddi:serviceDetail" minOccurs="0"/>
    <xsd:element ref="uddi:tModelDetail" minOccurs="0"/>
    <xsd:element ref="uddi:businessList" minOccurs="0"/>
    <xsd:element ref="uddi:relatedBusinessesList" minOccurs="0"/>
    <xsd:element ref="uddi:serviceList" minOccurs="0"/>
    <xsd:element ref="uddi:tModelList" minOccurs="0"/>
    <xsd:element ref="uddi:assertionStatusReport" minOccurs="0"/>
    <xsd:element ref="uddi_sub:keyBag" minOccurs="0"
  <xsd:attribute name="someResultsUnavailable"
                 type="xsd:boolean" use="optional"/>

<xsd:element name="keyBag" type="uddi_sub:keyBag"
<xsd:complexType name="keyBag" final="restriction">
    <xsd:element ref="uddi_sub:deleted"/>
      <xsd:element ref="uddi:tModelKey" maxOccurs="unbounded"/>
      <xsd:element ref="uddi:businessKey" maxOccurs="unbounded"/>
      <xsd:element ref="uddi:serviceKey" maxOccurs="unbounded"/>
      <xsd:element ref="uddi:bindingKey" maxOccurs="unbounded"/>

Listing 6: XML Schema definition for notify_subscriptionListener API.

Subscription Parameters

There are a number of subscription parameters that are defined in the UDDI Subscription API Specification. These parameters help the users monitor the changes to the registry data that interests them. Listing 1 defines the XML schema for the subscription parameters.

subscriptionKey: This is the subscription key that gets generated when user saves a subscription to the registry. This key is also used to renew or change an existing subscription. The XML schema type for this element is xsd:anyURI.

subscriptionFilter: This parameter specifies the filtering criteria for the data structure you are interested. The filter can contain any of the UDDI get_xx and find_xx APIs.

expiresAfter: This parameter specifies the time after which the subscription becomes invalid. The XML Schema type for this element is xsd:dateTime.

notificationInterval: This parameter is required only when asynchronous notifications are used. This parameter specifies how often notifications are sent to the subscriber. The XML Schema type for this element is xsd:duration.

maxEntities: This parameter specifies the maximum number of entities in a notification that are returned to a subscription listener. The XML Schema type for this element is xsd:int.

bindingKey: This parameter is required only when asynchronous notifications are used. This parameter specifies the bindingTemplate that the node uses to deliver notifications to subscription listeners. Only HTTP and SMTP transports are supported to deliver notifications. When using HTTP, the Web Service defined should implement the notify_subscriptionListener API, so that notifications are delivered to the subscription listeners by invoking the Web Service. On the other hand, when using SMTP, the notifications are delivered through e-mail, which is specified in the bindingTemplate.

brief: This parameter specifies the level of information that is returned to a subscription listener. When this parameter is set to “true”, the subscription results will return a keyBag that matches the entries in the subscriptionFilter. For example, if find_binding call is specified in the subscriptionFilter element, the subscription will contain only the binding keys when the brief is enabled. The XML schema type for this element is xsd:boolean.

Subscription in Systinet’s WASP UDDI 4.6

WASP UDDI 4.6 provides the UDDI V3 subscription implementation as a part of its UDDI registry offering. To know how subscriptions work, you can walk through the subscription demos provided in the WASP UDDI 4.6 product.

UDDI Business Registry Version 3 (UBR.3) Beta Availability

UDDI Version 3 (V.3) beta implementations are available for use from IBM, Microsoft, and SAP. This enables early adopters and tool providers to explore the new functionalities offered by these registries.

UDDI Business Registry V.3 beta implementations can be found at:

IBM: https://uddi.ibm.com/beta/registry.html
Microsoft: http://uddi.beta.microsoft.com
SAP: http://udditest.sap.com


With the help of subscriptions, a subset of the registry data can be monitored for a specific business need. Subscription helps businesses participate in a collaborative environment where they address the needs of a specific industry. More registries should soon become available with this powerful feature in place. The vision of UDDI is coming to reality with its powerful features such as subscriptions change the way businesses collaborate. In the next part of this article, I will discuss the Systinet WASP Subscription API interactions with the UDDI registry.


UDDI Version 3 Features List

UDDI Version 3.0
UDDI Spec Technical Committee Specification, 19 July 2002

Rocket ahead with UDDI V3

Systinet WASP UDDI 4.6 Product Overview

Systinet WASP UDDI 4.6 Product Documentation

About the Author

Arulazi Dhesiaseelan has been working as a Senior Software Engineer in Hewlett-Packard. He has a Master of Computer Applications Degree from the PSG College of Technology, India. He has more than three years of industry experience. He was also involved in the UDDI4J project hosted at http://uddi4j.org. He has been working on Web Service-related technologies such as WSDL, UDDI, and SOAP. Currently, he is involved in developing an object-based infrastructure for mobile solutions. He can be reached at aruld@india.hp.com.

Get the Free Newsletter!

Subscribe to Developer Insider for top news, trends & analysis

Latest Posts

Related Stories