• Motivation
  • SOAP protocol and related specifications
  • WSDL interface definition langiage
  • WS-Policy
  • Illustration by a larger exampe
  • Possible Extensions
  • Summary
  • Referneces


  • Service-Oriented Architecture
  • For large-scale distributed computing
  • For interoperability within and among enterprises
  • Business-oriented services
    • Coarse-grained service interfaces
    • Improves evolvability, manageability
  • Needs a suitable set of technologies

Solutions needed to implement SOA lifecycle

  • SOA is a programming style
  • An SOA application is a composition of services
  • A ‘service’ is a building block/unit of an SOA
  • Service encapsulates a business process
  • A Service Provider registers services
  • Service consumption involves Find-Bind-Execute pattern
  • Questions
    • How to specify data involved in the process?
    • How to specify the way to access a service functionality?
    • How to communicate to services?
    • Can we use some existing solutions?

Web Services

  • Technology for SOA
  • Client-server messaging approach
    • With predefined Message exchange patterns
    • Independent of network protocols
  • Application-specific interfaces
    • Similar to RPC, CORBA
  • Most data in XML
    • Descriptions in XML Schema

RPC vs. Web Services

  • Remote Procedure Calls
  • Aim to hide the network
    • Distributed system looks like a local system
    • Some calls happen to go over the network
  • But network is important
    • Latency, bandwidth
    • Reliability – connection, nodes
  • RPC is harmful

Why is RPC considered harmful?

  • Introduces semantics of a synchronous, blocking invocation
    • SOA needs a more flexible implementation technology
  • Usage of statically typed interfaces
    • Late binding is one of the premises of SOA
  • Restrictive, inflexible and doesn’t provide the required level of abstraction
    • Implicit introduction of the behavior which characterizes unified memory space solutions
  • Hinders resolution of the interoperability issues
    • Harder to adapt
  • An appropriate SOA underlying technology needs to shift from the single-machine-centric vision towards the network-centric vision

CORBA vs. Web Services

  • CORBA = Distributed Objects
    • Encourages fine-grained design
  • Much more advanced than RPC
  • High barrier to entry
    • Caused by binary protocols, high core complexity
  • Initial big interoperability problems
    • Due to the above, and incomplete specifications

Web Service Stack


  • née Simple Object Access Protocol
    • In fact, simple messaging protocol
  • Current version: 1.2 @ W3C
  • Message structure
  • Processing model
  • Protocol bindings


  • XML Envelope 
  • Body
    • Application payload
    • Faults
  • Headers
    • Metadata, processing instructions
    • May be marked as mandatory 
    • Possibly targeted at intermediaries

Message Example

SOAP Message Envelope

SOAP Processing Model

  • Processing a message
    • Selecting headers targeted at me
      • The current intermediary or ultimate receiver
    • Checking for understanding
      • Do I understand all that is targeted at me and marked as mandatory?
    • Processing everything in some order

SOAP Mandatory Headers

  • mustUnderstand="true"
    • The recipient must understand them
    • Implies agreement to act in accordance to the spec
    • Non-mandatory headers can be ignored
  • This mechanism enables gracious evolution
    • If a new feature can be ignored, its introduction won't harm older nodes
    • If a new feature must be understood, its introduction will be discovered early by older nodes, without unexpected behavior

SOAP Protocol Bindings

  • Transporting the message over a network
  • Addressing
    • What an endpoint address looks like
  • Serialization
    • How to put the XML message in on-the-wire bits and bytes
  • Connection
    • How to send the bits to the endpoint


  • Addressing: URIs
  • Serialization: HTTP message body
    • Media type application/soap+xml
  • Connection: TCP
  • Possibly Web-friendly
    • SOAP 1.1 only used HTTP POST


  • Message Exchange Patterns
  • Request-Response
    • Input message followed by output or fault
  • SOAP-Response
    • Request without SOAP (e.g. HTTP GET)
    • SOAP output or fault

SOAP Summary

  • Still pretty simple even if the name doesn’t say so any more
  • Extremely extensible
  • HTTP binding for easy communication
  • The value of SOAP:
    XML and Processing Model

SOAP Attachments

  • XML is nice, but… not binary
  • XOP: XML-binary Optimized Packaging
    • Binary data in XML logically in the tree
    • On serialization, it is outside, raw, efficient
      • MIME multipart message
  • MTOM: XOP for SOAP
    • Message Transfer Optimization Mechanism
    • Extends SOAP HTTP binding


  • Simple routing protocol
  • Endpoint References for addressing
    • With parameters or metadata in addition to the service address
  • Message headers for routing & correlation
    • Many headers use endpoint references

WSA Msg Info Headers

  • To – let the middleware deliver the message
  • From, ReplyTo, FaultTo – channels back
  • MessageID, RelatesTo – simple correlation
  • Action – semantics implied by the message

    <wsa:MessageID>unique ID </wsa:MessageID>
    <wsa:ReplyTo> endpoint </wsa:ReplyTo>
    <wsa:To> address </wsa:To>
    <wsa:Action> URI </wsa:Action>


  • Web Service Description Language
    • Interface Definition Language (IDL) for Web Services
  • Current version: 2.0 @ W3C
    • Version 1.1 still in widespread use
  • Interface – reusable, abstract
    • Operations with MEPs
  • Binding – reusable, concrete
  • Service implements an interface
    • Endpoints use bindings

WSDL Component Structure

  • The main component of WSDL is, of course, the Web service. A single WSDL file can describe multiple services.
  • A Web service can have a number of endpoints- network addresses where the service is accessible.
  • A service implements a single interface. In WSDL 1.1, the previous, unstandardized version, this was not enforced. An interface is an abstract view on what the operation does. A single WSDL file can describe multiple interfaces.
  • Interfaces contain descriptions of operations and faults. In WSDL 2.0, interfaces can one another, which basically includes all the operations and faults of the extended interface in the extending interface.
  • Since an interface is abstract, WSDL adds a binding component to specify how the interface is actually accessed over a network. Each endpoint of a service can have a different binding.
  • The structure of a binding follows the structure of an interface; the binding can even specify networking details for each operation or fault. 

WSDL Component Structure

Now let's take a closer look at the interface.

  • An interface operation contains message references and fault references. Message references refer to message exchange patterns . To illustrate: a request/response operation will have two message references, one for the request message, and one for the response message. Fault references in an operation point to fault definitions. In this way, fault definitions are shared among operations.
  • For describing the content of the messages and faults, WSDL contains a section called types that contains data schemas.
  • In XML Schema, the most common language, there are element declarations type definitions . Type definitions describe the inner structure of an element, whereas element declarations give elements their names.
  • Each operation message reference and each fault generally points to a single element declaration. The element declaration describes the body of the message, or the fault details of the fault.

WSDL Interface

  • Design of application interface
    • Possibly extending other interfaces
  • Operations
    • Message exchange pattern (MEP)
    • Input/output messages, faults
    • Referencing XML elements defined in types
  • Faults
    • Used and reused by operations

WSDL Interface Example

<interface name=“Banking”> <operation name=“transfer” pattern=“”> <input element=“Transfer”/> <output element=“Balance”/> <outfault ref=“ InvalidBankAccount ”/> <outfault ref=“ InsufficientFunds ”/> </operation> <operation name=“balance” safe=“true” pattern=“”> <input element=“ BalanceRequest ”/> <output element=“Balance”/> <outfault ref=“ InvalidBankAccount ”/> </operation> <fault name=“ InvalidBankAccount ” element=“ InvalidAccountInfo ” /> <fault name=“ InsufficientFunds ” element=“ InsufficentFundsInfo ” /> </interface>

WSDL Predefined MEPs

WSDL Invocation MEPs

  • In-only: a single input message
    • No faults
  • In-out: a single input message, a single output message
    • A fault may replace output message
  • Out-only and Out-in mirror images of the above

WSDL Messaging MEPs

  • Robust in-only: a single input message
    • May trigger a fault
  • In-optional-out: a single input message, possibly an output message
    • Either message may trigger a fault
  • Robust out-only, Out-optional-in mirrored

WSDL Bindings

  • Networking details necessary for accessing the service
  • Copies interface structure
  • SOAP and HTTP bindings provided
    • SOAP binding:
      • XML message in SOAP envelope
      • Transport using a SOAP protocol binding (HTTP)
    • HTTP binding:
      • Web-friendly
      • XML message in payload, or as parameters in the URI

WSDL Service

  • A logical node of the application
  • One interface
  • Multiple alternate endpoints
  • Endpoints may have different bindings
    • E.g. SOAP over HTTP for a public endpoint, and SOAP over JMS for the intranet
  • WSDL Service Example
    <service name=“HypoTirol ” interface=“Banking”>
    <endpoint name=“visible” binding=“HTTP” address=“” /> <endpoint name=“tls ” binding=“SecureHTTP ” address=“” />

WSDL Summary

  • Concrete service
  • Abstract and reusable Interface
  • Network binding
  • WSDL does not imply implementation
    • CORBA IDL requires objects
  • Exchange of XML business documents
  • Extensible in many ways


  • Universal Description, Discovery and Integration
  • A Web service registry API specification
    • Business-oriented service publication, discovery (initially limited search capabilities)
    • Itself has Web service interface
    • Useful for intranet registries
  • A failed public service
  • UDDI Structure
  • Business entity
    • Organization information, contact
  • Business Service
    • A group of related services
  • Binding Template
    • Information on how to access the service
  • tModel (technical model)
    • Any kind of specification, e.g. WSDL
    • Also for classification, categorization


  • None of the previous solutions is addressing the non-functional aspects in the context of Web Services
    • e.g., a Web Service can be accessed only if a particular security constrains (like secure channel communication) hold.
  • WS-Policy is an XML-based set of specifications to advertise and specify service-related non-functional metadata
    • Security, Quality of service, Privacy, Transactional policies
  • WS-Policy main specifications
    • WS-Policy Framework
      • Provides model and syntax to describe and communicate policies
  • WS-Policy Assertions
    • Defines a common set of policy assertions for Web services
  • WS-Policy Attachments
    • General-purpose mechanisms for associating such policies with the subjects to which they apply
  • Capability vs. requirement policy

A Policy

  • Policy is a collection of policy alternatives (OR)
    • Auth tokens: Kerberos OR X509
  • Policy alternative is a collection of policy assertions (AND)
    • Auth token AND secure channel
  • Policy assertions specify
    • traditional policies that will ultimately manifest on the wire (authentication scheme, transport protocol selection), and
    • critical to proper service selection and usage (privacy policy, QoS characteristics).
  • Two "operators" (XML tags) are used to make statements about policy combinations:
    • wsp:ExactlyOne - asserts that only one child node must be satisfied.
    • wsp:All - asserts that all child nodes must be satisfied.
  • The intersection is a new policy that complies with both their requirements/capabilities

An Example of the Security Policy

<wsp:Policy> <wsp:ExactlyOne> <wsse:SecurityToken> <wsse:TokenType>wsse:Kerberosv5TGT </wsse:TokenType> </wsse:SecurityToken> <wsse:SecurityToken> <wsse:TokenType>wsse:X509v3 </wsse:TokenType> </wsse:SecurityToken> </wsp:ExactlyOne> </wsp:Policy>


  • WS-BPEL is an orchestration executable language for specifying interactions with Web Service
    • Defines an interoperable integration model for Web Service-based processes.
    • Describes high-level state transition interactions of a process.
  • The language supports following basic facilities:
    • Message exchanges,
    • Property-based message correlation mechanism,
    • XML and WSDL typed variables,
    • Structured programming-language concepts such as if-then-else, while, sequence, and flow,
    • Scoping system to allow encapsulation of logic with local-variables, fault-, compensation- and event- handlers,
    • Serialized scopes to control concurrent access to variables,
    • Language plug-in model which allows expression writing in the language such as XPath

WS-BPEL v2.0 MetaModel

Main elements

  • Process
    • Root element for a WS-BPEL process specification 
  • Variable
    • Holding messages that constitute a part of the state of a business process.
  • Activity
    • Perform the process logic.
    • Basic vs. structured activities.
  • PartnerLink
    • Models peer-to-peer conversational partner relationships.
  • Catch
    • Scope-based custom fault-handling activities. 
  • Correlation
    • Used to differentiate instances of the business processes.
    • The declaration of correlation relies on declarative properties of messages
  • onEvent
    • Scope-based concurrent answering to events
    • onEvent vs, onAlarm

An Example

  • The operation of the process is very simple, and is represented in Figure: Purchase Order Process Outline. Dotted lines represent sequencing. Free grouping of sequences represents concurrent sequences. Solid arrows represent control links used for synchronization across concurrent activities. Note that this is not meant to be a definitive graphical notation for WS- BPEL processes. It is used here informally as an aid to understanding. On receiving the purchase order from a customer, the process initiates three paths concurrently: calculating the final price for the order, selecting a shipper, and scheduling the production and shipment for the order. While some of the processing can proceed concurrently, there are control and data dependencies between the three paths. In particular, the shipping price is required to finalize the price calculation, and the shipping date is required for the complete fulfillment schedule. When the three concurrent paths are completed, invoice processing can proceed and the invoice is sent to the customer.

An Example (cont')

<process name="purchaseOrderProcess" targetNamespace= xmlns= xmlns:lns=""> <partnerLinks> <partnerLink name="purchasing” partnerLinkType="lns:invoicingLT” myRole="invoiceRequester" partnerRole="invoiceService" /> <partnerLink name="shipping" partnerLinkType="lns:shippingLT” myRole="shippingRequester" partnerRole="shippingService" /> <partnerLink name="scheduling” partnerLinkType="lns:schedulingLT” partnerRole="schedulingService" /> </partnerLinks> <variables> <variable name="PO" messageType="lns:POMessage" /> <variable name="Invoice" messageType="lns:InvMessage" /> <variable name="shippingRequest"messageType="lns:shippingRequestMessage" /> <variable name="shippingInfo"messageType="lns:shippingInfoMessage" /> <variable name="shippingSchedule"messageType="lns:scheduleMessage" /> </variables> <faultHandlers> <catch faultName="lns:cannotCompleteOrder"faultVariable="POFault" faultMessageType="lns:orderFaultType”> <reply partnerLink="purchasing"portType="lns:purchaseOrderPT" operation="sendPurchaseOrder" variable="POFault" faultName="cannotCompleteOrder" /> </catch> </faultHandlers> …

An Example (cont')

… <sequence> <receive partnerLink="purchasing" portType="lns:purchaseOrderPT” operation="sendPurchaseOrder" variable="PO" createInstance="yes”> </receive> <flow> <links> <link name="ship-to-invoice" /> <link name="ship-to-scheduling" /> </links> <sequence> <assign> <copy> <from>$PO.customerInfo</from> <to>$shippingRequest.customerInfo</to> </copy> </assign> <invoke partnerLink="shipping" portType="lns:shippingPT" operation="requestShipping" inputVariable="shippingRequest" outputVariable="shippingInfo"> <sources> <source linkName="ship-to-invoice" /> </sources> </invoke> <receive partnerLink="shipping” portType="lns:shippingCallbackPT" operation="sendSchedule" variable="shippingSchedule”> <sources> <source linkName="ship-to-scheduling" /> </sources> </receive> </sequence> …

An Example (cont')

… <sequence> <invoke partnerLink="invoicing” portType="lns:computePricePT" operation="initiatePriceCalculation” inputVariable="PO”> </invoke> <invoke partnerLink="invoicing" portType="lns:computePricePT" operation="sendShippingPrice" inputVariable="shippingInfo”> <targets><target linkName="ship-to-invoice" /></targets> </invoke> <receive partnerLink="invoicing” portType="lns:invoiceCallbackPT” operation="sendInvoice" variable="Invoice" /> </sequence> <sequence> <invoke partnerLink="scheduling” portType="lns:schedulingPT” operation="requestProductionScheduling” inputVariable="PO"> </invoke> <invoke partnerLink="scheduling” portType="lns:schedulingPT” operation="sendShippingSchedule” inputVariable="shippingSchedule”> <targets><target linkName="ship-to-scheduling" /></targets> </invoke> </sequence> </flow> <reply partnerLink="purchasing" portType="lns:purchaseOrderPT” operation=”sendPurchaseOrder" variable="Invoice”> </reply> </sequence> </process>

The Rest of the Specs

  •  Security: authentication, encryption
  • Reliable messaging
    • “Get the message there or tell me”
  • Transactions: ACID, Compensating
  • WS-BPEL: Scripting Web Services
  • Interoperability: WS-I Basic Profile
  • … and still more

Virtual Travel Agency

Blue Hotel WSDL

<?xml version="1.0" encoding="utf-8" ?> <description xmlns ="" targetNamespace = "" xmlns:tns = "" xmlns:bhns = "" xmlns:wsoap = "" xmlns:soap ="" xmlns:wsdlx = ""> <documentation> This document describes the Blue Hotel Web service. </documentation>

Blue Hotel WSDL (cont')

<types> <xs:schema xmlns:xs="" targetNamespace="" xmlns=""> <xs:element name="checkAvailability" type="tCheckAvailability"/> <xs:complexType name="tCheckAvailability"> <xs:sequence> <xs:element name="checkInDate" type="xs:date"/> <xs:element name="checkOutDate" type="xs:date"/> <xs:element name="roomType" type="xs:string"/> </xs:sequence> </xs:complexType> <xs:element name="checkAvailabilityResponse" type="tCheckAvailabilityResponse"/> <xs:complexType name="tCheckAvailabilityResponse"> <xs:sequence> <xs:element name="roomType" type="xs:string"/> <xs:element name="rateType" type="xs:string"/> <xs:element name="rate" type="xs:double"/> </xs:sequence> </xs:complexType> <xs:element name="invalidDataError" type="xs:string"/> </xs:schema> </types>

Blue Hotel WSDL (cont')

<interface name = " BlueServiceInterface " > <fault name = " invalidDataFault " element = " bhns:invalidDataError "/> <operation name=" opCheckAvailability " pattern="" style="" wsdlx:safe = "true"> <input messageLabel ="In" element=" bhns:checkAvailability " /> <output messageLabel ="Out" element=" bhns:checkAvailabilityResponse " /> < outfault ref=" tns:invalidDataFault " messageLabel ="Out"/> </operation> </interface>

Blue Hotel WSDL (cont')

<binding name=" BlueServiceSOAPBinding " interface=" tns:BlueServiceInterface " wsoap:protocol ="" type=""> <fault ref=" tns:invalidDataFault " wsoap:code =" soap:Sender "/> <operation ref=" tns:opCheckAvailability " wsoap:mep = ""/> </binding> <service name=" BlueService " interface=" tns:BlueServiceInterface "> <endpoint name=" reservationEndpoint " binding=" tns:BlueServiceSOAPBinding " address=""/> </service> </description>

Blue Hotel UDDI Binding Template

<bindingTemplate bindingKey= "uuid:36F1B765-BDB3-4837-828D-8284301E5A2A" serviceKey= "uuid:40E6D5A8-3E16-4f01-99DA-035229685A40"> <description xml:lang="en"> SOAP binding for Blue Hotel service </description> <accessPoint URLType="http"> </accessPoint> <tModelInstanceDetails> <tModelInstanceInfo tModelKey= "uuid:AE1B645F-CF2F-491f-811A-4868705F5904"/> </tModelInstanceDetails> </bindingTemplate>

Blue Hotel UDDI tModel

<tModel tModelKey= "uddi:WE1B6Q5F-CF2F-491f-811A-4868705F5904" operator="" authorizedName="George Blue"> <name>BlueHotelInterface Port Type</name> <description> An interface for the Blue Hotel service </description> <overviewDoc><overviewURL> BlueHotelService.wsdl </overviewURL></overviewDoc> </tModel>

Blue Hotel SOAP Request

POST /InStock HTTP/1.1 Host: Content-Type: application/soap+xml; charset=utf-8 Content-Length: nnn <?xml version="1.0"?> <soap:Envelope soap:encodingStyle= "" xmlns:soap=""> <soap:Body xmlns:bhns= ""> <bhns:checkAvailability> <bhns:checkInDate>2009-03-24</bhns:checkInDate> <bhns:checkOutDate>2009-03-30</bhns:checkOutDate> <bhns:roomType>Single</bhns:roomType> </bhns:checkAvailability> </soap:Body> </soap:Envelope>

Blue Hotel SOAP Response

HTTP/1.1 200 OK Content-Type: application/ soap+xml ; charset =utf-8 Content-Length: nnn <?xml version="1.0"?> <soap:Envelope soap:encodingStyle = "" xmlns:soap =""> <soap:Body xmlns:bhns = ""> <bhns:checkAvailabilityResponse> <bhns:roomType > Single </bhns:roomType> <bhns:rateType > Discount </bhns:rateType> <bhns:rate > 150.50 </bhns:rate> </bhns:checkAvailabilityResponse> </soap:Body> </soap:Envelope>

Web Services Summary

  • Technology for service-oriented systems
  • Core: protocol + IDL (SOAP + WSDL)
  • Many extension specifications
  • Messaging paradigm
    • Sometimes RPC
  • Biggest benefit: XML
    • Vendor-neutral, platform-independent
    • Interoperable
    • Easy to begin and play with
    • But hidden in the frameworks 
      • Unless you're a developer of the framework

Possible Extensions

  • Semantic Web Services
    • Automating the use of Web services
    • Using semantic technologies
  • RESTful services
    • Real Web services
    • Integrated with the Web


  • G. Alonso, F. Casati, H. Kuno, V. Machiraju. Web Services, Concepts Architectures and Applications. Springer Verlag ISBN 3-540-44008-9
  • WSDL
  • SOAP
  • UDDI
  • XOP
  • MTOM
  • WS-Addressing
  • WS-Policy
  • W3C

Creator: sidraaslam

ali1k (VU Amsterdam)

Licensed under the Creative Commons
Attribution ShareAlike CC-BY-SA license

This deck was created using SlideWiki.