Chapter 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 specification is Version 1.2 which was announced in 2007. 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)IIOP: Internet Inter-ORB Protocol; GIOP: General Inter-ORB ProtocolORB: Object Request Protocol 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 4The background for HTTP and MIME The HyperText Transfer Protocol (HTTP) is a network (application layer) protocol for distributed information systems. Ä HTTP is a client/server type protocol. Ä Typically, web browsers or spiders act as clients, and an application running on the computer hosting the web site acts as a server.Ä An HTTP session is a sequence of request-response transactions. An HTTP client initiates a request. Upon receiving the request, the server sends back a status line and a message containing the resource requested or an error message. Multipurpose Internet Mail Extensions (MIME) is an Internet standard that extends the format of e-mail.Ä It supports character sets other than ASCII.Ä In supports non-text attachments such as image/jpeg or audio/mp3.©Gustavo Alonso, ETH Zürich. Web services: Concepts, Architectures and Applications - Chapter 6 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: 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 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©Gustavo Alonso, ETH Zürich. Web services: Concepts, Architectures and Applications - Chapter 6 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©Gustavo Alonso, ETH Zürich. Web services: Concepts, Architectures and Applications - Chapter 6 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 (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