Abstract

Web Services (as the narrowly defined field as opposed to the broader topic of Web-based Services) are usually described as three technologies. The Simple Object Access Protocol (SOAP) is the format which is used to encapsulate XML payload and provides a common envelope format which can be interpreted and processed by all SOAP-aware applications. The Web Services Description Language (WSDL) is used to describe the interface to a Web Service which accepts SOAP messages. Using WSDL, code can be generated to more easily interface with the Web Service. Finally, Universal Description, Discovery, and Integration (UDDI) is a registry which can be used to search for WSDL documents.

The Real World

• Web Services to 99% of IT people mean
  • Simple Object Access Protocol (SOAP)
  • Web Services Description Language (WSDL)
  • Universal Description, Discovery, and Integration (UDDI)
• SOAP to 99% of IT people means
  • XML-based access to APIs (i.e., language- and OS-independent APIs)
  • a way to build distributed systems based on Web technologies
• SOAP can be used to implement a Service Oriented Architecture (SOA)
  • SOAP is a protocol for transmitting XML messages
  • SOA is a way to build IT landscapes
  • the vast majority of SOAP users do not support or even know SOA

XML Message Format

• SOAP describes the message format being exchanged by peers
  • SOAP messages have an envelope for Web Service Metadata
  • SOAP messages have a body containing the actual payload
  • non-XML data can be attached in the same way as for e-mail messages
• SOAP has also made the transition to abstractions
  • SOAP 1.1 is defined as a format for exchanging XML documents
  • SOAP 1.2 is defined as a format for exchanging Infosets
  • using SOAP 1.2, XML technologies may be used but no pointy bracket is ever being used

SOAP Message Structure

SOAP Example Message

<?xml version="1.0"?>
<env:Envelope xmlns:env="http://www.w3.org/2003/05/soap-envelope">
 <env:Header>
  <m:reservation xmlns:m="http://travelcompany.example.org/reservation" env:role="http://www.w3.org/2003/05/soap-envelope/role/next" env:mustUnderstand="true">
   <m:reference>uuid:093a2da1-q345-739r-ba5d-pqff98fe8j7d</m:reference>
   <m:dateAndTime>2001-11-29T13:20:00.000-05:00</m:dateAndTime>
  </m:reservation>
  <n:passenger xmlns:n="http://mycompany.example.com/employees" env:role="http://www.w3.org/2003/05/soap-envelope/role/next" env:mustUnderstand="true">
   <n:name>Åke Jógvan Øyvind</n:name>
  </n:passenger>
 </env:Header>
 <env:Body>
  <p:itinerary xmlns:p="http://travelcompany.example.org/reservation/travel">
   <p:departure>
    <p:departing>New York</p:departing>
    <p:arriving>Los Angeles</p:arriving>
    <p:departureDate>2001-12-14</p:departureDate>
    <p:departureTime>late afternoon</p:departureTime>
    <p:seatPreference>aisle</p:seatPreference>
   </p:departure>
   <p:return>
    <p:departing>Los Angeles</p:departing>
    <p:arriving>New York</p:arriving>
    <p:departureDate>2001-12-20</p:departureDate>
    <p:departureTime>mid-morning</p:departureTime>
    <p:seatPreference/>
   </p:return>
  </p:itinerary>
  <q:lodging xmlns:q="http://travelcompany.example.org/reservation/hotels">
   <q:preference>none</q:preference>
  </q:lodging>
 </env:Body>
</env:Envelope>

Some Observations

• Most elements are not SOAP elements
  • Envelope, Header, and Body are SOAP elements
  • SOAP also defines how applications must handle other elements within the message
• Header information is Metadata about the SOAP message
  • the actual metadata format is not defined by SOAP
  • role specifies that all intermediaries should use this header
  • mustUnderstand specifies that the header must be interpreted by a node
• Body information is the payload for the ultimate receiver
  • header information may be inspected and acted upon on the way
  • the body may be protected by encrypting it (if required), leaving the headers open for inspection

SOAP Fault Message

<?xml version="1.0"?>
<env:Envelope xmlns:env="http://www.w3.org/2003/05/soap-envelope" xmlns:rpc="http://www.w3.org/2003/05/soap-rpc">
 <env:Body>
  <env:Fault>
   <env:Code>
    <env:Value>env:Sender</env:Value>
    <env:Subcode>
     <env:Value>rpc:BadArguments</env:Value>
    </env:Subcode>
   </env:Code>
   <env:Reason>
    <env:Text xml:lang="en-US">Processing error</env:Text>
    <env:Text xml:lang="cs">Chyba zpracování</env:Text>
   </env:Reason>
   <env:Detail>
    <e:myFaultDetails xmlns:e="http://travelcompany.example.org/faults">
     <e:message>Name does not match card number</e:message>
     <e:errorcode>999</e:errorcode>
    </e:myFaultDetails>
   </env:Detail>
  </env:Fault>
 </env:Body>
</env:Envelope>

Processing SOAP

• Processing SOAP messages should not be done by hand
  • SOAP handling is a routine task that can be done by existing software
  • Apache Axis is a popular open source package for processing SOAP
• Ideally, SOAP code should be generated for a given service
  • there must be some description of the service to generate code from
  • software could use this description to generate stubs (marshaling/unmarshaling)

SOAP Operation

Describing Web Services

• SOAP defines what to send to a Web Service
  • the payload format must be known
  • the different messages that may be sent must be known
  • the transport mechanism must be known
  • the address where to send the SOAP to must be known
• WSDL has been designed to describe service interfaces
• WSDL has versioning problems
  • WSDL 1.1 (Microsoft/IBM) was only published as a W3C Note
  • WSDL 1.2 was abandoned along the way
  • WSDL 2.0 takes a very long time (since 2002) before becoming a W3C Recommendation
  • most deployed Web Services are based on WSDL 1.1
  • the differences between WSDL 1.1 and WSDL 2.0 are considerable

WSDL Data Model

Types

• XML structures that are exchanged are described using XML Schema
• Types in WSDL define a type library for the WSDL description

 <wsdl:types>
  <xsd:schema xmlns="http://www.w3.org/2001/XMLSchema" targetNamespace="urn:GoogleSearch">
   <xsd:complexType name="GoogleSearchResult">
    <xsd:all>
     <xsd:element name="documentFiltering" type="xsd:boolean"/>
     <xsd:element name="searchComments" type="xsd:string"/>
     <xsd:element name="estimatedTotalResultsCount" type="xsd:int"/>
     <xsd:element name="estimateIsExact" type="xsd:boolean"/>
     <xsd:element name="resultElements" type="typens:ResultElementArray"/>
     <xsd:element name="searchQuery" type="xsd:string"/>
     <xsd:element name="startIndex" type="xsd:int"/>
     <xsd:element name="endIndex" type="xsd:int"/>
     <xsd:element name="searchTips" type="xsd:string"/>
     <xsd:element name="directoryCategories" type="typens:DirectoryCategoryArray"/>
     <xsd:element name="searchTime" type="xsd:double"/>
    </xsd:all>
   </xsd:complexType>

Messages

• Messages describe the SOAP body parts being sent
  • Messages can have one or more parts, which are different logical units

 <message name="doGoogleSearch">
  <part name="key" type="xsd:string"/>
  <part name="q" type="xsd:string"/>
  <part name="start" type="xsd:int"/>
  <part name="maxResults" type="xsd:int"/>
  <part name="filter" type="xsd:boolean"/>
  <part name="restrict" type="xsd:string"/>
  <part name="safeSearch" type="xsd:boolean"/>
  <part name="lr" type="xsd:string"/>
  <part name="ie" type="xsd:string"/>
  <part name="oe" type="xsd:string"/>
 </message>
 <message name="doGoogleSearchResponse">
  <part name="return" type="typens:GoogleSearchResult"/>
 </message>

Port Types

• Port Types are named sets of abstract operations
  • the operations are described by the messages they are based on
• WSDL supports four kinds of message exchange patterns
  • one-way: the endpoint receives a message
  • request-response: the endpoint receives a message, and sends a correlated message
  • solicit-response: the endpoint sends a message, and receives a correlated message
  • notification: the endpoint sends a message

 <portType name="GoogleSearchPort">
  <operation name="doGetCachedPage">
   <input message="typens:doGetCachedPage"/>
   <output message="typens:doGetCachedPageResponse"/>
  </operation>
  <operation name="doSpellingSuggestion">
   <input message="typens:doSpellingSuggestion"/>
   <output message="typens:doSpellingSuggestionResponse"/>
  </operation>
  <operation name="doGoogleSearch">
   <input message="typens:doGoogleSearch"/>
   <output message="typens:doGoogleSearchResponse"/>
  </operation>
 </portType>

Bindings

• Bindings defines message format and protocol details for a port type
  • the type attribute identifies the associated port type
  • there can be any number of bindings for a port type

 <binding name="GoogleSearchBinding" type="typens:GoogleSearchPort">
  <soap:binding style="rpc" transport="http://schemas.xmlsoap.org/soap/http"/>
  <operation name="doGetCachedPage">
   <soap:operation soapAction="urn:GoogleSearchAction"/>
   <input>
    <soap:body use="encoded" encodingStyle="http://schemas.xmlsoap.org/soap/encoding/" namespace="urn:GoogleSearch"/>
   </input>
   <output>
    <soap:body use="encoded" encodingStyle="http://schemas.xmlsoap.org/soap/encoding/" namespace="urn:GoogleSearch"/>
   </output>
  </operation>

Ports

• Ports are service endpoints
  • a port specifies an address for a binding

  <port name="GoogleSearchPort" binding="typens:GoogleSearchBinding">
   <soap:address location="http://api.google.com/search/beta2"/>
  </port>

Services

• Services group related ports together
  • these ports must not communicate with each other

 <service name="GoogleSearchService">
  <port name="GoogleSearchPort" binding="typens:GoogleSearchBinding">
   <soap:address location="http://api.google.com/search/beta2"/>
  </port>
 </service>

Visualizing WSDL

Locating WSDL Descriptions

• WSDL helps describing a Web Service
  • WSDL does not describe a service (the service's semantics)
  • WSDL describes a service's interface (the syntax for interaction)
• How can WSDL descriptions be located?

WSDL Directory

• UDDI is intended to be a repository for WSDL descriptions
  • users interested in a Web Service can use UDDI to locate it
• UDDI is not a global service like the DNS
  • but it is a distributed directory service designed for large-scale deployment
  • it is operated by user communities interested in distributing WSDL documents
  • most UDDI directories are closed user groups
• UDDI is modeled after yellow pages
  • how likely is it to simply look up a Web Service and then use it?
  • if other mechanisms are in place, locating a WSDL becomes a minor problem

UDDI Data Model

Mapping WSDL → UDDI

UDDI is a Web Service

• UDDI itself is a Web Service
  • operations for inserting and searching entries
• There is no normative WSDL for UDDI
  • UDDI implementers can define their own UDDI WSDL
  • UDDI defines a number of policies implementers must follow

Web Services Core Technologies

• SOAP encodes Web Services messages
• WSDL described Web Services interfaces
• UDDI is a repository for WSDL descriptions