Chapter 3. Describing and Publishing (WSDL and UDDI)

Explain the use of WSDL in Web services, including a description of WSDL's basic elements, binding mechanisms and the basic WSDL operation types as limited by the WS-I Basic Profile 1.1.

[Note]
[Warning]Warning

While SCDJWS 5.0 objectives specify WSDL 2.0 specification version, the exam questions are still based on the WSDL 1.1 specification.

WSDL is an XML-based language that allows formal XML desriptions of the interfaces of Web services:

  • Interface information describing all publicly available functions.

  • Data type information for all message requests and message responses.

  • Binding information about the transport protocol to be used.

  • Address information for locating the specified service.

WSDL benefits:

  • It is an interface description is a contract between the server developers and the client developers (like Java interface represents a contract between client code and the actual Java object).

  • It has formal descriptions which allows tool support, e.g. code template generators, integrate new services with little or no manual code.

WSDL language can be described as having two layers:

  1. The service definition layer describes abstract properties:

    • data types

    • message types

    • operations

    • services

  2. The binding layer describes concrete properties:

    • protocols

    • data formats

The definitions element MUST be the root element of all WSDL documents. It defines the name of the web service, declares multiple namespaces used throughout the remainder of the document. An actual WSDL document consists of a set of definitions of the following kinds:

  • types - Contains XML Schema element and type definitions. The types element describes all the data types used between the client and server. WSDL is not tied exclusively to a specific typing system, but it uses the W3C XML Schema specification as its default choice. If the service uses only XML Schema built-in simple types, such as strings and integers, the types element is not required.

    The types element encloses data type definitions that are relevant for the exchanged messages. For maximum interoperability and platform neutrality, WSDL prefers the use of XSD as the canonical type system, and treats it as the intrinsic type system.

    
    <definitions .... >
        <types>
            <xsd:schema .... />*
        </types>
    </definitions>
    
    								
    The XSD type system can be used to define the types in a message regardless of whether or not the resulting wire format is actually XML, or whether the resulting XSD schema validates the particular wire format. This is especially interesting if there will be multiple bindings for the same message, or if there is only one binding but that binding type does not already have a type system in widespread use.

    WS-I BP 1.1: A DESCRIPTION MUST NOT use QName references to WSDL components in namespaces that have been neither imported, nor defined in the referring WSDL document.

    WS-I BP 1.1: A QName reference to a Schema component in a DESCRIPTION MUST use the namespace defined in the targetNamespace attribute on the xsd:schema element, or to a namespace defined in the namespace attribute on an xsd:import element within the xsd:schema element.

    WS-I BP 1.1: All xsd:schema elements contained in a wsdl:types element of a DESCRIPTION MUST have a targetNamespace attribute with a valid and non-null value, UNLESS the xsd:schema element has xsd:import and/or xsd:annotation as its only child element(s).

    WS-I BP 1.1: In a DESCRIPTION, declarations MUST NOT extend or restrict the soapenc:Array type.

    WS-I BP 1.1: In a DESCRIPTION, declarations MUST NOT use wsdl:arrayType attribute in the type declaration.

    WS-I BP 1.1: In a DESCRIPTION, elements SHOULD NOT be named using the convention ArrayOfXXX.

    WS-I BP 1.1: An ENVELOPE MUST NOT include the soapenc:arrayType attribute.

    CORRECT:

    Given the WSDL Description:

    
    <xsd:element name="MyArray1" type="tns:MyArray1Type"/>
    <xsd:complexType name="MyArray1Type">
      <xsd:sequence>
        <xsd:element name="x" type="xsd:string" minOccurs="0" maxOccurs="unbounded"/>
      </xsd:sequence>
    </xsd:complexType>
    
    								
    The envelope would serialize as (omitting namespace declarations for clarity):
    
    <MyArray1>
      <x>abcd</x>
      <x>efgh</x>
    </MyArray1>
    
    								

    INCORRECT (uses soapenc:arrayType attribute and soapenc:Array type):

    Given the WSDL Description:

    
    <xsd:element name="MyArray2" type="tns:MyArray2Type"/>
    <xsd:complexType name="MyArray2Type" 
      xmlns:soapenc="http://schemas.xmlsoap.org/soap/encoding/"
      xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/" >
      <xsd:complexContent>
        <xsd:restriction base="soapenc:Array">
          <xsd:sequence>
            <xsd:element name="x" type="xsd:string" minOccurs="0" maxOccurs="unbounded"/>
          </xsd:sequence>
          <xsd:attribute ref="soapenc:arrayType" wsdl:arrayType="tns:MyArray2Type[]"/>
        </xsd:restriction>
      </xsd:complexContent>
    </xsd:complexType>
    
    								
    The envelope would serialize as (omitting namespace declarations for clarity):
    
    <MyArray2 soapenc:arrayType="tns:MyArray2Type[]" >
      <x>abcd</x>
      <x>efgh</x>
    </MyArray2>							
    
    								

  • message - Consists of either a number of named parts typed by XML Schema elements, or a single part typed by a XML Schema type. The message element describes a one-way message, whether it is a single message request or a single message response. It defines the name of the message and contains zero or more message part elements, which can refer to message parameters or message return values.

  • portType - describing a set of operations, each being either:

    • one-way: The endpoint receives an input message. (NOTE: The WS-I BP 1.1 restricts the valid wsdl:operations to one-way and request-response operations):

      A DESCRIPTION MUST NOT use Solicit-Response and Notification type operations in a wsdl:portType definition.

      
      <wsdl:definitions .... > 
        <wsdl:portType .... > *
          <wsdl:operation name="nmtoken">
            <wsdl:input name="nmtoken"? message="qname"/>
          </wsdl:operation>
        </wsdl:portType >
      </wsdl:definitions>
      					
      											

    • request-response: The endpoint receives an input message and then responds with an output message (like RPC - Remote Procedure Call). (NOTE: The WS-I BP 1.1 restricts the valid wsdl:operations to one-way and request-response operations).

      
      <wsdl:definitions .... > 
        <wsdl:portType .... > *
          <wsdl:operation name="nmtoken" parameterOrder="nmtokens">
            <wsdl:input name="nmtoken"? message="qname"/>
            <wsdl:output name="nmtoken"? message="qname"/>
            <wsdl:fault name="nmtoken" message="qname"/>*
          </wsdl:operation>
        </wsdl:portType >
      </wsdl:definitions>
      					
      											

    • solicit-response: The endpoint sends an output message and then receives an input message (NOTE: A DESCRIPTION MUST NOT use Solicit-Response and Notification type operations in a wsdl:portType definition - R2303 - BP 1.1).

      
      <wsdl:definitions .... > 
        <wsdl:portType .... > *
          <wsdl:operation name="nmtoken" parameterOrder="nmtokens">
            <wsdl:output name="nmtoken"? message="qname"/>
            <wsdl:input name="nmtoken"? message="qname"/>
            <wsdl:fault name="nmtoken" message="qname"/>*
          </wsdl:operation>
        </wsdl:portType >
      </wsdl:definitions>
      					
      											

    • notification: The endpoint sends an output message (NOTE: A DESCRIPTION MUST NOT use Solicit-Response and Notification type operations in a wsdl:portType definition - R2303 - BP 1.1).

      
      <wsdl:definitions .... > 
        <wsdl:portType .... > *
          <wsdl:operation name="nmtoken" parameterOrder="nmtokens">
            <wsdl:output name="nmtoken"? message="qname"/>    
          </wsdl:operation>
        </wsdl:portType >
      </wsdl:definitions>
      					
      											

    The portType element combines multiple message elements to form a complete one-way or round-trip operation. For example, a portType can combine one request and one response message into a single request/response operation, most commonly used in SOAP services. Note that a portType can (and frequently does) define multiple operations.

  • binding - Selects communication protocol and data formats for each operation and message. The binding element describes the concrete specifics of how the service will be implemented on the wire. WSDL includes built-in extensions for defining SOAP services, and SOAP-specific information therefore goes here.

    NOTE: For interoperability the WS-I BP 1.1 requires that all messages must be sent using the SOAP 1.1 protocol over an HTTP transport:

    WS-I BP 1.1: A wsdl:binding element in a DESCRIPTION MUST use WSDL SOAP Binding as defined in WSDL 1.1 Section 3.

    WS-I BP 1.1: A wsdl:binding element in a DESCRIPTION MUST specify the HTTP transport protocol with SOAP binding. Specifically, the transport attribute of its soapbind:binding child MUST have the value "http://schemas.xmlsoap.org/soap/http".

    The SOAP messages must be in either "document-literal" or "rpc-literal" form:

    WS-I BP 1.1: A wsdl:binding in a DESCRIPTION MUST either be a rpc- literal binding or a document-literal binding.

    The WS-I BP 1.1 requires that a wsdl:binding and its wsdl:portType have the same list of wsdl:operations. A perfect matching between the two lists is established through a 1-1 and onto relation from the wsdl:binding to the wsdl:portType. The wsdl:binding should completely bind all operations within a wsdl:portType:

    WS-I BP 1.1: A wsdl:binding in a DESCRIPTION MUST have the same set of wsdl:operations as the wsdl:portType to which it refers.

  • service - Describes a collection of named ports, each associated with a binding and a network address. The service element defines the address for invoking the specified service. Most commonly, this includes a URL for invoking the SOAP service.

The simplified structure of a WSDL document is:


<definitions> <!-- root WSDL element -->

  <types>
    <!-- defines data types to be transmitted -->
  </types>

  <message>
    <!-- defines messages to be transmitted -->
  </message>

  <portType>
    <!-- defines operations (functions) to be supported -->
  </portType>

  <binding>
    <!-- defines how will the messages be transmitted on the wire -->
  </binding>
  
  <service>
    <!-- defines location of web service -->
  </service>
   
</definitions> 
				
					

WSDL document grammar:


<wsdl:definitions name="nmtoken"? targetNamespace="uri"?>

    <import namespace="uri" location="uri"/>*

    <wsdl:documentation .... /> ?

    <wsdl:types> ?
        <wsdl:documentation .... />?
        <xsd:schema .... />*
        <-- extensibility element --> *
    </wsdl:types>

    <wsdl:message name="nmtoken"> *
        <wsdl:documentation .... />?
        <part name="nmtoken" element="qname"? type="qname"?/> *
    </wsdl:message>

    <wsdl:portType name="nmtoken">*
        <wsdl:documentation .... />?
        <wsdl:operation name="nmtoken">*
           <wsdl:documentation .... /> ?
           <wsdl:input name="nmtoken"? message="qname">?
               <wsdl:documentation .... /> ?
           </wsdl:input>
           <wsdl:output name="nmtoken"? message="qname">?
               <wsdl:documentation .... /> ?
           </wsdl:output>
           <wsdl:fault name="nmtoken" message="qname"> *
               <wsdl:documentation .... /> ?
           </wsdl:fault>
        </wsdl:operation>
    </wsdl:portType>

    <wsdl:binding name="nmtoken" type="qname">*
        <wsdl:documentation .... />?
        <-- extensibility element --> *
        <wsdl:operation name="nmtoken">*
           <wsdl:documentation .... /> ?
           <-- extensibility element --> *
           <wsdl:input> ?
               <wsdl:documentation .... /> ?
               <-- extensibility element -->
           </wsdl:input>
           <wsdl:output> ?
               <wsdl:documentation .... /> ?
               <-- extensibility element --> *
           </wsdl:output>
           <wsdl:fault name="nmtoken"> *
               <wsdl:documentation .... /> ?
               <-- extensibility element --> *
           </wsdl:fault>
        </wsdl:operation>
    </wsdl:binding>

    <wsdl:service name="nmtoken"> *
        <wsdl:documentation .... />?
        <wsdl:port name="nmtoken" binding="qname"> *
           <wsdl:documentation .... /> ?
           <-- extensibility element -->
        </wsdl:port>
        <-- extensibility element -->
    </wsdl:service>

    <-- extensibility element --> *

</wsdl:definitions>
				
					

Example of simple WSDL (SOAP 1.1 Request-Response via HTTP):


<?xml version="1.0" encoding="UTF-8"?>

<definitions name="StockQuote"

targetNamespace="http://example.com/stockquote.wsdl"
          xmlns:tns="http://example.com/stockquote.wsdl"
          xmlns:xsd1="http://example.com/stockquote.xsd"
          xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/"
          xmlns="http://schemas.xmlsoap.org/wsdl/">

    <types>
       <schema targetNamespace="http://example.com/stockquote.xsd"
              xmlns="http://www.w3.org/2000/10/XMLSchema">
           <element name="TradePriceRequest">
              <complexType>
                  <all>
                      <element name="tickerSymbol" type="string"/>
                  </all>
              </complexType>
           </element>
           <element name="TradePrice">
              <complexType>
                  <all>
                      <element name="price" type="float"/>
                  </all>
              </complexType>
           </element>
       </schema>
    </types>

    <message name="GetLastTradePriceInput">
        <part name="body" element="xsd1:TradePriceRequest"/>
    </message>

    <message name="GetLastTradePriceOutput">
        <part name="body" element="xsd1:TradePrice"/>
    </message>

    <portType name="StockQuotePortType">
        <operation name="GetLastTradePrice">
           <input message="tns:GetLastTradePriceInput"/>
           <output message="tns:GetLastTradePriceOutput"/>
        </operation>
    </portType>

    <binding name="StockQuoteSoapBinding" type="tns:StockQuotePortType">
        <soap:binding style="document" transport="http://schemas.xmlsoap.org/soap/http"/>
        <operation name="GetLastTradePrice">
           <soap:operation soapAction="http://example.com/GetLastTradePrice"/>
           <input>
               <soap:body use="literal"/>
           </input>
           <output>
               <soap:body use="literal"/>
           </output>
        </operation>
    </binding>

    <service name="StockQuoteService">
        <documentation>My first service</documentation>
        <port name="StockQuotePort" binding="tns:StockQuoteBinding">
           <soap:address location="http://example.com/stockquote"/>
        </port>
    </service>

</definitions>
				
					

Professional hosting     Belorussian informational portal         Free SCWCD 1.4 Study Guide     Free SCDJWS 1.4 Study Guide     SCDJWS 1.4 Quiz     Free IBM Certified Associate Developer Study Guide     IBM Test 000-287. Enterprise Application Development with IBM WebSphere Studio, V5.0 Study Guide     SCDJWS 5.0 Quiz