Unformatted text preview:

Web Services - Concepts, Architecture and Applications Part 4: Internet Interaction (SOAP)What is SOAP?The background of SOAPStructure of a SOAP messageSOAP messagesFor the XML fans (SOAP, body only)SOAP example, header and bodyThe SOAP headerThe SOAP bodySOAP Fault element (v 1.2)Message processingFrom TRPC to SOAP messagesMapping SOAP to a transport protocolHTTP as a communication protocolHTTP server sideParameter passingSOAP and HTTPIn XML (a request)In XML (the response)All togetherSOAP summaryWeb Services - Concepts, Architecture and Applications Part 4: Internet Interaction (SOAP)Gustavo Alonso, Cesare PautassoComputer Science DepartmentETH Zü[email protected]://www.inf.ethz.ch/~alonso©ETH Zürich Part 4: SOAP-1 2What is SOAP? The Simple Object Access Protocol (SOAP) was initiated by W3C in 1999. SOAP 1.0 was entirely based on HTTP, and the following version, SOAP 1.1 (May 2000), was more generic since it included other transport protocols. The first draft of SOAP 1.2 was presented in July 2001 and was recently promoted to a “Recommendation”. SOAP covers the following four main areas:Ä A message format for one-way communication describing how a message can be packed into an XML documentÄ A description of how (the XML document that makes up) a SOAP message should be transported through the Web (using HTTP) or e-mail (using SMTP).Ä A set of rules that must be followed when processing a SOAP message and a simple classification of the entities involved in that processing. It also specifies what parts of the messages should be read by whom and how to react in case the content is not understoodÄ A set of conventions on how to turn an RPC call into a SOAP message and back as well as how to implement the RPC style of interaction (how the client side RPC call is translated into a SOAP message, forwarded, turned into a server side RPC call, the reply converted into a SOAP message and returned to the client)©ETH Zürich Part 4: SOAP-1 3The background of SOAP SOAP was originally conceived as the minimal possible infrastructure necessary to perform RPC through the Internet:Ä use of XML as intermediate representation between systems Ä very simple message structureÄ mapping to HTTP for tunneling through firewalls and using the Web infrastructure The idea was to avoid the problems associated with CORBA’s IIOP/GIOP (which fulfilled a similar role, but used a non-standard intermediate representation and had to be tunneled through HTTP anyway) The goal was to have an extension that could be easily layered on top of existing middleware platforms to allow them to interact through the Internet rather than through a LAN, as is typically the case. Hence the emphasis on RPC from the very beginning (essentially all forms of middleware use RPC at one level or another) Eventually SOAP started to be presented as a generic vehicle for computer driven message exchanges through the Internet and then it was open to support interactions other than RPC and protocols other than HTTP. This process, though, is still on-going.©ETH Zürich Part 4: SOAP-1 4Structure of a SOAP message©ETH Zürich Part 4: SOAP-1 5SOAP messages SOAP is based on message exchanges Messages are seen as envelopes where the application encloses the data to be sent A message has two main parts; header and body, which both can be divided into blocks  SOAP does not specify what to do with the header and the body, it only states that the header is optional and the body is mandatory The use of header and body, however, is implicit. The body is for application level data. The header is for infrastructure level dataSOAP EnvelopeSOAP headerHeader BlockSOAP BodyBody Block©ETH Zürich Part 4: SOAP-1 6For the XML fans (SOAP, body only)<SOAP-ENV:Envelopexmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/"SOAP-ENV:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"><SOAP-ENV:Body><m:GetLastTradePrice xmlns:m="Some-URI"><symbol>DIS</symbol></m:GetLastTradePrice></SOAP-ENV:Body></SOAP-ENV:Envelope>From the: Simple Object Access Protocol (SOAP) 1.1. W3C Note 08 May 2000XML name space identifier for SOAP envelope XML name space identifier for SOAP serialization©ETH Zürich Part 4: SOAP-1 7SOAP example, header and body<SOAP-ENV:Envelopexmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/"SOAP-ENV:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"/><SOAP-ENV:Header><t:Transactionxmlns:t="some-URI"SOAP-ENV:mustUnderstand="1">5</t:Transaction></SOAP-ENV:Header><SOAP-ENV:Body><m:GetLastTradePrice xmlns:m="Some-URI"><symbol>DEF</symbol></m:GetLastTradePrice></SOAP-ENV:Body></SOAP-ENV:Envelope>From the: Simple Object Access Protocol (SOAP) 1.1. W3C Note 08 May 2000©ETH Zürich Part 4: SOAP-1 8The SOAP header The header is intended as a generic place holder for information that is not necessarily application dependent (the application may not even be aware that a header was attached to the message). Typical uses of the header are: coordination information, identifiers (for, e.g., transactions) and security information (e.g., certificates) SOAP provides mechanisms to specify who should deal with headers and what to do with them. For this purpose it includes:Ä SOAP role attribute (previously called “actor”): who should process that particular header entry (or header block). The “role” can be either: none, next, ultimateReceiver. ‘None’ is used to propagate information that does not need to be processed. ‘Next’ indicates that a node receiving the message can process that block. ‘ultimateReceiver’ indicates that the header is intended for the final recipient of the messageÄ mustUnderstand attribute: with values true/false (previously 1/0), indicating whether it is mandatory to process the header. If a node can process the message (as indicated by the “role” attribute), the mustUnderstand attribute determines whether it is mandatory to do so.Ä New in SOAP 1.2 is also the relay attribute (forward header if not processed)©ETH Zürich Part 4: SOAP-1 9The SOAP body The body is intended for the application specific data contained in the message  A body entry (or a body block) is syntactically equivalent to a header entry with attributes role = ultimateReceiver and mustUnderstand = 1 Unlike for headers, SOAP does specify the contents of some body entries:Ä mapping of RPC to a collection of SOAP body entriesÄ the Fault


View Full Document

MTU SSE 3200 - Internet Interaction

Download Internet Interaction
Our administrator received your request to download this document. We will send you the file to your email shortly.
Loading Unlocking...
Login

Join to view Internet Interaction and access 3M+ class-specific study document.

or
We will never post anything without your permission.
Don't have an account?
Sign Up

Join to view Internet Interaction 2 2 and access 3M+ class-specific study document.

or

By creating an account you agree to our Privacy Policy and Terms Of Use

Already a member?