際際滷

際際滷Share a Scribd company logo

Web Services - SOAP (part 2)

Download as PPTX, PDF
Martin Necasky
Martin Necasky

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 of 46
Downloaded 46 times
Web Services (NSWI145) Lecture 03: SOAP Martin Neask箪, 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 Intermediary Intermediary Receiver 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 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
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
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
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
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
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
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
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
SOAP Processing Model Attribute role Example Summer 2013
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
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
SOAP Processing Model Attribute mustUnderstand Example Summer 2013
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
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
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
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
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
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
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
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
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
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 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
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
SOAP Communication Model RPC-style web services Example Summer 2013
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
SOAP Communication Model Document-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
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
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
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
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 Advantages Modularity XML modularity SOAP modularity code modularity code re-use Summer 2013
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
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
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
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
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
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

More Related Content

Web Services - SOAP (part 2)

  • 1. Web Services (NSWI145) Lecture 03: SOAP Martin Neask箪, 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