Understanding SOAP 1.1 (Simple Object Access Protocol)

1. UnderstandingSOAP 1.1(Simple Object Access Protocol) Presented by Aimreddy Rakeshkumar

2. Web-Services • "Any application that can be accessed over a network using a combination of HTTP, XML, SMTP is a web service." • The service listener understands the transport protocol (HTTP, SOAP) and decodes these requests which it passes to • The service proxy which decodes them so that it can call the • application code, which is the code that actually does the work.

3. Dynamic Integration • Dynamic Integration is nothing but Just-In-Time Integration of services based on the requirements. • The basic architecture includes the use of servers, clients, and yellow pages. • The Service provider publishes a description to the • Service registry which is queried by the • Service consumer who, upon receiving a response can access the service provider of his choosing.

4. Web-Service Stack • Discovery: fetch descriptions of providers. UDDI, WS-Inspection. • Description: describe services. WSDL. • Packaging: is serialization or marshalling. SOAP. • Transport: application-to-application communication. HTTP, SMTP, TCP, Jabber. • Network: network layer. TCP/IP

5. SOAP Introduction SOAP stands for “Simple Object Access Protocol”, a relatively new protocol for distributed applications developed by Microsoft, IBM, DevelopMentor, and UserLand. SOAP is highly “flexible“ and can support different applications; however, the most important one is to enable remote procedure calls (RPC) over HTTP using XML. SOAP is used for • Passing documents: Electronic Document Interchange (EDI). • Remote Procedure Calls (RPC).

6. Why SOAP ? • Before XML only two main options to move data: Electronic Data Exchange Build a distributed object infrastructure • CORBA, RMI and DCOM do not communicate easily with each other because of lack of standards between them, and can communicate through special sockets and ports that required adding extra layers to an already complex architecture.  CORBA uses Internet Inter-ORB Protocol (IIOP) to handle objects communication. RMI uses Java Remote Method Protocol (JRMP) to handle objects communication. DCOM uses Object Remote Procedure Call (ORPC) to handle objects communication.

7. Why SOAP ?(Contd…) • But with XML data is easily transferred by using Web Protocols instead of to be tied to transport or language, this lead to building of loosely coupled systems around Internet protocols. • SOAP has a ability to move data anywhere across the Web. • SOAP combines the data capabilities of XML with the transport capability of Web protocols, thereby overcoming the drawbacks of both EDI and tightly coupled distributed object systems such as CORBA, RMI, and DCOM • With platform, language and transport independent characteristics, SOAP can be used to build loosely coupled distributed data exchange systems.  SOAP uses HTTP, FTP, SMTP to handle SOAP messages communication.

8. Why SOAP ?(Contd…)

9. History of SOAP • SOAP 0 (1998) • Microsoft, DevelopMentor • XML-RPC (1998) • Subset of SOAP • ebXML (1999) • Electronic Business XML • Messaging for multiparty transactions • SOAP 1.0 & 1.1 (2000) • SOAP 1.2 (2001 working draft) • Messaging and RPC

10. SOAP Uses HTTP and XML • SOAP uses existing technologies, and not inventing any new technologies for its support • XML and HTTP are accepted and deployed on all platforms • SOAP adds a set of HTTP headers and a rich XML payload to enable complex application-to-application communication over the Internet.

11. Why HTTP ? • HTTP has become the de facto protocol of the Internet • HTTP is available on all platforms • HTTP is a simple protocol that requires little runtime support to work properly • HTTP is barely connection-oriented • Few/no packets exchanged to set up/maintain sessions • HTTP typically the only thing usable over firewalls

12. Why XML ? • XML is platform neutral data representation protocol. • XML contains no fixed set of tags and users can build their own customized tags. • XML widely adopted across platforms • XML is text-based and easy to handle and it can be easily extended • Parsing XML documents is easy for retrieving the information (Using SAX or DOM)

13. Specification of SOAP Soap doesn’t care about: Operating System Programming Language Object Model SOAP extends HTTP with: Headers XML payload This is to enable complex app-app communica-tion over the net

14. Components of SOAP SOAP consists of three parts: • The SOAP Envelope • is a construct that defines an overall framework for expressing what is in a message, who should deal with it, and whether it is optional or mandatory. • The SOAP Encoding Rules • defines a serialization mechanism that can be used to exchange instances of application-defined datatypes. • The SOAP RPC Representation • defines a convention that can be used to represent remote procedure calls and responses.

15. SOAP Messages • A Valid SOAP Message is a well-formed XML document • SOAP Message consists of: • An XML Declaration (optional ) followed by • A SOAP Envelope (the root element) which includes • A SOAP Header (optional) • A SOAP Body

16. SOAP Message Exchange Model • SOAP messages are one-way transmissions. But, they are often combined to form patterns such as request/response. • SOAP nodes can be the sender, receiver, or any intermediary. SOAP does not provide a routing mechanism. • When processing a message, a node is said to take the role of a SOAP actor. • Every SOAP node must be able to act as an actor • No SOAP node should act as none, these are meant for the final receiver.

17. SOAP Envelope Structure • The whole message is contained inside an Envelope element. • The Envelope must contain exactly one Body element. • The Body element may contain as many child nodes as are required. • The contents of the Body element are the message. • If an Envelope contains a Headerelement (it can't have more) it must appear as the first child of the Envelope. • The contents of the Header and Body are application-dependent.

18. The complete SOAP Message SOAP Message Standard HTTP and SOAP HTTP Headers <Envelope> encloses payload SOAP Envelope HTTP Headers SOAP Header <Header> encloses headers Individual headers Headers SOAP Body <Body> contains SOAP Method Call XML Encoded SOAP Method Call & Data Method Call & Data Detail Structure of SOAP Message

19. Skeleton SOAP Message <?xml version="1.0"?> <soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/" soap:encodingStyle=“http://schemas.xmlsoap.org/soap/encoding"> <soap:Header> ... ... </soap:Header> <soap:Body> ... ... <soap:Fault> ... ... </soap:Fault> </soap:Body> </soap:Envelope>

20. SOAP Message Syntax Rules Important syntax rules: • A SOAP message MUST be encoded using XML • A SOAP message MUST use the SOAP Envelope namespace • A SOAP message MUST use the SOAP Encoding namespace • A SOAP message must NOT contain a DTD reference • A SOAP message must NOT contain XML Processing Instructions

21. Example: SOAP Request Message POST /StockQuote HTTP/1.1Host: www.stockquoteserver.comContent-Type: text/xml; charset="utf-8"Content-Length: nnnnSOAPAction: "Some-URI"<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope" soap:encodingStyle="http:// schemas.xmlsoap.org/soap/encoding">    <soap:Body>       <m:GetLastTradePrice xmlns:m="Some-URI">           <symbol>DIS</symbol>       </m:GetLastTradePrice>   </soap:Body></soap:Envelope

22. Example: SOAP Response Message HTTP/1.1 200 OK Content-Type: text/xml; charset="utf-8“ Content-Length: nnnn <soap:Envelope xmlns:soap="http:// schemas.xmlsoap.org/soap/envelope” soap:encodingStyle="http:// schemas.xmlsoap.org/soap/encoding">    <soap:Body>       <m:GetLastTradePriceResponse xmlns:m="Some-URI">           <Price>34.5</Price>       </m:GetLastTradePriceResponse>   </soap:Body> </soap:Envelope

23. SOAP Envelope Element Mandatory SOAP Envelope is the root element xmlns:soap Namespace A SOAP Message must always have an Envelope element associated with the http://schemas.xmlsoap.org/soap/envelope/ namespace Encoding Style Attribute SOAP encodingStyle attribute is used to define the datatypes used in the document. http:// schemas.xmlsoap.org/soap/encoding A SOAP message has no default encoding

24. SOAP Header Element Optional Header element provides meta-information about the request. For example, passing directives or contextual information related to the processing of the message. This allows a SOAP message to be extended in an application-specific manner Things that can be exchanged in headers include: • Protocols the server must understand to process the request. • A digital signature for the body of the message • A schema for the XML application used in the body • Credit card info to pay for the processing • A public key to be used to encrypt the response

25. SOAP Header: Example <?xml version="1.0"?> <SOAP-ENV:Envelope xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/" > <SOAP-ENV:Header xmlns:env="http://www.w3.org/2003/05/soap-envelope" > <Payment xmlns="http://namespaces.cafeconleche.org/xmljava/ch2/"> <Name>Elliotte Harold</Name> <Issuer>VISA</Issuer> <Number>5125456787651230</Number> <Expires>2005-12</Expires> </Payment> </SOAP-ENV:Header>

26. SOAP Header Attributes MAY have zero or more attribute information items in its [attributes] property. • encodingStyleattribute information item • actorattribute information item • mustUnderstandattribute information item

27. SOAP Header Attributes (Contd..) ACTOR Attribute SOAP defines the (optional) env:actor attribute - syntactically, xs:anyURI - that may be present in a header block, which identifies the role played by the intended target of that header block. Three standardized roles have been defined: • http://www.w3.org/2003/05/soap-envelope/role/none • http://www.w3.org/2003/05/soap-envelope/role/next • http://www.w3.org/2003/05/soap-envelope/role/ultimateReceiver <env:Header> <p:oneBlock xmlns:p="http://example.com" env:acotr="http://example.com/Log"> ... ... </p:oneBlock>

28. SOAP Header Attributes (Contd..) mustUnderstand Attribute The SOAP mustUnderstandattribute information item is used to indicate whether the processing of a SOAP header block is mandatory or optional The type of the mustUnderstandattribute information item is xs:boolean. <env:Header> <p:oneBlock xmlns:p=http://example.com env:actor="http://example.com/Log" env:mustUnderstand="true"> ... ... </p:oneBlock> <q:secondBlock xmlns:q="http://example.com" env:actor="http://www.w3.org/2003/05/soap-envelope/role/next"> ... ... </q:anotherBlock>

29. SOAP Body Element The SOAP Body element provides a simple mechanism for exchanging mandatory information intended for the ultimate recipient of the message. The SOAP Body element contains the data for either the receiving or sending application. Typical uses of the Body element include marshalling RPC calls and error reporting

30. Types of SOAP Bodies There are Three kinds of SOAP Bodies: • Request <env:Envelope xmlns:env="http://www.w3.org/2003/05/soap-envelope“ env:encodingStyle="http://www.w3.org/2003/05/soap-encoding"> <env:Body><basic:getFruitPrice xmlns:basic="http://www.foodbasic.ca/price">      <name>apples</name></basic:getFruitPrice>  </env:Body> </env:Envelope>

31. Types of SOAP Bodies (Contd..) • Response <env:Envelope xmlns:env="http://www.w3.org/2003/05/soap-envelope"env:encodingStyle="http://www.w3.org/2003/05/soap-encoding"> <env:Body> <basic:getFruitPriceResponse xmlns:basic="http://www.foodbasic.ca/price"> <price>$1.35/kg</price> </basic:getFruitPriceResponse> </env:Body> </env:Envelope> Each response message must contain the name of the method with "Response" at the end

32. Types of SOAP Bodies (Contd..) • Fault The SOAP Faultelement information item is used to carry error and/or status information within a SOAP message. If a Fault element is present, it must appear as a child element of the Body element. Detail information for faults resulting from headers are carried in the header. The Fault element has: • A element name of Fault . • A namespace name of "http://www.w3.org/2003/05/soap-envelope". • Two or more child elements

33. SOAP Fault Child ElementsTypes of SOAP Bodies (Contd..)

34. SOAP Fault Child Elements (Contd..)Types of SOAP Bodies (Contd..)

35. SOAP Fault Example <soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"soap:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"> <soap:Body><soap:Fault>  <faultcode>soap:Client.MissingParameter</faultcode>  <faultstring>A parameter was missing</faultstring>  <faultactor>http://www.wrox.com/heroes/endpoint.asp</faultactor>        <detail>            <w:error xmlns:w="http://www.wrox.com/">               <code>178</code>               <desc>The codename parameter was missing.</desc>            </w:error>        </detail> </soap:Fault>  </soap:Body> </soap:Envelope>

36. Processing SOAP Messages • Determine the set of roles in which the node is to act. • Identify all header blocks targeted at the node that are mandatory. • If one or more of the header blocks identified in the preceding step are not understood by the node then generate a single SOAP MustUnderstand fault and stop processing. • Process all header blocks targeted at the node and, in the case of the ultimate SOAP recipient, the SOAP body. • In the case of a SOAP intermediary, and where the message is to be forwarded further along the message path, remove all SOAP header blocks targeted at the node, and possibly insert new SOAP header blocks.

37. SOAP System SOAP System XML Encoding XML Decoding Packaging Retrieving Underlying protocol support Underlying protocol support SOAP Architecture Sender Receiver Whatever SOAP Message Binding Bound SOAP Request Network (with intermediaries)

38. SOAP Encoding • The ability to decide on a set of rules for representing data in a message is very important to the open nature of SOAP. The encodingStyle attribute defined by the SOAP specification is used to identify the encoding rules used in a particular message. • The SOAP Specification defines a single set of encoding rules that are referred to as SOAP encoding. SOAP encoding is based on XML Schemas • The value of the encodingStyle attribute for SOAP encoding is http://schemas.xmlsoap.org/soap/encoding/, which points to the XML Schema that defines the encoding rules

39. SOAP Encoding (Contd..) Simple Data Types • PrimitivesTypes provided in XML Schema such as boolean, string, integer, long and so on. • EnumerationsElementscan be limited to contain one item from a list of acceptable options.  For example, a color set: red, blue, yellow.. • Byte ArraysSOAP allow you to encode binary information into a message called byte arrays.  • PolymorphismIn this type the specific data type is not chosen until runtime.  This kind of variable belong to polymorphism type.

40. SOAP Encoding (Contd..) Simple Types Examples: 1. The following id the schema format: <element name="age" type="int"/><element name="height" type="float"/><element name="displacement" type="negativeInteger"/><element name="color">  <simpleType base="xsd:string">    <enumeration value="Green"/>    <enumeration value="Blue"/>  </simpleType> </element> Implementation of the Schema:<age>45</age><height>5.9</height><displacement>-450</displacement><color>Blue</color>  <picture xsi:type="SOAP-ENC:base64">   aG93IG5vDyBicm73biBjb3cNCg== </picture>

41. SOAP Encoding (Contd..) Compound Types • Structures: A structure can contain several different types variable.  The following is an example of a struct of type "Book": <e:Book>   <author>Henry Ford</author>   <preface>Prefatory text</preface>   <intro>This is a book.</intro> </e:Book> And this is a schema fragment describing the above structure: <element name="Book"><complexType>  <element name="author" type="xsd:string"/>  <element name="preface" type="xsd:string"/>   <element name="intro" type="xsd:string"/></complexType> </e:Book>

42. SOAP Encoding (Contd..) Compound Types • Arrays: SOAP arrays are defined as having a type of "SOAP-ENC:Array" The following example is a schema fragment: <element name="myArray" type="SOAP-ENC:Array"/> The follwing is the implementation of the schema: <myArray  SOAP-ENC:arrayType="xsd:int[2]">   <number>3</number>    <number>4</number> </myArray>

43. SOAP HTTP Binding SOAP HTTP GET Usage Using the HTTP binding with the SOAP Response message exchange pattern is restricted to the HTTP GET method. This means that the response to a HTTP GET request from a requesting SOAP node is a SOAP message in the HTTP response. Example: GET /travelcompany.example.org/reservations?code=FT35ZBQ HTTP/1.1 Host: travelcompany.example.org Accept: text/html, application/soap+xml

44. SOAP HTTP Binding (Contd..) SOAP HTTP POST Usage (Mostly Used) Using the HTTP binding with the SOAP Request-Response message exchange pattern is restricted to the HTTP POST method. The use of this message exchange pattern in the SOAP HTTP binding is available to all applications, whether they involve the exchange of general XML data or RPCs encapsulated in SOAP messages Example: POST /Reservations?code=FT35ZBQ HTTP/1.1 Host: travelcompany.example.org Content-Type: application/soap+xml; charset="utf-8" Content-Length: nnnn

45. SOAP Email Binding • It is also possible to use email as the transport. • SOAP messages can either be the text or an attachment. • This might look like: From: reservations@travelcompany.example.org To: john.public@mycompany.example.com Subject: Which NY airport? Date: Thu, 29 Nov 2001 13:35:11 EST Message-Id: <200101753.N655@travelcompany.example.org> In-reply-to:<EE492311A096@mycompany.example.com> Following by the <SOAP Message Content>

46. SOAP Use Case

47. SOAP RPC • One of the design goals of SOAP is to encapsulate and exchange RPC calls using the extensibility and flexibility of XML • SOAP RPC uses a request-response model for message exchanges • To make a method call, the following information is needed: The URI of the target object A method name An optional method signature The parameters to the method Optional header data

48. SOAP RPC (Contd..) The Request: Making a remote procedure call with SOAP just involves building a SOAP message. The message that is sent to the endpoint represents the call. The payload of that request message contains a struct that is the serialized method call. The child elements of that struct are the inbound parameters of the method. Example: 1. string ReverseString ( [in] string s );2. void ReverseString ( [in] string s, [out] string sRev );3. void ReverseString ( [in, out] string s ); <x:ReverseString xmlns:x="http://www.wrox.com/">  <s xsi:type="xsd:string">ROHT</s></x:ReverseString>

49. SOAP RPC (Contd..) The Response: Just as the call is represented in the request SOAP message, the results of the call are returned in the response SOAP message. The payload in the response also contains a struct, and the child elements are the outbound parameters and/or the return value of the method. Output: <x:ReverseStringResponse xmlns:x="http://www.wrox.com/"><x:ret xsi:type="xsd:string">THOR</x:ret> </x:ReverseStringresponse> <x:ReverseStringResponse xmlns:x="http://www.wrox.com/"><x:sRev xsi:type="xsd:string">THOR</x:sRev> </x:ReverseStringResponse> <x:ReverseStringResponse xmlns:x="http://www.wrox.com/"><x:s xsi:type="xsd:string">THOR</x:s> </x:ReverseStringResponse>

50. Complete Example for SOAP RPC POST /call.asp HTTP/1.1Content-Type: text/xmlContent-Length: ###SOAPAction: "urn:livezipcodes“ <soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"    soap:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"    xmlns:xsi="http://www.w3.org/1999/XMLSchema-instance"    xmlns:xsd="http://www.w3.org/1999/XMLSchema"> <soap:Body> <m:GetZipCode xmlns:m="http://www.livezipcodes.com/methods/">        <city xsi:type="xsd:string">Modest Town</city>        <state xsi:type="xsd:string">Virginia</state>     </m:GetZipCode>  </soap:Body></soap:Envelope> Request RPC Call