Source Code for this article

The Web services model relies on a stack of software specifications that makes the interoperability of heterogeneous environments a viable possibility. Two essential specifications of this stack are WSDL (Web Service Description Language) and UDDI (Universal Description, Discovery, and Integration). Understanding each of these initiatives alone is fundamental to comprehending the Web services model; understanding the relationship between the two is critical to developing robust software based on Web services.

Before drilling into the relationship between these two initiatives, it makes sense to address them individually. Each offers powerful software potential in its own right, but their usage together helps create a truly exciting new software ecosystem.

Recipes and Cookbooks
WSDL provides an XML grammar to define the abstract interface and protocol bindings necessary to invoke a Web service. Fundamentally, WSDL describes the contract of that Web service so a client can interact with it. By interpreting a WSDL file, a piece of client software can be written to send and receive messages correctly to that Web service. You might say that WSDL represents the "recipe" of a Web service. From an object-oriented language perspective, it's analogous to an IDL file.

UDDI is a group of Web-based registries designed to house information about businesses and services in a structured way. Through UDDI, you can publish and discover information about a business and the services it provides. This data can be classified using standard taxonomies so that information can be discovered based on categorization. Of primary importance is that UDDI contains information about the technical interfaces of a business's services. Through a set of SOAP-based XML API calls, you can interact with UDDI at both design-time and runtime to discover technical data about a business's services, so those services can be invoked and used.

If WSDL files are a kind of recipe for interacting with Web services, then UDDI might be referred to as the cookbook where all the recipes reside. It offers a place to publish and inquire about different services based on different classifications and protocols.

However, this analogy is potentially inaccurate and misleading. A common misconception about UDDI is that it's nothing more than a cookbook - a massive White and Yellow Pages for Web services. While these analogies have some validity, they undercut and reduce UDDI's scope and intention. UDDI was designed to accomplish goals beyond simply offering a Web directory of services.

UDDI is a registry in the sense that it contains entries that direct users to resources outside of UDDI. The data it contains is relatively lightweight; as a registry, its task is to provide network addresses to the resources - schemas, interface definitions, endpoints - in other locations. UDDI has been designed in a highly normalized fashion, not bound to any technology. In other words, a UDDI registry entry can contain any type of resource, whether that resource is XML-based or not. For example, the UDDI registry could contain information about a business's EDI system, its DCOM interface, or a service that uses the fax machine as its primary communication mechanism. The point is, while UDDI itself uses XML to represent the data it stores, it allows for other kinds of technology to be registered. This design decision makes UDDI an enduring piece of infrastructure that won't become outdated as technology moves forward.

Beyond the Cookbook: Interfaces and Implementations
A consideration of interfaces and implementations helps us grasp how UDDI and WSDL work together. Both WSDL and UDDI were designed to delineate clearly between abstract metadata and concrete implementations. Understanding the implications of the division between abstraction and implementation is essential to understanding the design decisions behind WSDL and UDDI.

For example, WSDL makes a clear distinction between messages and ports. Messages, the required syntax and semantics of a Web service, are always abstract, while ports, the network address where the Web service can be invoked, are always concrete. You're not required to provide port information in a WSDL file. A WSDL file can contain solely abstract interface information and not provide any concrete implementation data. Such a WSDL file is considered valid. In this way, WSDL files are decoupled from implementations.

Perhaps one of the most exciting implications of this is the possibility of multiple implementations of a WSDL interface. This design engenders the opportunity for disparate systems to write implementations of the same interface, guaranteeing that the systems can talk to one another. If three different companies have implemented the same WSDL file and a piece of client software has created the proxy/stub code for that WSDL interface, then the client software can communicate with all three of those implementations with the same codebase.

UDDI draws a similar distinction between abstraction and implementation with its concept of tModels. The tModel structure, short for "Technology Model," represents technical fingerprints, interfaces, and abstract types of metadata. A corollary of tModels is the binding template, which is the concrete implementation of one or more tModels. Inside a binding template, you can register the access point for a particular implementation of a tModel. Figure 1 demonstrates this relationship.

Just as the schema for WSDL allows you to decouple interface and implementation, UDDI provides a similar mechanism. tModels can be published separately from binding templates that reference them. For example, a standard's body or industry group might publish the canonical interface for a particular use case or vertical, and then multiple businesses could write implementations to this interface. Accordingly, each of those business's implementations would refer to that same tModel.

Because both the UDDI and WSDL schema have been architected to delineate clearly between interface and implementation, the two constructs work together naturally. In fact, they're entirely complementary. WSDL files become tModels; the ports of WSDL files become binding templates. By decoupling a WSDL file and registering it in UDDI, you can populate UDDI with standard interfaces that have multiple implementations, providing a landscape of software that shares interfaces.

Example
There are many software scenarios where this environment might manifest itself. One example is in the electric commerce arena. Today, anyone who's ever been involved in an interoperability project knows that most of the work is in getting the two systems to talk, agreeing on protocols, transport mechanisms, and so on. With WSDL, the contract is defined semantically, simplifying interoperability enormously. And by using UDDI to discover multiple implementations of that WSDL, an entire trading community can be tapped into, based on UDDI queries. Moreover, by writing UDDI inquiry into its software, a company could dynamically and programmatically query UDDI at runtime to update information about a trading partner's Web service.

A useful example of how UDDI and WSDL relate can be found by looking at the UDDI Web service itself. The UDDI API is a SOAP-based XML API defined by an XML Schema (www.uddi.org/schema/2001/uddi_v1.xsd) and corresponding WSDL files for inquiry (www.uddi.org/wsdl/inquire_v1.wsdl) and publishing (www.uddi.org/wsdl/publish_ v1.wsdl). If you examine these WSDL files, you'll discover they don't have a element identified; in other words, no endpoints are provided.

These two WSDL files have been registered in UDDI as tModels. For instance, to see the uddi-org:publication WSDL defined in UDDI, see Listing 1. It's worth noting here:

1. The tModel has a tModelKey associated with it in the convention of a uuid. UDDI generates a uuid for every entity registered in it; this allows for the ability to uniquely refer to this UDDI registry entry in other entries, like a foreign key.
2. The contents of the correspond to the location of the WSDL file hosted at www.uddi.org. Again, UDDI is a registry that directs the user to resources outside of UDDI.
3. This tModel has been categorized using keyedReferences in the element. Each of the keyedReferences corresponds to a canonical taxonomy, as specified in the UDDI API specification (www.uddi.org/specification.html). These categorizations allow a human or a machine to know some details about this tModel - in this case, the most important categorization defines this tModel of type "wsdlSpec". By following these conventions, a user can write tools that can search UDDI and find only tModels that are categorized in a certain way.

<find_business xmlns="urn:uddi-org:api" generic="1.0">
<tModelBag>
<tModelKey>uuid:64c756d1-3374-4e00-ae83-ee12e38fae63</tModelKey>
</tModelBag>
</find_business>

The uuid of the uddi-org:publication tModel is passed in the tModelBag of the find_ business query. The natural language version of this query states, "Find all businesses that have implemented the uddi-org:publication interface."

Issuing such a query to UDDI today would return IBM and Microsoft, the two companies that currently host UDDI operator nodes. In the future, as other operator nodes emerge, this query would return multiple results. Once the result set is obtained, you can drill down further into the service information of Microsoft and IBM and discover the accessPoint for the UDDI Web service. A fragment of the Microsoft XML that contains the UDDI Web service is shown in Listing 2.

Moving Full Circle
A few things to point out: in the <bin ding Template> is an <accessPoint> where the Web service can actually be invoked. Also, a child of the <binding Template> is the <tModel Inst anceDet ails>, which refers to the uuid that contains the WSDL for the uddi-org:publication tModel. The link between interface and implementation is created in the tModel InstanceDetail. Thus, we have moved full circle from interface definition to implementation specifics.

To correctly register WSDL in UDDI, follow the set of best practices defined in the document "Using WSDL in a UDDI Registry 1.05"(www.uddi.org/pubs/ws dlbestpractices-V1.05-Open-200106 25.doc).

Conclusion
UDDI and WSDL act as complementary specifications that assist in enabling a software landscape based on Web services. WSDL provides a vendor-neutral, formal way to define Web services so that the next-generation remote procedure calls can be realized. UDDI provides a broad, standardized infrastructure that allows users to describe and discover Web services, both at runtime and design time. By combining these two standards, a Web services ecosystem can flourish.

Author Bio:
Karsten Januszewski is a program manager for UDDI within Microsoft's Business Applications Division, and a member of the UDDI Working Group. His background includes field service management, application service provider software, and B2B supply chain management software. Karsten has also worked for the Microsoft Healthcare Users Group, meeting the needs of information systems developers and users in the healthcare industry karstenj@microsoft.com

UDDI and WSDL: Natural Companions, by Karsten Januszewski
WSJ Vol 01 Issue 03 - pg.18

	


Listing 1

   <tModelDetail generic="1.0" operator="Microsoft Corporation" truncated="false" xmlns="urn:uddi-org:api">
   <tModel tModelKey="uuid:64c756d1-3374-4e00-ae83-ee12e38fae63" operator="www.ibm.com/services/uddi" 
authorizedName="0100000M99">
        <name>uddi-org:publication</name>
        <description xml:lang="en">UDDI Publication API - 
		Core Specification</description>
        <overviewDoc>
          <description xml:lang="en">This tModel defines the publication 
		  API calls for interacting with the UDDI registry.</description>
          <overviewURL>http://www.uddi.org/wsdl/publish_v1.wsdl</overviewURL>
        </overviewDoc>
        <categoryBag>
          <keyedReference tModelKey="uuid:c1acf26d-9672-4404-9d70-39b756e62ab4" 
		  keyName="types" keyValue="specification" />
          <keyedReference tModelKey="uuid:c1acf26d-9672-4404-9d70-39b756e62ab4" 
		  keyName="types" keyValue="xmlSpec" />
          <keyedReference tModelKey="uuid:c1acf26d-9672-4404-9d70-39b756e62ab4" 
		  keyName="types" keyValue="soapSpec" />
          <keyedReference tModelKey="uuid:c1acf26d-9672-4404-9d70-39b756e62ab4" 
		  keyName="types" keyValue="wsdlSpec" />
        </categoryBag>
      </tModel>
    </tModelDetail>


Listing 2

     <bindingTemplate serviceKey="33c3d124-e967-4ab1-8f51-
	 d93d95fac91a" bindingKey="48f2bc6b-a6de-4be8-9f2b-2342aeafaaac">
            <description xml:lang="en">Production UDDI server, 
			Publishing interface</description>
            <accessPoint URLType="https">https://uddi.microsoft.com/publish</accessPoint>
            <tModelInstanceDetails>
              <tModelInstanceInfo tModelKey="uuid:64c756d1-3374-4e00-ae83-ee12e38fae63">
                <description xml:lang="en">UDDI SOAP Publication Interface</description>
              </tModelInstanceInfo>
            </tModelInstanceDetails>
     </bindingTemplate>