News Stay informed about the latest enterprise technology news and product updates.

Extending UDDI with robust Web services information

As enterprises begin to deploy more and more Web services, they need some method of keeping track of this diversity. Many companies are turning to universal description, discovery and integration (UDDI) registries to store information about those Web services. The UDDI standard contains a limited amount of information about Web services.

Market Analysis

Extending UDDI with robust Web services information
As enterprises begin to deploy more and more Web services, they need some method of keeping track of this diversity. Many companies are turning to universal description, discovery and integration (UDDI) registries to store information about those Web services. The UDDI standard contains a limited amount of information about Web services: the businesses, their exposed services and the binding templates (physical locations and references to the supported formats) of those services.

More information can be exposed about Web services than just these few attributes. For example the OASIS Technical Note "Using WSDL in a UDDI Registry 2.0" allows all of the information present in a WSDL specification to be stored in UDDI. This import of WSDL information into UDDI is just the first logical step in having more robust information about Web services represented in UDDI. The techniques that are used there can be used for even richer descriptions of Web services, whether through a technical note on new types of UDDI-stored information or a company's own internal efforts.

WSDL mapping
Web service Description Language files describe a Web service's operations (as a portType), their encoding formats and transport protocols (bindings), specific endpoint locations (ports) that implement a binding and services that contain a collection of named ports. Before this technical note, WSDL specifications of Web services were merely referenced by UDDI. Specifically, it is linked to by the overviewURL of a tModel referenced by the tModelInstanceDetails collection on the bindingTemplate. All of the information described above could be accessed by a developer by navigating to the WSDL from UDDI and accessing the information from there. In some cases the mapping repeats similar information that already should exist somewhere in UDDI (such as the WSDL services and ports). In other cases (such as WSDL portTypes and bindings) UDDI did not have this information and the native data tracked by UDDI had to be extended in significant ways. These techniques will be instructive in other efforts to extend information available on Web services from UDDI.

PortType mapping
WSDL portTypes are mapped to UDDI tModels created for each portType. The name of the tModel is the same as the local name of the portType in the WSDL specification. The overviewURL of the tModel is the URL of the WSDL specification.

The tModel contains a categoryBag with a keyedReference for the type of WSDL artifact and the namespace of WSDL definitions element containing the portType. Specifically there will be a tModelKey referring to the tModel for a taxonomy of WSDL objects: portType, binding, port and service. The keyName and keyValue in the keyedReference will both be portType. There is also a category representing the namespace: a keyedReference with a tModelKey of the XML Namespace taxonomy tModel.

Binding mapping
In similar fashion, WSDL bindings are mapped to tModels created for each binding, with name of the tModel gathered from the WSDL binding local name and the overviewURL being the URL of the WSDL spec. Using categoryBags with keyedReferences:

  • the type is categorized as "binding"
  • the namespace is categorized as the WSDL binding namespace
  • a portType category on the binding is used to refer to the portType tModel that was created for the WSDL portType (as described above)
  • protocol and transport category are set to whatever those attributes were in the WSDL binding
Port and service mapping
A WSDL port is mapped to a UDDI bindingTemplate. A tModelInstanceInfo container is used to refer to the tModels that were created for the portType and the binding, indicating that the port implements that portType (or interface) and that binding. UDDI Version 2 did not have categories on binding templates so there is no categoryBag on the bindingTemplate.

WSDL services containing multiple ports are mapped to UDDI business services containing multiple binding templates. A categoryBag is created on each UDDI business service with the type category set to "service," the namespace and localname categories set to the namespace and localname of the WSDL service.

Representing extended Web service attributes in UDDI
This summary shows two major techniques that we can see used above to enhance the data stored natively about each Web service in UDDI.

tModels as classes
Generate tModel instances to represent objects associated with a given Web service. Represent attributes of those objects using categories on a categoryBag. One of the categories should have a reference to the tModelKey for the taxonomy that contains the type of the object. In effect, this is a way of creating entire new classes of objects that may be associated with a Web service. This is most appropriate when there are collections of information associated with a Web service that need to be represented.

An example of this from the WSDL-UDDI mapping spec is the tModels that are generated for each WSDL portType and binding. Another example of this technique could be a new tModel for multiple attributes of performance information. It would be have a category that referred to another tModel with a taxonomy (in this case a simple list) of new types, such as "PerformanceInformation," "ReliabilityInformation," and "AvailabilityInformation." The keyValue could be one of those new types such as "PerformanceInformation." As with the WSDL- UDDI generated portTypes and bindings, there could be multiple categories on the new tModel, each representing an individual performance metric.

These new generated tModels that act as "classes" can be referenced from a UDDI businessService's bindingTemplates using tModelKey references in the tModelInstanceDetails structure. They can also be referenced from categories on businessServices or on UDDI Version 3 bindingTemplates (using the ability to create new categories as attributes described below).

Categories as attributes
Create new built-in ("canonical") tModels for new attributes that you want to reflect on UDDI businessServices, bindingTemplates or "class tModels" described above. UDDI business services and UDDI V3 bindingTemplates can link to these tModels by adding a category to the categoryBag on the business service or bindingTemplate that references these new categories.

An example of this technique from the mapping spec are the WSDL Entity Type and XML Namespace tModel that are placed as categories on the UDDI business services and the tModels to represent WSDL portTypes and bindings. Another example is that the performance of a Web service could be indicated with an additional tModel representing AverageResponseTime taxonomy, values of which could be stored in the categories on each WSDL-UDDI generated binding tModel.

UDDI is an excellent method of keeping track of Web services as an organization's volume of them grows. As UDDI usage increases, developers and users will want to have more information about each Web service available. Much of this information is stored elsewhere now. Recommendations such as the WSDL-UDDI mapping specification are a good way to enhance the information available in UDDI. The techniques that are used by the WSDL-UDDI spec can be applied to enhance the information available in UDDI even further.

[WSDL-UDDI] "Using WSDL in a UDDI Registry, Version 2.0"
[UDDI-Data] "UDDI Data Structure Reference"

About the Author
Adam Blum is chief technology officer (CTO) of Systinet. Blum leads all technology strategy and positioning efforts. Blum spent five years with Microsoft Corporation, most recently as a manager in Microsoft s SQL Server product group. More recently, Blum served as the vice president of engineering at Talaris Corporation, a provider of a Web services-based platform for supplier integration of corporate services. At Talaris, Blum was responsible for all software development and QA. Blum also worked as Vice President of Engineering for CommerceOne where he managed development of all XML-related tools and platforms, including MarketSite, the world's first XML-based document integration server. Blum's Weblog,, covers Web services and XML approaches and tools. He can be contacted at

You can also pose a question to Adam in our Ask the Experts section. Click here to visit his past UDDI answers and ask your question.

Dig Deeper on Topics Archive

Start the conversation

Send me notifications when other members comment.

Please create a username to comment.