Using WSDL Definitions with UDDI

WSDL is used to describe the interface of a web service. <tModel> UDDI documents provide metadata descriptions of a web service and pointers to specifications that describe their implementation. Given this provision, WSDL documents tie into the UDDI data structures in a couple of places:

• A <tModel> document should be created for each WSDL document supported by a web service. The <tModel> describes the abstract service type, not the service instance; if appropriate, the WSDL file pointed to by the <tModel> should not contain the <service> and <port> elements. Omitting the <service> and <port> elements allows a WSDL document to describe many web services located in several different places. The WSDL document's URL should be listed as the value of the <h1>viewURL> element. A <tModel> that references a WSDL document should have a categorization taxonomy of uddi-org:types; a categorization value of wsdlSpec should be applied to it by using a <categoryBag> element.

• A <bindingTemplate> structure is created for each unique URL access point used by the web service. The <bindingTemplate> document references one or more <tModel> documents containing the WSDL definitions supported at this access point.

• A <businessService> document is created for each web service. The document contains one <bindingTemplate> for each of the access points supported by the web service.

For example, if you implement one web service that has a single access point and is defined by a single WSDL document, you would create a single <tModel>, a single <bindingTemplate>, and a single <businessService>. Also, if you implement one web service that has two separate access points, each defined by a different WSDL document, you would create two <tModel> documents (one for each interface), two <bindingTemplate> documents (one for each access point), and a single <businessService> document. Each <bindingTemplate> document must point to the <tModel> that references its interface.

The Hertz reservation system web service provides a concrete example of how UDDI and WSDL work together. Here is the <tModel> for this web service:

<tModel authorizedName="..." operator="..." tModelKey="...">
    <name>HertzReserveService</name>
    <description xml:lang="en">WSDL description of the Hertz reservation service
     interface</description>
    <overviewDoc>
        <description xml:lang="en">WSDL source document.</description>
        <overviewURL>http://mach3.ebphost.net/wsdl/hertz_reserve.wsdl</overviewURL>
    </overviewDoc>
    <categoryBag>
        <keyedReference tModelKey="uuid:C1ACF26D-9672-4404-9D70-39B756E62AB4"
         keyName="uddi-org:types" keyValue="wsdlSpec"/>
    </categoryBag>
</tModel>

The WSDL document URL that this web service implements is contained as the value of the <overviewURL>. Additionally, this <tModel> is categorized as a web service by incorporating a <categoryBag>. The <categoryBag> has a <keyedReference> that specifies the keyName attribute as uddi-org:types and the keyValue attribute as wsdlSpec.

A <tModel> can further qualify the portion of the WSDL document it refers to. For example, a <tModel> can refer to a specific <binding> element within a WSDL document that has multiple <binding> elements. A pound sign fragment identifier is used between the URL of the WSDL document and the name of the <binding> element that accomplishes this qualification. For example:

<overviewURL>
http://mach3.ebphost.net/wsdl/hertz_reserve.wsdl#HertzReserveBinding
</overviewURL>

An Abstraction API

Writing a Java program that creates a complete web service registration to a UDDI registry requires a lot of effort: an understanding of SOAP, accessing a UDDI registry using the correct SOAP messages, and ensuring that WSDL documents are placed in the correct locations in a UDDI registry. A developer can easily make mistakes when following this model.

It didn't take long for companies to begin developing abstraction APIs that facilitate this process. It is argued that companies and developers will use the UDDI/WSDL/SOAP model more than any other model since it is a worldwide standard and supported by every major technology business. As such, providing an abstraction layer that simplifies publishing documents following this model makes sense.

IBM created an API that does this abstraction very cleanly. This API is called the Service Registry Proxy (SRP) and is contained as part of the UDDI4J project at IBM. This pseudocode demonstrates how to publish a new web service exposed by WSDL into a UDDI registry:

// Create an active connection to a UDDI registry
ServiceRegistryProxy srp = new ServiceRegistryProxy(
                     "http://localhost:8080/wasp/uddi/inquiry/",
                     "https://localhost:8443/wasp/uddi/publishing/",
                     "admin",
                     "changeit");
 
// Create a category list for an existing tModel (<categoryBag> document)
CategoryList categoryList = new CategoryList(
             TModelKeyTable.getTModelKey(TMODEL_UUID_VALUE_HERE),
             "uddi-org:types",
             "wsdlSpec");
 
// Create service provider (<businessService> document)
ServiceProvider serviceProvider = new ServiceProvider(
                "Demi Credit",
                "Financing Company",
                categoryList);
 
// Publish the service to UDDI
srp.publish(serviceProvider);