Understanding SOAP 1.1 (Simple Object Access Protocol) Presented by Aimreddy Rakeshkumar

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.

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.

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

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).

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.

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.

Why SOAP ? (Contd…)

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

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.

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

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)

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

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.

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

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.

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 Header element (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.

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

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>

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

Example: SOAP Request Message POST /StockQuote HTTP/1.1 Host: www.stockquoteserver.com Content-Type: text/xml; charset="utf-8" Content-Length: nnnn SOAPAction: "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

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

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

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

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>

SOAP Header Attributes MAY have zero or more attribute information items in its [attributes] property. encodingStyle attribute information item actor attribute information item mustUnderstand attribute information item

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>

SOAP Header Attributes (Contd..) mustUnderstand Attribute The SOAP mustUnderstand attribute information item is used to indicate whether the processing of a SOAP header block is mandatory or optional The type of the mustUnderstand attribute 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>

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

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>

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

Types of SOAP Bodies (Contd..) Fault The SOAP Fault element 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

SOAP Fault Child Elements Types of SOAP Bodies (Contd..) Description <faultcode> The faultcode element contains a value that identifies the error condition to the application. This means this value is for machine use and is not intended for the user. VersionMismatch This value indicates that the namespace of the SOAP Envelope element was not http://schemas.xmlsoap.org/soap/envelope MustUnderstand An immediate child element of the SOAP Header element that was either not understood or not obeyed by the processing party contained a SOAP mustUnderstand with a value of "true" Client The Client class of errors indicate that the message was incorrectly formed or did not contain the appropriate information in order to succeed Receiver In contrast to the Client fault code, Server indicates that a problem occurred during processing that was not directly related to the content of the message.

SOAP Fault Child Elements (Contd..) Types of SOAP Bodies (Contd..) Description <faultString> The faultstring element contains a string value that briefly describes the fault that occurred in a way that would make sense if it were displayed to the user in an error dialog. That is not to suggest that it could not be technical in nature. <faultactor> The faultactor element contains a URI that identifies the endpoint where the fault originated. This is especially true in systems that involve SOAP intermediaries. <detail> The detail element is intended for carrying application specific error information related to the SOAP Body. It MUST be present when the contents of the SOAP Body could not be processed successfully. The absence of this indicates that a SOAP Fault is not related to the processing of the SOAP Body.

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>

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.

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

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

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

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>

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>

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>

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

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

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>

SOAP Use Case

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

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>

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>

Complete Example for SOAP RPC POST /call.asp HTTP/1.1 Content-Type: text/xml Content-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

Complete Example for SOAP RPC HTTP/1.1 200 OK Content-Type: text/xml Content-Length: ### <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:GetZipCodeResponse xmlns:m="http://www.livezipcodes.com/methods/">         <zip xsi:type="xsd:string">23412</zip>      </m:GetZipCodeResponse>   </soap:Body> </soap:Envelope> Response for RPC Call

XML-RPC vs SOAP-RPC XML-RPC is a final specification which is less verbose and easier to implement than SOAP. SOAP allows for user record types by extending the XML document using XML Schemas. XML-RPC only allows for the base types defined in the specification SOAP tries to pick up where XML-RPC left off by implementing user defined data types, the ability to specify the recipient, message specific processing control, and other features. SOAP's greatest feature is its ability to step past XML-RPC's limitations and customize every portion of the message. This ability to customize allows developers to describe exactly what they want within their message XML-RPC is defined as operating over an HTTP connection, while SOAP describes the envelope format for an RPC request which may be sent over HTTP, SMTP or some other protocol

SOAP Security Easily pass SOAP messages through existing firewall/routing systems due to SOAP’s use of the existing HTTP protocol. SOAP may utilize any standard HTTP security feature or any endpoint application-specific security feature. SOAP requests are free to take advantage of HTTP authentication mechanisms as well as SSL for secure communications (using HTTPS).

SOAP Limitations SOAP does not specify any details about bi-directional communication. It is possible to layer these semantics on top of a SOAP implementation. Describes how a SOAP payload can be transferred via HTTP, and we can’t expect the functionalities offered by DCOM or RMI. SOAP does not require any particular language for interface description. XML is usually used. Parsing from text requires a large amount of processing power (performance issues).

SOAP and JAVA Technology Java API for XML-Based RPC (JAX-RPC) Member of the JAX* family of APIs: – JAXB, JAXM, JAXP, JAXR, JAX-RPC JAX-RPC enables developers to develop SOAP based interoperable and portable web services. JAX-RPC provides the core APIs for: – To develop web service clients and endpoints JAX-RPC abstracts the underlying runtime mechanisms (for example, SOAP protocol level mechanisms, marshalling and unmarshalling). APIs for RPC-based service definition

SOAP and JAVA Technology (Contd..) Java API for XML Messaging (JAXM) JAXM: Java API for XML Messaging JAXM supports sending and receiving SOAP messages Based on the SOAP 1.1 and the SOAP with Attachment specifications Supports higher-level and application specific protocols built on top of SOAP Intended to work with multiple transports—HTTP, SMTP, etc.

The java.xml.soap Package

Conclusion SOAP does not mandate an API of any kind. SOAP does not attempt to address the more complex distributed object protocol services such as object activation, marshaling objects/references, garbage collection, or bi-directional communications SOAP is inherently SIMPLE! SOAP defines how to access services, objects, and servers in a platform-independent manner using HTTP and XML. SOAP allows an increased level of interoperability.

Resources Building SOAP Messages Article which explains how to build SOAP messages using JAXM API. www-106.ibm.com/developerworks/library/x-jaxmsoap/index.html SOAP 1.1 Validator This application tells us whether our server is working in accordance with the SOAP 1.1 specification or not. http://validator.soapware.org/ J2EE and JAX: Developing Web Applications and Web Services by Michael Yawn http://www.theyawns.com/j2eejax.htm The Java API Resources for SOAP: http://jcp.org http://java.sun.com/xml/jaxrpc/

References http://www.w3.org/TR/SOAP/ SOAP Version 1.1 Specification Document from W3C http://www.w3.org/TR/soap12-part0/ SOAP Version 1.2 Part 0: Primer http://www.w3.org/TR/soap12-part1/ SOAP Version 1.2 Part 1: Messaging Framework http://www.w3.org/TR/soap12-part2/ SOAP Version 1.2 Part 2: Adjuncts Understanding SOAP: The Authoritative Solution by Scribner (Book) http://www.vbip.com/books/1861005091/chapter_5091_06.asp Sample Chapter from Professional XML Web Services\ http://www.soapclient.com/ http://www.sts.tu-harburg.de/papers/2001/Koft01.pdf SOAP explained neatly and easily understandable http://www.perfectxml.com/soap.asp http://weblog.masukomi.org/writings/xml-rpc_vs_soap.htm XML-RPC vs SOAP by Kate Rhodes

Thank You ………………….