SOAP: Simple Object Access Protocol: Mike P. Papazoglou Mikep@uvt - NL

Slide 4.
Chapter 4
SOAP: Simple Object Access Protocol
Principles & Technology
Web Services:
Mike P. Papazoglou
mikep@uvt.nl
Michael P. Papazoglou, Web Services, 1st Edition, © Pearson Education Limited 2008
Slide 4.2
Topics
• Inter application communication

• SOAP as a messaging protocol
• Structure of a SOAP message
• SOAP communication model
• SOAP fault message
• SOAP over HTTP
• Advantages and disadvantages of SOAP
Slide 4.3
Inter-Application Communication
• Conventional distributed applications use distributed communication

technologies, e.g., CORBA, DCOM, Java/RMI, based on object RPC
(ORPC) protocols that attempted to marry object orientation and
network protocols.
– ORPC request is an identifier or symbolic name that the server could use to
locate the target object inside the server process.
• Weaknesses
– Both ends of the communication link would need to be implemented under
the same distributed object model (Java/RMI or CORBA/IIOP)
– Difficulty of getting these protocols to work over firewalls or proxy servers,
e.g, most firewalls are configured to allow hypertext transfer protocol
(HTTP) to pass across, but not IIOP.
• To address the problem of overcoming proprietary systems running on
heterogeneous infrastructures, Web services rely on SOAP, an XML-
based communication protocol for exchanging messages between
computers regardless of their operating systems, programming
environment or object model framework.
Slide 4.4
Topics

• SOAP over HTTP
Slide 4.5
What is SOAP?
• SOAP is the standard messaging protocol used by Web services.

SOAP’s primary application is inter application communication. SOAP
codifies the use of XML as an encoding scheme for request and
response parameters using HTTP as a means for transport.
Service requestor Service provider
Application object Application object

(client) (service provider)
SOAP-based SOAP-based
middleware middleware
SOAP messages
exchanged on top of,
HTTP, SMTP, or other
transport
Converts procedure calls to/from XML

messages sent through HTTP or other
protocols.
Slide 4.6
What is SOAP? (continued)
• 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 a SOAP message should be
transported using HTTP (for Web-based interaction) or SMTP
(for e-mail-based interaction).
– A set of rules that must be followed when processing a
SOAP message and a simple classification of the entities
involved in processing a SOAP message.
– A set of conventions on how to turn an RPC call into a
SOAP message and back.
Slide 4.7
SOAP as a lightweight protocol

• SOAP is a lightweight protocol
that allows applications to pass
messages and data back and
forth between disparate systems
in a distributed environment
enabling remote method
invocation.
• By lightweight we mean that the
SOAP protocol possesses only
two fundamental properties. It
can:
– send and receive HTTP (or
other) transport protocol packets,
and
– process XML messages.
• This can be contrasted with the

heavyweight protocols such as
ORPC protocols.
Slide 4.8
Distributed messaging using SOAP
Slide 4.9
Topics

• SOAP over HTTP
Slide 4.10
SOAP messages
• SOAP is based on message exchanges.
• Messages are seen as envelopes where
the application encloses the data to be
sent.
• A SOAP message consists of an
<Envelope> element containing an
optional <Header> and a mandatory
<Body> element.
• The contents of these elements are SOAP envelope
application defined and not a part of the
SOAP specification. SOAP header
• A SOAP <Header> contains blocks of header block

information relevant to how the message is
to be processed. This helps pass
information in SOAP messages that is not
SOAP body
for the application but for the SOAP engine
body block
• The SOAP <Body> is where the main end-
to-end information conveyed in a SOAP
message must be carried.
Slide 4.11
SOAP envelope and header

<env:Envelope
xmlns:env=“http://www.w3.org/2003/05/soap-envelope”
env:encodingStyle=”http://schemas.xmlsoap.org/soap/encoding/”>
……
</env:Envelope>
Example of SOAP envelope
<env:Envelope
xmlns:env=“http://www.w3.org/2003/05/soap-envelope” >
…
<env:Header>
<tx:transaction-id
xmlns:tx=”http://www.transaction.com/transaction”
env:mustUnderstand=”true”>
512
</tx:transaction-id>
<notary:token xmlns:notary=”http://www.notarization-services.com/token”
env:mustUnderstand=”true”>
GRAAL-5YF3
</notary:token>
</env:Header>
……………
</env:Envelope>
Example of SOAP header
Slide 4.12
SOAP Intermediaries
• SOAP headers have been

designed in anticipation of
participation of other SOAP
processing nodes – called SOAP
intermediaries – along a
message's path from an initial
SOAP sender to an ultimate
SOAP receiver.
• A SOAP message travels along
the message path from a sender
to a receiver.
• All SOAP messages start with an
initial sender, which creates the
SOAP message, and end with an
ultimate receiver.
Slide 4.13
Example of SOAP header with

message routing
<?xml version="1.0" encoding="UTF-8"?>

<env:Envelope
The “next” role is one
xmlns:env=“http://www.w3.org/2003/05/soap-envelope”> that all SOAP nodes are
<env:Header>
<m:order required to support;
xmlns:m="http://www.plastics_supply.com/purchase-order"
env:role="http://www.w3.org/2003/05/soap-
envelope/role/next" By tagging each header
env:mustUnderstand="true">
<m:order-no >uuid:0411a2daa</m:order-no> in this message with the
<m:date>2004-11-8</m:date>
</m:order>
“next” role, this message
<n:customer xmlns:n="http://www.supply.com/customers" is saying that all SOAP
env:role="http://www.w3.org/2003/05/soap-
envelope/role/next" nodes (intermediaries
env:mustUnderstand="true">
<n:name> Marvin Sanders </n:name>
and the ultimate
</n:customer > receiver) MUST
</env:Header>
<env:Body> understand and be able
<-- Payload element goes here -->
</env:Body>
to process the m:order
</env:Envelope> header and the
n:customer header.
Slide 4.14
The SOAP Body
• The SOAP body is the area of the SOAP message, where the
application specific XML data (payload) being exchanged in the
message is placed.
• The <Body> element must be present and is an immediate child of the

envelope. It may contain a number of child elements, called body
entries, but it may also be empty. The <Body> element contains either
of the following:
– Application-specific data: is the information that is exchanged with a Web
service. The SOAP <Body> is where the method call information and its
related arguments are encoded. It is where the response to a method call is
placed, and where error information can be stored.
– fault message: is used only when an error occurs.
• A SOAP message may carry either application-specific data or a fault,

but not both.
Slide 4.15
Example SOAP Message

<?xml version='1.0' ?>
<env:Envelope xmlns:env="http://www.w3.org/2002/06/soap-envelope" >

Envelope
<env:Header>
<t:transactionID
xmlns:t="http://intermediary.example.com/procurement"
Header
env:role="http://www.w3.org/2002/06/soap-envelope/role/next"
env:mustUnderstand="true" >
57539
</t:transactionID>
</env:Header>
Blocks
<env:Body>
<m:orderGoods
env:encodingStyle="http://www.w3.org/2002/06/soap-encoding"
xmlns:m="http://example.com/procurement">
<m:productItem>
<name>ACME Softener</name>
Body
</m:productItem>
<m:quantity>
35
</m:quantity>
</m:orderGoods>
</env:Body>
</env:Envelope>
Slide 4.16
Topics

• SOAP over HTTP
Slide 4.17
The SOAP Communication Model
• SOAP supports two possible communication styles:

– remote procedure call (RPC) and
– document (or message).
RPC-style interaction Document-style interaction
Slide 4.18
RPC-style SOAP Services
• A remote procedure call (RPC)-style Web service appears as a remote

object to a client application. The interaction between a client and an
RPC-style Web service centers around a service-specific interface.
Clients express their request as a method call with a set of arguments,
which returns a response containing a return value.
SOAP envelope SOAP envelope
SOAP body SOAP body

Method name Method return
orderGoods
Input parameter 1 Return value
product item order id
Input parameter 2
quantity
Slide 4.19
RPC-style web services

<env:Envelope
xmlns:SOAP=“http://www.w3.org/2003/05/soap-envelope”
xmlns:m="http://www.plastics_supply.com/product-prices">
<env:Header>
<tx:Transaction-id
xmlns:t=”http://www.transaction.com/transactions”
env:mustUnderstand='1'>
512
</tx:Transaction-id>
</env:Header>
<env:Body>
<m:GetProductPrice>
<product-id> 450R6OP </product-id >
</m:GetProductPrice >
</env:Body>
</env:Envelope>
Example of RPC-style SOAP body
<env:Envelope
<env:Header>
<--! – Optional context information -->
</env:Header>
<env:Body>
<m:GetProductPriceResponse>
<product-price> 134.32 </product-price>
</m:GetProductPriceResponse>
</env:Body>
</env:Envelope>
Example of RPC-style SOAP response message
Slide 4.20
Document (Message)-style SOAP Services
• In the document-style of messaging, the SOAP <Body> contains an

XML document fragment. The <Body> element reflects no explicit XML
structure.
• The SOAP run-time environment accepts the SOAP <Body> element
as it stands and hands it over to the application it is destined for
unchanged. There may or may not be a response associated with this
message.
SOAP envelope SOAP envelope
SOAP body SOAP body
PurchaseOrder
Acknowledgement
document document
-product item -order id
-quantity
Slide 4.21
Example of document-style SOAP body

<env:Envelope
xmlns:SOAP=“http://www.w3.org/2003/05/soap-envelope”>
<env:Header>
<tx:Transaction-id
512
</env:Header>
<env:Body>
<po:PurchaseOrder oderDate=”2004-12-02”
xmlns:m="http://www.plastics_supply.com/POs">
<po:from>
<po:accountName> RightPlastics </po:accountName>
<po:accountNumber> PSC-0343-02 </po:accountNumber>
</po:from>
<po:to>
<po:supplierName> Plastic Supplies Inc. </po:supplierName>
<po:supplierAddress> Yara Valley Melbourne </po:supplierAddress>
</po:to>
<po:product>
<po:product-name> injection molder </po:product-name>
<po:product-model> G-100T </po:product-model>
<po:quantity> 2 </po:quantity>
</po:product>
</ po:PurchaseOrder >
</env:Body>
</env:Envelope>
Example of document-style SOAP body
Slide 4.22
Topics

• SOAP over HTTP
Slide 4.23
SOAP Fault element

• SOAP provides a model for handling faults arise.
• It distinguishes between the conditions that result in a fault, and the ability to
signal that fault to the originator of the faulty message or another node. The
SOAP <Body> is the place where fault information is placed.
<env:Envelope
<env:Header>
<tx:Transaction-id
512
</tx:Transaction-id>
</env:Header>
<env:Body>
<env:Fault>
<env:Code>
<env:Value>env:Sender</env:Value>
<env:Subcode>
<env:Value> m:InvalidPurchaseOrder </env:Value>
</env:Subcode>
</env:Code>
<env:Reason>
<env:Text xml:lang="en-UK"> Specified product did not exist </env:Text>
</env:Reason>
<env:Detail>
<err:myFaultDetails
xmlns:err="http://www.plastics_supply.com/faults">
<err:message> Product number contains invalid characters </err:message>
<err:errorcode> 129 </err:errorcode>
</err:myFaultDetails>
</env:Detail>
</env:Fault>
</env:Body>
</env:Envelope>
Slide 4.24
Topics

• SOAP over HTTP
Slide 4.25
SOAP and HTTP

 A binding of SOAP to a transport protocol is HTTP POST
a description of how a SOAP message is to SOAP envelope
be sent using that transport protocol. SOAP header
 The typical binding for SOAP is HTTP. Transactional

context
 SOAP can use GET or POST. With GET,
the request is not a SOAP message but the SOAP body
response is a SOAP message, with POST Name of procedure
both request and response are SOAP Input parameter 1

messages (in version 1.2, version 1.1 Input parameter 2
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.
Slide 4.26
RPC call using SOAP over HTTP

HTTP Post
SOAP envelope
SOAP header
Transactional
context
SOAP body
Name of the
procedure
Service requestor Service provider
Input parameter 1
SOAP HTTP Input parameter 2

HTTP SOAP
engine engine engine engine
Client implementation (other HTTP Post Service implementation

tiers) SOAP envelope (other tiers)
SOAP header
transactional
Transactional
context
context
SOAP body
return
Return
parameter
parameter
Slide 4.27
Topics

• SOAP over HTTP
Slide 4.28
Advantages and disadvantages of SOAP
• Advantages of SOAP are:

– Simplicity Try not to laugh too hard at this assertion!!!
– Portability
– Firewall friendliness
– Use of open standards
– Interoperability
– Universal acceptance.
• Disadvantages of SOAP are:
– Too much reliance on HTTP
– Statelessness
– Serialization by value and not by reference.

SOAP: Simple Object Access Protocol: Mike P. Papazoglou Mikep@uvt - NL

Uploaded by

Copyright:

Available Formats

SOAP: Simple Object Access Protocol: Mike P. Papazoglou Mikep@uvt - NL

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

SOAP: Simple Object Access Protocol: Mike P. Papazoglou Mikep@uvt - NL

Uploaded by

Copyright:

Available Formats

Slide 4.

• Inter application communication

• Conventional distributed applications use distributed communication

• Inter application communication

• SOAP is the standard messaging protocol used by Web services.

Service requestor Service provider

Application object Application object

Converts procedure calls to/from XML

What is SOAP? (continued)

• SOAP covers the following four main areas:

SOAP as a lightweight protocol

• This can be contrasted with the

Distributed messaging using SOAP

• Inter application communication

• A SOAP <Header> contains blocks of header block

SOAP envelope and header

Example of SOAP envelope

Example of SOAP header

• SOAP headers have been

Example of SOAP header with

<?xml version="1.0" encoding="UTF-8"?>

The SOAP Body

• The <Body> element must be present and is an immediate child of the

• A SOAP message may carry either application-specific data or a fault,

Example SOAP Message

<env:Envelope xmlns:env="http://www.w3.org/2002/06/soap-envelope" >

• Inter application communication

The SOAP Communication Model

• SOAP supports two possible communication styles:

RPC-style interaction Document-style interaction

RPC-style SOAP Services

• A remote procedure call (RPC)-style Web service appears as a remote

SOAP envelope SOAP envelope

SOAP body SOAP body

RPC-style web services

Example of RPC-style SOAP body

Example of RPC-style SOAP response message

Document (Message)-style SOAP Services

• In the document-style of messaging, the SOAP <Body> contains an

SOAP envelope SOAP envelope

SOAP body SOAP body

Example of document-style SOAP body

Example of document-style SOAP body

• Inter application communication

SOAP Fault element

• Inter application communication

SOAP and HTTP

 The typical binding for SOAP is HTTP. Transactional

response is a SOAP message, with POST Name of procedure

both request and response are SOAP Input parameter 1

RPC call using SOAP over HTTP

SOAP HTTP Input parameter 2

Client implementation (other HTTP Post Service implementation

• Inter application communication

Advantages and disadvantages of SOAP

• Advantages of SOAP are:

You might also like