Soap protocol
1 / 55

SOAP Protocol - PowerPoint PPT Presentation

  • Updated On :

SOAP Protocol. Service Oriented Architecture Protocol Simple Object Access Protocol. W3C Web Service Definition.

I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
Download Presentation

PowerPoint Slideshow about 'SOAP Protocol' - elina

An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.

- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
Soap protocol l.jpg

SOAP Protocol

Service Oriented Architecture Protocol

Simple Object Access Protocol

W3c web service definition l.jpg
W3C Web Service Definition

  • “A Web service is a software system designed to support interoperable machine-to-machine interaction over a network. It has an interface described in a machine-processable format (specifically WSDL). Other systems interact with the Web service in a manner prescribed by its description using SOAP-messages, typically conveyed using HTTP with an XML serialization in conjunction with other Web-related standards”

Soap history l.jpg
SOAP History

  • Microsoft begins investigating XML-based distributed computing in 1997

  • Goal: enable applications to communicate by Remote Procedure Calls (RPCs)

  • Userland publishes a version of the SOAP specification in 1998 (XML-RPC)

  • IBM supports SOAP 1.1 in 2000 and releases a Java Soap implementation

  • SOAP 1.2 was a W3C recommendation in 2003

What is soap l.jpg
What is SOAP?

  • Industry’s best effort to standardize on an infrastructure for cross-platform XML distributed computing

  • A mechanism for defining the unit of communication

    • SOAP envelope that encloses everything

    • A Body for the Message which can contain arbitrary XML information

    • Headers that encapsulate information outside the body

What is soap5 l.jpg
What is SOAP?

  • A processing model – a set of rules for dealing with SOAP messages in software

  • A mechanism for error handling – Using SOAP faults, errors can be detected and diagnostic information can be exchanged between participants

  • An extensibility model – SOAP headers are used to create extensions on top of SOAP

What is soap6 l.jpg
What is SOAP?

  • A flexible mechanism for data representation – allows for the exchange of data already serialized in some format as well as a convention for representing programming language datatypes in XML

  • A convention for RPCs and responses

  • A protocol binding framework – used to send SOAP messages across HTTP connections

Specification structure l.jpg
Specification Structure

  • Find the spec at

  • Part 1, The Messaging Protocol – foundation info (processing model, extensibility model, message structure)

  • Part 2, Adjuncts – extensions for proof-of-concept and to provide a baseline for functional interoperable services

Soap messaging framework l.jpg
SOAP Messaging Framework

  • What does a message look like?

  • This one is XML sent by HTTP

    POST /axis/InventoryCheck.jws HTTP/1.0

    Content-Tye application/soap+xml;charset=utf-8

    <?xml version=“1.0”encoding=“UTF-8”?>

    <soapenv:Envelope xmlns:soapenv=“”




    <doCheck soapenv:encodingStyle=“>

    <arg0 xsi:type=“soapenc:string”


    <arg1 xsi:type=“soapenc:int”





Here is the response l.jpg
Here is the Response

  • Response delivered using HTTP

    Content-Tye application/soap+xml;charset=utf-8

    <?xml version=“1.0”encoding=“UTF-8”?>

    <soapenv:Envelope xmlns:soapenv=“”




    <doCheckResponse soapenv:encodingStyle=“”>

    <rpc:result xmlns:rpc=“”>return</rpc:result>

    <return xsi:type”xsdboolean”>true</return>




Vertical extensibility l.jpg
Vertical Extensibility

  • Why use SOAP? Why not just use HTTP?

  • Document can be extended using headers without changing the body

  • Consider adding notary information to a purchase order

    <po id=“2352” submitted=“2004-01-05 custID=“73852”>

    <notary:token xmlns:notary=“”> XQ34Z-4G5


    <billTo> … </billTo


Repercussions l.jpg

  • Document schema would have to be extensible

  • You and consumers would have to agree on how to process extensible parts of the document

  • SOAP presents headers as an alternative to this technique

Headers l.jpg

  • The notary information is carried in the SOAP header as an extension

    <soapenv:Envelope xmlns:soapenv=“”>


    <notary:token xmlns:notary=“”>





    <po id=“2352” submitted=“2004-01-05 custID=“73852”>

    … normal purchase order info …




Header uses l.jpg
Header Uses

  • Extending messaging infrastructure – headers are usually processed by middleware. Applications may not even see them

  • Defining orthogonal data – A way to send information to the application without having to change the document schema

Mustunderstand flag l.jpg
mustUnderstand Flag

  • Some headers carry useful but not critical information about the message

  • Some headers must be processed in order for the body message to make sense


    <notary:token xmlns:notary=“”





Mustunderstand flag15 l.jpg
mustUnderstand Flag

  • If “true” an application must be able to process the header in order to correctly process the message

  • If “false” or missing, the application can safely process the message without processing the header

  • The flag allows you to build extensions that fundamentally change the way a document is processed and in a way that is interoperable

  • Applications can gracefully fail using the flag

Soap modules l.jpg
SOAP Modules

  • If you are adding headers you probably want other parties to use your extension

  • Usually a specification is written that covers the details of the constraints, rules, preconditions, and data formats of the extension

  • These specifications are called “SOAP modules”

  • Modules are named with URIs

Soap intermediaries l.jpg
SOAP Intermediaries

  • Vertical extensibility is about adding new information within a SOAP message

  • Horizontal extensibility is about targeting different parts of the same SOAP message to different recipients

  • Horizontal extensibility is provided by SOAP intermediaries

Why intermediaries l.jpg
Why Intermediaries?

  • Intermediaries are applications that can process parts of a SOAP message as it travels from origin to destination

  • The route taken by the message is called the SOAP message path





Why intermediaries19 l.jpg
Why Intermediaries?

  • Intermediaries can accept and forward SOAP messages

  • Intermediaries can process messages

  • Three use cases:

    • Crossing trust domains

    • Ensuring scalability

    • Providing value-added services

Crossing trust domains l.jpg
Crossing Trust Domains

  • Employees and customers are probably kept in different trust domains. Internet requests can be processed by an intermediary before crossing into a trusted domain to be processed

Scalability l.jpg

  • Highly scalable systems may require buffering of messages and routing of messages based on parameters contained in headers

  • Users are unaware of the extra processing by intermediaries

Some value added services l.jpg
Some Value-added Services

  • Securing message exchanges through untrustworth domains – An intermediary encrypts a message and signs it before sending the message. Another intermediary receives the message, checks the digital signature, and decrypts the message

  • Notarization/nonrepudiation – A third party records an interaction

  • Providing message tracing facilities – Discover the path a message took along with timings

Transparent and explicit intermediaries l.jpg
Transparent and Explicit Intermediaries

  • A transparent intermediary is one the client knows nothing about. The client thinks the message is going straight to the service endpoint

  • An explicit intermediary is one in which the client knows that the message will travel through an intermediary

Soap intermediaries24 l.jpg
SOAP Intermediaries

  • SOAP was designed with intermediaries in mind

  • Three aspects of intermediary-enabled architecture

  • How do you pass information to intermediaries?

  • How do you identify who should process what?

  • What happens to information that is processed by intermediaries

Identification of intermediaries l.jpg
Identification of Intermediaries

  • All headers can optionally have a soapenv:role attribute

  • The value of the attribute is a URI that identifies the intermediary

  • The URI might mean a particular node (John’s machine) or it might mean a class of nodes (any cache manager along the path)

  • A given node can play multiple roles (John’s machine might be a cache manager)

Node processing steps l.jpg
Node Processing Steps

  • Each node must collect all headers targeted at the node

  • Each node looks at the headers marked “mustUnderstand” and verifies it can process the header in accordance with the rules associated with that header

  • If if finds a mustUnderstand header it doesn’t recognize, it must immediately stop processing

Special values of attribute role l.jpg
Special Values of Attribute “role”

  • – Indicates the header entry’s recipient is the next SOAP node that processes the message – good for hop-by-hop message processing

  • – Refers to the final recipient of the message. Omitting this implies that the final recipient should process the header. The final recipient also processes the body

Special values of attribute role28 l.jpg
Special Values of Attribute “role”

  • – Indicates that no SOAP node should process this header. The node still might read information in the node

Types of intermediaries l.jpg
Types of Intermediaries

  • Forwarding Intermediary – these intermediaries process only certain headers and forward the message to the next node in the path

  • Active Intermediary – Process and perhaps modify a message in ways not defined by the message contents. For example adding a digital signature to every outbound message

Intermediary rules and headers l.jpg
Intermediary Rules and Headers

  • All headers targeted at a particular intermediary are removed from the message when it’s forwarded to the next node

  • The contract implied by a given header is between the sender of that header and the first node satisfying the role to which it’s targeted

  • Headers that aren’t targeted at a particular intermediary should be forwarded through untouched

  • Either type of intermediary may do work on the message

Intermediary rules and headers31 l.jpg
Intermediary Rules and Headers

  • Headers are removed by a target even if they aren’t understood

  • Two exceptions:

    • The specification for a given extension indicates that a copy of the header should be placed in the outgoing message (reinserted)

    • When you want to indicate to an intermediary that extensions targeted at them but not understood should be passed through. Soap 1.2 has a “relay” attribute for this purpose

The soap body l.jpg
The SOAP Body

  • The SOAP Body element surrounds the information that is core to the SOAP message

  • All immediate children of the Body element are body entries (“bodies”)

  • Bodies contain arbitrary XML.

  • Based on the intent of the SOAP message, certain conventions govern the format of the SOAP body (for example, RPCs)

  • When a node identifies itself as the ultimate recipient, it’s required to process the contents of the body which carries the core of the SOAP message

The soap processing model l.jpg
The SOAP Processing Model

Steps a processor must perform when a SOAP message is received:

  • Determine the set of roles in which the node is to act. The contents of the envelope, including any headers and the body may be inspected in making this determination

  • Identify all header blocks targeted at the node that are mandatory

The soap processing model34 l.jpg
The SOAP Processing Model

Steps a processor must perform when a SOAP message is received:

  • If one or more header blocks aren’t understood by the node, generate a single SOAP fault with the value of “Code” set to env:mustUnderstand. No further processing is done. Faults related to the body must not be generated in this step

  • Process all mandatory headers targeted at the node, and in the case of ultimate receiver, the body. Non-mandatory headers directed at the node can also be processed

The soap processing model35 l.jpg
The SOAP Processing Model

Steps a processor must perform when a SOAP message is received:

5. In the case of an intermediary where the message exchange pattern and processing require the message to be relayed, do so.

Versioning in soap l.jpg
Versioning in SOAP

  • The SOAP envelope does not expose any explicit version information (like HTTP or XML)

  • Instead, SOAP uses namespaces to define a protocol version using a URI

  • Web service engines have a choice of how to treat SOAP messages that have a version other than the one the engine is best suited to process

Versioning in soap37 l.jpg
Versioning in SOAP

Suppose and engine reads a message:

  • If the message version is the same as any version the engine knows, it can process the message

  • If the message version is older than any version the engine knows, it should generate a VersionMismatch fault and attempt to negotiate the protocol version with the client by sending info about the versions it can accept

  • If the message version is newer than any version the engine knows, it must generate VersionMismatch fault

Processing headers and bodies l.jpg
Processing Headers and Bodies

  • The SOAP definition of “process” is to fulfill the contract indicated by a particular piece of a SOAP message (header or body)

  • An intermediary might encrypt the body of a message as it passes through, but this is not “processing” in the SOAP sense. The intermediary isn’t doing something the body requested

  • A header added to supply data (instead of changing the body and schema) might add “none” to the role to make sure no one tries to process it

Faults error handling in soap l.jpg
Faults: Error Handling in SOAP

  • A SOAP fault message is a normal SOAP message with a well-known element: soapenv:Fault

  • The presence of soapenv:Fault signals processors that something has gone wrong

  • The fault code can signal exactly what is wrong

Faults error handling in soap40 l.jpg
Faults: Error Handling in SOAP


<st:PSAnnounce>Services unavailable after 5PM</st:PSAnnounce>







<env:Value>st:Invalid PO</env:Value>




<env:Text xml:lang=“en-US”>PO didn’t validate</env:Text>


<env:Detail> …</env:Detail>




Fault code l.jpg
Fault Code

  • Sender – the problem is missing or incorrect data from the sender

  • Receiver – Something went wrong with the receiver while processing the message. Not directly attributable to the sender

  • mustUnderstand – a header was received that was targeted to the receiving node marked mustUnderstand=“true”, and was not understood

  • VersionMismatch – the namespace on the SOAP envelope isn’t compatible with the version on the receiver

Subcodes l.jpg

  • You can specify an arbitrary hierarchy of subcodes




    <env:Value>st:Invalid PO</env:Value>



  • Each subcode can contain another subcode

Reason l.jpg

  • The Reason element contains human readable descriptions of the fault

  • The Text element contains the text

  • Multiple Text elements can be coded but each one should have a different language


    <env:Text xml:lang=“en-US”>PO didn’t validate</env:Text>


Node and role l.jpg
Node and Role

  • An optional Node element can indicate which node (sender, intermediary, ultimate destination) was processing the message when the fault occurred. It contains a URI

  • The Role element indicates which role the faulting node was playing when the fault occurred.

Fault details l.jpg
Fault Details

  • We may want to pass back complex machine-readable data (stack trace)

  • You can place anything inside the Detail element

Using headers in faults l.jpg
Using Headers in Faults

  • Since Faults are messages, they can contain headers

  • Some headers are specifically for faults

  • NotUnderstood header– used to indicate which header was not understood. Multiple headers of this type can be coded

  • Upgrade header – used to indicate a versioning problem

Objects in xml soap data model l.jpg
Objects in XML: SOAP Data Model

  • In order for programmers to send Java/C++/VB objects in SOAP envelopes, two concepts were introduced:

  • SOAP Data model

  • SOAP encoding

Objects in xml l.jpg
Objects in XML

  • The SOAP data model is an abstract representation of data structure in Java…

  • The encoding is a set of rules that map the data model into XML

Java data model l.jpg
Java Data Model


Class Product {

String description;

String sku;

double unitPrice;








Object graphs l.jpg
Object Graphs

  • Nodes can have outgoing edges (compound values)

  • Nodes can have only incoming edges (simple values)

  • Edges coming out of a compound value have names and the node represents a structure

  • The edge names (accessors) are equivalent to field names in Java

  • A node with outgoing edges that are only distiquished by position represents an array

Multireference values l.jpg
Multireference values

  • The same value can be referred two more than once



The soap encoding l.jpg
The SOAP Encoding

  • The encoding is used to convert the model to XML

    <product soapenv:encodingStyle=“”>





  • Multirefs cause a small problems

Encoding arrays l.jpg
Encoding Arrays

<myArray soapenc:itemType=“xsd:string” soapenc:arraySize=“3”>





Soap rpc conventions l.jpg
SOAP RPC Conventions

  • Data model can be used to map a procedure call to SOAP

  • Java: public int addFive(int arg);



    <myNS:addFive xmlns:myNS=“” enc:encodingStyle=“http://”>

    <arg xsi:type=“xsd:int”>33</arg>




Rpc response l.jpg
RPC Response

  • The RPC response might look like this:



    <myNS:addFiveResponse xmlns:myNS=“”




    <ret xsi:type=“xsd:int”>38</ret>