Introduction to SOAP

Introduction to SOAP

Basically, SOAP is a standard way of serializing the information needed to invoke services located on remote systems so that the information can be sent over a network (or “wire”) to the remote system, in a format the remote system can understand, regardless of what platform the remote service runs on or what language it’s written in. If you’re familiar with RPC architectures such as CORBA and DCOM, this description of SOAP should sound familiar, because SOAP resembles the wire protocols underlying both architectures: the Internet Inter-ORB Protocol (IIOP) that underlies CORBA and Microsoft’s Distributed Component Object Model (DCOM) protocol, respectively. In fact, SOAP can be thought of as a simplified XML-based replacement for these protocols.

Improved RPC

In order to understand SOAP’s context, it helps to put it in perspective relative to RPC architectures in particular, and communications within distributed computing models in general.

The two dominant communications models throughout the history of distributed comput-ing have been message passing/queuing and request/response. With message passing, a message sender can send a message at any time, and the messaging infrastructure is responsible for delivering the message whenever it can, thus typically offering asynchro-nous message delivery. With the request/response model, the message sender typically must wait until it receives a response from the recipient, in what is an example of syn-chronous message delivery. If the goal is to send data to a method hosted on a remote system and wait for its response, the request/response model is a natural fit. Message passing, however, is more appropriate when a response is not immediately required.

As a result, RPC architectures generally followed the synchronous request/response model, and when object-oriented architectures came into widespread use, Object RPC (ORPC) protocols such as CORBA’s IIOP and DCOM became dominant in the distrib-uted computing arena. However, both CORBA/IIOP and DCOM have several problems, including the following:

   Both CORBA and DCOM are single-vendor solutions. DCOM is expressly a Microsoft solution, and although CORBA is intended to be cross-platform, in real-ity it is typically only cost-effective when all the involved systems share a single Object Request Broker (ORB) platform.

   Both CORBA and DCOM have different, proprietary characteristics. For example,

CORBA’s payload parameter value format is the Common Data Representation (CDR), whereas DCOM’s is the incompatible Network Data Representation (NDR). Likewise, CORBA uses Interoperable Object References (IORs) for end-point naming, whereas DCOM uses OBJREFs.

   IIOP and DCOM are both binary protocols, which means they are not human-read-able, and neither is firewall friendly. The firewall limitation in particular relegates both architectures to use primarily within individual enterprises.

   Both CORBA and DCOM are tightly coupled, which means that a change in the exposed methods of any distributed object requires programming changes in dis-tributed objects that communicate with it. As a result, interfaces must be specified at design time, and any changes required during runtime involve expensive, time-consuming version upgrades.

Such is the environment that gave birth to SOAP. SOAP addresses each of these draw-backs to existing ORPC architectures:

   SOAP is built with open technologies and is an open specification. Because SOAP is built with XML and is itself managed by international standards bodies, SOAP is a vendor-neutral protocol.

   It follows, then, that SOAP’s characteristics are also open. SOAP uses XML as its payload parameter value format and uses URIs (which are like URLs; more about URIs later) for endpoint naming. In addition, SOAP interfaces are described with the Web Services Description Language (WSDL), which is also an open technol-ogy. (More about WSDL in Chapter 16, “Web Services Building Blocks: WSDL and UDDI.”)

   Because SOAP is based on XML, it is a text-based protocol. As a result, it is sim-pler than CORBA and DCOM. SOAP messages are human-readable and firewall friendly. SOAP messages are typically sent over HTTP, either over the standard port, 80, or the standard SSL port, 443. Human-readability is valuable for develop-ing and maintaining the software.

   SOAP is a loosely coupled protocol. Because SOAP takes advantage of XML’s self-describing capabilities, SOAP messages (in conjunction with WSDL) can indi-cate to their recipients their interface requirements. Therefore, it is possible to change SOAP message interfaces at runtime, as long as the underlying architecture supports just-in-time (JIT) integration. You can learn more about JIT integration in Chapter 14.

In addition, SOAP works quite well in messaging as well as RPC architectures. Although both CORBA and DCOM are inherently based on their request/response mechanisms, the SOAP protocol supports asynchronous messages as well as one-way messages that don’t come in request/response pairs.

Improved Interoperability

If there is one phrase that strikes fear in the hearts of many a system integrator, it is “DCOM-CORBA bridge.” Sure, DCOM and CORBA are technically interoperable via such bridges, but in reality, the custom integration needed to make such bridges work in real-world environments is extraordinarily expensive and time consuming. If such inte-gration was just a matter of translating Network Data Representation (NDR) payloads to Common Data Representation (CDR) payloads, for example, then integration wouldn’t be as great an issue. The problem is, however, that DCOM and CORBA handle location transparency in different ways.

Sending executable code over the network, naturally, opens a Pandora’s box of issues, including security, flexibility, and the previously mentioned firewall unfriendliness. It is clearly problematic to unmarshal an object written in one language into an object sup-ported on a different platform. SOAP’s capabilities can help to resolve these issues with location transparency.

SOAP, in essence, is the XML-based replacement for the object serialization techniques used by the existing ORPC architectures. Using XML to structure the data serialization provides a “neutral third party” between CORBA and DCOM (as well as other propri-etary RPC architectures). CORBA-SOAP and DCOM-SOAP bridges are much simpler to build and use than a CORBA-DCOM bridge, because they are simply XML interfaces to existing objects.

Key Building Block for Web Services

SOAP provides an additional advantage over traditional ORPC architectures: Because SOAP messages are self-describing, the method calls contained in a SOAP message can vary each time the message is sent. In addition, it is possible to marshal several method calls in a single SOAP message. With a traditional ORPC, each call to a remote method must be handled as a separate roundtrip. A SOAP message, however, can be constructed on-the-fly to send data to multiple methods. Used judiciously, this capability can more than compensate for the slowness of SOAP’s text-based messages as compared to the binary messages of CORBA and DCOM.

The ability of SOAP messages to be constructed on-the-fly is the linchpin of the Web Services model. If you look at the Web Services stack in Figure 14.5, you’ll see that SOAP is a key element in the foundation of Web Services. SOAP is ideally suited both for messages between Web Services and for messages that other systems exchange with Web Services. As explained in Chapter 14, the true power of Web Services lies in its JIT capabilities, and it is SOAP’s extensibility—inherited from XML—that forms the basis for Web Services’ new JIT paradigm.