SOAP - Intro 2 Webservices

Lecture 5
Introduction to Web Services

Simple Object Access Protocol (SOAP)
Gustavo Alonso and Cesare Pautasso
Computer Science Department
Swiss Federal Institute of Technology (ETHZ)
pautasso@inf.ethz.ch
http://www.iks.inf.ethz.ch/
Contents – Lecture 5 - SOAP

Web Services
Context: WWW, Components, Interoperability Standards
Limitations of Middleware
Web Services Architecture
The Service Bus
Chapter 6
SOAP
RPC across the Internet
Structure of a SOAP Message
SOAP Header
SOAP Body
SOAP Faults
From TRPC to SOAP messages
Mapping SOAP to a transport protocol

SOAP and HTTP
©IKS, ETH Zürich. 2

Introduction to Web Services
Web Services in Context
World Wide
Components
Web
Web Services
Middleware Standards

Is this a Web Service?
Web-based Services
Services offered through a Web site
Web HTML Web

Browser HTTP Server
Web Services
Services offered through Web-wide standardized
protocols
SOAP
Client XML Server
HTTP
Extending the Web with Services
Web Browser WS Client
HTML/HTTP SOAP/HTTP
Web Server
add your
Java ASP
CGI PHP favourite
Servlet .NET here
Back-end Systems and Databases

Components vs. Services

Software components are reusable Web services are reusable too.
To be used a component must: To be used a service must:
be packaged to be deployed as be published on the Web
part of some larger application advertise its description and
system location to potential clients
fit with the existing framework across the Web so that they
used to develop the system (as can access it using standard
an exercise try to use a .NET protocols
assembly to make an Eclipse Web Services can be sold too.
plug-in and see what happens) Service providers can charge
Components can be sold. on a per-call basis: each time
Component developers charge an existing client interacts
on a per-deployment basis: with a service by exchanging
whenever a new client a new message.
downloads the component. Web services can be composed
There are many component into larger systems and (of
frameworks available for building course) can be found on the Web.
distributed systems (e.g., J2EE, Unlike components, Web services
DCOM, .NET, CORBA). do not have to be downloaded
The problem is: they are not and deployed in order to be used
compatible. by clients.
Component Interoperability
Due to lack of interoperability, it is not always
possible to build a distributed system using
heterogeneous components
Enterprise
DCOM Eiffel
Java
Objects .NET
Beans
Assemblies
Web Legacy
CORBA
Services COBOL
Objects
Programs
Web Services for Interoperability

If the components are published as Web services,
they can interoperate across different component
frameworks. (Interoperability through Wrapping)
Java Eiffel
DCOM
Bean .NET
Object
Assembly
Web Legacy
CORBA COBOL
Object Service
Program

Standards for Interoperability
Interoperable distributed systems are built using
standardized layers of increasingly higher abstraction levels.
It took 20 years to go from the TCP/IP (Internet, 1973) standard
to the HTTP/HTML (World Wide Web, 1992) standards.
By reusing HTTP, the time to standardize SOAP/XML was
halved (Web Services, 2000).
Layers
Standard
Standard API
Standard User SOAP
Network Interface
HTML XML
Protocol
HTTP
TCP/IP
Ethernet POTS Wireless
Web Services Standards

“Standards are good because there are so many to choose from”
This also applies to Web services, where since 2000 hundreds of
standards, standard proposals, specifications, revisions and
drafts have appeared, disappeared and more will continue to
appear.
Without standards in place, interoperability would not exist.
It takes time for a standard to reach widespread acceptance
throughout the industry. A specification that begins with “WS”
does not necessarily guarantee that interoperable tools exist.
Main standard bodies relevant to Web services:
W3C (World Wide Web Consortium)
OASIS (Organization for the Advancement of Structured
Information Standards)
WS-I (Web Services Interoperability Organization)
GGF (Global Grid Forum)

Standardization Process
There is a fundamental Standard
tension between:
standardization of
implementations
(de-facto standards)
and standardization of
specifications (de-jure Products
standards) that still Customers prefer standards
have to be proven because of the “warm fuzzy
by a working feeling” that they avoid to
implementation. lock-in a specific vendor’s
Web services vendors platform and tools.
agree on standards and This is true, as long as
compete on the quality of customers do not rely on
the products proprietary non-standard
implementing them. extensions.
WS Standards and Specifications

Transport HTTP, IIOP, SMTP, JMS
Messaging XML, SOAP WS-Addressing
Description XML Schema, WSDL WS-Policy, SSDL
Discovery UDDI WS-MetadataExchange
Choreography WSCL WSCI WS-Coordination
Business Processes WS-BPEL BPML WSCDL
Stateful Resources WS-Resource Framework
Transactions WS-CAF WS-Atomic Transactions
WS-Business Activities
Reliable Messaging WS-Reliability WS-ReliableMessaging
WS-Security WS-Trust, WS-Privacy
Security
SAML, XACML WS-SecureConversation
Event Notification WS-Notification WS-Eventing
Management WSDM WS-Management
Data Access OGSA-DAI SDO
Web Services standards and tools address some of the limitations
of traditional middleware platforms:
Non-standard interfaces.
Traditional middleware systems and tools suffer from lack of
standardization: they are not compatible. Thus, it is very
expensive to build integrated distributed systems across
different middleware platforms.
Lack of trust.
Building integrated systems spawning across different trust
domains can be difficult.
With Web Services the internal “API” of a company is exposed to
the Internet. How to trust the clients?
Middleware systems are (logically) centralized.
There is no place for them in B2B Integration scenarios as they
should be distributed across all partners. Point to Point
integration does not scale.
RPC vs. Messaging
Interactions across organizational boundaries may be slow and
should be handled asynchronously.
Company A | A direct connection between different
organizations is not allowed (security
breach) and sometimes not possible
(incompatible middleware)
middleware
Company B
Company C
Middleware

Company A | Conceptually, it could be possible to use a
global middleware. However, in practice,
there is no “place” for it.
middleware
Global
Middleware
Company B
Company C
Middleware
Company A | Point to Point solutions are expensive and
do not scale well with the number of
systems to be integrated
middleware
Company B
Company C
Middleware

Web Services for integration
Company A | Publishing the systems to be integrated
as Web Services simplifies the integration
and keeps the companies decoupled
middleware WS We
bS
e rv
ices
pro Company B
toc
ols
Web Services
Wrapper
Company C
Middleware
Web Services and Middleware

Web Services can be seen as the natural evolution of existing
Middleware systems:
Web Services standards enable the interoperability of
existing Middleware platforms and tools
Enterprise Application Integration made easier by using
Web Services
Business to Business integration enabled by common
interface standards
(“Unlike CORBA protocols, SOAP goes through firewalls”)
SOAP-based Middleware SOAP across the Internet
WS Wrapper WS Wrapper WS Interface WS Interface
Legacy Legacy Business Business

Application Application A B

Web Services
The term Web services has This definition emphasizes different
become nowadays very popular aspects:
and it is not always used with the In order to be accessible, a service
should be defined, described and
same meaning. discovered.
At one extreme, a Web service is XML is the foundation for all
any application which is standards that are going to be used
accessible through the WWW (SOAP, WSDL, UDDI)
Web services are components that
More precisely, a Web service is a can be readily integrated into more
software application identified by complex distributed applications.
a URI, whose interfaces and Web services are meant for
bindings are capable of being software based consumption
defined, described and discovered (while Web-based applications are
meant to be used by humans
as XML artifacts. A Web service equipped with a WWW browser)
supports direct interactions with
other software
agents using
XML-based messages
exchanged via
the Internet (W3C)

A popular interpretation of Web
services is based on IBM’s Web
service architecture based on
three elements:
1. Service requester: The potential
user of a service (the client)
2. Service provider: The entity that
implements the service and offers
to carry it out on behalf of the
requester (the server)
3. Service registry: A place where
available services are listed and
that allows providers to advertise
their services and requesters to
lookup and query for services
The goal is just-in-time
integration of applications by
discovering and orchestrating
network-available services
Main Web Services Standards

The Web service architecture
proposed by IBM is based on
two key concepts: UDDI
architecture of existing
synchronous middleware
platforms
current specifications of
SOAP, UDDI and WSDL
The architecture has a
remarkable client/server flavor
It reflects only what can be SOAP
done with
SOAP (Simple Object
Access Protocol)
UDDI (Universal
Description and Discovery
Protocol)
WSDL (Web Services WSDL
Description Language)
The Service Bus
The service bus can be seen a refactoring of the basic Web
service architecture, where a higher degree of loose coupling
has been added. This looks very similar to a message broker.
Service Bus
The Enterprise Service Bus

IBM Systems Journal, 44(4), 2005

Benefits of Web services
The Web services architecture First implementations are just
represented by SOAP, UDDI, and extensions of existing platforms
WSDL is a direct descendant of to accept invocations through a
conventional middleware Web service interface (e.g.,
platforms. They can be seen as database stored procedure
the most basic extensions that published as Web services)
are necessary to allow One important difference with
conventional synchronous conventional middleware is
(RPC=based) middleware to related to the standardization
achieve interoperability. efforts at the W3C that should
The model and even the notation guarantee:
followed in this architecture Platform independence
mimics to a very large extent (Hardware, OS)
what has been done in RPC, TP- Programming language
Monitors, CORBA, etc. neutrality
This dependency gives a very Portability across
good hint of what can be done Vendor/Middleware tools
with these technologies today
and what is missing to obtain a What is the price to pay?
complete platform for business to Currently Web services standards
business electronic commerce are still rapidly evolving and the
performance of some of the
available tools and protocols is
©IKS, ETH Zürich. quite poor. 27
SOAP
Remote calls in RPC/DCE
Remote calls in CORBA

Identifying Service
Client
and locating (sever)
services
Client stub Interface Implementation Skeleton

CORBA repository repository Object
runtime adapter
ORB ORB
MIDDLEWARE Marshalling MIDDLEWARE
and serializing
arguments
TCP/IP TCP/IP
socket socket
Local Area Network

Remote calls in DCOM
Identifying Service
Client
and locating (sever)
services
Client proxy Server stub

COM Registry Registry COM
runtime runtime
SCM SCM
MIDDLEWARE Marshalling MIDDLEWARE
and serializing
arguments
DCE DCE
RPC RPC
SCM = Service Control

Manager Local Area Network
Wire-protocols, XML and SOAP

RPC, CORBA, DCOM, even Java, use To address this problem, XML was used
different mechanisms and protocols to define SOAP (Simple Object Access
for communicating. All of them map Protocol)
to TCP or UDP one way or another but SOAP is conceptually quite simple:
use different syntax for marshalling,
serializing and packaging messages RPC using HTTP
The problem is that these (at the client) turn an RPC call
mechanisms are a legacy from the into an XML document
time when communications were (at the server) turn the XML
mostly within LANs and within document into a procedure call
homogeneous systems
(at the server) turn the
Building a B2B environment
combining the systems of different
procedure’s response into an
companies becomes difficult because XML document
the protocols available in RPC, CORBA, (at the client) turn the XML
or DCOM are too low level and document into the response to
certainly not compatible among each the RPC
other (gateways are needed, etc.)
use XML to serialize the
arguments following the SOAP
specification

SOAP as an RPC wrapper
SOAP has been conceived as a way of
SOAP Envelope wrapping different protocols into an XML
document sent using HTTP (or other
SOAP header
mechanisms)
The structure of a SOAP message is very
Header Block simple: it contains headers and body. The
header and the body can be divided into
SOAP Body blocks so that the information sent in them
can be structured.
SOAP as a communication protocol is also
Body Block extremely simple: it only has two types of
interaction (request response or
notification). It also allows for client
initiated or server initiated exchanges
(mechanism is identical, the only difference
is who starts)
SOAP as RPC mechanism

CLIENT stubs, SOAP system Wrap doc HTTP
runtime in HTTP support
call service Serialized POST (web
location XML doc request client)
This could be
INTERNET
RPC, CORBA,
DCOM, using SOAP
as protocol
SERVER SOAP system Retrieve HTTP

stubs,
runtime doc from support
service Serialized HTTP (web
adapters XML doc response server)

What is SOAP?
The W3C started working on A set of rules that must be followed
SOAP in 1999. The current W3C when processing a SOAP message
recommendation is Version 1.2 and a simple classification of the
SOAP covers the following four entities involved in processing a
main areas: SOAP message. It also specifies what
A message format for one- parts of the messages should be read
way communication by whom and how to react in case
describing how a message the content is not understood
can be packed into an XML A set of conventions on how to turn
document an RPC call into a SOAP message and
A description of how a SOAP back as well as how to implement
message (or the XML the RPC style of interaction (how the
document that makes up a client makes an RPC call, this is
SOAP message) should be translated into a SOAP message,
transported using HTTP (for forwarded, turned into an RPC call at
Web based interaction) or the server, the reply of the server
SMTP(for e-mail based converted into a SOAP message, sent
interaction) to the client, and passed on to the
client as the return of the RPC call)
The background for SOAP

SOAP was originally conceived as the minimal possible infrastructure
necessary to perform RPC through the Internet:
use of XML as intermediate representation between systems
very simple message structure
mapping to HTTP for tunneling through firewalls and using the Web
infrastructure
The idea was to avoid the problems associated with CORBA’s IIOP/GIOP
(which fulfilled a similar role but using a non-standard intermediate
representation and had to be tunneled through HTTP anyway)
The goal was to have an extension that could be easily plugged on top of
existing middleware platforms to allow them to interact through the
Internet rather than through a LAN as in the original case. Hence the
emphasis on RPC from the very beginning (essentially all forms of
middleware use RPC at one level or another)
Eventually SOAP started to be presented as a generic vehicle for computer
driven message exchanges through the Internet and then it was open to
support interactions other than RPC and protocols other then HTTP. This
process, however, is only in its very early stages.

Structure of a SOAP Message
SOAP Messages
SOAP is based on message
exchanges SOAP Envelope
Messages are structured with an SOAP header
envelope where the application
encloses the data to be sent
A message has two main parts: Header Block
header: which can be divided
into blocks SOAP Body
body: which can also be
divided into blocks
SOAP does not say what to do Body Block
with the header and the body, it
only states that the header is
optional and the body is
mandatory
Use of header and body, however,
is implicit. The body is for
application level data. The header
is for infrastructure level data
For the XML fans (SOAP, body only)
XML name space identifier for SOAP serialization
XML name space identifier for SOAP envelope
<SOAP-ENV:Envelope
xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/"
SOAP-ENV:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/">
<SOAP-ENV:Body>
<m:GetLastTradePrice xmlns:m="Some-URI">
<symbol>DIS</symbol>
</m:GetLastTradePrice>
</SOAP-ENV:Body>
</SOAP-ENV:Envelope>
From the: Simple Object Access Protocol (SOAP) 1.1. ©W3C Note 08 May 2000
SOAP example, header and body

From the: Simple Object Access Protocol (SOAP) 1.1. © W3C Note 08 May 2000
<SOAP-ENV:Envelope
xmlns:SOAP-ENV=
"http://schemas.xmlsoap.org/soap/envelope/"
SOAP-ENV:encodingStyle=
"http://schemas.xmlsoap.org/soap/encoding/"/>
<SOAP-ENV:Header>
<t:Transaction
xmlns:t="some-URI"
SOAP-ENV:mustUnderstand="1">
5
</t:Transaction>
</SOAP-ENV:Header>
<SOAP-ENV:Body>
<symbol>DEF</symbol>
</SOAP-ENV:Body>

The SOAP header
The header is intended as a generic place holder for information that is
not necessarily application dependent (the application may not even
be aware that a header was attached to the message).
Typical uses of the header are: coordination information, identifiers
(e.g., for transactions), security information (e.g., certificates)
SOAP provides mechanisms to specify who should deal with headers
and what to do with them. For this purpose it includes:
SOAP actor attribute: who should process that particular header
entry (or header block). The actor can be either: none, next,
ultimateReceiver. None is used to propagate information that does
not need to be processed. Next indicates that a node receiving the
message can process that block. ultimateReceiver indicates the
header is intended for the final recipient of the message
mustUnderstand attribute: with values 1 or 0, indicating whether it
is mandatory to process the header. If a node can process the
message (as indicated by the actor attribute), the mustUnderstand
attribute determines whether it is mandatory to do so.
SOAP 1.2 adds a relay attribute (forward header if not processed)
Example: SOAP Headers for Security

RPC Request
SOAP Envelope
SOAP header
RPC Response (one of the two)
Security context
Message SOAP Envelope SOAP Envelope
Signature
SOAP header SOAP header
Security context Security context
SOAP Body Message Message
Signature Signature
Name of Procedure
Input param 1 SOAP Body SOAP Body
Return parameter Fault entry

Input param 2

The SOAP body
The body is intended for the application specific data contained in the
message
A body entry (or a body block) is syntactically equivalent to a header
entry with attributes actor= ultimateReceiver and mustUnderstand = 1
Unlike for headers, SOAP does specify the contents of some body
entries:
mapping of RPC to a collection of SOAP body entries
the Fault entry (for reporting errors in processing a SOAP message)
The fault entry has four elements (in 1.1):
fault code: indicating the class of error (version, mustUnderstand,
client, server)
fault string: human readable explanation of the fault (not intended
for automated processing)
fault actor: who originated the fault
detail: application specific information about the nature of the
fault
SOAP Fault element (v 1.2)

In version 1.2, the fault element is specified in more detail. It must
contain two mandatory sub-elements:
Code: containing a value (the code for the fault) and possibly a
subcode (for application specific information)
Reason: same as fault string in 1.1
and may contain a few additional elements:
detail: as in 1.1
node: the identification of the node producing the fault (if absent,
it defaults to the intended recipient of the message)
role: the role played by the node that generated the fault
Errors in understanding a mandatory header are responded using a
fault element but also include a special header indicating which one o f
the original headers was not understood.

Message Processing Model
SOAP specifies in detail how messages must be processed (in
particular, how header entries must be processed)
Each SOAP node along the message path looks at the role
associated with each part of the message
There are three standard roles: none, next, or ultimateReceiver
Applications can define their own roles and use them in the
message
The role determines who is responsible for each part of a message
If a block does not have a role associated to it, it defaults to
ultimateReceiver
If a mustUnderstand flag is included, a node that matches the role
specified must process that part of the message, otherwise it must
generate a fault and do not forward the message any further
SOAP 1.2 includes a relay attribute. If present, a node that does not
process that part of the message must forward it (i.e., it cannot remove
the part)
The use of the relay attribute, combined with the role next, is useful for
establishing persistence information along the message path (like
session information)
Mapping SOAP to a transport protocol

SOAP and HTTP
A binding of SOAP to a transport
protocol is a description of how a
SOAP message is to be sent using HTTP POST
that transport protocol SOAP
SOAP Envelope
Envelope
SOAP header
The typical binding for SOAP is HTTP
Transactional
SOAP can use GET or POST. With context
GET, the request is not a SOAP

SOAP Body
message but the response is a SOAP Name of Procedure
message, with POST both request
Input parameter 1
and response are SOAP messages
Input parameter 2
(in version 1.2, version 1.1 mainly
considers the use of POST).
SOAP uses the same error and
status codes as those used in HTTP
so that HTTP responses can be
directly interpreted by a SOAP
module
In XML (a request)
POST /StockQuote HTTP/1.1
Host: www.stockquoteserver.com
Content-Type: text/xml; charset="utf-8"

Content-Length: nnnn
SOAPAction: "GetLastTradePrice"
<SOAP-ENV:Envelope
xmlns:SOAP-ENV=
"http://schemas.xmlsoap.org/soap/encoding/">
<SOAP-ENV:Body>
<symbol>DIS</symbol>
</SOAP-ENV:Body>

In XML (the response)
HTTP/1.1 200 OK
Content-Type: text/xml; charset="utf-8"
Content-Length: nnnn
<SOAP-ENV:Envelope
xmlns:SOAP-ENV=
"http://schemas.xmlsoap.org/soap/encoding/"/>
<SOAP-ENV:Body>
<m:GetLastTradePriceResponse xmlns:m="Some-URI">
<Price>34.5</Price>
</m:GetLastTradePriceResponse>
</SOAP-ENV:Body>
HTTP POST
All together SOAP

SOAP Envelope
Envelope
SOAP header
Transactional
context
SOAP Body
Name of Procedure
Input parameter 1
SERVICE REQUESTER SERVICE PROVIDER
Input parameter 2
Procedure
RPC call
HTTP engine
HTTP engine
SOAP SOAP
engine engine
HTTP Acknowledgement
SOAP
SOAP Envelope
Envelope
SOAP header
Transactional
context
SOAP Body
Return parameter

SOAP Summary
SOAP, in its current form, provides SOAP takes advantage of the
a basic mechanism for: standardization of XML to
encapsulating messages into resolve problems of data
an XML document representation and serialization
mapping the XML document (it uses XML Schema to
with the SOAP message into represent data and data
an HTTP request structures, and it also relies on
XML for serializing the data for
transforming RPC calls into transmission). As XML becomes
SOAP messages more powerful and additional
simple rules on how to standards around XML appear,
process a SOAP message SOAP can take advantage of
(rules became more precise them by simply indicating what
and comprehensive in v1.2 of schema and encoding is used as
the specification) part of the SOAP message.
SOAP is a very simple protocol Current schema and encoding
intended for transferring data are generic but soon there will
from one middleware platform to be vertical standards
another. In spite of its claims to implementing schemas and
be open (which are true), current encoding tailored to a particular
specifications and are very tied to application area (e.g., the efforts
RPC and HTTP. around EDI)

SOAP - Intro 2 Webservices

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

SOAP - Intro 2 Webservices

Uploaded by

Copyright:

Available Formats

Lecture 5

Introduction to Web Services

Contents – Lecture 5 - SOAP

 Mapping SOAP to a transport protocol

©IKS, ETH Zürich. 2

Web Services in Context

©IKS, ETH Zürich. 4

©IKS, ETH Zürich. 5

Web HTML Web

Web Browser WS Client

Back-end Systems and Databases

Components vs. Services

©IKS, ETH Zürich. 9

Web Services for Interoperability

©IKS, ETH Zürich. 10

©IKS, ETH Zürich. 11

Web Services Standards

©IKS, ETH Zürich. 12

WS Standards and Specifications

©IKS, ETH Zürich. 16

©IKS, ETH Zürich. 17

©IKS, ETH Zürich. 18

©IKS, ETH Zürich. 19

Web Services and Middleware

SOAP-based Middleware SOAP across the Internet

WS Wrapper WS Wrapper WS Interface WS Interface

Legacy Legacy Business Business

©IKS, ETH Zürich. 20

©IKS, ETH Zürich. 22

©IKS, ETH Zürich. 23

Main Web Services Standards

©IKS, ETH Zürich. 25

The Enterprise Service Bus

©IKS, ETH Zürich. 26

©IKS, ETH Zürich. 29

Remote calls in CORBA

Client stub Interface Implementation Skeleton

Local Area Network

Client proxy Server stub

SCM = Service Control

Wire-protocols, XML and SOAP

©IKS, ETH Zürich. 32

©IKS, ETH Zürich. 33

SOAP as RPC mechanism

SERVER SOAP system Retrieve HTTP

©IKS, ETH Zürich. 34

©IKS, ETH Zürich. 35

The background for SOAP

©IKS, ETH Zürich. 36

©IKS, ETH Zürich. 39

SOAP example, header and body

©IKS, ETH Zürich. 40

Example: SOAP Headers for Security

Input param 1 SOAP Body SOAP Body

Return parameter Fault entry

©IKS, ETH Zürich. 42

©IKS, ETH Zürich. 43

SOAP Fault element (v 1.2)

©IKS, ETH Zürich. 44

©IKS, ETH Zürich. 45

Mapping SOAP to a transport protocol

GET, the request is not a SOAP

©IKS, ETH Zürich. 47

Content-Type: text/xml; charset="utf-8"

Mapping SOAP to a transport protocol