The document discusses the SOAP processing model. It describes how a SOAP message travels from a sender through zero or more intermediaries to a receiver. Each node in the path is identified by a unique URI. SOAP header blocks can be processed or relayed by intermediaries depending on attributes like role, mustUnderstand, and relay. The role attribute specifies the target nodes for a header block, mustUnderstand indicates required processing, and relay determines forwarding behavior.

1. Web Services (NSWI145)
Lecture 03: SOAP
Martin Nečaský, Ph.D.
Faculty of Mathematics and Physics
Charles University in Prague, Czech Republic
Summer 2013

2. SOAP Reminder
 example
Summer 2013

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

4. SOAP Processing Model
Sender Intermediary
…
Intermediary Receiver
Summer 2013

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

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

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

8. SOAP Processing Model
Attribute 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

9. SOAP Processing Model
Attribute role
 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

10. SOAP Processing Model
Attribute role
 value none
 SOAP nodes MUST NOT act in this role
• i.e. header block does not target any SOAP node
Summer 2013

11. SOAP Processing Model
Attribute role
 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

12. SOAP Processing Model
Attribute role
 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

13. SOAP Processing Model
Attribute role
 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

14. SOAP Processing Model
Attribute role
 SOAP node is targeted by header block iff
SOAP 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

15. SOAP Processing Model
Attribute role
 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

16. SOAP Processing Model
Attribute role Example
Summer 2013

17. SOAP Processing Model
Attribute 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

18. SOAP Processing Model
Attribute 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

19. SOAP Processing Model
Attribute mustUnderstand Example
Summer 2013

20. SOAP Processing Model
Attribute 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

21. SOAP Processing Model
Processing SOAP Header Blocks
1. determine roles
2. identify targeting header blocks
3. 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

22. SOAP Processing Model
Processing SOAP Header Blocks
 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

23. SOAP Processing Model
Processing SOAP Header Blocks
 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

24. SOAP Processing Model
Relaying SOAP Header Blocks
SOAP Header
Header Block A
role="Annotate"
mustUnderstand="true"
Header Block B
role="Annotate"
Sender relay="true"
Header Block C
role="next"
Header Block D
role="Log"
Summer 2013

25. SOAP Processing Model
Relaying SOAP Header Blocks
SOAP Header SOAP Header
Header Block A Header Block A
role="Annotate" role="Annotate"
mustUnderstand="true" mustUnderstand="true"
Header Block B Header Block B
role="Annotate"
Forwarding role="Annotate"
Sender relay="true" relay="true"
Intermediary
roles:
Header Block C Header Block C
Annotate
role="next" role="next"
next
Header Block D
ignores: Header Block D
role="Log"
Header Block B role="Log"
Summer 2013

26. SOAP Processing Model
Relaying SOAP Header Blocks
SOAP Header SOAP Header
Header Block A Header Block A
role="Annotate" role="Annotate"
mustUnderstand="true" mustUnderstand="true"
Header Block B Header Block B
role="Annotate" Forwarding role="Annotate"
relay="true" relay="true"
Intermediary
Header Block C roles: Header Block C
role="next" Annotate role="next"
next
Header Block D ignores: Header Block D
role="Log" Header Block B role="Log"
Summer 2013

27. SOAP Processing Model
Relaying SOAP Header Blocks
SOAP Header SOAP Header
Header Block A Header Block A
role="Annotate" role="Annotate"
mustUnderstand="true" mustUnderstand="true"
Header Block B Header Block B
E
role="Annotate" Active role="Annotate"
role="next"
relay="true" relay="true"
Intermediary
Header Block B
Header Block C roles: role="Annotate"
role="next" Annotate relay="true"
next
Header Block D ignores: Header Block D
role="Log" Header Block B role="Log"
Summer 2013

28. 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 • primary content
by SOAP intermediaries • processed only by ultimate
• SOAP intermediaries provide SOAP receiver
value-added services on base • must be understood by
ultimate SOAP receiver
of header blocks
Summer 2013

29. SOAP Communication Model
 two possible communication models
 RPC-style web services
• RPC/Literal
 document-(or message-)style web services
• RPC/Document
Summer 2013

30. SOAP Communication Model
RPC-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

31. SOAP Communication Model
RPC-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

32. SOAP Communication Model
RPC-style web services Example
Summer 2013

33. SOAP Communication Model
Document-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

34. SOAP Communication Model
Document-style web services
 closer to real-world
 communication between real-world
"components" instead of software components
 asynchronous
Summer 2013

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

36. SOAP Network Protocol Binding
 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

37. SOAP Network Protocol Binding
 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

38. SOAP Network Protocol Binding
HTTP 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

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

40. SOAP Advantages
Modularity
XML modularity
SOAP modularity
code modularity  code re-use
Summer 2013

41. SOAP Advantages
Modularity
 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

42. SOAP Advantages
Modularity
SOAP Envelope SOAP v1.1
SOAP Header library
http://schemas.xmlsoap.org/
soap/envelope/
SOAP Body http://www.w3.org/
2003/05/soap-envelope
SOAP v1.2
library
Summer 2013

43. SOAP Advantages
Modularity
SOAP Envelope
SOAP Header
PayPalAPI v 1.0
urn:ebay:api: library
PayPalAPI
SOAP Body
Message PayPalAPI v 1.1
urn:ebay:api: library
PayPalAPI11
Summer 2013

44. SOAP Advantages
Modularity
<?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

45. SOAP Advantages
Modularity
SOAP Envelope
SOAP Header http://digsig.com/
standard Digital signature
Header Block
library
Header Block http://thirdparty.com/
ws-trans1-0
Transactions 1.0
SOAP Body library
http://fourthparty.com/
ws-trans2-0
Transactions 2.0
library
Summer 2013

46. 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
Summer 2013