Service consumption involves Find-Bind-Execute pattern
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?
Technology for SOA
Client-server messaging approach
With predefined Message exchange patterns
Independent of network protocols
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
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
Metadata, processing instructions
May be marked as mandatory
Possibly targeted at intermediaries
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
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
What an endpoint address looks like
How to put the XML message in on-the-wire bits and bytes
How to send the bits to the endpoint
SOAP HTTP Binding
Serialization: HTTP message body
Media type application/soap+xml
SOAP 1.1 only used HTTP POST
Message Exchange Patterns
Input message followed by output or fault
Request without SOAP (e.g. HTTP GET)
SOAP output or fault
Still pretty simple even if the name doesn’t say so any more
HTTP binding for easy communication
The value of SOAP: XML and Processing Model
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 <S:Header>
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
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
that contains data schemas.
In XML Schema, the most common language, there are
. 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.
Used to differentiate instances of the business processes.
The declaration of correlation relies on declarative properties of messages
Scope-based concurrent answering to events
onEvent vs, onAlarm
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
SOAP binding for Blue Hotel service
Blue Hotel UDDI tModel
<name>BlueHotelInterface Port Type</name>
An interface for the Blue Hotel service