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

UnderstandingSOAP 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 IntroductionSOAP 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 ModelSOAP extends HTTP with: Headers XML payloadThis is to enable complex app-app communica-tion over the net

Components of SOAPSOAP 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 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.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

Example: SOAP Response Message

HTTP/1.1 200 OKContent-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 ElementMandatory SOAP Envelope is the root elementxmlns:soap Namespace A SOAP Message must always have an Envelope

element associated with the http://schemas.xmlsoap.org/soap/envelope/

namespaceEncoding Style Attribute SOAP encodingStyle attribute is used to define the

datatypes used in the document. http:// schemas.xmlsoap.org/soap/encodingA SOAP message has no default encoding

SOAP Header ElementOptional 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 AttributesMAY 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 ElementThe 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 BodiesThere are Three kinds of SOAP Bodies:1. 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..)

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

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

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

Child Elem. 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 Messages1. Determine the set of roles in which the node is to act. 2. Identify all header blocks targeted at the node that are

mandatory. 3. 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.

4. Process all header blocks targeted at the node and, in the case of the ultimate SOAP recipient, the SOAP body.

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

SOAP Architecture

Underlying protocol support

Network(with intermediaries)

Binding

SOAP System

Packaging

XML Encoding

SOAP System

Retrieving

XML DecodingSOAP Message

Bound SOAP Request

Underlying protocol support

Whatever

Sender Receiver

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 Types1. Primitives

Types provided in XML Schema such as boolean, string, integer, long and so on.

2. EnumerationsElements can be limited to contain one item from a list of acceptable options.  For example, a color set: red, blue, yellow..

3. Byte ArraysSOAP allow you to encode binary information into a message called byte arrays. 

4. PolymorphismIn 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 Types1. 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 Types2. 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 BindingSOAP HTTP GET UsageUsing 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 messagesExample: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/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

Complete Example for SOAP RPC HTTP/1.1 200 OKContent-Type: text/xmlContent-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 TechnologyJava 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.orghttp://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………………….