This article has been excerpted from book "The Complete Visual C# Programmer's Guide" from the Authors of C# Corner.
Simple Object Access Protocol (SOAP) is an industry-standard protocol designed to improve cross platform interoperability by using the World Wide Web and Extensible Markup Language (XML). With the advent of XML as a standard document-tagging syntax, derivatives began appearing in the arena. XML evolved into SOAP, and SOAP has since evolved into BizTalk. Thus, SOAP and BizTalk are indeed nothing but specialized XML documents. Prior to the appearance of SOAP, Microsoft implemented COM+ (an extension of Component Object Model), Java proponents supported Enterprise JavaBeans (EJB), and other companies supported Common Object Request Broker Architecture (CORBA). In fact, all these models tried to make remote component usage easy and secure. However, they only handle components of the same style that is; none of them is able to communicate with the others. SOAP has now made this possible. It solves the problem of platform incompatibility in accessing data. It is a syntax that allows you to build applications for remotely invoking methods on objects. SOAP removes the requirement that two systems must run on the same platform or be written in the same programming language. Instead of invoking methods through a proprietary binary protocol, a SOAP package uses an open standard syntax for making method calls. That syntax is XML.
SOAP is simply equal to XML plus Hypertext Transfer Protocol (HTTP). SOAP sends an XML request to a SOAP server over HTTP and receives the response back in XML. Because HTTP is the de facto mode of communication on the Internet, with all Web servers recognizing and responding to an HTTP request, it is an ideal protocol for enabling the integration of various systems. XML is emerging as a de facto standard to exchange information among disparate systems. SOAP's use of XML to send and receive messages ensures that any system on any platform can read and process the message, unlike with a proprietary format.
Existing technologies such as Distributed Component Object Model (DCOM) or CORBA enable components to be distributed; however, DCOM and CORBA use remote procedure call (RPC) for communication, which doesn't work well across the Internet. Further, both the client and server must have the same or similar systems and operating systems for DCOM or CORBA to work. Setup time may also be needed to make these solutions work. For these reasons, we do not regard the DCOM and CORBA solutions as supporting true distributed components. With true distributed components, the client and server can be disparate. The client and server can have different operating systems and run on different kinds of machines and networks. Because SOAP uses XML over HTTP to communicate, it offers true distributed component support.
SOAP is not a replacement for COM or CORBA; however, COM and CORBA can use SOAP to enable them to work across the Internet. SOAP uses the common standards XML and HTTP to promote interoperability between heterogeneous systems anywhere on the Internet. Web services are fast emerging as a new solution paradigm, and it won't be too long before you start using SOAP to build Web services. Web services expose data through the Web without formatting it. Think of Web services as applications that make it possible for you to program using data available on the Web, just as you can program now using data available internally. Applications on different platforms have only a limited ability to share data. In recognition of those limitations, developers have pushed overwhelmingly for the establishment of standards for data formats and for data exchange. This push stems from a vision that is rapidly evolving into a new computing paradigm: the seamless, Web-enabled integration of services across traditional hardware and software barriers.
Introduction to SOAP
A SOAP document is an electronic envelope into which you place your payload. The payload consists of the tags that describe the method you want to invoke and the data that method invocation needs to do its job. A SOAP envelope document has two sub elements the SOAP:Header and SOAP:Body. The SOAP:Header element contains information about the transaction. The Body contains the content data. (Note that in our examples we will refer to HTTP protocol when we mean SOAP communication protocol, but other protocols will be supported by new SOAP versions.)
As you can see in Figure 23.1, a SOAP client submits a request (XML-formatted) over any SOAPsupported protocol (e.g., HTTP) to a "listener" SOAP server at another site. This listening server captures the message, interprets the request, and invokes a method on an object in its domain. That object returns something useful (XML-formatted response) to our application by responding through the SOAP server to our waiting client application.
![figure 23.1.gif]()
Please note that the object being invoked does not need any kind of modification. The SOAP server will interpret the SOAP XML document that comes over the HTTP, Transmission Control Protocol (TCP), or Simple Mail Transfer Protocol (SMTP) connection. Then the SOAP server turns the XML document into something meaningful that the object understands. The SOAP server speaks the SOAP language and the language of the object being called, translating conversation between them. We can say that the SOAP server acts as an interpreter. Consequently, the object can be developed in any programming language on any operating system or platform.
A SOAP package (Figure 23.2) simply contains information used to call a method. But the SOAP specification does not define how that method is to be called. It just contains what to call with what, not how to call. This makes the client and server communication loosely coupled and more free. On the other hand, some things SOAP does not do as well. It does not provide any means for bidirectional communication, type safety, distributed garbage collection, or messages that contain more than one business document (a SOAP message can contain only one business document!). However, SOAP allows us to pass parameters and commands between HTTP, TCP, and SMTP clients and servers, and this is done independent of any platforms, operating systems, or applications. Of course, the commands and parameters passed back and forth are all encoded in SOAP Client Application Requesting Data SOAP Server Remote Object Currently Only HTTP/HTTPS, but in the Future, SMTP, FTP, or Other Protocol Implemented by SOAP XML syntax. XML provides us a formatting syntax with which to express almost any kind of data. Refer to the XML chapter if you need a refresher on XML.
![figure 23.2.gif]()
The SOAP specification defines the SOAP elements that can be used with a SOAP request: they are the envelope, head, and body. The envelope is a container for the head and body. The head contains information about the SOAP message, and the body contains the actual message. Namespaces are used to distinguish the SOAP elements from the other elements of the payload. For example, SOAPENV: Envelope, SOAP-ENV:Head, and SOAP-ENV:Body are used in a SOAP document. Listing 23.1 shows a SOAP schema for the envelope of SOAP 1.1.
Listing 23.1: SOAP Schema for the Envelope of SOAP 1.1
<?xml version="1.0" ?>
<!-- XML Schema for SOAP v 1.1 Envelope -->
<!-- Copyright 2000 DevelopMentor, International Business
Machines Corporation, Lotus Development Corporation,
Microsoft, UserLand Software -->
<schema xmlns="http://www.w3.org/1999/XMLSchema"
xmlns:tns="http://schemas.xmlsoap.org/soap/envelope/"
targetNamespace="http://schemas.xmlsoap.org/soap/envelope/">
<!-- SOAP envelope, header, and body -->
<element name="Envelope" type="tns:Envelope"/>
<complexType name="Envelope">
<element ref="tns:Header" minOccurs="0"/>
<element ref="tns:Body" minOccurs="1"/>
<any minOccurs="0" maxOccurs="*"/>
<anyAttribute/>
</complexType>
<element name="Header" type="tns:Header"/>
<complexType name="Header">
<any minOccurs="0" maxOccurs="*"/>
<anyAttribute/>
</complexType>
<element name="Body" type="tns:Body"/>
<complexType name="Body">
<any minOccurs="0" maxOccurs="*"/>
<anyAttribute/>
</complexType>
<!-- Global Attributes. The following attributes are
intended to be usable via qualified attribute names on any complex type referencing them.-->
<attribute name="mustUnderstand" default="0">
<simpleType base="boolean">
<pattern value="0|1"/>
</simpleType>
</attribute>
<attribute name="actor" type="uri-reference"/>
<!-- 'encodingStyle' indicates any canonicalization conventions followed in the contents of the containing
element. For example, the value
'http://schemas.xmlsoap.org/soap/encoding/' indicates
the pattern described in SOAP specification. -->
<simpleType name="encodingStyle" base="uri-reference"
derivedBy="list"/>
<attributeGroup name="encodingStyle">
<attribute name="encodingStyle"
type="tns:encodingStyle"/>
</attributeGroup>
<!-- SOAP fault reporting structure -->
<complexType name="Fault" final="extension">
<element name="faultcode" type="qname"/>
<element name="faultstring" type="string"/>
<element name="faultactor" type="uri-reference"
minOccurs="0"/>
<element name="detail" type="tns:detail" minOccurs="0"/>
</complexType>
<complexType name="detail">
<any minOccurs="0" maxOccurs="*"/>
<anyAttribute/>
</complexType>
</schema>
When we use HTTP, we use the POST request method because with this method, as opposed to the GET method, the size of the HTTP headers is unlimited. We will see two types of headers in HTTP-request headers and response headers. Please refer to the document RFC2616 (Hypertext Transfer Protocol-HTTP 1.1 by R. Fielding et al.) for more details about HTTP implementation details. Listing 23.2 shows an example of an HTTP POST request header. You can add any headers you like to HTTP-for example, in Listing 23.2 SOAPAction is a SOAP-added HTTP header referring to the remote method, UpdateData, to be invoked and its Uniform Resource Locator (URL).
Listing 23.2: HTTP POST Request Header
POST /Order HTTP/1.1
Host: www.mindcracker.com
Content-Type: text/xml
Content-Length: nnnn
SOAPAction: "http://www.mindcracker.com#UpdateData"
Information being sent would be located here.
Listing 23.3 shows a good response-type HTTP header.
Listing 23.3: Good HTTP Response Header
200 OK
Content-Type: text/plain
Content-Length: nnnn
Content goes here.
Listing 23.4 shows a bad HTTP response header.
Listing 23.4: Bad HTTP Response Header
400 Bad Request
Content-Type: text/plain
Content-Length: 0
A SOAP request document without HTTP headers is shown in Listing 23.5.
Listing 23.5: SOAP Request Document Without HTTP Headers
<SOAP-ENV:Envelope
xmlns:xsi="http://www.w3.org/1999/XMLSchema/instance"
xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope"
xsi:schemaLocation=
"http://www.mindcracker.com/schemas/Schema.xsd">
<SOAP-ENV:Header xsi:type="MindcrackerHeader">
<COM:GUID xmlns:COM="http://comobject.northwindtraders.com">
10000000-0000-abcd-0000-000000000001
</COM:GUID>
</SOAP-ENV:Header>
<SOAP-ENV:Body xsi:type="MindcrackerBody">
<OrderUpdate>
<orderID>0</orderID>
<item>89</item>
</OrderUpdate>
</SOAP-ENV:Body>
</SOAP-ENV:Envelope>
Listing 23.6 shows a SOAP body schema-the contents of the file http://www.mindcracker.com/schemas/Schema.xsd.
Listing 23.6: Schema.xsd File Contents
<xsd:schema xmlns:xsd="http://www.w3.org/1999/XMLSchema"
targetNamespace="http://schemas.xmlsoap.org/soap/envelope"
xmlns:SOAP="http://schemas.xmlsoap.org/soap/envelope">
<xsd:complexType name="MindcrackerHeader">
<xsd:element name="GUID" type="string"/>
</xsd:complexType>
<xsd:complexType name="MindcrackerBody">
<xsd:element name="OrderUpdate">
<xsd:complexType>
<element name="orderID" type="integer"/>
<element name="item" type="double"/>
</xsd:complexType>
</xsd:element>
</xsd:complexType>
</xsd:schema>
A successful SOAP response document is shown in Listing 23.7.
Listing 23.7: Successful SOAP Response Document
<SOAP-ENV:Envelope
xmlns:xsi="http://www.w3.org/1999/XMLSchema/instance"
xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope"
xsi:schemaLocation=
"http://www.mindcracker.com/schemas/Schema.xsd">
<SOAP-ENV:Body xsi:type="MindcrackerBody">
<OrderUpdate>
<orderID>09999</orderID>
<return>0</return>
</OrderUpdate>
</SOAP-ENV:Body>
</SOAP-ENV:Envelope>
Listing 23.8 shows a faulty SOAP response document. The transaction has failed for the reason noted in the error message.
Listing 23.8: Faulty SOAP Response Document
<SOAP-ENV:Envelope
xmlns:xsi="http://www.w3.org/1999/XMLSchema/instance"
xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope"
xsi:schemaLocation=
"http://www.mindcracker.com/schemas/Schema.xsd">
<SOAP-ENV:Fault>
<SOAP-ENV:faultcode>200</SOAP-ENV:faultcode>
<SOAP-ENV:faultstring>
Must Understand Error
</SOAP-ENV:faultstring>
<SOAP-ENV:detail xsi:type="Fault">
<errorMessage>
The object cannot be found or is not installed.
</errorMessage>
</SOAP-ENV:detail>
</SOAP-ENV:Fault >
</SOAP-ENV:Body>
</SOAP-ENV:Envelope>
Following is an example of a C# SOAP server/client with the UpdateData method declaration:
public int OrderUpdateMethod(ref int OrderID, double Item);
More information about SOAP encoding is available at http://www.w3.org/tr/soap. SOAP is used extensively by developers working with .NET Remoting, Web services (ASP.NET), and Active Template Library (ATL) Server's C++ native, unmanaged Web services code.
Conclusion
Hope this article would have helped you in understanding SOAP and .NET Remoting. See other articles on the website on .NET and C#.
![visual C-sharp.jpg]() |
The Complete Visual C# Programmer's Guide covers most of the major components that make up C# and the .net environment. The book is geared toward the intermediate programmer, but contains enough material to satisfy the advanced developer. |