An Introduction to WSDL - A Critical Part of an Automated Web

Source Code for this article

The Web Services Description Language (WSDL) is an industry-standard XML vocabulary used to describe and expose services for client consumption. To be more precise, it's a simple, extensible, and reusable interface definition language that serves to specify Web service operations, messages and their data types, and the deployment details of network services. This article introduces the basic semantics of WSDL and illustrates its importance as a key element among the collection of technologies that have made Web services a reality. It requires a working knowledge of XML and XML namespaces. In addition, some familiarity with XML Schemas and SOAP is helpful.

Web services represent an important new breed of distributed Web applications. They are self-contained, self-describing, modular applications that can be published, located dynamically, and invoked across the Web. Utilizing distributed Web services, applications can be engineered, assembled, and deployed across Web application boundaries, regardless of the underlying hardware or operating system.

A Move to a Semantic Web
For a number of years, the majority of distributed systems have been designed using the most popular distributed component object models, such as CORBA, COM+, and Enterprise JavaBeans. Although these models have contributed to the success and growth of the Web, they have several unfortunate limitations. For example, network services exposed by COM+ interfaces utilize an RPC-based network representation, whereas Enterprise JavaBeans are commonly invoked over the RMI/IIOP protocol. This ultimately leads to a division among component models, and the inability to interoperate at the most fundamental level. The essential piece of the puzzle that's been missing for a number of years has been the motivation to design a standard set of APIs for intercomponent discovery, description, and communication.

Most experts are predicting a second wave in the growth of the World Wide Web and a shift towards a more automated and collaborative environment. Web services will be a major driving force behind this shift, the transformation into a "semantic" Web composed of self-describing resources and automation interfaces. However, for this trend to become reality, a few fundamental questions must be answered. For example, how can business and process logic, which may currently reside deep in internal corporate structures, be exposed on the Web in a standardized manner? In technical terms, we need to agree on a common set of semantics for describing Web service "interfaces." This is the motivation driving the development of WSDL.

As you continue to experiment with this new XML-based technology, keep in mind that the major proponents of WSDL and Web services in general have attempted to leverage as many existing standards as possible. For example, many SOAP implementations are simply a combination of XML and HTTP. In the same fashion, WSDL is a simple, human-readable markup language. If you have experience manipulating XML documents, then the learning curve should be minimal.

Although there have been numerous efforts to standardize on a service description language for a component-based Web, such as WebMethods' Web Interface Definition Language (WIDL) and Microsoft's Service Contract Language (SCL), the WSDL standard has generated the most support from technology vendors, including Microsoft, IBM, Ariba, and Sun. For example, the majority of Web services toolkits and component application servers have or will soon have built-in support for creating and manipulating WSDL documents.

Interface-Based Programming
From an application development standpoint, the ability to program against a set of abstract interfaces has been central to the development of most distributed object models. COM+ requires the compilation of IDL into a binary format to allow for intercomponent communication, and EJB relies on the generation of home and component interfaces. In addition, interface-based programming can serve as the foundation for component versioning, run-time- type inspection, location transparency, and polymorphism. WSDL expands on this tradition by providing an extensible description of component interaction that is both reusable and extremely flexible. Presenting software services through an interface-based WSDL vocabulary has several important ramifications in addition to presenting components in a standard fashion.

First, it should be noted that WSDL promotes the physical separation of a Web service's interface from its corresponding code implementation. In other words, the entry point to a component will be described in a WSDL document, but the actual code base that represents the business logic can be composed in any software language. The benefits of this should be evident. By keeping these two entities physically separated, a developer can continue to enhance the language specific implementation without changes to the external interface. In addition, a WSDL document is extensible enough to support various network and messaging protocols, such as HTTP, SMTP, and FTP. This type of programming allows for ease of distribution, reusability, and enhanced versioning capabilities. An easy way to remember this type of model is to think of an interface or WSDL document as a contract language. The server states that it promises to implement the messages described in the WSDL document. In return, a client will consume and transform the WSDL document metadata into a language that will ultimately be understood and processed regardless of the underlying software and hardware implementation.

Second, when illustrating this type of separation between interface and implementation, Web services can be categorized as part of a "service-oriented" design paradigm. The WSDL document defines a component or procedure in terms of a service that the client wishes to invoke. Service-based architectures are different in many ways from traditional object-oriented models and are implemented in popular connectionless protocols, such as JMS (Java Messaging Service), HTTP, and asynchronous programming techniques.

The Need for New Approaches
Your development team may need to alter the way they approach problem domains, focusing on more granular and stateless programming models as opposed to components, which possess a reliance on state information. For example, a stateless session EJB used as a Web facade object would lend itself nicely to this type of programming paradigm.

Service-based models are inherently transactional, and scalability requires serious forethought rather than afterthought. When services respond in a highly procedure-oriented manner, they are often categorized as coarse-grained components. Coarse-grained components are a fundamental precursor to system scalability. As a technologist, you'll see that your information systems in the future will have a much higher reliance on technologies, such as messaging systems and workflow-centric technologies. For example, IBM's Web Services Flow Language and Microsoft's XLANG support workflow processes and programming models.

WSDL Structure
Now that we have examined some of the background and benefits of WSDL, let's move forward and inspect the structure and semantics that serve as its foundation. First, I'll present a general description of some of the various entities that comprise a simple WSDL document, followed by a more advanced look at each of the structures. Although most tools and service containers will have built-in support for automating the manipulation of WSDL, there are certain circumstances that will require a more intimate understanding of its syntax. For example, the marshalling of objects between Web services will most certainly require a deeper knowledge of WSDL.

As I previously stated, WSDL is highly extensible. For example, it doesn't require a certain network protocol or messaging format. However, for the purpose of this article we'll assume that we're using WSDL in a system whose message data conforms to the XSD Schema specification and the SOAP protocol.

From one perspective, there are actually two logical parts that combine to form a WSDL document - a reusable part and a non-reusable part. Most distributed component object models require the use of some type of registry or location service, such as an ORB. Web services don't require such interposition protocols, but the absolute location of a service endpoint must be declared in the non-reusable section of a WSDL document known as a port, which will be described in more detail later. The reusable piece of a WSDL document will allow applications to be deployed in multiple locations without duplicating interface definitions and remain extensible with regards to messaging formats and protocol bindings.

At first glance, the different elements that make up this structure may seem confusing and make manual interaction appear difficult and error-prone, which explains the influx of WSDL APIs such as JWSDL and programming tools such as Microsoft's SOAP Toolkit. However, it's helpful to envision a WSDL document as an abstract representation of a messaging system, with each of the seven parts serving as a component or subsystem. As we examine the various parts of a WSDL document, I'll make frequent analogies to a typical electronic mail system. Like WSDL, most mail systems have certain types of acceptable data (text, html, rtf). This data is further combined to form messages, which are sent and received by operations. Operations are then carried out using specific protocols, such as SMTP. Similar to other network protocols, ports and binding mechanisms must also be employed.

In order to construct a WSDL document, we first need to describe the basic data types that will be used in transmitting our messages. Most applications will require data types to conform to the XML Schema standard. However, WSDL supports the description of complex data types. The document fragment in Listing 1 illustrates how schemas can be utilized within WSDL to define types.

The root element of all WSDL documents is represented by the element. In Listing 1, we've declared the WSDL namespace as the default namespace, so all of the elements are included in this namespace, unless otherwise specified with an additional declaration. Because XML Schema data types are defined by an abstract model, there are several rules that should be implemented when using XML Schemas; these include using elements instead of attributes, protocol-agnostic data types, and the use of xsd: anyType if the type is not important.

WSDL Operations
After the types used in an application are described, they are combined to form messages. WSDL messages don't rely on any specific network protocol. In other words, messages can ultimately be sent using SOAP, HTTP GET, SMTP, etc. Furthermore, in the typical Web-based system (request/response) messages will have to be described for input as well as output operations. Input and output operations will most likely need to accept parameters. These parameters are described within the <message> element and are known as message parts. The following document fragment illustrates message structures and parts in WSDL:

Each of the above message elements represents a function in a request/response pair described by the WSDL document. This collection of messages is known as an operation. There are only four forms of operations with built-in support in WSDL: one-way, request/response, solicit/response, and notification. In a typical mail system, sending a piece of mail would be classified as an operation. Transactional in nature, operations represent an all-or-nothing, single unit of work for the service being described. This is evidence that Web services truly represent a unique programming paradigm. Unfortunately, many experienced developers will be tempted to use WSDL as a simple object serialization format. This isn't the intent of a service-based Web infrastructure.

The cornerstone of a scalable, service-based programming model will be composed of messaging algorithms and stateless, granular procedural invocations rather than complex object models. When e-mail is sent to a co-worker, it either arrives or is never sent; there's no in-between. As I noted earlier, Web services will most likely cause an increased reliance on messaging, workflow-based tools, and languages. Microsoft's BizTalk Server and the Java Message Service (JMS) are examples of this trend. Sample code expressing operations in WSDL is shown below:

Ports and Port Types
WSDL documents can contain any number of operations. This collection is referred to as a port type. Port types fundamentally represent the set of functions that are publicly exposed by the Web service. They are defined in WSDL using the <portType> element:

Although messages can be represented by abstract data types, eventually they must be implemented in a concrete fashion. In other words, there still needs to be a physical wire format for representing your data in the physical world. Bindings are used to describe these concrete implementations, as seen in Listing 2.

The last and final data structure in a WSDL document is known as a port. Ports are non-reusable and are used to associate a binding with a protocol-specific address. In addition, they describe what are commonly referred to as SOAP endpoints. The following markup describes a port:

Although the preceding example imple-ments the HTTP protocol, keep in mind that WSDL avoids limiting the number of network protocols. The WSDL specification describes a standard binding mechanism used to attach a specific protocol, data format, or structure to an abstract implementation, operation, or port. WSDL supports the creation of custom bindings and is also the preferred representation of a UDDI (Universal Description, Discovery, and Integration) Service Description element.

Conclusion
WSDL is a critical part of an automated Web based on services. In the spirit of SOAP and UDDI, WSDL is a simple language and it does a good job at leveraging existing technologies such as XML, XSD, and RDF (Resource Description Format). The use of WSDL promotes service-based design and process patterns, reusability, and dynamic component discovery. The current official state of WSDL can be found at www.w3.org/tr/wsdl.

Author Bio:
Mike Richardson is a cofounder and the CTO of Distributed Objex, Inc. (www.distributedobjex.com), an IT solutions, training, and mentoring firm. His firm designs and implements major information systems for numerous companies in the Fortune 100. They have implemented early Web Services technologies at numerous client sites, such as SOAP, WSDL, and "pluggable providers". mrichardson@Doxinc.com

An Introduction to WSDL, by Mike Richardson
WSJ Vol 01 Issue 03 - pg.54

	


Listing 1

<?xml version="1.0" encoding="UTF-8"?>
<definitions name="ClaimServer-interface"
targetNamespace="
<a href="http://www.doxinc.com/ClaimServer-interface">
http://www.doxinc.com/ClaimServer-interface</a>"
xmlns:xsd="
<a href="http://www.w3.org/1999/XMLSchema">
http://www.w3.org/1999/XMLSchema</a>"
xmlns:soap="
<a href="http://schemas.xmlsoap.org/wsdl/soap">
http://schemas.xmlsoap.org/wsdl/soap</a>"
xmlns="
<a href="http://schemas.xmlsoap.org/wsdl/">
http://schemas.xmlsoap.org/wsdl/</a>">
<br>
<types>
<xsd:schema targetNamespace="
<a href="http://www.doxinc.com/claim.xsd">
http://www.doxinc.com/claim.xsd</a>">
<element name="...">
</element>
</xsd:schema>
</types>
</definitions>
<br>

Listing 2

<binding name="GetClaimServiceBinding" 
type="GetClaimService">
<soap:binding style="rpc" transport="
<a href="http://schemas.xmlsoap.org/soap/http">
http://schemas.xmlsoap.org/soap/http</a>"/>
<operation name="GetClaim">
<soap:operation soapAction="
<a href="http://www.getclaim.com/getclaim">
http://www.getclaim.com/getclaim</a>"/>
<input>
<soap:body use="encoded"
namespace="urn:claim-requests"
encodingStyle="
<a href="http://schemas.xmlsoap.org/soap/encoding/">
http://schemas.xmlsoap.org/soap/encoding/</a>"/>
</input>
<output>
<soap:body use="encoded"
namespace="urn:claim-requests"
encodingStyle="
<a href="http://schemas.xmlsoap.org/soap/encoding/">
http://schemas.xmlsoap.org/soap/encoding/</a>"/>
</output>
</operation>
</binding>

Java and Java-based marks are trademarks or registered trademarks of Sun Microsystems, Inc. in the United States and other countries. SYS-CON Publications, Inc. is independent of Sun Microsystems, Inc.