CS835 - Data and Document Representation & Processing

Lecture 10 - Distribution and Collaboration

 

Web Services Description Language (WSDL) from

http://www.w3schools.com/wsdl/default.asp

What is WSDL?

The WSDL Document Structure

A WSDL document defines a web service using these major elements:

Element

Defines

<portType>

The operations performed by the web service

<message>

The messages used by the web service

<types>

The data types used by the web service

<binding>

The communication protocols used by the web service

The main structure of a WSDL document looks like this:

<definitions>
<types>
 definition of types........
</types>
 
<message>
 definition of a message....
</message>
 
<portType>
 definition of a port.......
</portType>
 
<binding>
 definition of a binding....
</binding>
 
</definitions>

A WSDL document can contain other elements:

extension elements and service element that makes it possible to group together the definitions of several web services in one single WSDL document.

 

WSDL Ports

o       <portType> element - most important WSDL element

o       defines :

o      a web service

o      the operations that can be performed

o      the messages that are involved.

o       The <portType> element can be compared to a function library (or a module, or a class) in a traditional programming language.

 

WSDL Messages

o       <message> element defines the data elements of an operation.

o       Each messages can consist of one or more parts.

o       The parts are comparable to the parameters of a function call in a traditional programming language.

 

WSDL Types

o       <types> element defines the data types that are used by the web service.

o       WSDL uses XML Schema syntax to define data types.

 

WSDL Bindings

<binding> element defines the message format and protocol details for each port.

 

WSDL Example

This is a simplified fraction of a WSDL document:

<message name="getTermRequest">
 <part name="term" type="xs:string"/>
</message>
 
<message name="getTermResponse">
 <part name="value" type="xs:string"/>
</message>
<portType name="glossaryTerms">

 <operation name="getTerm">

 <input message="getTermRequest"/>

 <output message="getTermResponse"/>

 </operation>

</portType>

portType element defines:

o       "glossaryTerms" as the name of a port

o       "getTerm" as the name of an operation

getTerm operation has :

o       an input message called "getTermRequest"

o       an output message called "getTermResponse"

message elements define the parts of each message and the associated data types.

o       glossaryTerms is a like function library

o       "getTerm" is a function with "getTermRequest" as the input parameter

o       getTermResponse as the return parameter.

 

 

WSDL Ports

o       <portType> element is the most important WSDL element.

o       Defines:

o      a web service

o      the operations that can be performed,

o      the messages that are involved.

o       The port defines the connection point to a web service.

o       Similar to a function library (or a module, or a class) in a traditional programming language.

o       Each operation can be compared to a function in a traditional programming language.

 

Operation Types

The request-response type is the most common operation type, but WSDL defines four types:

Type

Definition

One-way

The operation can receive a message but will not return a response

Request-response

The operation can receive a request and will return a response

Solicit-response

The operation can send a request and will wait for a response

Notification

The operation can send a message but will not wait for a response

 

 

One-Way Operation

A one-way operation example:

<message name="newTermValues">
 <part name="term" type="xs:string"/>
 <part name="value" type="xs:string"/>
</message>
<portType name="glossaryTerms">
 <operation name="setTerm">
 <input name="newTerm" message="newTermValues"/>
 </operation>
</portType >

o      Port glossaryTerms defines a one-way operation called "setTerm"

o      "setTerm" operation allows input of new glossary terms messages using a "newTermValues" message with the input parameters "term" and "value".

o      No output is defined for the operation.

 

Request-Response Operation

A request-response operation example:

<message name="getTermRequest">
 <part name="term" type="xs:string"/>
</message>
 
<message name="getTermResponse">
 <part name="value" type="xs:string"/>
</message>
<portType name="glossaryTerms">

 <operation name="getTerm">

 <input message="getTermRequest"/>

 <output message="getTermResponse"/>

 </operation>

</portType>

o      Port "glossaryTerms" defines a request-response operation called "getTerm"

o      "getTerm" operation requires an input message called "getTermRequest" with a parameter called "term", and will return an output message called "getTermResponse" with a parameter called "value".

 

WSDL bindings defines the message format and protocol details for a web service.

Binding to SOAP

A request-response operation example:

<message name="getTermRequest">
 <part name="term" type="xs:string"/>
</message>
 
<message name="getTermResponse">
 <part name="value" type="xs:string"/>
</message>
<portType name="glossaryTerms">

 <operation name="getTerm">

 <input message="getTermRequest"/>

 <output message="getTermResponse"/>

 </operation>

</portType>
<binding type="glossaryTerms" name="b1">
<soap:binding style="document"
transport="http://schemas.xmlsoap.org/soap/http" />
 <operation>
 <soap:operation
 soapAction="http://example.com/getTerm"/>
 <input>
 <soap:body use="literal"/>
 </input>
 <output>
 <soap:body use="literal"/>
 </output>
 </operation>
</binding>

o      The binding element has two attributes - the name attribute and the type attribute.

o      name attribute defines the name of the binding

o      type attribute points to the port for the binding, in this case the "glossaryTerms" port.

o      soap:binding element has two attributes - the style attribute and the transport attribute.

o      The style attribute can be "rpc" or "document".

o      The transport attribute defines the SOAP protocol to use. In this case we use HTTP.

o      The operation element defines each operation that the port exposes.

o      SOAP action has to be defined for each corresponding operation.

o      Must specify how the input and output are encoded. In this case we use "literal".

 

What is UDDI - Universal Description, Discovery and Integration

       UDDI is a platform-independent framework for :

        Describing Services

        discovering businesses

        integrating business services by using the Internet.

       UDDI stands for Universal Description, Discovery and Integration

       UDDI is a directory for storing information about web services

       UDDI is a directory of web service interfaces described by WSDL

       UDDI communicates via SOAP

       UDDI is built into the Microsoft .NET platform

 

What is UDDI Based On?

       UDDI uses World Wide Web Consortium (W3C) and Internet Engineering Task Force (IETF) Internet standards such as XML, HTTP, and DNS protocols.

       UDDI uses WSDL to describe interfaces to web services

       Cross platform programming features are addressed by adopting SOAP, known as XML Protocol messaging specifications found at the W3C Web site.

 

UDDI Benefits

       Any industry or businesses of all sizes can benefit from UDDI

       Before UDDI, there was no Internet standard for businesses to reach their customers and partners with information about their products and services.

       There a no method for integrating diverse systems and processes.

 

Problems the UDDI specification can help to solve:

       Making it possible to discover the right business from the millions currently online

       Defining how to enable commerce once the preferred business is discovered

       Reaching new customers and increasing access to current customers

       Expanding offerings and extending market reach

       Solving customer-driven need to remove barriers to allow for rapid participation in the global Internet economy

       Describing services and business processes programmatically in a single, open, and secure environment

 

How can UDDI be Used

Example Airline Industry

       If the industry published an UDDI standard for flight rate checking and reservation, airlines could register their services into an UDDI directory.

       Travel agencies could then search the UDDI directory to find the airline's reservation interface.

       When the interface is found, the travel agency can communicate with the service immediately because it uses a well-defined reservation interface.

 

Who is Supporting UDDI?

       UDDI is a cross-industry effort driven by all major platform and software providers like Dell, Fujitsu, HP, Hitachi, IBM, Intel, Microsoft, Oracle, SAP, and Sun, as well as a large community of marketplace operators, and e-business leaders.

       Over 220 companies are members of the UDDI community.

 

The full WSDL 1.2 syntax as described in the W3C Working Draft is listed below.

<wsdl:definitions name="nmtoken"? targetNamespace="uri">
 <import namespace="uri" location="uri"/> *
 <wsdl:documentation .... /> ?
 <wsdl:types> ?
 <wsdl:documentation .... /> ?
 <xsd:schema .... /> *
 </wsdl:types>
 <wsdl:message name="ncname"> *
 <wsdl:documentation .... /> ?
 <part name="ncname" element="qname"? type="qname"?/> *
 </wsdl:message>
 <wsdl:portType name="ncname"> *
 <wsdl:documentation .... /> ?
 <wsdl:operation name="ncname"> *
 <wsdl:documentation .... /> ?
 <wsdl:input message="qname"> ?
 <wsdl:documentation .... /> ?
 </wsdl:input>
 <wsdl:output message="qname"> ?
 <wsdl:documentation .... /> ?
 </wsdl:output>
 <wsdl:fault name="ncname" message="qname"> *
 <wsdl:documentation .... /> ?
 </wsdl:fault>
 </wsdl:operation>
 </wsdl:portType>
 <wsdl:serviceType name="ncname"> *
 <wsdl:portType name="qname"/> +
 </wsdl:serviceType>
 <wsdl:binding name="ncname" type="qname"> *
 <wsdl:documentation .... /> ?
 <-- binding details --> *
 <wsdl:operation name="ncname"> *
 <wsdl:documentation .... /> ?
 <-- binding details --> *
 <wsdl:input> ?
 <wsdl:documentation .... /> ?
 <-- binding details -->
 </wsdl:input>
 <wsdl:output> ?
 <wsdl:documentation .... /> ?
 <-- binding details --> *
 </wsdl:output>
 <wsdl:fault name="ncname"> *
 <wsdl:documentation .... /> ?
 <-- binding details --> *
 </wsdl:fault>
 </wsdl:operation>
 </wsdl:binding>
 <wsdl:service name="ncname" serviceType="qname"> *
 <wsdl:documentation .... /> ?
 <wsdl:port name="ncname" binding="qname"> *
 <wsdl:documentation .... /> ?
 <-- address details -->
 </wsdl:port>
 </wsdl:service>
</wsdl:definitions>

 

 

 

What is SOAP?

 

Why SOAP?

       Need to allow Internet communication between programs.

       Applications communicate using Remote Procedure Calls (RPC) between objects like DCOM and CORBA

       HTTP was not designed for this.

       RPC represents a compatibility and security problem - firewalls and proxy servers will normally block this kind of traffic.

       A better way to communicate between applications is over HTTP, because HTTP is supported by all Internet browsers and servers.

       SOAP was created to accomplish this.

       SOAP provides a way to communicate between applications running on different operating systems, with different technologies and programming languages.

 

SOAP Building Blocks

A SOAP message is an ordinary XML document containing the following elements:

        A required Envelope element that identifies the XML document as a SOAP message

        An optional Header element that contains header information

        A required Body element that contains call and response information

        An optional Fault element that provides information about errors that occurred while processing the message

All the elements above are declared in the default namespace for the SOAP envelope:

http://www.w3.org/2001/12/soap-envelope

and the default namespace for SOAP encoding and data types is:

http://www.w3.org/2001/12/soap-encoding

 

Syntax Rules

Important syntax rules:

        A SOAP message MUST be encoded using XML

        A SOAP message MUST use the SOAP Envelope namespace

        A SOAP message MUST use the SOAP Encoding namespace

        A SOAP message must NOT contain a DTD reference

        A SOAP message must NOT contain XML Processing Instructions

 

Skeleton SOAP Message

<?xml version="1.0"?>
 
<soap:Envelope
 
xmlns:soap="http://www.w3.org/2001/12/soap-envelope"
soap:encodingStyle="http://www.w3.org/2001/12/soap-encoding">
 
<soap:Header>
 ...
 ...
</soap:Header>
 
<soap:Body>
 ...
 ...
 <soap:Fault>
 ...
 ...
 </soap:Fault>
 
</soap:Body>
 
</soap:Envelope>

 

The SOAP Envelope Element

       Required SOAP Envelope element is the root element of a SOAP message.

       It defines the XML document as a SOAP message.

       Note the use of the xmlns:soap namespace. It should always have the value of:

http://www.w3.org/2001/12/soap-envelope

       it defines the Envelope as a SOAP Envelope:

<?xml version="1.0"?>
 
<soap:Envelope
 
xmlns:soap="http://www.w3.org/2001/12/soap-envelope"
 
soap:encodingStyle="http://www.w3.org/2001/12/soap-encoding">
 ...
 Message information goes here
 ...
</soap:Envelope>

 

 

The xmlns:soap Namespace

       A SOAP message must always have an Envelope element associated with the "http://www.w3.org/2001/12/soap-envelope" namespace.

       If a different namespace is used, the application must generate an error and discard the message.

 

The encodingStyle Attribute

       The SOAP encodingStyle attribute is used to define the data types used in the document.

       This attribute may appear on any SOAP element

       It will apply to that element's contents and all child elements.

       A SOAP message has no default encoding.

Syntax

soap:encodingStyle="URI"

Example

<?xml version="1.0"?>
 
<soap:Envelope
 
xmlns:soap="http://www.w3.org/2001/12/soap-envelope"
soap:encodingStyle="http://www.w3.org/2001/12/soap-encoding">
...
Message information goes here
...
</soap:Envelope>

 

The SOAP Header Element

       The optional SOAP Header element contains application specific information (like authentication, payment, etc) about the SOAP message.

       If the Header element is present, it must be the first child element of the Envelope element.

       Note: All immediate child elements of the Header element must be namespace-qualified.

<?xml version="1.0"?>
 
<soap:Envelope
xmlns:soap="http://www.w3.org/2001/12/soap-envelope"
soap:encodingStyle="http://www.w3.org/2001/12/soap-encoding">
 
<soap:Header>
<m:Trans
 xmlns:m="http://www.w3schools.com/transaction/"
 soap:mustUnderstand="1">234</m:Trans>
</soap:Header>
...
...
</soap:Envelope>

Above contains:

       a header with a "Trans" element

       a "mustUnderstand" attribute value of "1"

       a value of 234

       SOAP defines three attributes in the default namespace ("http://www.w3.org/2001/12/soap-envelope")

o      Actor

o      MustUnderstand

o      encodingStyle

       The attributes defined in the SOAP Header defines how a recipient should process the SOAP message.

 

The actor Attribute

o      A SOAP message may travel from a sender to a receiver by passing different endpoints along the message path

o      Not all parts of the SOAP message may be intended for the ultimate endpoint of the SOAP message

o      They may be intended for one or more of the endpoints on the message path.

o      The SOAP actor attribute may be used to address the Header element to a particular endpoint.

Syntax

soap:actor="URI"

Example

<?xml version="1.0"?>
 
<soap:Envelope
 xmlns:soap="http://www.w3.org/2001/12/soap-envelope"
 soap:encodingStyle="http://www.w3.org/2001/12/soap-encoding">
 
<soap:Header>
 <m:Trans
 xmlns:m="http://www.w3schools.com/transaction/"
 soap:actor="http://www.w3schools.com/appml/">
 234
 </m:Trans>
</soap:Header>
...
...
</soap:Envelope>

 

The mustUnderstand Attribute

o      The SOAP mustUnderstand attribute can be used to indicate whether a header entry is mandatory or optional for the recipient to process.

o      "mustUnderstand="1" of a child element of the Header element indicates that the receiver processing the Header must recognize the element.

o      If the receiver does not recognize the element it must fail when processing the Header.

Syntax

soap:mustUnderstand="0|1"

Example

<?xml version="1.0"?>
 
<soap:Envelope
xmlns:soap="http://www.w3.org/2001/12/soap-envelope"
soap:encodingStyle="http://www.w3.org/2001/12/soap-encoding">
 
<soap:Header>
 <m:Trans
 xmlns:m="http://www.w3schools.com/transaction/"
 soap:mustUnderstand="1">
 234
 </m:Trans>
</soap:Header>
...
...
</soap:Envelope>

 

The SOAP Body Element

o      The required SOAP Body element contains the actual SOAP message intended for the ultimate endpoint of the message.

o      Immediate child elements of the SOAP Body element may be namespace-qualified

o      SOAP defines one element inside the Body element in the default namespace ("http://www.w3.org/2001/12/soap-envelope").

o      This is the SOAP Fault element, which is used to indicate error messages.

<?xml version="1.0"?>
 
<soap:Envelope
 xmlns:soap="http://www.w3.org/2001/12/soap-envelope"
 soap:encodingStyle="http://www.w3.org/2001/12/soap-encoding">
 <soap:Body>
 <m:GetPrice xmlns:m="http://www.w3schools.com/prices">
 <m:Item>Apples</m:Item>
 </m:GetPrice>
 </soap:Body>
</soap:Envelope>

o      The example above requests the price of apples.

o      Note that the m:GetPrice and the Item elements above are application-specific elements.

 

A SOAP response could look something like this:

<?xml version="1.0"?>
 
<soap:Envelope
 xmlns:soap="http://www.w3.org/2001/12/soap-envelope"
 soap:encodingStyle="http://www.w3.org/2001/12/soap-encoding">
 <soap:Body>
 <m:GetPriceResponse xmlns:m="http://www.w3schools.com/prices">
 <m:Price>1.90</m:Price>
 </m:GetPriceResponse>
 </soap:Body>
</soap:Envelope>

 

The SOAP Fault Element

o      An error message from a SOAP message is carried inside a Fault element.

o      If a Fault element is present, it must appear as a child element of the Body element.

o      A Fault element can only appear once in a SOAP message.

o      The SOAP Fault element has the following sub elements:

Sub Element

Description

<faultcode>

A code for identifying the fault

<faultstring>

A human readable explanation of the fault

<faultactor>

Information about who caused the fault to happen

<detail>

Holds application specific error information related to the Body element

SOAP Fault Codes

The faultcode values defined below must be used in the faultcode element when describing faults:

Error

Description

VersionMismatch

Found an invalid namespace for the SOAP Envelope element

MustUnderstand

An immediate child element of the Header element, with the mustUnderstand attribute set to "1", was not understood

Client

The message was incorrectly formed or contained incorrect information

Server

There was a problem with the server so the message could not proceed

 

The HTTP Protocol

       HTTP communicates over TCP/IP.

       An HTTP client connects to an HTTP server using TCP.

       After establishing a connection, the client can send an HTTP request message to the server:

POST /item HTTP/1.1
Host: 189.123.345.239
Content-Type: text/plain
Content-Length: 200

 

       The server then processes the request and sends an HTTP response back to the client.

       The response contains a status code that indicates the status of the request:

200 OK
Content-Type: text/plain
Content-Length: 200

       In the example above, the server returned a status code of 200.

       This is the standard success code for HTTP.

 

       If the server could not decode the request, it could have returned something like this:

400 Bad Request
Content-Length: 0

 

 

SOAP HTTP Binding

A SOAP method is an HTTP request/response that complies with the SOAP encoding rules.

HTTP + XML = SOAP

       A SOAP request could be an HTTP POST or an HTTP GET request.

       The HTTP POST request specifies at least two HTTP headers:

o      Content-Type

o      Content-Length.

 

Content-Type

The Content-Type header for a SOAP request and response defines the MIME type for the message and the character encoding (optional) used for the XML body of the request or response.

Syntax

Content-Type: MIMEType; charset=character-encoding

Example

POST /item HTTP/1.1
Content-Type: application/soap+xml; charset=utf-8

 

Content-Length

The Content-Length header for a SOAP request and response specifies the number of bytes in the body of the request or response.

Syntax

Content-Length: bytes

Example

POST /item HTTP/1.1
Content-Type: application/soap+xml; charset=utf-8
Content-Length: 250

 

A SOAP Example

       A GetStockPrice request is sent to a server

       The request has a StockName parameter

       A Price parameter will be returned in the response.

       The namespace for the function is defined in "http://www.stock.org/stock" address.

       The SOAP request:

POST /InStock HTTP/1.1
Host: www.stock.org
Content-Type: application/soap+xml; charset=utf-8
Content-Length: nnn
 
<?xml version="1.0"?>
<soap:Envelope
xmlns:soap="http://www.w3.org/2001/12/soap-envelope"
soap:encodingStyle="http://www.w3.org/2001/12/soap-encoding">
 <soap:Body xmlns:m="http://www.stock.org/stock">
   <m:GetStockPrice>
 <m:StockName>IBM</m:StockName>
    </m:GetStockPrice>
 </soap:Body>
</soap:Envelope>

 

A SOAP response:

HTTP/1.1 200 OK
Content-Type: application/soap; charset=utf-8
Content-Length: nnn
<?xml version="1.0"?>
<soap:Envelope
xmlns:soap="http://www.w3.org/2001/12/soap-envelope"
soap:encodingStyle="http://www.w3.org/2001/12/soap-encoding">
 <soap:Body xmlns:m="http://www.stock.org/stock">
 <m:GetStockPriceResponse>
 <m:Price>34.5</m:Price>
 </m:GetStockPriceResponse>
 </soap:Body>
</soap:Envelope>