Your SlideShare is downloading. ×
0
Web Services - SOAP (part 2)
Web Services - SOAP (part 2)
Web Services - SOAP (part 2)
Web Services - SOAP (part 2)
Web Services - SOAP (part 2)
Web Services - SOAP (part 2)
Web Services - SOAP (part 2)
Web Services - SOAP (part 2)
Web Services - SOAP (part 2)
Web Services - SOAP (part 2)
Web Services - SOAP (part 2)
Web Services - SOAP (part 2)
Web Services - SOAP (part 2)
Web Services - SOAP (part 2)
Web Services - SOAP (part 2)
Web Services - SOAP (part 2)
Web Services - SOAP (part 2)
Web Services - SOAP (part 2)
Web Services - SOAP (part 2)
Web Services - SOAP (part 2)
Web Services - SOAP (part 2)
Web Services - SOAP (part 2)
Web Services - SOAP (part 2)
Web Services - SOAP (part 2)
Web Services - SOAP (part 2)
Web Services - SOAP (part 2)
Web Services - SOAP (part 2)
Web Services - SOAP (part 2)
Web Services - SOAP (part 2)
Web Services - SOAP (part 2)
Web Services - SOAP (part 2)
Web Services - SOAP (part 2)
Web Services - SOAP (part 2)
Web Services - SOAP (part 2)
Web Services - SOAP (part 2)
Web Services - SOAP (part 2)
Web Services - SOAP (part 2)
Web Services - SOAP (part 2)
Web Services - SOAP (part 2)
Web Services - SOAP (part 2)
Web Services - SOAP (part 2)
Web Services - SOAP (part 2)
Web Services - SOAP (part 2)
Web Services - SOAP (part 2)
Web Services - SOAP (part 2)
Web Services - SOAP (part 2)
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×
Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

Web Services - SOAP (part 2)

305

Published on

0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total Views
305
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
21
Comments
0
Likes
0
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

  • 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 ModelSender 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 ModelAttribute 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 Blocks1. 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 optionally1. 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 modularitycode 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 ModularitySOAP 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 ModularitySOAP 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 ModularitySOAP 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

×