SCDJWS Study Guide: WSDL

Printer-friendly version Printer-friendly version | Send this 
article to a friend Mail this to a friend

Previous Next vertical dots separating previous/next from contents/index/pdf Contents

Logical Sections of WSDL Document

Each WSDL document contains both an abstract definition of the service and the concrete description of how the service binds to a particular network implementation and data format bindings. A WSDL document can be partitioned into two logical sections: abstract definitions and concrete descriptions respectively. The abstract section defines SOAP messages in a language- and platform-independent manner; they do not contain any machine- nor language-specific elements. This helps define a set of services that several, diverse Web sites can implement. In contrast, the concrete descriptions define site-specific matters such as serialization.

The first three elements, that are <types>, <message>, and <portType>, are all abstract definitions of the Web service interface. These elements constitute the programmatic interface that you typically interface with in your code. The last two elements, that are <binding> and <service>, describe the concrete details of how the abstract interface maps to messages on the wire. These details are typically handled by the underlying infrastructure, not by your application code.

Each Web service is described in WSDL, which is an XML format for documenting the exchange of messages between the service requestor and service provider. The exchange of messages is termed an operation, and a collection of operations is called a port type (interface). Finally, a service is a group of ports. The key property of WSDL is that it separates the abstract description of service functionality from the concrete details of the service implementation.

The aim of Web Services is to allow different service providers to implement this abstract service description upon their chosen concrete middleware binding. For example, a news service may be implemented using SOAP by one vendor while another may use publish-subscribe.

Client applications, programmed against the abstract WSDL definition, can interoperate with both concrete implementations.

Abstract Definitions

Individual Web service interfaces are represented by WSDL portType elements. These constructs contain a group of logically related operation(s). In a component-based architecture, a WSDL portType is comparable to a component interface. An operation is therefore the equivalent of a component method, as it represents a single action or function.

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. Each type of message can be described further by listing the data-types and order of its parameters.

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.

When the portType has multiple operations, it is possible that some operations exchange the same messages and that some data types are common across messages. In Java program language that is “an interface may contain multiple methods and some of methods may have same data type input or output parameters”. In order to represent all this information about the object in a normalized form, one would:

  • Describe all the data types used in all messages
  • List all messages that can be exchanged and represent the message as a set of data types.
  • Describe each operations (interaction with the portType) as a collection of input, output and exception type messages.

Here's a brief summary of the fundamental constructs that can be assembled to establish an abstract interface definition:

typesContains the platform- and language-independent data type definitions.
messagesThe message elements contain input and output parameters for the service, and are used to describe different messages that the service exchanges. It can contain multiple parts.
partsrepresent either incoming or outgoing operation parameter data
portTypesRepresents service interfaces and uses the messages section to describe function signatures (operation name, input and output parameters). It represents a set of operations supported by the service.
operationshe operation element represents a particular interaction ( a Web service function) with the service and is used to describe the input, output, and exception messages that are possible during that interaction.

Concrete Description

A Web service runs on a network address where the Web service deployed and also understands a particular protocol (e.g., the messages and data that are sent to the web service must be sent in a particular format that the web service understands).Specific location and implementation information about a Web service are the concrete parts of a WSDL document, as represented by the <binding>, <service>, and <port> elements which is child element of <service> element.

Let’s define the invocation requirements of each of the Web service’s operations. The <binding> element maps an abstract portType to a set of concrete protocols such as SOAP and HTTP, message styles (RPC or document), and encoding styles (Literal or SOAP encoded) protocol and message format information to operations. The operation construct that resides within the binding block resembles its counterpart in the interface section.

How to access a Web service in the network? The <service> element represents one or more service endpoints at which the Web service can be accessed. The service endpoints consist of location and protocol information, and are stored in a collection of <port> elements.

The description of concrete information within a WSDL document can be summarized as follows:

bindingSpecifies binding of each operation in the portTypes section. It associates the abstract descriptions of a portType (for example, a portType’s operations, messages and data types) with a protocol.
serviceIn addition to protocol-specific information, the WSDL document should also describe where the service is deployed.
portAssociates between a binding and the network address at which it can be found. iThe <port> elements, which are children element of <service> contain endpoint data, including physical address and protocol information.

When designing WSDL documents, it is good practice to separate the abstract descriptions, concrete descriptions, and the XML schemas into individual files and aggregate them using import statements. The logical separation of abstract information (like methods, parameters, and error messages) from information that changes with the implementation type (like transport protocols) allows the reuse of abstract definitions of the service across different implementations of the service. Also, the XML schemas can be used independently of the WSDL by other tools and applications without having to parse the WSDL file.

As an example, the same service may be exposed over the HTTP transport, as well as the SMTP/POP transports. In both cases, the service does the same function, so the abstract description of the service and its methods can be reused and only the concrete, implementation-specific information needs to be changed across the two instances of the service.

Previous Next vertical dots separating previous/next from contents/index/pdf Contents

  |   |