1. Understanding SOAP 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 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.

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

19. Skeleton SOAP Message <?xml version="1.0"?>
<soap:Envelope xmlns:soap=" soap:encodingStyle=“
<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.1 Host: Content-Type: text/xml; charset="utf-8" Content-Length: nnnn SOAPAction: "Some-URI" <soap:Envelope  xmlns:soap=" soap:encodingStyle=" 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/ OK
Content-Type: text/xml; charset="utf-8“
Content-Length: nnnn
<soap:Envelope
xmlns:soap=" schemas.xmlsoap.org/soap/envelope”
soap:encodingStyle=" 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
namespace
Encoding Style Attribute
SOAP encodingStyle attribute is used to define the datatypes used in the document.
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=" >
<SOAP-ENV:Header xmlns:env=" >
<Payment xmlns="
<Name>Elliotte Harold</Name>
<Issuer>VISA</Issuer>
<Number> </Number>
<Expires> </Expires>
</Payment>
</SOAP-ENV:Header>

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

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:
<env:Header>
<p:oneBlock xmlns:p=" env:acotr="
</p:oneBlock>

28. 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=
env:actor="
env:mustUnderstand="true">
</p:oneBlock>
<q:secondBlock xmlns:q=" env:actor=" </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="
env:encodingStyle="
<env:Body> <basic:getFruitPrice xmlns:basic="       <name>apples</name> </basic:getFruitPrice>
 </env:Body>
</env:Envelope>

31. Types of SOAP Bodies (Contd..)
Response
<env:Envelope xmlns:env=" env:encodingStyle="
<env:Body>
<basic:getFruitPriceResponse xmlns:basic=" <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 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 "
Two or more child elements

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

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

35. SOAP Fault Example
<soap:Envelope xmlns:soap=" soap:encodingStyle="
<soap:Body> <soap:Fault>   <faultcode>soap:Client.MissingParameter</faultcode>   <faultstring>A parameter was missing</faultstring>   <faultactor>         <detail>            <w:error xmlns:w="                <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. (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)

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 which points to the XML Schema that defines the encoding rules

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

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:
To:
Subject: Which NY airport?
Date: Thu, 29 Nov :35:11 EST
Message-Id:
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="   <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="   <x:ret xsi:type="xsd:string">THOR</x:ret> </x:ReverseStringresponse>
<x:ReverseStringResponse xmlns:x="  <x:sRev xsi:type="xsd:string">THOR</x:sRev> </x:ReverseStringResponse>
<x:ReverseStringResponse xmlns:x="   <x:s xsi:type="xsd:string">THOR</x:s> </x:ReverseStringResponse>

50. Complete Example for SOAP RPC
POST /call.asp HTTP/1.1 Content-Type: text/xml Content-Length: ### SOAPAction: "urn:livezipcodes“
<soap:Envelope xmlns:soap="     soap:encodingStyle="    xmlns:xsi="     xmlns:xsd=" <soap:Body>  <m:GetZipCode xmlns:m="         <city xsi:type="xsd:string">Modest Town</city>         <state xsi:type="xsd:string">Virginia</state>      </m:GetZipCode>   </soap:Body> </soap:Envelope>
Request RPC Call

51. Complete Example for SOAP RPC
HTTP/ OK Content-Type: text/xml Content-Length: ###
<soap:Envelope xmlns:soap="   soap:encodingStyle="     xmlns:xsi="    xmlns:xsd="   <soap:Body>      <m:GetZipCodeResponse
xmlns:m="         <zip xsi:type="xsd:string">23412</zip>      </m:GetZipCodeResponse>   </soap:Body> </soap:Envelope>
Response for RPC Call

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

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

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

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

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

57. The java.xml.soap Package

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

59. 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.
J2EE and JAX: Developing Web Applications and Web Services by Michael Yawn
The Java API Resources for SOAP:

60. References http://www.w3.org/TR/SOAP/
SOAP Version 1.1 Specification Document from W3C
SOAP Version 1.2 Part 0: Primer
SOAP Version 1.2 Part 1: Messaging Framework
SOAP Version 1.2 Part 2: Adjuncts
Understanding SOAP: The Authoritative Solution by Scribner (Book)
Sample Chapter from Professional XML Web Services\
SOAP explained neatly and easily understandable
XML-RPC vs SOAP by Kate Rhodes

61. Thank You
………………….