Multiple Service consumers invoke operations defined on a Service Provider. To do that they need a way to find out the Service Location of where the provider service is hosted, and the various interfaces, operations, and data types that are provided and suppoted  by the Service Provider so that they can interact with the provider's services.

The Web Services Desciption Language (WSDL) is an XML document that describes all the Service Provider contracts (also known as service descriptions) to which consumers of the service must agree to in order to interact with the Provider.

As can be seen in the figure below, WSDL separates the service contract into two distinct parts. They are:

1. The Abstract WSDL Model that contains a series of elements that include types, messages that define the structure of the method input parameters, returned output types & exception (or fault) types, the port type also known as the interface, and,
2. The WSDL Concrete Model that is comprised of bindings to protocols, concrete data structures, concrete address locations and service elements.
   

The Abstract WSDL model:
The Abstract model provides the interface description, and is completely devoid of any concrete data structures, or communication transport protocols, or network address locations, etc. For each abstract interface definition that is provided in the abstract model, there may exist multiple concrete implementations (in the concrete model) that allow the consumer to pick the one that is most suitable to use to interact with provider services.

As can be seen in the figure below, a collection of service operations that are supported by the web service are defined within the portType element. the sample below provides a MyPortType interface that supports one operation called operationA. The operation operationA is a request-response operation type as it contains an input message and an output message. The operation element lists all the messages that are exchanged between the web service provider and the consumer in addition to any faults (or exceptions) that are thrown by the service provider operation. The message requestMessage is linked by the name attribute to the input element of the operationA operation. This message encapsulates the data that is sent from the consumer to the provider as input. Similarly, the message responseMessage is linked by the name attribute to the output element of the operationA operation. The message represents the data that is sent by the provider to the consumer as part of the result values.

A message consists of parts and parts are linked to types or elements. The types element is a container for all the Abstract Data Type definitions that are required by the interface description.

Note: While the type definitions define data that a service provider expects abstractly, the concrete WSDL model in its binding element is required to map these abstract data types to concrete data as they will appear on the wire.



The Concrete WSDL Model:
While the abstract WSDL model completes the service interface description, it still lacks concrete information like the service location, the protocol & transport information, and the mapping to concrete wire representation of the data which will be required by the consumer to communicate with provider services.

Extensibility Elements: Each interface definition may have multiple service implementations using protocol-specific binding information and wire-formats. Each protocol binding provides binding-specific elements called Extensibility Elements to describe the mapping from the abstract WSDL model to a concrete protocol description. In the example above, all extensibility elements are highlighted in blue. The WSDL Extensibility Elements mechanism is a very powerful concept that allows us to extend WSDL in myriad ways. This facility is what allows us to add the whole  WS-* stack to web services. This is the same mechanism that allows us to define the <partnerLinkType>, <property>, or <propertyAlias> BPEL extension elements in WSDL documents. To read more about this refer to "BPEL: What are partnerLinkTypes, roles, and partnerLinks" in this blog entry and "BPEL: What is Correlation, message Property, Property Alias, and Correlation Set" in this blog entry.

The binding element provides information about the transport protocol and the concrete data types that the provider expects at a well-defined network address. As can be seen in the figure above, the binding element associates the portType named MyPortType to the port named SynchronousSamplePortName through the binding name SoapBinding. For each concrete implementation of the same portType (interface), there will be a binding element that specifies the transport protocol information and concrete data types associated with that concrete implementation.

In the example above, we are using SOAP over HTTP with the document communication style and literal encoding (read this blog entry entitled WSDL & SOAP: Binding Style to use - Document or RPC? for more information). Therefore, the abstract operation operationA along with its input and output messages from the service interface description is mapped to concrete SOAP messages for wire-transfer. It should however be noted that the binding element does not specify implementation-specific information. How the service is actually implemented, is completely outside the scope of WSDL.

The port element provides the network service location through which the service exchanges messages. The same service may be offered with multiple different data formats on multiple ports at different network locations. As long as the service consumer understands and knows how to communicate with a concrete message format defined by the service, it may bind to the port and interact with the service.

The service element combines all ports and provides an endpoint for the consumer to interact with the service provider.



The figure above describes the containment structure of the WSDL document. As can be seen, the definitions element is the container for all WSDL elements. The portType containment structure in the abstract WSDL Model has an equivalent binding containment structure in the concrete WSDL model. Every type of binding maps a concrete implementation to an abstract portType. The message container provides a data type definition container for portType operations through its parts. Individual datatypes may appear multiple times in each message. A single message is reusable for several operations. Similarly a binding is a reusable entity because of the separation of the port and binding containers. Therefore, the same service implementation can be offered at multiple network locations.

The NetBeans Enterprise Pack 5.5 Early access that is part of the Java EE Tools Bundle is a FREE download that comes with a plethora of tooling that helps the SOA Developer. Tools like the XML Schema Editor, the WSDL Editor, the BPEL Visual Designer, and all the other tools that are part of this download help the SOA developer be extremely productive at what he is doing.

Learn to use those tools here:

• Getting Started with XML Schema tools
• Using the BPEL Visual Designer & the WSDL Edior tools

Download the Java EE 5 Tools Bundle Beta from http://java.sun.com/javaee/downloads/index.jsp for FREE, and provide us feedback on the improvements you'd like to see. It combines the new Java EE 5 SDK with NetBeans IDE 5.5 Beta, NetBeans Enterprise Pack 5.5 Early Access, and Sun Java System Application Server Platform Edition 9. This bundle also contains Project Open ESB Starter Kit Beta, Java EE 5 samples, Java BluePrints, and API docs (Javadoc).

The screen-shot below shows the Schema view of the XSD for the Synchronous Sample scenario in the Sun NetBeans 5.5 Enterprise Pack Beta XML Schema Editor	The screen-shot below shows the Instance view of the XSD for the Synchronous Sample scenario in the Sun NetBeans 5.5 Enterprise Pack Beta XML Schema Editor

The screen-shot below shows the WSDL for the Synchronous Sample scenario in the Sun NetBeans 5.5 Enterprise Pack Beta WSDL Editor