SOAP, the Simple Object Access Protocol, is a new protocol engineered by IBM, Microsoft, Userland, and DevelopMentor to support remote procedure calls (and other sophisticated requests) over HTTP.
SOAP draws from two distinct environments. Built on HTTP and XML, SOAP aims to be as simple as the Web. Yet it targets object-oriented remote procedure calls borrowed from CORBA and DCOM.
I think that the major benefit of adopting SOAP is that it builds on a Web server. Therefore, to understand SOAP, one needs to start with Web servers. Modern Web serversand in particular application servers such as WebSphere, WebLogic, or Tomcatare powerful development platforms. They are optimized to process requests efficiently.
SOAP is an attempt to turn these Web servers into object servers. By object servers, I mean the middle-tier servers in a three-tier architecture. SOAP supports object servers this way by adding a thin XML layer over HTTP.
Let me give an example. I once had to compile ranking information from search engines (for example, Google, AllTheWeb, and Alta Vista). My customer produced reports on site popularity. It is easy to simulate a browser request from an application; the problem is decoding the response. It came in HTML, and my application would parse it to extract the links. Unfortunately, the application broke whenever the search engines changed their layouts. That is one of the limitations of the Web: It works well when a user queries a Web server, but it is very difficult to automate.
Now, imagine that the search engine would run an object server. An updated version of my application could query it. If the object server is built on SOAP, the request and the response are XML responses. Because XML contains no formatting instructions, the application would not break the next time the search engines change their layouts.
Should You Consider SOAP?
I will confess to an initial skepticism toward SOAP. I was originally concerned that SOAP was too simple. The new protocol targets a crowded market: other object protocols include DCOM (Microsoft offering), RMI (Java networking by Sun), and CORBA (an open effort). When I compared CORBA and SOAP, I could not help but feel that SOAP was too limited for real applications.
However, what it lacks in power, SOAP more than compensates for in its simplicity. For example, because SOAP uses HTTP, SOAP servers are Web servers. Most businesses have significant experience in deploying Web servers or developing Web applications. With SOAP, they can leverage that experience for object servers.