- Web services and the service-oriented architecture (SOA)
- Web Services Description Language (WSDL)
- Simple Object Access Protocol (SOAP)
- Universal Description, Discovery, and Integration (UDDI)
3.2 Web Services Description Language (WSDL)
Web services need to be defined in a consistent manner so that they can be discovered by and interfaced with other services and applications. The Web Services Description Language is a W3C specification providing the foremost language for the description of Web service definitions.
The integration layer introduced by the Web services framework establishes a standard, universally recognized and supported programmatic interface. As shown in Figure 3.17, WSDL enables communication between these layers by providing standardized endpoint descriptions.
Figure 3.17 WSDL documents representing Web services to applications.
The best way to understand how a Web service is defined and expressed by a WSDL document is to step through each of the constructs that collectively represent this definition. Let's begin with the root definitions element, which acts as the container for the entire service definition.
Example 3.1. A service definition, as expressed by the definitions construct
<definitions> <interface name="Catalog"> ... </interface> <message name="BookInfo"> ... </message> <service> ... </service> <binding name="Binding1"> ... </binding> </definitions>
A WSDL definition can host collections of the following primary constructs:
-
interface (previously known as portType)1
-
message
-
service
-
binding
Figure 3.18 illustrates how the first two constructs represent the service interface definition, and the latter two provide the service implementation details.
Figure 3.18 The contents of a WSDL document, as they relate to a service definition.
3.2.1 Abstract interface definition
Individual Web service interfaces are represented by WSDL interface elements. These constructs contain a group of logically related operations. In a component-based architecture, a WSDL interface is comparable to a component interface. An operation is therefore the equivalent of a component method, as it represents a single action or function.
Example 3.2. A Web service interface represented by the interface element
<definitions> <interface name="Catalog"> <operation name="GetBook"> ... </operation> </interface > </definitions>
A typical operation element consists of a group of related input and output messages. The execution of an operation requires the transmission or exchange of these messages between the service requestor and the service provider.
Operation messages are represented by message constructs that are declared separately under the definitions element. The message names then are referenced in the operation's input or output child elements.
Example 3.3. The input element within an operation construct referencing a message block
<definitions> <message name="BookInfo"> ... </message> <interface name="Catalog"> <operation name="GetBook"> <input name="Msg1" message="BookInfo" /> </operation> </interface> </definitions>
A message element can contain one or more input or output parameters that belong to an operation. Each part element defines one such parameter. It provides a name/value set, along with an associated data type. In a component-based architecture, a WSDL part is the equivalent of an input or output parameter (or a return value) of a component method.
Example 3.4. A message block with part constructs representing operation parameters
<definitions> <message name="BookInfo"> <part name="title" type="xs:string"> Field Guide </part> <part name="author" type="xs:string"> Mr. T </part> </message> </definitions>
Here's a brief summary of the fundamental constructs that can be assembled to establish an abstract interface definition:
-
interfaces represent service interfaces, and can contain multiple operations
-
operations represent a Web service function, and can reference multiple messages
-
messages represent collections of input or output parameters, and can contain multiple parts
-
parts represent either incoming or outgoing operation parameter data
3.2.2 Concrete (implementation) definition
On to the implementation details. Using the elements described in this section, a WSDL document can establish concrete binding details for protocols, such as SOAP and HTTP.
Within a WSDL document, the service element represents one or more endpoints at which the Web service can be accessed. These endpoints consist of location and protocol information, and are stored in a collection of endpoint (previously known as port)2 elements.
Example 3.5. The endpoint element
<definitions> <service name="Service1"> <endpoint name="Endpoint1" binding="Binding1"> ...concrete implementation details... </endpoint> </service> </definitions>
Now that we've described how a Web service can be accessed, we need to define the invocation requirements of each of its operations. The binding element associates protocol and message format information to operations. The operation construct that resides within the binding block resembles its counterpart in the interface section.
Example 3.6. The binding element representing an existing operation
<definitions> <service> <binding name="Binding1"> <operation> <input name="Msg1" message="book" /> </operation> </binding> </service> </definitions>
The description of concrete information within a WSDL document can be summarized as follows:
-
service elements host collections of endpoints represented individually by endpoint elements
-
endpoint elements contain endpoint data, including physical address and protocol information
-
binding elements associate themselves to operation constructs
-
each endpoint can reference a binding element, and therefore relates the endpoint information to underlying operation
3.2.3 Supplementary constructs
An additional feature used to provide data type support for Web service definitions is the types element. Its construct allows XSD schemas to be embedded or imported into the definition document.
Example 3.7. The types element establishing XSD data types
<definitions> <types> <xsd:schema targetNamespace="http://www.examples.ws/" xmlns="http://www.w3.org/2000/10/XMLSchema"> ... </xsd:schema> </types> </definitions>
Finally, the optional documentation element allows supplementary annotations to be added.
Example 3.8. The documentation element allows you to supplement service definitions with annotations
<definitions> <documentation> I wrote this service definition some time ago, when I was younger and times were simpler for us all... </documentation> </definitions>
SUMMARY OF KEY POINTS
-
A service definition can be represented by the contents of a WSDL document, as defined within the definitions construct.
-
The abstract interface definition is described by the interface, message, and types constructs. This part of the WSDL document provides a mobile, platform-independent description of the Web service interface.
-
Concrete implementation information is contained within the binding, service, and endpoint/port elements. This part of the WSDL document is used to bind an abstract interface to specific protocols, such as SOAP and HTTP.
For more information regarding WSDL features and resources, visit www.specifications.ws.