Contents: A new UDDI version Multi-registry environments Publisher specified keys Subscription Subscription example Policy Security Enhanced inquiry New find qualifiers Find qualifier extensibility and compound queries Management of large result sets Conclusion Resources About the author Rate this article Related content: Understanding UDDI: Tracking the evolving specification Subscriptions: dW newsletters dW Subscription (CDs and downloads)

Tom Bellwood (bellwood@us.ibm.com)
Senior Technical Staff Member, IBM
01 Nov 2002

If you are familiar with Web services, you probably recognize the importance of Universal Description, Discovery, and Integration (UDDI) and the role it plays as a Web services registry. Having a general solution for describing Web services so that you can quickly and easily discover these services is fundamental to the success of heterogeneous Web service environments. This article focuses on support for multi-registry heterogeneous environments, security, and the separation of policy from implementation, which are the key features that strongly differentiate Version 3 from prior versions.

This article was published in the November 2002 issue of the IBM developerWorks journal .

A new UDDI version
The previous version of UDDI added significant support to help fuel the growth of Web services, primarily through its introduction of business relationships and external taxonomy validation, more powerful inquiry and internationalization features, and others. Unfortunately, significant gaps still exist in UDDI, which have confined its adoption primarily to use in private registry settings on company intranets, typically within a single business. Both UDDI adopters and implementation providers alike have identified various areas that require further development, resulting in a number of focus areas for the UDDI V3 specification development effort:

• Support for multi-registry environments.
• Separation of policy from implementation.
• Security features.
• Enhanced inquiry.

The July 2002 release of the V3 specification addresses each of these areas. This article discusses each area, covers key features in V3, and illustrates how to use these features.

The UDDI documentation also received a major facelift in V3 as well. In V2, there were several specification documents: APIs, Data Structures, Replication, and Operators. The V3 specification presents a unified, organized document that eliminates redundancy and conflicts that were present in the prior documentation. The new documentation also has significant explanatory and descriptive information in a set of appendices that covers the use of key features. With the addition of many new features, the document clearly differentiates between normative features, requiring implementation by registries, and non-normative features, which specify required registry behavior if implemented.

That said, the unified V3 specification is a somewhat daunting document; this article summarizes the capabilities of V3 and assumes some familiarity with prior versions of UDDI (see Resources).

Multi-registry environments
Generally, Web services environments are not homogeneous. Sometimes it is appropriate for Web services to be visible to all, limitations on their general use notwithstanding. A public registry is best for these cases. In other situations, certain Web services may be proprietary or otherwise restricted, limiting the ability to discover their existence or to obtain information on how to invoke them to be used by certain groups, such as within a company or an organization specific to an industry segment. These cases are best served by the use of private registries. Private registries enable their owners to exert control over their visibility, content, and use.

The UDDI Business Registry (UBR), often termed the public registry, is jointly operated by IBM, Microsoft, NTT Communications, and SAP, serving the needs of those who are interested in publicly visible Web services. Support for UDDI in products is available from various companies, including IBM. You can configure products and use them to fill the role of private and semi-private registries.

So what's been missing? For starters, there has not been a good solution for use cases, such as when a private service needs to go public. Transferring registry information on existing businesses and their services from one isolated registry to another, in a way that fully preserves the keys used to uniquely identify these entities, has not been possible. This was because saving new entities required generating a new and unique key by the registry itself. Prior to V3, UDDI registry implementations had no relationship to one another. Identical entities having the exact same keys could not be saved into multiple registries.

In recognition of the reality of multi-registry environments, V3 introduces the concepts of root and affiliate registries to provide guidance on interregistry associations. A root registry acts as the authority for key spaces. Such registries are used to delegate key partitions so that other registries can rely upon the root registry to verify and maintain the uniqueness of such key partitions. The UBR is a good example of a root registry, which Figure 1 illustrates (adopted from the UDDI V3 specifications).

Affiliate registries interact with a root registry. These affiliates rely upon the root registry for delegating unique key partitions. Afterwards, data can be shared between and among the root and affiliate registries with the assurance that each given key partition is unique. Do not confuse the affiliation of multiple registries with the concept of replication, which UDDI has always supported for sharing entities identically between two or more node implementations that compose a particular registry.

Publisher specified keys
V3 enables registry affiliation by providing two features: publisher-specified keys and subscription. Prior to V3, the formatted Universally Unique Identifier (uuid) keys uniquely identified the core UDDI data types (businessEntity, businessService, bindingTemplate, and tModel). Specification of keys associated with such entities was limited to the registry itself. Publishers creating new entities would simply leave out the value for the key in their save_xx API request and the registry would automatically generate one. Supplying a key value implied an update to existing data in the registry. An error occurs if the registry finds no match during the save_xx operation.

In V3, it is now possible for publishers to specify their own key values when they create new entities. This provides the ability to save the same entity with the same key value in more than one registry. Entities in a private registry, for instance, can now be copied into another affiliated private registry for broader exposure or into a root registry, such as the UBR, for public consumption. The reverse also is true.

Depending upon the policy of the particular registry, V3 also enables the use of vanity keys. The uuid-based keys are an essentially random hexadecimal string in a defined format that serves no purpose beyond that of ensuring uniqueness. One of the drawbacks of such a scheme is that these long, meaningless strings are difficult to manage, remember, and use. While tooling generally hides most of the pain associated with this, a more flexible and useful solution often has been requested. Vanity keys allow publishers to specify a meaningful name for a key as an alternative to having a uuid-based key assigned automatically by the registry.

The V3 specification establishes some rules on how this is done. While it is a registry policy decision, the V3 specification recommends an appropriate keying policy. First, keys are now Universal Resource Identifiers (URI) instead of simple uuids. Each key in V3 is now known as a uddiKey. A uddiKey can be either a uuidKey, a domainKey, or a derivedKey. A uuidKey is essentially the V3 equivalent of a uuid-based key, in the form "uddi:" uuid. A domainKey takes the form "uddi:" domain, where the domain is based upon an established DNS record. A derivedKey has the form uddiKey ":" KSS, where the key specific string (KSS) is composed of upper and lowercase characters, numbers, and other symbols permitted in a URI. Given the number of us, ds, and is in this clinical explanation, a few uddiKey examples might help:

• Here is an example of a typical uuidKey: uddi:2AB7E4BF-887B-923A-9936-443EAAC8AE23. Essentially, this is the familiar and sometimes despised pre-V3 uuid entity key, converted into a uuidKey by prefixing "uddi:" to it.
• Here are some domainKey examples: uddi:mydomain.com and uddi:yourdomain.com. In each case, mydomain.com and yourdomain.com are the respective domains.
• Finally, a few derivedKey examples are useful: uddi:2AB7E4BF-887B-923A-9936443EAAC8AE23:derivedPart GoesHere and uddi:mydomain.com:my Product:browsingService. The derivedPartGoesHere and myProduct:browsingService are the KSS part of the derivedKey.

For registries that use the V3 recommended key policy, there are also some rules for using keys that are derived from a domainKey. You must acquire a license to publish such keys. This entails creating a special tModel known as a domain keyGenerator. These tModels establish a key partition from which uddiKeys can be derived and used in other entities, which are created and controlled by the publisher. The tModelKey for these tModels must be in the form of a domain_key and must end with the term keyGenerator. The publisher must categorize the tModel using a value of keyGenerator from the uddi-org:types value set. Depending upon registry policy, the publisher may need to sign these tModels. Publishers may then create derived keys based upon the domain identified by a keyGeneratortModel that they own.

Subscription
The subscription feature in V3 enables you to track changes in the content of a UDDI registry through either synchronous requests for this information or through asynchronous notifications made by a registry node to the requestor, as illustrated in Figure 2.

While subscription is a non-normative part of the V3 specification, it fills a key role in enabling registry affiliation. In scenarios where one or more affiliated registries rely upon a root registry to manage key spaces, an affiliated registry may want to be aware of changes of interest in the root registry and then reflect copies of those entries into the affiliate.

As an example, a pharmaceutical industry segment has an affiliate registry that manages the Web services that its member companies offer to each other, covering everything from the acquisition and distribution of raw materials and supplies to product distribution and business process management. Some services of general interest used by these companies also are public in nature and are registered in the UBR, which is the root registry for the pharmaceutical affiliate. For the convenience of its members, the affiliate wants to include copies of such entries in its registry. Subscription provides a simple means by which the affiliate can identify the types of entries in which it has an interest and request notification when such entries are added, changed, or deleted by the owning publisher(s). In this way, the affiliate can easily keep up-to-date.

There are, of course, many other examples of where subscription is useful, such as the business that wants to be kept aware of when its list of potential suppliers changes. Another example might be of a business that issues certifications or organizational memberships. It could use subscription to determine when others are attempting to assert such a relationship by tracking when a publisherAssertion of this nature is created against its businessEntity.

The subscription API set provides a great deal of flexibility on how information of interest is identified and communicated back to the subscriber. Subscribers define the filter criteria for a subscription, which determines which registry changes will be tracked for the subscriber. Subscribers establish a subscription by issuing a save_subscription request. This is essentially a compound API, because the filter criteria, known as a subscriptionFilter, is essentially a compound request. A subscriptionFilter must contain one of the UDDI inquiry API requests, such as find_tModel of get_BusinessService. The subscriber may establish multiple subscriptions, if additional criteria need to be used.

Subscribers also register a number of other preferences when saving a subscription request, such as how they want to receive the results of activity matching their subscription criteria. You can opt to have the registry provide notifications through either e-mail or Simple Object Access Protocol (SOAP) messages to a service that the subscriber supplies and on a schedule that the subscriber defines (although this and numerous other aspects of subscription are subject to individual registry, node policies, or both). A bindingKey corresponding to a bindingTemplate with a valid endpoint is required in the subscription to use this feature.

To take advantage of the SOAP message option, subscribers are required to support a SOAP (subscription listener) service endpoint that processes notify_subscriptionListener messages from the registry containing their subscription results. Large result sets can be chunked into multiple groups to facilitate a subscription listener's needs. Subscribers can elect to receive results in detail (which takes the form of the standard results provided from the particular inquiry API used as part of the filter criteria in their subscriptionFilter), or in brief, for which only a list of the affected entity keys is provided.

Subscription example
Here is a simple example of how this works, along with some XML code showing some of the new V3 SOAP messages. The Association of Micro-Brewed Beer Producers (AMBP) offers membership in its organization to beer producers who meet their strict criteria for quality and who pay the annual dues. Membership in the AMBP is desirable to producers because it indicates to customers the high quality standards they have met. Dues include both a monetary payment and a substantial product-based donation made directly to the organization board members -- apparently judging quality requires extensive testing. With membership comes access to many Web services tailored to their industry for everything from equipment and supply ordering to more generalized services, such as invoicing. The AMBP operates a semi-private UDDI registry whose use is restricted to its membership. This is an affiliate registry of the UBR. The AMBP populates its affiliate registry with copies of Web services of interest from the UBR.

To monitor UBR activity related to its areas of interest, the AMBP establishes a subscription with one of the UBR node operators. This subscription requests daily notifications through SOAP messages on activities of interest. It will operate a Web service to respond to the messages provided and process the entries returned for inclusion in its own affiliate registry. To set this up, it first needs to register a service in their AMBP businessEntity with a bindingTemplate that indicates its desire to receive such notifications, as shown in Listing 1.

<save_binding xmlns="urn:uddi-org:api_v3">
  <authInfo>AMBP_AuthCode</authInfo>
  <bindingTemplate
    bindingKey="uddi:AMBP.org:
     subscriptionListenerService:binding"
    serviceKey="uddi:AMBP.org:
     subscriptionListenerService">
    <description>notify_subscriptionListener
     service binding for AMBP subscription 
     to UBR.
    </description>
    <accessPoint URLType="https">
      https://AMBP.org/services/
       notify_subscriptionListener
    </accessPoint>
    <tModelInstanceDetails>
      <tModelInstanceInfo
        tModelKey="uddi:uddi.org:
        v3_subscriptionListener"/>
    </tModelInstanceDetails>
  </bindingTemplate>
</save_binding>
  

<save_subscription xmlns="urn:uddi-org:sub_v3">
  <authInfo>AMBP_AuthCode</authInfo>
  <subscriptions>
    <subscription brief="true">
      <subscriptionFilter>
        <find_service xmlns=
          "urn:uddi-org:api_v3" >
          <categoryBag>
            <keyedReference
              tModeKey="uddi:ubr.uddi.org:
                taxonomy:unspsc"
              keyName="Beer"
              keyValue="50.20.20.02.00"/>
          </categoryBag>
        </find_service>
      </subscriptionFilter>
      <bindingKey>uddi:AMBP.org:
        subscriptionListenerService:binding
      </bindingKey>
      <notificationInterval>P1D
      </notificationInterval>
      <maxEntities>1000</maxEntities>
    </subscription>
  </subscriptions>
</save_subscription>
  

Next, it registers its subscription request for daily notification, as shown in Listing 2. The simple filter criteria chosen seeks services , based on UNSPSC classification, that are classified as beer producers.

In reality, such a subscription request would include many more classifications to establish a complete list of the types of services to be retrieved. The node would now use the SOAP access point to invoke the Web service identified by the bindingTemplate of the subscription. This would entail use of the API notify_subscriptionListener. The node would issue this call, as illustrated in the code sample in Listing 3.

<notify_subscriptionListener>
  <subscriptionResultsList>
    <coveragePeriod>
      <startPoint>20020727T00:00:00
      </startPoint>
      <endPoint>20020728T00:00:00</endPoint>
    </coveragePeriod>
    <subscriptionbrief="true">
      <subscriptionFilter>
        <find_servicexmlns=
         "urn:uddi-org:api_v3" >
          <categoryBag>
            <keyedReference
              tModeKey="uddi:ubr.uddi.org:
                taxonomy:unspsc"
              keyName="Beer"
              keyValue="50.20.20.02.00"/>
          </categoryBag>
        </find_service>
      </subscriptionFilter>
      <bindingKey>
        bindingKeyOfTheClients
        NotifySubscriptionListenerService
      </bindingKey>
      <notificationInterval>P1D
      </notificationInterval>
      <maxEntities>1000</maxEntities>
      <expiresAfter>20030101T00:00:00
      </expiresAfter>
    </subscription>
    <keyBag>
      <deleted>false</deleted>
      <serviceKey>uddi:BeerSupplies.com:
        maltSelectionService</serviceKey>
      <serviceKey>uddi:Containers.com:kegs:
        orderingService</serviceKey>
    ...
    </keyBag>
  </subscriptionResultsList>
</notify_subscriptionListener>
  

Use of the brief attribute caused only the serviceKey values to be returned in the keyBag in Listing 3. Next, the AMBP subscription listener service can make requests to the UBR to retrieve the full business entities corresponding to these serviceKey values and integrate them into its own affiliate registry.

Policy
Policies describe the specific behavior of a registry or of a node within a registry, insofar as the UDDI specification permits such variances. In earlier versions, the UDDI specification mixed policy issues with UBR implementation concerns. V3 separates these and expands the role of policy by prescribing a set of policies that registries must address. The UDDI specification addresses issues of policy using several terms:

• Policy abstractions. Describes various types of high-level policies and provides broad definitions of high-level information management policies.
• Policy rule. The basic building block of any policy-based system. It defines the metrics of a set of actions mapped against a set of conditions.
• Policy decision. Involves the evaluation of a policy rule's conditions.
• Policy decision point (PDP). The logical entity where policies are decided. In UDDI, this will be either the registry or the nodes within the registry.
• Policy enforcement point (PEP). The point at which policies are enforced. In UDDI, this will be at either the registry or node level.

Registries may delegate certain PDPs and PEPs to their constituent nodes. Figure 3 illustrates these relationships. The specification groups policies into several categories, including:

• Policy delegation. Covers policies for determining which sets of polices may be delegated to nodes.
• Keying. Defines policies on key format, generation, and so on.
• Information access and control. Defines policies on registration and authorization of users, privacy, and more.
• APIs. Defines policies on data confidentiality for each API set (Inquiry, Publication, Subscription, Custody, and others).
• User policies. Describes policies on user publication limits and ownership transfer.
• Data custody. Determines whether custody transfer is permitted.
• Replication. Determines whether replication is supported.
• Subscription. Determines whether subscription is supported and other related policies affecting the behavior and capabilities provided in subscription, such as the duration of a subscription.
• Value sets. Defines policies dealing with management of external validation and related caching behavior.

Security
The UDDI security model is defined by the set of registry and node policies and their implementations. From a security features perspective, the capability most lacking in UDDI has been the ability to determine the veracity of data in a registry. Use of registries in completely private environments ameliorated this to some extent by allowing managed control over access to registry data and over who is in the user set, but the general problem of trust remained. V3 adds support for digital signing of all core data types to address issues of data integrity and authenticity not previously available in UDDI.

By digitally signing data in the registry, publishers can now ensure that no one can spoof their data with imitations that are easily mistaken by inquirers. Furthermore, once the data is signed by a publisher, altering it in any way breaks the signature, providing confidence in the data's integrity. By verifying the signature, inquirers using the registry can also be assured that a signed entity is valid and that the publisher represented by the signature created it. They can now also issue inquiries that only return results pertaining to signed data.

Given the multi-registry environment enabled in V3, the reliability of data becomes even more important. When signed data is copied between registries, you can guarantee its integrity by simply validating the signature.

To support digital signatures, both publishers and registry implementations must support normalization and canonicalization. In normalization, the registry must reduce each of the characters that make up the SOAP message to a single standard representation. This is necessary because in UTF-8, it is often possible to represent the same character with multiple encodings.

Canonicalization creates a standard representation of XML, addressing issues like the tag representation, attribute ordering, namespace declaration, expansion and ordering, and white space handling. Ensuring consistent behavior is critical. Registries must save and retrieve data in a well-defined way so that a digital signature is not broken. This also places a burden on the publisher, who must similarly process the data before signing it so that the registry will not modify it further during these steps so that the signature is not broken.

The use of digital signatures improves both the quality of data in UDDI and provides users with the trust and protection needed for Web services used in e-business and other applications.

Enhanced inquiry
Each version of UDDI provides significant new enhancements to the Inquiry API in response to user requests. V3 adds support for:

• new find qualifiers
• find qualifier extensibility
• compound queries
• management of large result sets.

Here is a quick tour of what has changed.

New find qualifiers
Recall that find qualifiers are essentially flags that alter the behavior of searching in UDDI, such as how results are sorted or matching is performed. The new find qualifiers provide enhanced selection options in the area of internationalization, but also formalize and expand some older capabilities as well. Those related to internationalization include:

• case Insensitive Match. Matches without regard to case.
• case Insensitive Sort. Sorts without regard to case.
• case Sensitive Sort. Sorts with consideration of case.
• diacritic Insensitive Match. Matches without regard to diacritic markings (for example, accents).
• diacritic Sensitive Match. Matches with consideration of diacritic markings.
• UTS-10. Sorts based on the Unicode Collation Algorithm on elements normalized, according to Unicode Normalization Form C.

Other new find qualifiers include:

• approximate Match. UDDI now has standardized wildcard matching based on an SQL LIKE syntax.
• binary Sort. Causes a binary sort by name.
• exact Match. Matches based on exact criteria supplied. This is the new default.
• signature Present. Returns only results that contain a signature.

Find qualifier extensibility and compound queries
The set of defined find qualifiers may be more easily extended by registries because now they may be either tModelKeys or can be represented by their short names. Compound queries were added to several of the inquiry APIs to facilitate common tooling idioms. In particular:

• find_binding. Permits the discovery of binding Templates across businessService elements, as well as the embedded use of the find_tModel API. The tModel results of this inner find_tModel API are added to any that were supplied in the tModelBag provided with the find_binding API call.
• find_business. Permits the embedded use of the find_relatedBusinesses and find_tModel APIs. When an inquirer includes the find_relatedBusinesses API here, this causes the results returned by find_business to be an intersection of the businesses returned by the find_relatedBusinesses query and those returned based upon the other criteria supplied in the find_business query. Use of find_tModel behaves similarly to that described previously.
• find_service. Permits the embedded use of the find_tModel API, with similar behavior as described previously.

Management of large result sets
Finally, V3 now supports large result sets, enabling inquirers to retrieve results in a quasi-chunked fashion. This is not a true cursor-like behavior because, while the registry allows chunked retrieval of results, these results do not represent a frozen snapshot in time. Data in the registry could change during the retrieval process (adds or deletes), which could affect the overall results.

Conclusion
This article focused on the key differentiators for V3 that create a more robust infrastructure for the Web services environment. There also are many other new features in V3, although they are too numerous to describe fully here. A few other areas worth mentioning include:

• Enhancements to the custody and ownership transfer APIs.
• Simplifications for external validation.
• Replication enhancements.
• More useful access point content and behavior.
• Improved WSDL support.
• Much tighter schema definition.
• Complex categorization (allowing categorization information to be logically grouped -- for example, latitude and longitude).
• Extensibility.

With the completion of V3, the uddi.org effort has ended, and the specification and related IP have been transferred to the OASIS group for further development. With OASIS, UDDI will continue to evolve to meet the registry needs of Web services.

Resources

• Read the "Understanding UDDI: Tracking the evolving specification" article which appeared in the May 2002 issue of the developerWorks journal for more information on UDDI V2.
  
  
• Take a quick look through the features of UDDI version 3 or read the full UDDI version 3 specification document from UDDI.org.
  
  
• For more information on UDDI version 3 schemas and WSDL interfaces, read the additional documentation from UDDI.org.
  

About the author Tom Bellwood is a Senior Technical Staff Member with IBM and is an engineering professional with many years of experience in the technology sector, ranging from the world of semiconductor design and design automation to systems and application development. He is an expert on UDDI and how it supports the growing world of Web services. He is the technical lead for the IBM UDDI Business Registry, is a principal author of the UDDI V3 specification, is the OASIS UDDI specification Technical Committee cochair, and has spoken at many technical conferences. You can reach Tom at bellwood@us.ibm.com.

Rate this article This content was helpful to me: Strongly disagree (1) Disagree (2) Neutral (3) Agree (4) Strongly agree (5) Comments?

developerWorks > SOA and Web services >