Understanding SOAP 1.1 (Simple Object Access Protocol) Presented by Aimreddy Rakeshkumar
Dec 25, 2015
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: [email protected] To: [email protected] Subject: Which NY airport? Date: Thu, 29 Nov 2001 13:35:11 EST Message-Id: <[email protected]> In-reply-to:<[email protected]> 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………………….