web services - soap (part 2)

Summer 2013

Web Services (NSWI145)Lecture 03: SOAP

Martin Nečaský, Ph.D.Faculty of Mathematics and Physics

Charles University in Prague, Czech Republic

Summer 2013

SOAP Reminder

example

Summer 2013

SOAP Processing Model SOAP message travels along path of SOAP

nodes = SOAP message path from initial SOAP sender• point of origin

to ultimate SOAP receiver• final destination

passes zero or more SOAP intermediaries each SOAP node is identified by unique URI

Summer 2013

SOAP Processing Model

Sender

Receiver

Intermediary

Intermediary

…

Summer 2013

SOAP Processing Model processing SOAP message by SOAP node:

check if message is valid SOAP message process SOAP standard elements• body entries MUST be processed by ultimate SOAP

receiver and MAY NOT be processed by SOAP intermediary• header blocks MAY be processed by any SOAP

intermediary and ultimate SOAP receiver

Summer 2013

SOAP Processing Model processing SOAP message by SOAP

intermediary results in: generating single SOAP fault, OR forwarding (optionally) updated SOAP message

and generating and sending zero or more additional SOAP messages

Summer 2013

SOAP Processing Model each header block in SOAP message has optional

attributes which adjust how SOAP nodes on SOAP message path process header block role mustUnderstand relay

Summer 2013

SOAP Processing ModelAttribute role

each SOAP node assumes its roles (one or more) for processing given SOAP message must be invariant during processing single SOAP

message each header block has specified targeted role

by optional role attribute

Summer 2013


value of type xs:anyURI 3 standard values

none next ultimateReceiver

application-specific roles can be created each must have its own URI

Summer 2013


value none SOAP nodes MUST NOT act in this role• i.e. header block does not target any SOAP node

Summer 2013


value ultimateReceiver each SOAP ultimate receiver must act in this role• i.e. header block targets each SOAP node that assumes

being ultimate SOAP receiver default value when role is not specified

Summer 2013


value next each SOAP intermediary and ultimate SOAP

receiver MUST act in this role• i.e. header targets any SOAP node except initial SOAP

sender which is meaningless

Summer 2013


application specific value header targets each SOAP node that assumes to

play that application-specific role e.g.:

• http://www.ksi.mff.cuni.cz/soap/roles/Cache• http://www.ksi.mff.cuni.cz/soap/roles/Log• http://www.ksi.mff.cuni.cz/soap/roles/Encrypt• http://www.ksi.mff.cuni.cz/soap/roles/Annotate• http://www.ksi.mff.cuni.cz/soap/roles/Backup• …

Summer 2013


SOAP node is targeted by header block iffSOAP node assumed role

= header block role

targeted SOAP node may process header block processing according to application specific rules

of that block (which is not part of SOAP)

Summer 2013


SOAP does not specify how SOAP node determines its roles entirely application-specific task can be known a priori as well as determined

dynamically in run-time

Summer 2013

SOAP Processing ModelAttribute role Example

Summer 2013

SOAP Processing ModelAttribute mustUnderstand

value of type xs:boolean default value: false

if true, targeted SOAP node must process header block header block is called mandatory header block for

that SOAP node

Summer 2013

SOAP Processing ModelAttribute mustUnderstand

inability to process mandatory header block means that single SOAP fault is generated• with code MustUnderstand

original SOAP message is not forwarded any further

all further processing of original SOAP message is cancelled

Summer 2013

SOAP Processing ModelAttribute mustUnderstand Example

Summer 2013

SOAP Processing ModelAttribute relay

value of type xs:boolean default value: false

specifies forwarding header blocks by targeted SOAP intermediaries

relayable vs. non-relayable header blocks

Summer 2013

SOAP Processing ModelProcessing SOAP Header Blocks

1. determine roles2. identify targeting header blocks3. if one or more mandatory header blocks are

not understood generate SOAP fault exit

process header blocks mandatory and others optionally

1. if you are SOAP intermediary then relay header blocks

Summer 2013


SOAP intermediary relays header blocks as follows: header block targeting SOAP intermediary• processed block is removed• ignored and non-relayable block is removed• ignored and relayable block is retained

header block not targeting SOAP intermediary is retained

Summer 2013


SOAP intermediary acting exactly as described in previous two slides is called forwarding SOAP intermediary

SOAP intermediary which moreover adds, removes or updates header blocks is called active SOAP intermediary

Summer 2013

SOAP Processing ModelRelaying SOAP Header Blocks

SOAP Header

Header Block Arole="Annotate"

mustUnderstand="true"

Header Block Brole="Annotate"relay="true"

Header Block Crole="next"

Header Block Drole="Log"

Sender

Summer 2013


SOAP Header






Sender ForwardingIntermediary

roles:Annotatenext

SOAP Header






ignores:Header Block B

Summer 2013


ForwardingIntermediary

roles:Annotatenext

SOAP Header







SOAP Header






Summer 2013


ActiveIntermediary

roles:Annotatenext

SOAP Header




SOAP Header









Header Block Erole="next"

Summer 2013

SOAP Header vs. Body what information should be part of header and what

should be placed in body? decision made during application design

Header Body• may be processed and updated

by SOAP intermediaries• SOAP intermediaries provide

value-added services on base of header blocks

• primary content• processed only by ultimate

SOAP receiver• must be understood by

ultimate SOAP receiver

Summer 2013

SOAP Communication Model

two possible communication models RPC-style web services• RPC/Literal

document-(or message-)style web services• RPC/Document

Summer 2013

SOAP Communication ModelRPC-style web services

web service appears as remote object request = method call with name and set of

typed arguments response = return value automatic serialization/deserialization of

method calls and return values

Summer 2013

SOAP Communication ModelRPC-style web services

tightly coupled client and service hard-coded

usually synchronous allows for exposing software components as

web services servlets, Java RMI objects, ... components natively DO NOT exchange XML data

Summer 2013

SOAP Communication ModelRPC-style web services Example

Summer 2013

SOAP Communication ModelDocument-style web services

exchanging any documents (any information) documents encoded in XML no automatic serialization/deseralization of

documents in XML exchanged documents are primarily encoded in

XML by application

Summer 2013

SOAP Communication ModelDocument-style web services

closer to real-world communication between real-world

"components" instead of software components asynchronous

Summer 2013

SOAP Network Protocol Binding

SOAP does not specify how SOAP messages are encoded for network transfer

SOAP message must be encapsulated in a message conforming to a network protocol binding SOAP messages to HTTP, SMTP, FTP, etc. or

even simpler TCP/IP or UDP

Summer 2013


particular network protocol influences what must be implemented at SOAP level HTTP natively supports request/response

communication pattern UDP natively does not natively support

request/response communication pattern which must be therefore implemented at SOAP level

Summer 2013


different network protocols can be applied on SOAP message path with one or more SOAP intermediaries

web services developers usually do not come in touch with binding specification HTTP used in most cases

Summer 2013

SOAP Network Protocol BindingHTTP Binding

SOAP messages encoded as HTTP messages become data part of HTTP message supplemented with HTTP headers• e.g. Host, Content-Length, etc.

client identifies server via URL, connects using TCP/IP, issues HTTP request message and receives HTTP response

Summer 2013

SOAP Advantages simplicity

XML is structured and easy to parse portability

no dependency on the underlying platform firewall-friendly

HTTP, SMTP open, interoperable standard universal acceptance

Summer 2013

SOAP AdvantagesModularity

XML modularity

SOAP modularity

code modularity code re-use

Summer 2013


namespaces identify different header block and body languages and their particular versions different libraries for processing different versions

of SOAP different libraries for processing different header

blocks and body

Summer 2013


SOAP Envelope

SOAP Header

SOAP Body

SOAP v1.2library

http://www.w3.org/2003/05/soap-envelope

SOAP v1.1library

http://schemas.xmlsoap.org/soap/envelope/

Summer 2013


SOAP Envelope

SOAP Header

SOAP Body

Message

PayPalAPI v 1.0library

PayPalAPI v 1.1libraryurn:ebay:api:

PayPalAPI11

urn:ebay:api:PayPalAPI

Summer 2013


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

<env:Body xmlns="urn:ebay:api:PayPalAPI" />

</env:Envelope>

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

<env:Body xmlns="urn:ebay:api:PayPalAPI-11" />

</env:Envelope>

Summer 2013


SOAP Envelope

SOAP Header

SOAP Body

Header Block Digital signaturelibrary

http://digsig.com/standard

Header Block

Transactions 1.0library

Transactions 2.0library

http://thirdparty.com/ws-trans1-0

http://fourthparty.com/ws-trans2-0

Summer 2013

SOAP Disadvantages

originally tied to HTTP request/response architecture, SOAP performance

suffers improved in recent versions

stateless but may be managed by SOAP extensions

reference by value no object references

XML

web services - soap (part 2)

Documents

soap summer

soap nodes

soap nodedetermines

soap intermediaries

soap node summer

soap ultimate receiver

soap message path

single soap fault