Enterprise Software

An introduction to the Simple Object Access Protocol (SOAP)

How does Simple Object Access Protocol (SOAP) work, and what does it offer your company? TechRepublic's director of application development, Brian Moore, comes clean on SOAP.


By Brian Moore

The Electronic Business XML (ebXML) standards body announced in March that it will incorporate Simple Object Access Protocol (SOAP) into its messaging specifications. According to Gartner, this move points to a clearer choice for enterprises that have been pondering whether to embrace SOAP or MIME for messaging specifications. (TechRepublic is an independent subsidiary of Gartner.)

SOAP is used primarily for making remote procedure calls across machine and network boundaries. SOAP has these primary advantages:
  • Posting data over the HTTP protocol means not only that the delivery mechanism is widely available but also that SOAP is able to get past firewalls that pose problems for other methods.
  • SOAP uses the open standard of XML to format the data, which makes it easily extendable and well supported.
  • Because SOAP is a wire protocol based on XML and HTTP, it is possibly the most widely interoperable protocol to date.

SOAP will change the way we design systems, making it easier to take advantage of third-party software via Web services.

In this article, I’ll provide an overview of how SOAP works and which systems support this protocol and I’ll explain how SOAP is leading to the rise in “Web services.”

How it works
SOAP primarily uses the standard HTTP request/response model (see Figure A).

The client wraps a method call in SOAP/XML, which is then posted over HTTP to the server. The XML request is parsed to read the method name and parameters passed and delegated for processing. The XML response is then sent back to the client, containing the return value—or fault data—of the method call. Finally, the client may parse the response XML to make use of the return value.

Figure A
SOAP uses the standard HTTP request/response model.


The server uses a “listener” to process SOAP requests. The listener is simply the server code at the specified URL for parsing the XML request, making the procedure call, and wrapping the result in XML to send as the response (see Figure B).

Figure B
Data flow of a SOAP call


But HTTP is not the only transfer protocol that SOAP supports. In version 1.1 of SOAP, the specification was expanded to cover other transfer protocols such as Simple Mail Transfer Protocol (SMTP), File Transfer Protocol (FTP), or any other protocol that can transfer text. These other protocols could be used to make asynchronous SOAP calls, meaning the client application could invoke the SOAP service but would not have to wait for a response from the server.

Uses for SOAP
SOAP is fueling the rapid rise of “Web services,” which have the potential to change the face of Internet application development.

Web services are Internet-based modules that perform a specific business task. The service publishes the interface used to interact with it in Web Service Description Language (WSDL), and other applications can invoke the service by making SOAP calls.

For example, let’s assume for a moment that you have an application that keeps up-to-the-minute weather information by ZIP code. You want to provide this information as a service to a new segment of customers—other Web applications. You simply define the interface for the SOAP call, which requires the invoker to pass the requested ZIP code in a SOAP envelope, and your application packages the current weather data in SOAP and sends it as the HTTP response.

Web services are analogous to ActiveX controls or objects, but Web services are available to anyone who can make the SOAP call to them. Projects such as Universal Description, Discovery and Integration (UDDI) are attempting to create a catalog of services available on the Web.
Does your company use SOAP? If so, we’d like to know in what capacity it uses this tool. Please post a comment below or e-mail us.
Which systems can use SOAP? Any system that supports both XML and HTTP is capable of supporting SOAP. Most significant platforms have a software developer's kit (SDK) that wraps the SOAP functionality in a class library or have wizards that generate the listener code. (A list of SDKs is available at SoapWare.org.)

Remember that although these SDKs are not required, they can make implementing SOAP easier. SOAP implementations are being released quickly, as SOAP rapidly becomes the standard for cross-platform remote procedure calls.

SOAP does not attempt to handle some issues that other remoting protocols tackle (e.g., garbage collection and marshalling by reference). These features are left to the implementer, if required, since not all clients and servers support them.

For example, COM+ uses reference counting, whereas Java does garbage collection. If these two technologies needed to communicate with one another, how would the protocol track the object references to perform the cleanup? Though possible to implement, the protocol would become bogged down in the details of client and server systems. Rather than attempt to be everything to all users, SOAP leaves these features to the individual implementer if necessary.

SOAP: A remoting standard
SOAP achieves interoperability by providing an XML format that can be transferred as simple text over HTTP or any other protocol capable of transferring XML text. The widespread support of HTTP and XML makes SOAP available as the remoting protocol for nearly any solution. SOAP has considerable momentum over similar solutions, like XML/RPC, and is quickly becoming the standard for remoting.

Brian Moore has been an IT professional since graduating in 1991 with a B.S. in Mathematics from Gustavus Adolphus College in St. Peter, MN. As a developer and system architect, he has worked on a variety of systems, with his most recent experience on the Microsoft platform, where he has focused on COM+ component development for Web applications. Brian spent four years working with healthcare software in Germany before returning to the United States in 1998. He is currently Director of Application Development at TechRepublic.com, where he and his team focus on vendor services applications.

Editor's Picks

Free Newsletters, In your Inbox