Chapter 6: Simple Object Access Protocol (SOAP) What is SOAP?The background for SOAPSOAP 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 messagesSOAP and HTTPIn XML (a request)In XML (the response)All togetherSOAP summarySOAP and the client server modelA first use of SOAPAutomatic conversion RPC - SOAPSOAP exchange patterns (v 1.2)How to implement this with SOAP?Implementing message queuesThe need for attachmentsA possible solutionAttachments in SOAPThe problems with attachmentsSOAP as simple protocolBeyond SOAPebXML messaging serviceebXML and SOAPAdditional features of ebXML messagesChapter 6:Simple Object Access Protocol (SOAP)Gustavo AlonsoComputer Science DepartmentSwiss Federal Institute of Technology (ETHZ)[email protected]://www.iks.inf.ethz.ch/©Gustavo Alonso, ETH Zürich. Web services: Concepts, Architectures and Applications - Chapter 6 2What is SOAP? The W3C started working on SOAP in 1999. The current W3C recommendation is Version 1.2 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 a SOAP message (or the XML document that makes up a SOAP message) should be transported using HTTP (for Web based interaction) or SMTP(for e-mail based interaction)Ä A set of rules that must be followed when processing a SOAP message and a simple classification of the entities involved in processing a SOAP message. 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 makes an RPC call, this is translated into a SOAP message, forwarded, turned into an RPC call at the server, the reply of the server converted into a SOAP message, sent to the client, and passed on to the client as the return of the RPC call)©Gustavo Alonso, ETH Zürich. Web services: Concepts, Architectures and Applications - Chapter 6 3The background for 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 using a non-standard intermediate representation and had to be tunneled through HTTP any way) The goal was to have an extension that could be easily plugged on top of existing middleware platforms to allow them to interact through the Internet rather than through a LAN as it 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 then HTTP. This process, however, is only in its very early stages.©Gustavo Alonso, ETH Zürich. Web services: Concepts, Architectures and Applications - Chapter 6 4SOAP messages SOAP is based on message exchanges Messages are seen as envelops where the application encloses the data to be sent A message has two main parts:Ä header: which can be divided into blocks Ä body: which can be divided into blocks SOAP does not say what to do with the header and the body, it only states that the header is optional and the body is mandatory 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©Gustavo Alonso, ETH Zürich. Web services: Concepts, Architectures and Applications - Chapter 6 5For 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©Gustavo Alonso, ETH Zürich. Web services: Concepts, Architectures and Applications - Chapter 6 6SOAP 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©Gustavo Alonso, ETH Zürich. Web services: Concepts, Architectures and Applications - Chapter 6 7The 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), 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 actor attribute: who should process that particular header entry (or header block). The actor 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 the header is intended for the final recipient of the messageÄ mustUnderstand attribute: with values 1 or 0, indicating whether it is mandatory to process the header. If a node can process the message (as indicated by the actor attribute), the mustUnderstand attribute determines whether it is mandatory to do so. Ä SOAP 1.2 adds a relay attribute (forward header if not processed)©Gustavo Alonso, ETH