WebServices - Faculty of Computer Science

abnormalobeisanceSecurity

Nov 3, 2013 (3 years and 7 months ago)

157 views

3

What are ‘Web Services’?

(Quotes from Alonso
et al.
)


‘A form of distributed information
system’
(p. 1)


‘“
a software application identified by a URI,
whose interfaces and bindings are capable of
being discovered as XML artifacts. A Web
service supports direct interactions with other
software agents using XML
-
based messages
exchanged via Internet
-
based protocols
”’
(p.124,
quoting Web Service Architecture Requirements document (Oct. 2002) at W3C)

4

Web Services & Middleware

(Quote from Alonso
et al.
)



In middleware terms, a service is a procedure,
method, or object with a stable, published interface
that can be invoked by clients.


The invocation,
and this is very important
, is made by
a program. Thus, requesting and executing a service
involves a program calling another program.

(p.131, their
emphasis)

©Gustavo Alonso, ETH Zürich.

Web services: Concepts, Architectures and Applications
5

Objectives for this topic

Understanding Web services


In order to understand Web services,
we need to take a step back and look
at the way middleware and
enterprise application integration
technology has been evolving in the
last decades. Only so we will then
be able to understand Web services.



The most popular version of Web
services (SOAP, UDDI, and WSDL)
is a very poor and limiting view on
what true Web services should be.
Alternative proposals such as
ebXML, xCBL, or RosettaNet
provide a much deeper insight on
what is needed for electronic
commerce through Web services.

Putting Web services into perspective


We will go over the basic Web
service technology available today
and discuss SOAP, UDDI and
WSDL in detail.


We will also discuss what can be
done with these specifications and
what is missing nowadays for them
to be truly useful tools for electronic
commerce.


The course aims at developing a
critical understanding of Web
technology and its possibilities
today. The goal is for participants to
be able to look at current and future
developments with enough
background to be able to judge how
much of a contribution they are and
what their true potential is.

Modified from original

©Gustavo Alonso, ETH Zürich.

Web services: Concepts, Architectures and Applications
6

Sub
-
topics


Layers and Tiers


Why Middleware & Why not client/server


The Service World


Motivation for changes to middleware model


Bottom
-
up & Top
-
down thinking


Messages, Documents, and Processes


Asynchronous coordination


The WWW Protocols That make it all happen


SOAP (
S
imple

o
bject
a
ccess
p
rotocol)


UDDI (
U
niversal
d
iscovery
d
escription &

i
ntegration)


WSDL (
W
eb
s
ervices
d
escription
l
anguage)

©Gustavo Alonso, ETH Zürich.

Web services: Concepts, Architectures and Applications
7

Layers and tiers



Client

is any user or program that wants
to perform an operation over the system.
Clients interact with the system through
a
presentation layer




The
application logic

determines what
the system actually does. It takes care of
enforcing the business rules and
establish the business processes. The
application logic can take many forms:
programs, constraints, business
processes, etc.



The
resource manager

deals with the
organization (storage, indexing, and
retrieval) of the data necessary to
support the application logic. This is
typically a database but it can also be a
text retrieval system or any other data
management system providing querying
capabilities and persistence.

Client

Application Logic

Resource Manager

Presentation layer

Business rules

Business objects

Client

Server

Database

Client

Business processes

Persistent storage

©Gustavo Alonso, ETH Zürich.

Web services: Concepts, Architectures and Applications
8

A game of boxes and arrows


Each box represents a part of the system.


Each arrow represents a connection
between two parts of the system.


The more boxes, the more modular the
system: more opportunities for
distribution and parallelism. This allows
encapsulation, component based design,
reuse.


The more boxes, the more arrows: more
sessions (connections) need to be
maintained, more coordination is
necessary. The system becomes more
complex to monitor and manage.


The more boxes, the greater the number
of context switches and intermediate
steps to go through before one gets to
the data. Performance suffers
considerably.


System designers try to balance the
flexibility of modular design with the
performance demands of real
applications. Once a layer is established,
it tends to migrate down and merge with
lower layers.

There is no problem in system
design that cannot be solved by
adding a level of indirection.

There is no performance
problem that cannot be
lessened by removing a level of
indirection.

Modified from original

©Gustavo Alonso, ETH Zürich.

Web services: Concepts, Architectures and Applications
9

One tier: fully centralized


The presentation layer, application
logic and resource manager are built
as a monolithic entity.


Users/programs access the system
through display terminals but what
is displayed and how it appears is
controlled by the server. (These are
“dumb” terminals).


This was the typical architecture of
mainframes, offering several
advantages:


no forced context switches in
the control flow (everything
happens within the system),


all is centralized, managing and
controlling resources is easier,


the design can be highly
optimized by blurring the
separation between layers.

1
-
tier architecture

Server

©Gustavo Alonso, ETH Zürich.

Web services: Concepts, Architectures and Applications
10

Two tier: client/server


As computers became more powerful, it
was possible to move the presentation
layer to the client. This has several
advantages:


Clients are independent of each
other: one could have several
presentation layers depending on
what each client wants to do.


One can take advantage of the
computing power at the client
machine to have more sophisticated
presentation layers. This also saves
computer resources at the server
machine.


It introduces the concept of API
(Application Program Interface).
An interface to invoke the system
from the outside. It also allows
designers to think about federating
the systems into a single system.


The resource manager only sees one
client: the application logic. This
greatly helps with performance
since there are no client
connections/sessions to maintain.

2
-
tier architecture

Server

©Gustavo Alonso, ETH Zürich.

Web services: Concepts, Architectures and Applications
11

API in client/server


Client/server systems introduced the notion of service (the client invokes a service
implemented by the server)


Together with the notion of service, client/server introduced the notion of service
interface (how the client can invoke a given service)


Taken all together, the interfaces to all the services provided by a server (whether there
are application or system specific) define the server’s Application Program Interface
(API) that describes how to interact with the server from the outside


Many standardization efforts were triggered by the need to agree to common APIs for
each type of server

resource management
layer

service

interface

service

interface

service

interface

service

interface

server’s API

service

service

service

service

©Gustavo Alonso, ETH Zürich.

Web services: Concepts, Architectures and Applications
12

Technical aspects of the 2 tier architecture


There are clear technical advantages when going from one tier to two tier
architectures:


take advantage of client capacity to off
-
load work to the clients


work within the server takes place within one scope (almost as in 1 tier),


the server design is still tightly coupled and can be optimized by ignoring
presentation issues


still relatively easy to manage and control from a software engineering point
of view



However, two tier systems have disadvantages:


The server has to deal with all possible client connections. The maximum
number of clients is given by the number of connections supported by the
server.


Clients are “tied” to the system since there is no standard presentation layer.
If one wants to connect to two systems, then the client needs two
presentation layers.


There is no failure or load encapsulation. If the server fails, nobody can
work. Similarly, the load created by a client will directly affect the work of
others since they are all competing for the same resources.

©Gustavo Alonso, ETH Zürich.

Web services: Concepts, Architectures and Applications
13

The main limitation of client/server


The responsibility of dealing
with heterogeneous systems is
shifted to the client.


The client becomes responsible
for knowing where things are,
how to get to them, and how to
ensure consistency


This is tremendously inefficient
from all points of view (software
design, portability, code reuse,
performance since the client
capacity is limited, etc.).


There is very little that can be done
to solve this problems if staying
within the 2 tier model.

Server A

Server B


If clients want to access two or more
servers, a 2
-
tier architecture causes
several problems:


the underlying systems don’t
know about each other


there is no common business
logic


the client is the point of
integration (increasingly fat
clients)

©Gustavo Alonso, ETH Zürich.

Web services: Concepts, Architectures and Applications
14

Three tier: middleware


In a 3 tier system, the three layers
are fully separated.


The layers are also typically
distributed taking advantage of the
complete modularity of the design
(in two tier systems, the server is
typically centralized)


A middleware based system is a 3
tier architecture. This is a bit
oversimplified but conceptually
correct since the underlying systems
can be treated as black boxes. In
fact, 3 tier makes only sense in the
context of middleware systems
(otherwise the client has the same
problems as in a 2 tier system).

3
-
tier architecture

©Gustavo Alonso, ETH Zürich.

Web services: Concepts, Architectures and Applications
15

Middleware


Middleware is just a level of
indirection between clients and other
layers of the system.


It introduces an additional layer of
business logic encompassing all
underlying systems.


By doing this, a middleware system:


simplifies the design of the
clients by reducing the number
of interfaces,


provides transparent access to
the underlying systems,


acts as the platform for inter
-
system functionality and high
level application logic, and


takes care of locating resources,
accessing them, and gathering
results.


But a middleware system is just a
system like any other! It can also be
1 tier, 2 tier, 3 tier ...

Middleware or
global application logic

clients

Local resource
managers

Local application logic

Server A

Server B

middleware

©Gustavo Alonso, ETH Zürich.

Web services: Concepts, Architectures and Applications
16

Technical aspects of middleware


The introduction of a middleware layer helps in that:


the number of necessary interfaces is greatly reduced:


clients see only one system (the middleware),


local applications see only one system (the middleware),


it centralizes control (middleware systems themselves are usually 2 tier),


it makes necessary functionality widely available to all clients,


it allows to implement functionality that otherwise would be very difficult to
provide, and


it is a first step towards dealing with application heterogeneity (some forms
of it).


The middleware layer does not help in that:


it is another indirection level,


it is complex software,


it is a development platform, not a complete system

©Gustavo Alonso, ETH Zürich.

Web services: Concepts, Architectures and Applications
17

A three tier middleware based system ...

External clients

connecting logic

control

user
logic

internal
clients

2 tier systems

Resource
managers

wrappers

middleware

Resource
manager

2 tier system

middleware system

External client

©Gustavo Alonso, ETH Zürich.

Web services: Concepts, Architectures and Applications
18

N
-
tier: connecting to the Web


N
-
tier architectures result from
connecting several three tier
systems to each other and/or by
adding an additional layer to
allow clients to access the system
through a Web server


The Web layer was initially
external to the system (a true
additional layer); today, it is
slowly being incorporated into a
presentation layer that resides on
the server side (part of the
middleware infrastructure in a
three tier system, or part of the
server directly in a two tier
system)


The addition of the Web layer led
to the notion of “application
servers”, which was used to refer
to middleware platforms
supporting access through the
Web

client



resource management
layer

application logic

layer

middleware

presentation

layer

Web server

Web browser

HTML filter

©Gustavo Alonso, ETH Zürich.

Web services: Concepts, Architectures and Applications
19

INTERNET

FIREWALL

LAN

Web

server

cluster

LAN,

gateways

LAN

internal

clients

LAN

middleware

application

logic

resource

management

layer

database

server

LAN

middleware

application

logic

additional resource

management layers

LAN

Wrappers

and

gateways

file

server

application

N
-
tier systems in reality

©Gustavo Alonso, ETH Zürich.

Web services: Concepts, Architectures and Applications
20

The service world


The WWW suddenly opened up
software systems that had remained
hidden within the IT organization of
a company


The nature of the interaction did not
change. Behind the WWW there is
the same client/server model as in
basic RPC. However, the WWW
made everything much easier,
cheaper and efficient


integration at the level of user
interface became possible


services could be accessed from
anywhere in the world


the clients could now be not just
an internal or selected user but
anybody with a browser

Branch

1

Branch 2

wrappers

Front end

user

program

user

program

user

program

user

program

MIDDLEWARE

WEB SERVER

Browser

©Gustavo Alonso, ETH Zürich.

Web services: Concepts, Architectures and Applications
21

Remote clients

user defined
application logic

database

resource manager

client

database management
system

stored

procedure

API

client

embedded

SQL

user defined
application logic

database

resource manager

API

WEB SERVER

FIREWALL

client

browser

XML

©Gustavo Alonso, ETH Zürich.

Web services: Concepts, Architectures and Applications
22

Business to Business (B2B)

Resource 1

Resource 2

wrappers

Front end

user

program

user

program

user

program

user

program

MIDDLEWARE

WEB SERVER

FIREWALL

Resource X

Resource Y

wrappers

Front end

user

program

user

program

user

program

user

program

MIDDLEWARE

WEB SERVER

FIREWALL

INTERNET

©Gustavo Alonso, ETH Zürich.

Web services: Concepts, Architectures and Applications
23

Two competing views of Web services


bottom up: application integration


top down: business exchanges

©Gustavo Alonso, ETH Zürich.

Web services: Concepts, Architectures and Applications
24

WS architecture: application integration


A popular interpretation of Web
services is based on IBM’s
Web
service architecture

based on three
elements:


Service requester: The potential user
of a service


Service provider: The entity that
implements the service and offers to
carry it out on behalf of the
requester


Service registry: A place where
available services are listed and
which allows providers to advertise
their services and requesters to
query for services


The goal is
just
-
in
-
time integration
of applications by discovering and
orchestrating network
-
available
services

©Gustavo Alonso, ETH Zürich.

Web services: Concepts, Architectures and Applications
25

How is it ‘bottom up’?


The Web service architecture
proposed by IBM is based on two
key concepts:


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 done
with


SOAP (Simple Object Access
Protocol)


UDDI (Universal Description
and Discovery Protocol)


WSDL (Web Services
Description Language)

UDDI

SOAP

WSDL

©Gustavo Alonso, ETH Zürich.

Web services: Concepts, Architectures and Applications
26

ebXML architecture

ebXML
compliant
system
Business Profiles
Business Scenarios
ebXML
Registry
XML
Request Business Details
1
Build Local System
Implementation
Register Implementation Details
Register COMPANY A Profile
3
2
5
Agree on Business Arrangement
4
Query about COMPANY A profile
Download
Scenarios and Profiles
DO BUSINESS TRANSACTIONS
6
COMPANY A
COMPANY B
ebXML
compliant
system
Business Profiles
Business Scenarios
ebXML
Registry
XML
Request Business Details
1
Build Local System
Implementation
Register Implementation Details
Register COMPANY A Profile
3
2
5
Agree on Business Arrangement
4
Query about COMPANY A profile
Download
Scenarios and Profiles
DO BUSINESS TRANSACTIONS
6
COMPANY A
COMPANY B
ebXML
compliant
system
Business Profiles
Business Scenarios
ebXML
Registry
XML
Request Business Details
1
Build Local System
Implementation
Register Implementation Details
Register COMPANY A Profile
3
2
5
Agree on Business Arrangement
4
Query about COMPANY A profile
Download
Scenarios and Profiles
DO BUSINESS TRANSACTIONS
6
COMPANY A
COMPANY B
©Gustavo Alonso, ETH Zürich.

Web services: Concepts, Architectures and Applications
28

How is ebXML ‘top down’?


The ebXML (electronic business XML) architecture tries to describe all
elements and steps of a commercial exchange, including the characteristics of
the technology that supports those exchanges. Its goals are an attempt at:


Providing a view for
integration of business processes

among ad
-
hoc or
established independent business partners by electronic means


Reducing the need for collaborative business partners to have
individual
and expensive prior agreement

on how to integrate business processes


Providing a high
-
level business
-
centric view of
distributed e
-
business
processes


Supporting and representing business processes
independent of the
technical solution


Providing and supporting a
library of common, standard intra
-
business
processes


Allowing for both
business processes and enabling technologies

to evolve
independently while retaining long
-
term investments in both


Integrating with new and legacy systems throughout the enterprise


Leveraging existing technologies and standards


2000 ebXML TM

©Gustavo Alonso, ETH Zürich.

Web services: Concepts, Architectures and Applications
29

Background for these views


The IBM’s Web service architecture
follows traditional middleware
architecture and it is very tied in
spirit to conventional middleware


It interprets electronic commerce as
an essentially synchronous activity
where a client requests services (in
the middleware sense) from a server.
If necessary, a name and directory
service infrastructure (the registry)
is available for matchmaking
between clients and servers in this
interpretation


This view of Web services focuses
on the low level mechanisms
necessary to implement Web
services. It does not say anything
about how these mechanisms map to
real business exchanges


The ebXML electronic business
architecture predates the efforts
around Web services. It sees
electronic commerce as an
asynchronous sequence of message
exchanges



ebXML has inherited many ideas
from the EDI (Electronic Data
Interchange) world as one of the
main supporters of ebXML is the
same organization that is in charge
of EDI. As such, its main interest is
standardizing business processes and
business operations



ebXML contains a much richer
vocabulary and deeper
understanding of business relations
that uses to establish what the low
level technology should do. As a
result, it is far more encompassing
than IBM’s Web service architecture

©Gustavo Alonso, ETH Zürich.

Web services: Concepts, Architectures and Applications
30

Extending information systems to
communicate through the Internet

©Gustavo Alonso, ETH Zürich.

Web services: Concepts, Architectures and Applications
31

The next step ...


The next step in that progression leads immediately to the notion of Web
services as considered in IBM’s Web service architecture.


The notion of service in the conventional middleware is now translated into
the notion of Web service based on the access channel to that service (the
service in fact can be a pre
-
existing middleware service, e.g., stored
procedures in databases made available as Web services)


The only thing that changes from the middleware and enterprise application
integration world is that a few details need to be changed so that they match
the needs of exchanges through the Internet rather than a LAN:


XML as the data representation format


SOAP as a protocol wrapper to allow conventional communication
protocols of middleware platforms to cross the Internet and firewalls
(essentially turns invocations into document exchanges)


WSDL as the XML version of IDLs (plus a few other things)


UDDI as the WWW version of basic name and directory services

Messages & Queues

33

request

response

invoking

execution thread

invoked

execution thread

blocking

period

Web Services:Concepts, Architectures and Applications
by Alonso
et al. ©2004 by Springer Verlag Berlin Heidelberg 2004

Ch.2, Fig 13,
§
3.2

Synchronous Execution

34

put

put

invoking

execution thread

invoked

execution thread

queue

fetch

fetch

queue

thread remains

active

Web Services:Concepts, Architectures and Applications
by Alonso
et al. ©2004 by Springer Verlag Berlin Heidelberg 2004

Ch.2, Fig 14,
§
3.3

Asynchronous Execution

©Gustavo Alonso, ETH Zürich.

Web services: Concepts, Architectures and Applications
35

The message world

©Gustavo Alonso, ETH Zürich.

Web services: Concepts, Architectures and Applications
36

©Gustavo Alonso, ETH Zürich.

Web services: Concepts, Architectures and Applications
37

Documents rather than methods


When exchanges occur as documents, the emphasis is no longer on the
mechanisms for sending and receiving documents (there are many to choose
from) but on the contents of the documents and how to interpret them.


The arrival of documents is not a function or a method call. It is not even a
service request as such but one element of a business process. Hence, in addition
to specifying the format for the documents and the semantics for the contents of
the documents, it is necessary to agree on what documents are needed to get
things done, i.e., the business process that defines the interaction between the
participants.


The basic document exchange standard is the Electronic Data Interchange
(EDI), a set of common data format standards developed in the late 1970s.


EDI is a collection of basic data elements (e.g., a price) that can be
combined to form composite data elements, which are then combined into
functionally related units called data segments (e.g., the complete
description of an item), and finally grouped into transaction sets (minimal
meaningful unit for document exchanges between companies, e.g., an
invoice or a purchase order)


Additional standards (EDIFACT, X12) describe how to use transaction sets
as part of concrete business processes.

©Gustavo Alonso, ETH Zürich.

Web services: Concepts, Architectures and Applications
38

Processes rather than service calls

“The xCBL 3.5 ChangeOrder document is a buyer
-
initiated document that can be used to

change an existing Order already received and responded to by a seller. The document

can be used to make changes to header level information, change line items, cancel line

items, add line items, etc. Note that if an OrderResponse has not been received for a

given Order, a ChangeOrder is not necessary (an Order with a purpose of “Replace”

should be used). Similarly, if an entire order is to be cancelled (regardless of whether a

response has been received or not) an Order with a purpose of “Cancellation” should be

used.”

xCBL 3.5
Order Management Recommended Use, Version 1.0 November

19, 2001

©Gustavo Alonso, ETH Zürich.

Web services: Concepts, Architectures and Applications
39

The next step ...


The next step for message based electronic commerce is to take advantage of the
Internet to improve electronic commerce: e.g., ebXML and the many attempts at
producing an XML version of EDI. Note, these efforts also include linking to
the standardization efforts around XML and Web services. However, the final
goal is still the standardization of business exchanges rather than the
standardization of the low level mechanisms used to implement those
exchanges.


With this interpretation, there is no client server flavor to the exchanges.
Business interactions occur between trading partners


Middleware architectures are not obvious in these proposals. One assumes
they are there to implement the business processes but they do not determine
the specification of the exchanges


There is much concern with the semantics of business exchanges than with
the syntax (unlike in the Web services architecture which is purely
syntactic)


Many concepts that are unknown in the Web service architecture play an
important role in these architectures: role of the participant, business
agreement, automatic enforcement of business agreements, conversations,
business protocols, integration of business processes, etc.

©Gustavo Alonso, ETH Zürich.

Web services: Concepts, Architectures and Applications
40

Advantages of queues in EAI


Queuing management systems
completely detach the two sides of
an interaction as there is no direct
call but a document exchange


This makes the development of both
sides of the interaction (e.g., client
and server) completely independent
and very flexible


The interaction can be defined in
terms of the document to exchange
rather than the interface to invoke.
This is a more natural approach in
the business world where
interactions tend to be document
based


From the scheduling point of view,
it is much easier to deal with
messages than with synchronous
invocations.


Technically, the infrastructure
necessary to deal with messages is
simpler than the infrastructure
necessary to deal with synchronous
calls. Especially if there are no fancy
features added to the queues.


Queues also have the advantage of
being easily adaptable to
communicate with external systems,
even systems outside the
organization (e.g., plug a queue to
an e
-
mail address)


When working with messages, the
effort in describing the interaction
goes into the description of the
message or document within the
message. This can be done without
knowledge of how the message will
be processed.

©Gustavo Alonso, ETH Zürich.

Web services: Concepts, Architectures and Applications
42

Message based interaction


Message based interaction has several advantages over synchronous systems,
particularly when the interaction involves different organizations and typical
business transactions (where the response might not be immediate).


Message based interaction has less of a client server flavor and more of an
exchange of information between partners, this affects not only the way the
interaction is implemented (as interconnected business processes) but also the
technology used for that purpose.


If the messages are standardized, then it is possible to create off
-
the
-
shelf
systems that can process such messages. This was the original goal of EDI but
the technology was not yet there. The Internet, XML, and the whole notion of
Web services will probably now help to make this goal a reality at a lower cost
and with less effort than was required before.


Message based interaction is behind many of the most comprehensive models
for electronic commerce (ebXML, xCBL, etc.) and will certainly have a decisive
influence on how SOAP, WSDL and UDDI will evolve in the future.


©Gustavo Alonso, ETH Zürich.

Web services: Concepts, Architectures and Applications
43

Queues in TP
-
Monitors


Any synchronous middleware introduces a
tight coupling between the caller and the
called. Name and directory services help to
minimize the effects of this coupling but
the tight connection between components
is nevertheless there.


It also creates considerable problems when
trying to implement certain properties or
manage the interaction between client and
servers (fault tolerance, availability, etc.)


The first systems to provide alternatives
were TP
-
Monitors which offered two
choices:


asynchronous RPC: client makes a
call that returns immediately; the
client is responsible for making a
second call to get the results


Reliable queuing systems (e.g.,
Encina, Tuxedo) where, instead of
using procedure calls, client and
server interact by exchanging
messages. Making the messages
persistent by storing them in queues
added considerable flexibility to the
system

client

service call


get results


server

service


return results


Client stub

RPC support

external
application

external
application

Input queue

Input

queue

Output

queue

Output queue

Reliable

queuing

system

©Gustavo Alonso, ETH Zürich.

Web services: Concepts, Architectures and Applications
46

Queuing systems


Queuing systems implement
asynchronous interactions.


Each element in the system
communicates with the rest via
persistent queues.
These queues store
messages transactionally,
guaranteeing that messages are there
even after failures occur.


Queuing systems offer significant
advantages over traditional solutions
in terms of fault tolerance and overall
system flexibility: applications do not
need to be there at the time a request
is made!


Queues provide a way to
communicate across heterogeneous
networks and systems while still being
able to make some assumptions about
the behavior of the messages.


They can be used when embedded
(workflow, TP
-
Monitors) or by
themselves (MQSeries, Tuxedo/Q).

external
application

client

Input queue

Input queue

Output queue

Output queue

Reliable queuing system

Monitoring

Administration

Persistent storage

Simple Object Access Protocol (SOAP)

©Gustavo Alonso, ETH Zürich.

Web services: Concepts, Architectures and Applications
50

What is SOAP?


The Simple Object Access Protocol (SOAP) was initiated by W3C in 1999.
SOAP 1.0 was entirely based on HTTP, and the following version, SOAP 1.1
(May 2000), was more generic since it included other transport protocols. The
first draft of SOAP 1.2 was presented in July 2001 and is now a
“Recommendation”.


SOAP covers the following four main areas:


A message format for one
-
way communication describing how a message
can be packed into an XML document


A description of how (the XML document that makes up) a SOAP message
should be transported through the Web (using HTTP) or e
-
mail (using
SMTP).


A set of rules that must be followed when processing a SOAP message and
a simple classification of the entities involved in that processing. It also
specifies what parts of the messages should be read by whom and how to
react in case the content is not understood


A set of conventions on how to turn an RPC call into a SOAP message and
back as well as how to implement the RPC style of interaction (how the
client side RPC call is translated into a SOAP message, forwarded, turned
into a server side RPC call, the reply converted into a SOAP message and
returned to the client)

©Gustavo Alonso, ETH Zürich.

Web services: Concepts, Architectures and Applications
51

The background of 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 used a non
-
standard intermediate
representation and had to be tunneled through HTTP anyway)


The goal was to have an extension that could be easily layered on top of existing
middleware platforms to allow them to interact through the Internet rather than
through a LAN, as is typically the 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 than HTTP. This process,
though, is still on
-
going.

©Gustavo Alonso, ETH Zürich.

Web services: Concepts, Architectures and Applications
52

Structure of a SOAP message

©Gustavo Alonso, ETH Zürich.

Web services: Concepts, Architectures and Applications
53

SOAP messages


SOAP is based on message exchanges


Messages are seen as envelopes where
the application encloses the data to be
sent


A message has two main parts; header
and body, which both can be divided
into blocks


SOAP does not specify what to do with
the header and the body, it only states
that the header is optional and the body
is mandatory


The use of header and body, however, is
implicit. The body is for application
level data. The header is for
infrastructure level data

SOAP Envelope
















SOAP

header





Header Block

SOAP

Body





Body Block

©Gustavo Alonso, ETH Zürich.

Web services: Concepts, Architectures and Applications
54

For the XML fans (SOAP, body only)

<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

XML name space identifier for SOAP envelope

XML name space identifier for SOAP serialization

©Gustavo Alonso, ETH Zürich.

Web services: Concepts, Architectures and Applications
55

SOAP example, header and body

<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="true">


5


</t:Transaction>


</SOAP
-
ENV:Header>



<SOAP
-
ENV:Body>


<m:
GetLastTradePrice

xmlns:m="Some
-
URI">


<symbol>
DEF
</symbol>


</m:
GetLastTradePrice
>


</SOAP
-
ENV:Body>

</SOAP
-
ENV:
Envelope
>

©Gustavo Alonso, ETH Zürich.

Web services: Concepts, Architectures and Applications
56

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 (for, e.g.,
transactions) and 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 role attribute (previously called “actor”): who should process that
particular header entry (or header block). The “role” 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 that the header
is intended for the final recipient of the message


mustUnderstand attribute: with values
true
/
false

(previously
1
/
0
),
indicating whether it is mandatory to process the header. If a node can
process the message (as indicated by the “role” attribute), the
mustUnderstand attribute determines whether it is mandatory to do so.


New in SOAP 1.2 is also the relay attribute (forward header if not
processed)

©Gustavo Alonso, ETH Zürich.

Web services: Concepts, Architectures and Applications
57

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 role = ultimateReceiver and mustUnderstand = true


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

©Gustavo Alonso, ETH Zürich.

Web services: Concepts, Architectures and Applications
58

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 of the fault) and possibly a sub
-
code (for
application specific information)


Reason: same as fault string in 1.1


This string can be provided in different languages:



<env:Text xml:lang="en
-
US">Header not understood</env:Text>



<env:Text xml:lang="fr">En
-
tête non compris</env:Text>


and may contain any of the following optional elements:


Node: the URI identifying 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


Detail: as in 1.1


Errors in understanding a mandatory header are responded using a fault element
but also include a special header indicating which one of the original headers
was not understood.


©Gustavo Alonso, ETH Zürich.

Web services: Concepts, Architectures and Applications
59

Message processing


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 3 standard roles: none, next or ultimateReceiver (as mentioned
above)


Applications can define their own message roles


The role determines who is responsible for each part of a message


If a block doesn’t have a role associated with it, it defaults to ultimateReceiver


If a mustUnderstand flag is included, a node that matches the specified role
must

process that part of the message, otherwise it
must

generate a fault and 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)

©Gustavo Alonso, ETH Zürich.

Web services: Concepts, Architectures and Applications
60

From TRPC to SOAP messages

SOAP Envelope



















SOAP

header





Transactional

context

SOAP

Body








Input param 1

Input param 2

Name of Procedure

RPC Request

SOAP Envelope















SOAP

header




SOAP

Body



Return parameter

Transactional

context

RPC Response (one of the two)

SOAP Envelope















SOAP

header




SOAP

Body



Fault entry

Transactional

context

©Gustavo Alonso, ETH Zürich.

Web services: Concepts, Architectures and Applications
61

Mapping SOAP to a transport protocol

©Gustavo Alonso, ETH Zürich.

Web services: Concepts, Architectures and Applications
62

HTTP as a communication protocol


HTTP was designed for exchanging
documents. It is almost like e
-
mail
(in fact, it uses RFC 822 compliant
mail headers and MIME types)


Example of a simplified request
(from browser):


GET /docu2.html HTTP/1.0

Accept: www/source

Accept: text/html

Accept: image/gif

User
-
Agent: Lynx/2.2 libwww/2.14

From: eggs@spam.com


* a blank line *


Request methods: GET (retrieve
data), POST (append information),
PUT (send information), DELETE
(remove information), ...

File being requested

(docu2.html) and

version of the protocol used

List of MIME types

accepted by the browser

Information about the

environment where the

browser is running

E
-
mail or identifier

of the user

(provided by the browser)

End of request

©Gustavo Alonso, ETH Zürich.

Web services: Concepts, Architectures and Applications
63

HTTP server side


Example of a response from
the server (to the request by
the browser):


HTTP/1.0 200 OK

Date: Wednesday, 02
-
Feb
-
94 23:04:12
GMT

Server: NCSA/1.1

MIME
-
version: 1.0

Last
-
modified: Monday, 15
-
Nov
-
93
23:33:16 GMT

Content
-
type: text/html

Content
-
length: 2345


* a blank line *

<HTML><HEAD><TITLE> . . .
</TITLE> . . .etc.



The server is expected to
convert the data into a MIME
type specified in the request
(“Accept:” headers)

Protocol version, code indicating

request status (200=ok)

Date, server identification (type)

and format used in the request

MIME type of the document

being sent

Header for the document

(document length in bytes)

Document sent

©Gustavo Alonso, ETH Zürich.

Web services: Concepts, Architectures and Applications
64

Parameter passing


The introduction of forms for allowing
users to provide information to a web
server required the modification of HTML
(and HTTP), but it provided a more
advanced interface than just retrieving
files:


POST /cgi
-
bin/post
-
query HTTP/1.0

Accept: www/source

Accept: text/html

Accept: video/mpeg

Accept: image/jpeg

...

Accept: application/postscript

User
-
Agent: Lynx/2.2 libwww/2.14

From: mickey@mouse.com

Content
-
type: application/x
-
www
-
form
-
urlencoded

Content
-
length: 150



* a blank line *


&name = Gustavo

&email= alonso@inf.ethz.ch

...

POST request indicating the

CGI script to execute (post
-
query)

GET can be used, but requires the

parameters to be sent as part of the

URL:

As before

Data provided through the form

and sent back to the server

©Gustavo Alonso, ETH Zürich.

Web services: Concepts, Architectures and Applications
65

SOAP and HTTP


A binding of SOAP to a transport
protocol is a description of how a
SOAP message is to be sent using
that transport protocol


The typical binding for SOAP is
HTTP


SOAP can use GET or POST. With
GET, the request is not a SOAP
message but the response is a SOAP
message, with POST both request
and response are SOAP messages
(in v1.2, v1.1 mainly considers
using 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


SOAP Envelope














SOAP

header




Transactional

context

SOAP

Body







Input parameter 1

Input parameter 2

Name of Procedure

HTTP POST

©Gustavo Alonso, ETH Zürich.

Web services: Concepts, Architectures and Applications
66

In XML (a request)

POST /StockQuote HTTP/1.1


Host: www.stockquoteserver.com


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


Content
-
Length: nnnn


SOAPAction: "Some
-
URI"



<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>

©Gustavo Alonso, ETH Zürich.

Web services: Concepts, Architectures and Applications
67

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/envelope/"


SOAP
-
ENV:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"/>


<SOAP
-
ENV:Body>


<m:GetLastTradePriceResponse xmlns:m="Some
-
URI">


<Price>34.5</Price>


</m:GetLastTradePriceResponse>


</SOAP
-
ENV:Body>


</SOAP
-
ENV:Envelope>

©Gustavo Alonso, ETH Zürich.

Web services: Concepts, Architectures and Applications
68

SOAP Envelope














SOAP

header




Transactional

context

SOAP

Body







Input parameter 1

Input parameter 2

Name of Procedure

HTTP POST

SOAP Envelope











SOAP

header




Transactional

context

SOAP

Body




Return parameter

HTTP Acknowledgement

SERVICE REQUESTER

SERVICE PROVIDER

RPC call

HTTP engine

SOAP

engine

Procedure

HTTP engine

SOAP

engine

All together

©Gustavo Alonso, ETH Zürich.

Web services: Concepts, Architectures and Applications
69

SOAP summary


SOAP, in its current form, provides basic mechanisms for:


encapsulating messages into an XML document


mapping the XML document to a SOAP message and turn it into an HTTP
request


transforming RPC calls into SOAP messages


simple rules on how to process a SOAP message (rules have become more
precise and comprehensive in v1.2 of the specification)


SOAP takes advantage of the standards surrounding XML to resolve problems
of data representation and serialisation (it uses XML Schema to represent data
and data structures, and it also relies on XML for serialising the data for
transfer). As XML becomes more powerful and additional XML standards
appear, SOAP can take advantage of them by simply indicating what schema
and encoding is used as part of the SOAP message. Current schema and
encoding are generic but soon there will be vertical standards implementing
schemas and encoding tailored to a particular application area (e.g., the efforts
around EDI, Electronic Data Interchange)


SOAP is a very simple protocol intended for transferring data from one
middleware platform to another. In spite of its claims to be open (which are
true), current specifications are very tied to RPC and HTTP.

70

Alsonso
et al.

Web Services: Concepts, Architectures
and Applications

by Gustavo Alonso, Fabio Casati, Harumi
Kuno, and Vijay Machiraju

©2004 (Springer
-
Verlag)

ISBN 3
-
540
-
44008
-
9


B
o
o
k


S
l
i
d
e
s


‘Graduate course on Web services [Gustavo
Alonso, Cesare Pautasso]. Graduate course
given at the University of Lappeenranta,Finland.
August 9
-
13, 2004.’


http://www.inf.ethz.ch/personal/alonso/WebServicesBook
&


http://www.inf.ethz.ch/personal/alonso/Web
-
book/Lappeenranta
-
graduate
-
course.zip
?