Chapter 1: Essential SOAP: A Comparison of SOAP to Existing Distributed Object Technologies
SOAP: (n): Hydrolysis or saponification of the sodium salt of a long chain of fatty acids.
Not anymore. There is a new SOAP on the block. The Introduction gave you an idea of what SOAP really is and why it's necessary. This chapter furthers that introductory discussion by more fully explaining SOAP's purpose, and then by comparing SOAP (as a wire protocol) to the commonly-used distributed object technologies and their wire protocols in use today.
It's important to remember that SOAP is itself a wire protocol rather than an entire distributed object architecture. On the other hand, entire distributed object architectures are designed around their wire protocols for efficiency. Some distributed object technologies concern themselves with security, for example, and carry security information within their data packets. They have mechanisms to efficiently encode the security information to speed the data's consumption on the receiving end.
Also, unlike contemporary distributed object architectures, SOAP makes use of openly available technologies that, when combined, specify a wire protocol. This protocol can be used to facilitate highly and ultra-distributed architectures. As you've seen from the introduction, SOAP commonly uses the HTTP protocol to transport XML-encoded serialized method argument data from system to system. This serialized argument data is used on the remote end to execute the client's method call on that system, rather than the client's local system.
This chapter begins by exploring the SOAP wire protocol and why such aprotocol makes sense. Then the chapter introduces the wire protocols of other contemporary distributed systems to see how they are incorporated into the overall distributed architecture. This should provide you with a good feel for where SOAP fits in relation to other systems as well as help you better understand the SOAP specification itself.
The Argument for SOAP
After reading the introduction, you might wonder why the SOAP protocol is generating so much interest. After all, it is just another Microsoft XML-based initiative, isn't it?
In truth, SOAP does have roots in Microsoft, as one of the main specification authors works for Microsoft. That said, though, SOAP is a compelling technology in its own right and was honestly developed to be vendor independent. You can see this simply by examining the two fundamental SOAP technologies-HTTP and XML. These two technologies are international standards, and although Microsoft has played a significant role in the development of several of the key XML technologies, XML is nonetheless not under Microsoft's control.
A better way to view SOAP is based upon its technical merit. SOAP is fundamentally the combination of textual information shared via the Internet. The textual information is encoded in an XML format, which has specific rules for encoding and processing. The actual transmission of the XML data is managed by the transport protocol, which is (today) commonly HTTP served by a Web server. The combination of the open XML encoding style and the pervasive HTTP protocol makes SOAP possibly the most interoperable wire protocol yet invented.
If you are using HTTP as your SOAP transport protocol, then SOAP processing is very much aligned with the Internet, which specifies a stateless programming model. That is, object clients request services from a remote entity, which in turn responds with the pertinent information. After the remote entity responds, all state information regarding that invocation is destroyed unless measures are taken to persistently store the state information for later use. Regarding SOAP, rudimentary SOAP servers also follow this basic stateless, request/response scenario. SOAP itself doesn't preclude you from implementing more exotic servers that are capable of state management and decoupled request/response pairs (as with asynchronous callbacks). This makes it easy for scripts as well as more complex applications to implement SOAP.
Heavyweight Versus Lightweight Protocols
You will find a description of several contemporary distributed object technologies in this chapter. Although the purpose of the descriptions is to afford a comparison of SOAP to other wire protocols (and complete architectures, which SOAP does not provide), keep these questions in mind as you read the descriptions:
How complex is the wire protocol for the given system, and is it an open standard?
How complex is the given system?
If you design a distributed application using the given system, what are the development costs associated with the system? For example, is it easier to hire developers who know XML/HTTP or an architecture-specific protocol like HOP or RMI?
If you design a distributed application using the given system, what are the administrative costs associated with the system when you ship your application to an arbitrary user?
Does the selection of a given system bind you to specific vendor, and, if so, can you easily migrate your application to another vendor?
One argument in favor of the SOAP protocol is that it is a tremendously lightweight protocol. That is, the protocol itself requires two fundamental capabilities:
The capability to send and receive HTTP (or other) packets
The capability to process XML
At this time, HTTP is a pervasive technology. One can hardly imagine a business that doesn't handle HTTP data, at least if it interacts with the Internet in any meaningful fashion. At the very least, HTTP processing is well understood and widely implemented...