Abstract

SOAP is a format for message exchange between Web Service peers. SOAP does only define very basic semantics for message headers. A multitude of WS-* specifications has been developed to extend SOAP with semantics which can then be reused in various application scenarios. WS-* specifications range from very simple header conventions to highly complex infrastructures, depending on how complex the problem is they are trying to solve.

SOAP is Messaging

• SOAP defines a message format for Web Services
• WSDL defines which SOAP messages can be exchanged
• SOAP and WSDL support very basic functionality
  • defining the message formats that a service accepts and produces
  • defining the binding through which these messages can be exchanged
• SOAP and WSDL are extensible
  • SOAP messages may carry any header and body
  • WSDL can specify which SOAP features it expects

Closing Open Standards

• SQL is a very good example for a pseudo-open standard
  • SQL is standardized in publicly available ANSI/ISO specifications
  • the relevant specification have thousands of pages
  • market entry is de-facto closed to any but well-established organizations
• Web-Services in the SOAP/WS-* world is another example
  • SOAP and WSDL alone often are not sufficient
  • WS-I defines profiles for portable Web Services applications
  • it is almost impossible to keep up with WS-* specifications

WS-Anything

• WS-Addressing
• WS-AtomicTransaction
• WS-BaseNotification
• WS-BrokeredNotification
• WS-BusinessActivity
• WS-Choreography
• WS-Coordination
• WS-Discovery
• WS-Eventing
• WS-Federation
• WS-Inspection
• WS-Management
• WS-Notification
• WS-Policy
• WS-PolicyAttachment
• WS-PolicyAssertions
• WS-Provisioning
• WS-ReliableMessaging
• WS-SecureConversation
• WS-Security
• WS-SecurityPolicy
• WS-Transaction
• WS-Trust
• WS-Topics

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>

SOAP Messages

• SOAP is a very simple messaging framework
  • messages have a body and may have headers
  • headers can be marked as mustUnderstand
  • SOAP defines no standard headers (but some processing semantics)
• SOAP Processing Model
  1. check the message for integrity
  2. check whether a role identifies a header which has to be processed
  3. if a header has to be processed, is it marked as mustUnderstand?
  4. process all headers and relay unprocessed headers if specified
  5. by default, applicable and unprocessed headers are removed

SOAP and XML Namespaces

• SOAP messages usually contain header blocks
  • very minimal semantics are conveyed by SOAP (role, mustUnderstand, relay)
  • other semantics are bound to the headers' namespaces
• XML Namespaces allow the identification of header vocabularies
  • instead of individually negotiated semantics, applications rely on reusable semantics
  • Web Services can then use standardized semantics for communications
  • WS-* should thus be a collection of building blocks for Web Services semantics

WS-* in Practice

• Most WS-* specifications have a narrow focus
  • WS-* specifications only rarely are produced by an open process
  • most WS-* specifications are proprietary products seeking the openness brand
• Relying on a WS-* specification can be risky
  • underspecified descriptions which may lead to implementation problems
  • there is no real conformance testing or compliance definition
  • change management of the specification is still done by the originator

Flexible Addressing

• WS-Addressing is one of the most popular WS-* specifications
  • submitted as W3C Submission by Microsoft, IBM, and BEA
  • moved to W3C Recommendation status in May 2006
• Addressing of messages in SOAP is outside of a message
  • the endpoint of the message is specified in the HTTP request
  • the response message is sent at HTTP response
• WS-Addressing enables messages to contain addressing information
  • the HTTP receiver may be a firewall or a load balancer
  • the service endpoint is described in the message itself
  • replies may go to different recipients (support for results and faults)

Simple Example (Request)

<S:Envelope xmlns:S="http://www.w3.org/2003/05/soap-envelope" xmlns:wsa="http://www.w3.org/2005/08/addressing">
  <S:Header> 
  <wsa:MessageID>http://example.com/someuniquestring</wsa:MessageID>
    <wsa:ReplyTo>
      <wsa:Address>http://example.com/business/client1</wsa:Address>
    </wsa:ReplyTo>
    <wsa:To>mailto:fabrikam@example.com</wsa:To>
    <wsa:Action>http://example.com/fabrikam/mail/Delete</wsa:Action>
  </S:Header>
  <S:Body>
    <f:Delete xmlns:f="http://example.com/fabrikam">     
       <maxCount>42</maxCount>
    </f:Delete>
  </S:Body>
</S:Envelope>

• Destination: mailto:fabrikam@example.com
• Reply endpoint: The endpoint with address http://example.com/business/client1
• Action: http://example.com/fabrikam/mail/Delete
• Message ID: http://example.com/someuniquestring

Simple Example (Reply)

<S:Envelope xmlns:S="http://www.w3.org/2003/05/soap-envelope" xmlns:wsa="http://www.w3.org/2005/08/addressing">
  <S:Header>
    <wsa:MessageID>http://example.com/someotheruniquestring</wsa:MessageID>
    <wsa:RelatesTo>http://example.com/someuniquestring</wsa:RelatesTo>
    <wsa:To>http://example.com/business/client1</wsa:To>
    <wsa:Action>http://example.com/fabrikam/mail/DeleteAck</wsa:Action>
  </S:Header>
  <S:Body>
    <f:DeleteAck xmlns:f="http://example.com/fabrikam"/>
  </S:Body>
</S:Envelope>

• Destination: http://example.com/business/client1
• Action: http://example.com/fabrikam/mail/DeleteAck
• Message ID: http://example.com/someotheruniquestring
• Relationship: (http://www.w3.org/2005/08/addressing/reply, http://example.com/someuniquestring)

Fault Handling

<S:Envelope xmlns:S="http://www.w3.org/2003/05/soap-envelope" xmlns:wsa="http://www.w3.org/2004/12/addressing">
    <S:Header>
        <wsa:MessageID>http://example.com/SomeUniqueMessageIdString</wsa:MessageID>
        <wsa:ReplyTo>
            <wsa:Address>http://myClient.example/someClientUser</wsa:Address>
        </wsa:ReplyTo>
        <wsa:FaultTo>
            <wsa:Address>http://myserver.example/DemoErrorHandler</wsa:Address>
        </wsa:FaultTo>
        <wsa:To>http://myserver.example/DemoServiceURI</wsa:To>
        <wsa:Action>http://myserver.example/DoSomething</wsa:Action>
    </S:Header>
    <S:Body>
        <!-- The message body of the SOAP request appears here -->
    </S:Body>
</S:Envelope>

Address Translation

Service Interactions

• WSDL describes service interfaces
• Business processes are composed out of various services
  • service orchestration describes the process from a central perspective
  • service choreography has no single point of control
• WS-CDL describes the allowed sequences of message exchanges
  • there is no way how the originating parties can be controlled
  • it is possible to detect out-of-sequence messages and raise an error
  • WS-CDL is for description, not for execution (but it may be used for observation)

Example Scenario

SOAP is Insecure

• SOAP messages are typically sent over HTTP
  • SOAP is XML and thus clear text
  • HTTP is also a text-based protocol
• HTTPS supports end-to-end encryption
  • HTTPS encryption may be too expensive
  • end-to-end encryption hides everything (e.g., WS-Addressing)
• WSS is an attempt to define security features for SOAP payloads
  • the message body can be signed and/or encrypted
• Developed by IBM, Microsoft, and VeriSign, now published by OASIS

Securing SOAP Message Exchanges

• Goals of WS-Security
  • multiple security token formats
  • multiple trust domains
  • multiple signature formats
  • multiple encryption technologies
  • end-to-end message content security
• Non-goals of WS-Security
  • establishing a security context
  • key derivation
  • communications about security policies
  • establishment or determination of trust
  • non-repudiation

Encrypting Message Contents

WSS Functionality

• Encryption (message privacy)
  • based on W3C's XML Encryption Syntax and Processing
  • supports symmetric and asymmetric encryption
  • how the keys are established is outside the scope of WSS
• Digital signatures (message authenticity)
  • based on W3C's XML-Signature Syntax and Processing
  • sender creates a digest (fingerprint) of the message
  • the fingerprint is encrypted with the private key
  • the receiver checks the message's digest against the decrypted digest

Digital Signatures

Negotiable Policies

• Describing requirements and capabilities
  • functional requirements: encryption algorithms, transport mechanisms
  • non-functional requirements: SLAs, privacy policies
• WS-Policy defines a grammar for expressing policies
  • WS-Policy does not define a concrete set of policies
  • WS-Policy does define how to determine whether policies match
• Policies are defined in a service's description
  • WS-PolicyAttachment embeds WS-Policy into WSDL and UDDI
  • UDDI can thus be used to search for the best service

WS-Policy Example

<wsp:Policy xmlns:sp="http://schemas.xmlsoap.org/ws/2005/07/securitypolicy" xmlns:wsp="http://schemas.xmlsoap.org/ws/2004/09/policy">
  <sp:TransportBinding>
    <wsp:Policy>
      <sp:AlgorithmSuite>
        <wsp:Policy>
          <wsp:ExactlyOne>
            <sp:Basic256Rsa15/>
            <sp:TripleDesRsa15/>
          </wsp:ExactlyOne>
        </wsp:Policy>
      </sp:AlgorithmSuite>
      <sp:TransportToken>
        <wsp:Policy>
          <sp:HttpsToken RequireClientCertificate="false"/>
        </wsp:Policy>
      </sp:TransportToken>
    </wsp:Policy>
  </sp:TransportBinding>
</wsp:Policy>

• HTTPS must be used as the transport protocol
• It is acceptable if there is not client certificate for the HTTPS connection
• One of the two specified encryption algorithms must be used

WS-SecurityPolicy

• Concrete security policy assertions
  • WS-Policy is the foundation for these assertions
  • security is a large field (dozens of possible assertions about a service)
• Expression of security policies for WSS-related specifications
  • SOAP messages must be secured accordingly (signed and/or encrypted)
  • WS-Trust (issuance and dissemination of security-related credentials)
  • WS-SecureConversation (extending WS-Security with secure contexts)

Describing Services

• Services have various facets which should be described
  • the interface can be described by WSDL
  • the association with a business may be described in UDDI
  • additional documentation may be available
• There is no standard for tying all pieces together
  • WS-Inspection is a schema for linking this information together
  • services described by WS-Inspection should be easier to use
  • WS-Inspection defines a self-contained format

WS-Inspection = (G)RDDL4WS

• XML vocabularies often have various documents associated with them
  • a schema which describes the vocabulary as a grammar
  • documentation which describes the vocabulary semantically
  • example instances
  • test suites (a special case of example instances)
  • dependencies with other vocabularies
  • tools or code fragments for processing the vocabulary
• All this information could be associated with the XML Namespace
  • there is no standard for how namespace descriptions should be structured
  • RDDL was a first attempt but failed
  • GRDDL is based on RDF and thus will also fail
  • instead of waiting for the W3C, inhouse solutions should be built
• WS-Inspection also failed, but in a SOA it is a problem worth solving

Too Many Specifications

• WS-* specifications solve common problems
• Not all problems may be adequately addressed by the specifications
• Many specifications have undocumented underlying assumptions
• The WS-* landscape will consolidate into a small set

There are two ways of constructing a software design: One way is to make it so simple that there are obviously no deficiencies, and the other way is to make it so complicated that there are no obvious deficiencies. The first method is far more difficult.

C. A. R. Hoare, The Emperor's Old Clothes, 1980 Turing Award Lecture