What Are Web Services'?: - A Form of Distributed Information System' - "

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)
3
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)
4
Objectives for this topic
Understanding Web services Putting Web services into perspective
 In order to understand Web  We will go over the basic Web
services, we need to take a step back service technology available today
and look at the way middleware and and discuss SOAP, UDDI and
enterprise application integration WSDL in detail.
technology has been evolving in the  We will also discuss what can be
last decades. Only so we will then done with these specifications and
be able to understand Web services. what is missing nowadays for them
to be truly useful tools for electronic
 The most popular version of Web commerce.
services (SOAP, UDDI, and  The course aims at developing a
WSDL) is a very poor and limiting critical understanding of Web
view on what true Web services technology and its possibilities
should be. Alternative proposals today. The goal is for participants to
such as ebXML, xCBL, or be able to look at current and future
RosettaNet provide a much deeper developments with enough
insight on what is needed for background to be able to judge how
electronic commerce through Web much of a contribution they are and
services. what their true potential is.
Modified from original Web services:

Concepts,
©Gustavo Alonso, ETH Zürich. Architectures and
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 (Simple object access protocol)
 UDDI (Universal discovery description & integration)
 WSDL (Web services description language)
Web services:
Concepts,
Layers and tiers
 Client is any user or program that wants
Client Presentation layer
to perform an operation over the system.
Clients interact with the system through
a presentation layer
Application Logic Business rules
 The application logic determines what

Resource Manager Business objects 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.
Client Client
 The resource manager deals with the
organization (storage, indexing, and
retrieval) of the data necessary to
Server Business processes
support the application logic. This is
typically a database but it can also be a
text retrieval system or any other data
Database Persistent storage management system providing querying
capabilities and persistence.
Web services:
Concepts,
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
There is no problem in system complex to monitor and manage.
design that cannot be solved by  The more boxes, the greater the number
adding a level of indirection. of context switches and intermediate
steps to go through before one gets to the
There is no performance data. Performance suffers considerably.
problem that cannot be  System designers try to balance the
flexibility of modular design with the
lessened by removing a level of performance demands of real
indirection. applications. Once a layer is established,
it tends to migrate down and merge with
lower layers.
Modified from original Web services:
Concepts,
One tier: fully centralized
 The presentation layer, application
1-tier architecture 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
Server 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.
Web services:
Concepts,
Two tier: client/server
 As computers became more powerful, it
2-tier architecture 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
Server 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.
Web services:
Concepts,
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
server’s API
service service service service

interface interface interface interface
server
service service service service
resource management
layer
Web services:
Concepts,
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.
Web services:
Concepts,
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
Server A Server B design, portability, code reuse,
performance since the client
 If clients want to access two or more capacity is limited, etc.).
servers, a 2-tier architecture causes  There is very little that can be done
several problems: to solve this problems if staying
 the underlying systems don’t know within the 2 tier model.
about each other
 there is no common business logic
 the client is the point of integration
(increasingly fat clients)
Web services:
Concepts,
Three tier: middleware
 In a 3 tier system, the three layers
3-tier architecture 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).
Web services:
Concepts,
Middleware
 Middleware is just a level of
clients indirection between clients and other
layers of the system.
Middleware or  It introduces an additional layer of
global application logic business logic encompassing all
underlying systems.
Local application logic  By doing this, a middleware system:
 simplifies the design of the clients
Local resource
by reducing the number of
interfaces,
managers  provides transparent access to the
underlying systems,
 acts as the platform for inter-
system functionality and high
level application logic, and
middleware  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 ...
Server A Server B Web services:
Concepts,
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
Web services:
Concepts,
A three tier middleware based system ...
External clients
External client
middleware system
internal
clients control
connecting logic
user
logic middleware
wrappers
2 tier systems
Resource
managers 2 tier system Resource
manager
Web services:
Concepts,
N-tier: connecting to the Web
client
 N-tier architectures result from
N-tier connecting several three tier
Web browser architecture systems to each other and/or by
adding an additional layer to allow
clients to access the system
through a Web server
Web server  The Web layer was initially
external to the system (a true
presentation additional layer); today, it is
layer slowly being incorporated into a
HTML filter 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
application logic system)
layer middleware  The addition of the Web layer led
to the notion of “application
servers”, which was used to refer
to middleware platforms
resource management supporting access through the
layer Web
Web services:
information system Concepts,
N-tier systems in reality
INTERNET
FIREWALL
internal
clients Web
server
LAN cluster
LAN
middleware
application LAN,
logic gateways
LAN
resource middleware
application
Wrappers
and
management logic gateways
LAN LAN
layer
database file application additional resource
management layers Web services:
server server Concepts,
The service world
 The WWW suddenly opened up
software systems that had remained
hidden within the IT organization of Browser
a company
 The nature of the interaction did not
change. Behind the WWW there is WEB SERVER
the same client/server model as in
basic RPC. However, the WWW
made everything much easier, Front end
MIDDLEWARE
cheaper and efficient
 integration at the level of user
app server 1’
app server 1
interface became possible
program
program
program
program
 services could be accessed from
user
user
user
user
anywhere in the world
 the clients could now be not just
an internal or selected user but
anybody with a browser wrappers
Branch 1 Branch 2
Web services:
Concepts,
Remote clients
client
client client
browser
stored embedded XML
procedure SQL
FIREWALL
WEB SERVER
user defined
application logic
API
user defined
application logic API
database database
resource manager resource manager
database management Web services:
system Concepts,
Business to Business (B2B)
FIREWALL FIREWALL
WEB SERVER INTERNET WEB SERVER
Front end Front end
MIDDLEWARE
MIDDLEWARE
Service B
Service 2
Service A
Service 1
program
program
program
program
program
program
program
program
user
user
user
user
user
user
user
user
wrappers wrappers
Resource X Resource Y Resource 1 Resource 2
Web services:
Concepts,
Two competing views of Web services
bottom up: application integration
top down: business exchanges
Web services:
Concepts,
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
Web services:
Concepts,
How is it ‘bottom up’?
 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 done
with SOAP
 SOAP (Simple Object Access
Protocol)
 UDDI (Universal Description
and Discovery Protocol)
 WSDL (Web Services
Description Language)
WSDL
Web services:
Concepts,
ebXML architecture
2000 ebXML TM
XM
XML
Business
BusinessSc
Scenarios
enarios 1
1
Business
Business Profile
Profiless
Request
Request Busine
Business
ss De
Details
tails
COMPANYA
2
2
Build Loc
Build Local
al Syste
System
m
ebXML
ebXML 3 Re
3 Implementation
Implementation
Register
gister Im
Implementation
plementation De
Details
tails
Registry
Registry
Register
Register COMPAN
PANY
YA Profile
Profile
Download
Download
Query about
Query aboutCOMPANY
COMPANY
A profile
A profile
4
4
Scenarios andand
Scenarios Profiles
Profiles
5
5
Agree onon
Agree Business
Business
Arrangement
Arrangement
COMPANYB
DO BUSINESS TRANSACTIONS
ebXML
ebXMLccompliant
ompliant
system
system Web services:
Concepts,
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
2000 ebXML TM
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
Web services:
Concepts,
Background for these views
 The IBM’s Web service architecture  The ebXML electronic business
follows traditional middleware architecture predates the efforts
architecture and it is very tied in around Web services. It sees
spirit to conventional middleware electronic commerce as an
asynchronous sequence of message
 It interprets electronic commerce as exchanges
an essentially synchronous activity
where a client requests services (in  ebXML has inherited many ideas
the middleware sense) from a from the EDI (Electronic Data
server. If necessary, a name and Interchange) world as one of the
directory service infrastructure (the main supporters of ebXML is the
registry) is available for same organization that is in charge
matchmaking between clients and of EDI. As such, its main interest is
standardizing business processes and
servers in this interpretation business operations
 This view of Web services focuses
on the low level mechanisms  ebXML contains a much richer
necessary to implement Web vocabulary and deeper
services. It does not say anything understanding of business relations
about how these mechanisms map to that uses to establish what the low
real business exchanges level technology should do. As a
result, it is far more encompassing
than IBM’s Web service architecture
Web services:
Concepts,
Extending information systems to
communicate through the Internet
Web services:
Concepts,
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
Web services:
Concepts,
Messages & Queues
Synchronous Execution
invoking
execution thread
invoked
execution thread
request
blocking
period
response
Web Services:Concepts, Architectures and Applications by

Alonso et al. ©2004 by Springer Verlag Berlin Heidelberg 2004
33
Ch.2, Fig 13, §3.2
Asynchronous Execution
invoking invoked
execution thread execution thread
queue
fetch
thread remains
put
active
fetch put
queue
Web Services:Concepts, Architectures and Applications by

Alonso et al. ©2004 by Springer Verlag Berlin Heidelberg 2004 34
Ch.2, Fig 14, §3.3
The message world
Web services:
Concepts,
Using Workflows with ebXML ©BEA
Web services:
Concepts,
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.
Web services:
Concepts,
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
Web services:
Concepts,
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.
Web services:
Concepts,
Advantages of queues in EAI
 Queuing management systems  Technically, the infrastructure
completely detach the two sides of necessary to deal with messages is
an interaction as there is no direct simpler than the infrastructure
call but a document exchange necessary to deal with synchronous
 This makes the development of both calls. Especially if there are no
sides of the interaction (e.g., client fancy features added to the queues.
and server) completely independent  Queues also have the advantage of
and very flexible being easily adaptable to
 The interaction can be defined in communicate with external systems,
terms of the document to exchange even systems outside the
rather than the interface to invoke. organization (e.g., plug a queue to
This is a more natural approach in an e-mail address)
the business world where  When working with messages, the
interactions tend to be document effort in describing the interaction
based goes into the description of the
 From the scheduling point of view, message or document within the
it is much easier to deal with message. This can be done without
messages than with synchronous knowledge of how the message will
invocations. be processed.
Web services:
Concepts,
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.
Web services:
Concepts,
Queues in TP-Monitors
 Any synchronous middleware introduces a
tight coupling between the caller and the client server
Server stub
Client stub
called. Name and directory services help to service call service
minimize the effects of this coupling but
the tight connection between components is
nevertheless there. get results return results
 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 RPC support
were TP-Monitors which offered two
choices:
 asynchronous RPC: client makes a Input queue Output queue
call that returns immediately; the Reliable
client is responsible for making a queuing
second call to get the results
 Reliable queuing systems (e.g., system
Encina, Tuxedo) where, instead of external
application Output
using procedure calls, client and queue
server interact by exchanging
messages. Making the messages
persistent by storing them in queues
added considerable flexibility to the Input
system queue
external
application
Web services:
Concepts,
Queuing systems
 Queuing systems implement
client asynchronous interactions.
 Each element in the system
communicates with the rest via
persistent queues. These queues store
messages transactionally,
Input queue Output queue guaranteeing that messages are there
even after failures occur.
 Queuing systems offer significant
advantages over traditional solutions
Reliable queuing system in terms of fault tolerance and overall
Monitoring system flexibility: applications do not
need to be there at the time a request
Administration is made!
Persistent storage  Queues provide a way to
communicate across heterogeneous
Input queue Output queue networks and systems while still being
able to make some assumptions about
the behavior of the messages.
 They can be used when embedded
external (workflow, TP-Monitors) or by
application themselves (MQSeries, Tuxedo/Q).
Web services:
Concepts,
Simple Object Access Protocol (SOAP)
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)
Web services:
Concepts,
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.
Web services:
Concepts,
Structure of a SOAP message
Web services:
Concepts,
SOAP messages
 SOAP is based on message exchanges SOAP Envelope
 Messages are seen as envelopes where
the application encloses the data to be SOAP header
sent
 A message has two main parts; header
Header Block
and body, which both can be divided
into blocks
 SOAP does not specify what to do with
SOAP Body
the header and the body, it only states
that the header is optional and the body
is mandatory Body Block
 The use of header and body, however, is
implicit. The body is for application
level data. The header is for
infrastructure level data
Web services:
Concepts,
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
Web services:
Concepts,
SOAP example, header and body
<SOAP-ENV: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>
<symbol>DEF</symbol>
</SOAP-ENV:Body>
Web services:
Concepts,
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)
Web services:
Concepts,
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
Web services:
Concepts,
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.
Web services:
Concepts,
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)
Web services:
Concepts,
From TRPC to SOAP messages
RPC Request
SOAP Envelope
SOAP header
RPC Response (one of the two)
Transactional SOAP Envelope SOAP Envelope
context
SOAP header SOAP header
Transactional Transactional
SOAP Body context context
Name of Procedure
Input param 1 SOAP Body SOAP Body
Return parameter Fault entry

Input param 2
Web services:
Concepts,
Mapping SOAP to a transport protocol
Web services:
Concepts,
HTTP as a communication protocol
 HTTP was designed for exchanging
documents. It is almost like e-mail
(in fact, it uses RFC 822 compliant File being requested
mail headers and MIME types) (docu2.html) and
version of the protocol used
 Example of a simplified request
(from browser):
GET /docu2.html HTTP/1.0 List of MIME types

Accept: www/source accepted by the browser
Accept: text/html
Accept: image/gif
User-Agent: Lynx/2.2 libwww/2.14
From: eggs@spam.com Information about the
* a blank line * environment where the
browser is running
 Request methods: GET (retrieve
data), POST (append information),
PUT (send information), DELETE E-mail or identifier
(remove information), ... of the user
(provided by the browser)
End of request
Web services:
Concepts,
HTTP server side
 Example of a response from
the server (to the request by Protocol version, code indicating
the browser): request status (200=ok)
HTTP/1.0 200 OK
Date: Wednesday, 02-Feb-94 23:04:12 Date, server identification (type)
GMT
Server: NCSA/1.1 and format used in the request
MIME-version: 1.0
Last-modified: Monday, 15-Nov-93
23:33:16 GMT
Content-type: text/html
MIME type of the document
Content-length: 2345
* a blank line * being sent
<HTML><HEAD><TITLE> . . .
</TITLE> . . .etc.
Header for the document
(document length in bytes)
 The server is expected to
convert the data into a MIME
type specified in the request Document sent
(“Accept:” headers) Web services:
Concepts,
Parameter passing
 The introduction of forms for allowing
users to provide information to a web POST request indicating the
server required the modification of HTML CGI script to execute (post-query)
(and HTTP), but it provided a more
advanced interface than just retrieving GET can be used, but requires the
files: parameters to be sent as part of the
URL:
POST /cgi-bin/post-query HTTP/1.0
Accept: www/source
Accept: text/html
Accept: video/mpeg As before
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 *
Data provided through the form
&name = Gustavo and sent back to the server
&email= alonso@inf.ethz.ch Web services:
... Concepts,
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 Envelope
 The typical binding for SOAP is SOAP header
HTTP Transactional
 SOAP can use GET or POST. With context
GET, the request is not a SOAP

message but the response is a SOAP SOAP Body
message, with POST both request Name of Procedure
and response are SOAP messages Input parameter 1

(in v1.2, v1.1 mainly considers Input parameter 2
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
Web services:
Concepts,
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
SOAP-ENV:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/">
<SOAP-ENV:Body>
<symbol>DIS</symbol>
</SOAP-ENV:Body>
Web services:
Concepts,
In XML (the response)
HTTP/1.1 200 OK
Content-Type: text/xml; charset="utf-8"
Content-Length: nnnn
<SOAP-ENV: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>
Web services:
Concepts,
HTTP POST
All together SOAP Envelope

SOAP header
Transactional
context
SOAP Body
Name of Procedure
Input parameter 1
SERVICE REQUESTER SERVICE PROVIDER
Input parameter 2
RPC call Procedure
HTTP engine
HTTP engine
SOAP SOAP
engine engine
HTTP Acknowledgement
SOAP Envelope
SOAP header
Transactional
context
SOAP Body
Return parameter
Web services:
Concepts,
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.
Web services:
Concepts,
Alsonso et al.
Web Services: Concepts, Architectures
and Applications
B by Gustavo Alonso, Fabio Casati, Harumi
o Kuno, and Vijay Machiraju
o ©2004 (Springer-Verlag)
k
ISBN 3-540-44008-9
‘Graduate course on Web services [Gustavo

S Alonso, Cesare Pautasso]. Graduate course given
l at the University of Lappeenranta,Finland. August
i 9-13, 2004.’
d http://www.inf.ethz.ch/personal/alonso/WebServicesBook &
e http://www.inf.ethz.ch/personal/alonso/Web-book/Lappeenran
s ta-graduate-course.zip 70

What Are Web Services'?: - A Form of Distributed Information System' - "

Uploaded by

Document Information

Original Title

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

What Are Web Services'?: - A Form of Distributed Information System' - "

Uploaded by

Copyright:

Available Formats

What are ‘Web Services’?

(Quotes from Alonso et al.)

• ‘A form of distributed information

• ‘In middleware terms, a service is a procedure,

Modified from original Web services:

The Service World

Messages, Documents, and Processes

The WWW Protocols That make it all happen

 The application logic determines what

service service service service

 However, two tier systems have disadvantages:

WEB SERVER INTERNET WEB SERVER

Front end Front end

Resource X Resource Y Resource 1 Resource 2

Web Services:Concepts, Architectures and Applications by

Web Services:Concepts, Architectures and Applications by

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

Input param 1 SOAP Body SOAP Body

Return parameter Fault entry

GET /docu2.html HTTP/1.0 List of MIME types

GET, the request is not a SOAP

message, with POST both request Name of Procedure

and response are SOAP messages Input parameter 1

POST /StockQuote HTTP/1.1

All together SOAP Envelope

RPC call Procedure

‘Graduate course on Web services [Gustavo

You might also like