Layman's SOAP

Introduction

This is a beginner level article giving basic introduction to SOAP. The purpose of this article is to introduce the SOAP concept. This article does not address 'How to Build a SOAP Server/Client'. I plan to publish a separate article on how to build a SOAP Server/Client soon.

What is SOAP?

SOAP is acronym for Simple Object Access Protocol. Simply put, SOAP = XML + HTTP. SOAP sends XML request to SOAP server over HTTP and receives the response back in XML. Since HTTP is the de facto mode of communication in Internet and all the web servers recognize and respond to HTTP request, it is an ideal protocol to use to enable integration of various systems. XML is emerging as a de facto standard to exchange information over disparate systems. SOAP's use of XML to send/receive message enables any system on any platform to read and process the message, unlike any proprietary format.

What is the need for SOAP?

Before we get into the need for SOAP, let's discuss the problem with existing technologies. Did you ever try to make your COM components distributed? I mean, if COM component resides on a different machine or network, how successful were you in using that component? Not much, uh?

Existing technologies like DCOM or CORBA can make your component distributed. However, DCOM/CORBA uses Remote Procedure Call (RPC) for communication which doesn't work well across Internet. Further, both the client and the server have to have similar or the same system and OS for DCOM/CORBA to work. You may also have to spend some time on setup, to make these solutions work.

For these reasons and more, DCOM/CORBA solutions may not be considered as supporting true distributed components. What I mean by true distributed component is, the client and server can be disparate. The client and server can have different operating systems, run on different kind of machines and network. Since SOAP uses XML over HTTP to communicate, SOAP offers true distributed component support.

Please note that SOAP is not a replacement for COM or CORBA. However, COM/CORBA can use SOAP to enable them work across the Internet.

Jargon

You will encounter all of these jargons below sooner or later and I will give you a basic idea of what these jargons mean.

• WSDL

  WSDL stands for Web Service Description Language. WSDL is an XML document that describes the operations provided by the service. For each operation, WSDL will define the schema for request and response XML string. For e.g. if you provide a web service operation that accepts Farenheit as input and returns Celsius degrees as output, part of the WSDL that describes this will look like below:

  <textarea rows=7 cols=80>
    <message name='TempConverter.FarenheitToCelcius'>
      <PART type="xsd:short" name="Farenheit" />
    </message>
    <message name='TempConverter.FarenheitToCelciusResponse'>
      <PART type="xsd:short" name="Result" />
    </message>
    </textarea>
    

• WSML

  Web Service Meta Language maps a web service operation to a COM component's method. For Farenheit to Celsius degrees web service, WSML will look like below:

  <textarea rows=16 cols=80>
  <?xml version='1.0' encoding='UTF-8' ?> 
   <!-- Generated 06/04/01 by Microsoft SOAP Toolkit WSDL File Generator,
        Version 1.00.623.1 --> 
  <servicemapping name='FtoC'>
    <service name='FtoC'>
      <using PROGID='FtoC.TempConverter.1' cachable='0' 
                 ID='TempConverterObject' />
      <PORT name="TempConverterSoapPort">
        <operation name='FarenheitToCelcius'>
          <execute uses='TempConverterObject' method='FarenheitToCelcius' 
                            dispID='1'>
  <PARAMETER name="Farenheit" elementName="Farenheit" callIndex="1" />
            <PARAMETER name="retval" elementName="Result" callIndex="-1" />
          </execute>
        </operation>
      </PORT>
    </service>
  </servicemapping> 
  </textarea>

Overall process

In this section, I will give you a brief overview of the whole server side and client side process involved in making a SOAP request. The diagram below gives an overall idea of what is involved in making SOAP calls.

• Client side

  • SOAP Client will initiate the process by making a SOAP request. In this process, client will refer the WSDL file which resides in the SOAP server, to form a valid SOAP request. (Steps 1 and 2 in the diagram)
  • Client will send the request to the SOAP server using HTTP.

• Server side

  • SOAP Listener will receive the SOAP request from the client. Theoretically, Listener can be any server side CGI that can process HTTP request. However, Microsoft's SOAP Toolkit 2.0 can only support ASP and ISAPI.
  • Listener will make sure the request adheres to the schema defined in WSDL (Step 3)
  • Once the request is validated, listener will figure out appropriate method to call in the COM component with the help of WSML file.
  • COM method will be called. (Step 4)
  • The result from the COM method (Step 5) will be packaged into SOAP XML response (Step 6) in accordance with the scheme defined in WSDL.

• Client side

  • Client will receive the SOAP response.
  • Client can unpack the SOAP response and read the result.

Note that Microsoft SOAP objects/APIs that are part of Microsoft's SOAP Toolkit will help you to do all of the above processes.

Conclusion

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 building web services using SOAP.