Chapter: XML and Web Services : Web Services Building Blocks

Web Services Description Language (WSDL) and Universal Description, Discovery, and Integration (UDDI)

The Web Services Description Language (WSDL) and Universal Description, Discovery, and Integration (UDDI), along with SOAP, form the essential building blocks for Web Services. Each one, taken separately, serves its own particular purposes.

WSDL:

Basic WSDL Syntax:

WSDL documents use the following elements:

• definitions. Associates the Web Service with its namespaces.

• types. A container for data type definitions, typically using a XML Schema

Definition (XSD) or possibly some other type system.

• message. An abstract, typed definition of the data contained in the message.

• operation. An abstract description of an action that the Web Service supports.

• portType. The set of operations supported by one or more endpoints.

• binding. A specification of the protocol and data format for a particular portType.

• port. An endpoint, defined in terms of a binding and its network address (typically a URL). This is not a TCP/IP port, which is represented by a number.

• service. A collection of related endpoints.

Example:

<?xml version=‖1.0‖?>

<types>

...

</element>

</schema>

</types>

</message>

</message>

</operation>

</portType>

<soap:operation soapAction=‖http://mySite.com/MyMethod‖/>

<input>

<soap:body use=‖literal‖/>

</input>

<soap:body use=‖literal‖/>

</output>

</operation>

</binding>

<documentation>My first service</documentation>

</port>

</service>

</definitions>

The types Element:

Thetypeselementcontainsdatatypedefinitionsthatarerequiredbythemessages describedintheWSDLdocument:

<types> <schematargetNamespace=‖http://mySite.com/myService.xsd‖

xmlns=‖http://www.w3.org/2000/10/XMLSchema‖> <elementname=‖MyRequest‖>

...

</element>

</schema>

</types>

The message and portType Elements:

Within the definitions element is one or more message elements:

</message>

</message>

SOAP Binding:

When using WSDL documents to describe Web Services that will exchange SOAP mes-sages (that is, SOAP endpoints), you need to have a way to indicate within the WSDL document all the necessary information about the SOAP messages that will be exchanged. WSDL uses extensibility elements to provide this information. The SOAP binding that is provided with WSDL supplies the following information:

• An indication that the WSDL binding is bound to the SOAP protocol.

• How to specify the address for the SOAP endpoints.

• For the HTTP binding of SOAP, the URI for the SOAPAction HTTP header

• A list of definitions for all Header elements in the SOAP Envelope.

• A way of specifying SOAP roots in XSD.

The service Element:

The service element represents a collection of port elements, where each port repre- sents the availability of a binding at a particular endpoint:

<documentation>My first service</documentation>

</port>

</service>

The binding attribute of the port element ties it to the corresponding binding element defined previously.

The documentation Element:

You should also notice the documentation child element of the preceding service ele- ment. This element essentially allows you to provide a human-readable comment and is allowed in every other element as well.

The import Element

The import element is an optional element that allows you to break up a WSDL document into multiple documents. When present, it must immediately follow the definitions element. The following example imports a schema, but it is possible to import any WSDL elements, including the definitions element, essentially allowing you to import

an entire WSDL document:

The import element is particularly useful for breaking up a WSDL document into inter- face and implementation documents.

soap:binding, soap:operation, soap:header, and soap:body

The following example shows a SOAP binding of a request/response operation over

HTTP:

<soap:operation SOAPAction=‖http://mySite.com/MyMethod‖ style=‖rpc‖ />

<input>

<soap:body use=‖encoded‖ namespace=‖http://mySite.com/myService‖ encodingStyle=‖http://schemas.xmlsoap.org/soap/encoding/‖ /> <soap:header message=‖tns:MyMethod‖ part=‖MyHeader‖ use=‖literal‖/>

</input>

<soap:body use=‖encoded‖ namespace=‖http://mySite.com/myService‖ encodingStyle=‖http://schemas.xmlsoap.org/soap/encoding/‖ />

</output>

</operation>

</binding>

Note that the style attribute of the soap:binding element is set to rpc. In the case of a one-way operation over SMTP, for example, the style attribute would have a value of document (and document is the default if the attribute is omitted). The transport attribute (here, set to the URI of the HTTP binding in the SOAP specification) indicates to which transport of SOAP this binding corresponds.

soap:address, soap:fault, and soap:headerfault

There are a few additional elements in the SOAP binding worth mentioning. First, the soap:address element simply assigns a URI to a port:

</port>

</service>

The soap:fault element specifies the contents of the SOAP Fault element:

<fault>

<soap:fault name=‖MyFault‖ use=‖encoded‖ encodingStyle=‖http://schemas.xmlsoap.org/soap/encoding/‖

<http://schemas.xmlsoap.org/soap/encoding/>/>

</fault>

Finally, the soap:headerfault element follows the syntax of the soap:fault element but refers to SOAP Fault in Header elements.

WSDL Implementations:

Because WSDL is a bridge technology in the sense that it bridges SOAP and UDDI, you‘re unlikely to find a WSDL toolkit that stands by itself. The two most popular WSDL implementations, therefore, are parts of other toolkits:

• The Microsoft SOAP Toolkit. This toolkit, covered in depth in Chapter 15, is primarily aimed at developers who want to work with SOAP in a Microsoft environment, although it does support

Microsoft‘s UDDI implementation.

• The IBM Web Services Toolkit (WSTK). This toolkit provides WSDL support, several security enhancements, UDDI integration, and support for the IBM WebSphere application server. The WSTK also includes the open-source Web Services Description Language for Java Toolkit (WSDL4J)

Demo Client Application MyClass.java

public class MyClass

{

public int MyMethod (String arg)

{

return 47;

}

public static void main ( String[] args )

{

System.out.println( ―output‖ );

}

Introduction to UDDI:

If WSDL is The Empire Strikes Back, then UDDI is The Return of the Jedi, concluding the chapters on Web Services. Universal Description, Discovery, and Integration (UDDI) is a platform-independent, open framework for describing services, discovering businesses, and integrating business services using the Internet as well as public registries of Web Services designed to store information about businesses and the services they offer. UDDI is also a specification for building such registries as well as an application programming interface (API) that exposes the functionality of the registries. Fundamentally, UDDI provides for the publication and discovery of Web Services, which are the key functional components of the Service-Oriented

Architecture explained in Chapter 14, ―Architecting Web Services.‖

The UDDI Consortium, established by hundreds of companies, emerged in response to a series of challenges posed by the new Web Services model. These challenges included the following:

• How do you discover Web Services?

• How should information about Web Services be categorized?

• How do you handle the global nature of Web Services? How do you provide for localization?

• How can interoperability be provided, both in the discovery and invocation mechanisms?

• How can you interact with the discovery and invocation mechanisms at runtime?

For UDDI to provide the foundation for Web Services registries, therefore, it had to serve two primary roles within the Web Services model: Service publication and service discovery).

The rest of this chapter addresses how UDDI‘s publication and discovery capabilities operate as well as how UDDI addresses the listed challenges.

UDDI Basics:

Public UDDI registries are hosted by operator nodes, which are companies such as Microsoft and IBM that have committed to running public UDDI nodes. The public reg- istry system is loosely modeled after the Domain Name Service (DNS) system, in that there are multiple registries responsible for synchronizing their data with each other. Currently, each public UDDI node synchronizes with the others daily, but a more fre- quent schedule is in the works.

Likewise, as is the case with the DNS system, UDDI registries are not repositories of data; rather, in their roles as registries, they simply provide information on how to find and invoke Web Services. Just as the DNS system provides for unique domain names,

UDDI relies on globally unique identifiers (GUIDs), which are URNs that uniquely iden- tify the resources in each registry.

There are three levels of information available in each UDDI registry, which correspond roughly to the features of a phone book:

• White pages. These pages provide listings of companies that can be queried by name, text description, contact information, and known identifiers (like Dun and Bradstreet‘s DUNS numbers).

• Yellow pages. These pages allow for the looking up of companies by the kind of services they offer, organized into established business categories (industry codes, location, and products and services). These categories are organized into taxonomies.

• Green pages. These pages provide information about how to interact with compa- nies‘ Web Services by exposing service descriptions and binding information.

The Structure of UDDI:

The XML schema that provides the structure of UDDI defines four core types of infor-mation in a UDDI registry, as shown in Figure.

• Business information. Provided by the businessEntity element. The

businessEntity element supports the ―white pages‖ and ―yellow pages‖ taxonomies, allowing for structured information about companies. This element is the top-level information manager for the information in the registry about a particular business.

• Service information. Provided by the businessService element. This element supports the ―green pages‖ functionality. The business Service structure contains a group of Web Services related to a category of services or possibly a business process. Each businessService element contains one or more technical Web Services descriptions, which describe how to find and bind to each of the Web Services.

• Binding information. Provided by the bindingTemplate element, which is the element contained within the businessService element that provides the information needed to bind to and invoke a Web Service.‖

• Specifications for services. Enclosed within each bindingTemplate element are special elements that list references to information about specifications for services. These elements, called tModel elements (from ―technical models‖), are metadata about each specification, providing information on a specification‘s name, publishing organizations, and URLs to the specifications themselves. T Model elements have several uses within a UDDI registry, in particular, representing technical specifications for wire protocols (such as SOAP), interchange formats (WSDL), and sequencing rules. Each specification registered as a tModel in a UDDI registry receives a unique GUID.

T Model Structure;

Understanding tModel elements is critical to understanding how UDDI works, because they form the basis of how UDDI deals with the meaning of the various specifications it deals with. The concept of a tModel is necessarily somewhat nebulous, because tModel elements consist of metadata (data about data). tModel elements provide a reference sys- tem for UDDI registries that is based on abstraction (in other words, a tModel can define just about anything).

The primary use for tModel elements within UDDI is to represent a technical specifica-tion for example, wire protocols (such as SOAP), interchange formats, and the like. When two parties wish to communicate using a particular specification, they must share a mutually agreed on technical identity for the specification they share. This technical identity can be registered in a tModel. Once such a specification is uniquely defined in this way, other parties can refer to it by referring to its unique tModel identifier, which is called a tModelKey. tModelKey elements act as ―technical fingerprints‖ that uniquely designate individual specifications.‖.

• The other main use for tModel elements supports how UDDI handles its search capabil-ity. Searching, of course, is an essential part of UDDI‘s ―find‖ capability. Searching is provided for in UDDI with the use of two structures: identifierBag and categoryBag. The identifierBag structure defines organizational identity. It consists of name/value pairs that record and define identification numbers—for example, ―DUNS number 12345‖ or ―SS# 987-65-4321.‖ The categoryBag elements, on the other hand, are name/value pairs that correlate specific taxonomy information—for example, ―Florists 45311‖ (from the NAICS taxonomy), ―Massachusetts US-MA‖ (from the ISO 3166 Geographic Taxonomy), or ―Boston 516499‖ (from the GeoWeb taxonomy). A particular florist in Boston, Massachusetts would possess all three of these categoryBag elements, as well as each identifier‘s supercategories. The tModel, then, is used to correlate different levels of these hierarchies—for example, to express the relationship that Boston is within Massachusetts, or that florists are retailers.

Publishing and Finding WSDL Descriptions in a UDDI Registry:

In order to understand how UDDI uses WSDL as a description language, you must be clear on how WSDL documents are mapped to the UDDI structure. As discussed earlier, WSDL documents can be organized as service implementation and service interface documents. The service implementation document maps to the UDDI businessService element, whereas the service interface document maps to the tModel elements, as shown in Figure‖.

The first step in publishing a WSDL description in a UDDI registry is publishing the ser vice interface as a tModel in the registry. Here are the steps to follow to create the appropriate tModel:

1. Set the name field of the tModel to the targetNamespace attribute of the definitions element in the interface document. This field is used to locate the appropriate tModel.

2. The description field of the tModel corresponds to the documentation elementof the interface document. This field can have a maximum of 256 characters.

3. Set the overviewURL field of the tModel to the URL and binding specification in the interface document.

Set the categoryBag field of the tModel so that its keyed reference is uddi org:types and its keyValue is wsdlSpec. This defines the UDDI entry as a WSDL service interface definition.

tModel.xml—A tModel Created from a WSDL Service Interface

<?xml version=‖1.0‖?> <tModel tModelKey=‖‖>

<name>http://www.myclassservice.com/MyClass-interface</name>

Service interface definition for our demo Service. </description>

WSDL Service Interface Document </description>

<overviewURL> http://www.myclassservice.com/MyClass- interface#MyClass_ServiceBinding </overviewURL>

</overviewDoc>

<keyedReference tModelKey=‖UUID:DB77450D-9FA8-45D4-A7BC-9C8C7D998F8D‖ keyName=‖Sample Web Service‖

keyValue=‖12345678‖/>

</categoryBag>

</tModel>

Next, we must create the businessService and bindingTemplate elements that corre- spond to the WSDL service implementation document shown in Listing 16.2. The businessService has the following fields.‖:

• The name field of the businessService is set to the name attribute of the service element in the implementation document.

• The description field of the businessService comes from the documentation element in the implementation document. The bindingTemplate has the following fields:

• The description field of the bindingTemplate comes from the first 256 characters of the documentation element of the port element, if it exists.

• The accessPoint field is set to the value of the location attribute of the extension element that is associated with the port element, in the case of a SOAP or HTTP binding.

• The bindingTemplate contains one t Model Instance Info field for each t Model it references.

• The overviewURL field directly references the service implementation document;

however, it is only used to provide human readability.

<name>MyClass_Service</name>

IBM WSTK V2.4 generated service definition file </description>

<accessPoint URLType=‖http‖> http://localhost:8080/soap/servlet/rpcrouter </accessPoint>

<overviewURL> http://localhost:8080/wsdl/MyClass_Service-interface.wsdl </overviewURL>

</instanceDetails>

</tModelInstanceInfo>

</tModelInstanceDetails>

</bindingTemplate>

</bindingTemplates>

<keyedReference tModelKey=‖UUID:DB77450D-9FA8-45D4-A7BC-3663DA8D8CFB‖ keyName=‖Sample Web Service‖

keyValue=‖84121801‖/>

</categoryBag>

</businessService>

UDDI Invocation Model:

Now that we can build a business Service and its various elements, let‘s step through the process for using a UDDI registry to find and invoke a Web Service.‖:

1. You use the UDDI business registry to locate the business Entity information that was previously published by a company advertising a Web Service.

2. You either request more specific information about the business Service or request the entire business Entity structure. This structure contains the relevant

Binding Template information needed to connect to the service. You put this binding information into a cache.

3. You refer to the tModel key information in the binding Template to obtain relevant information on the specifications needed to invoke the desired Web Service, and you use this information to write the program that will access the service.

4. The program invokes the Web Service using the binding Template information that has been cached.

5. If the call to the Web Service fails, refresh the binding Template information. If the new call succeeds, refresh the cache. Otherwise, keep trying.

By using cached binding information and taking a ―retry on failure‖ approach, the UDDI registry infrastructure is not burdened by unnecessary calls but rather allows for seamless operation when binding information changes. This approach to scalability is quite similar to the way the DNS system works.‖

Study Material, Lecturing Notes, Assignment, Reference, Wiki description explanation, brief detail

XML and Web Services : Web Services Building Blocks : Web Services Description Language (WSDL) and Universal Description, Discovery, and Integration (UDDI) |