Understanding SOAP as a Wire Protocol

SOAP allows business software programs to communicate over the Internet regardless of the platform on which they are based. This article addresses such topics as scalability, performance, security, and state management with respect to SOAP as a wire protocol

Understanding SOAP as a Wire Protocol

SOAP allows business software programs to communicate over the Internet
regardless of the platform on which they are based. This article addresses such
topics as scalability, performance, security, and state management with respect
to SOAP as a wire protocol.

by Kennard Scribner and Mark
C. Stiver

SOAP

Unlike the other distributed object architectures such as COM/COM+ and Corba,
SOAP is merely a wire protocol. To truly compare SOAP with these other architectures,
you would need to implement the SOAP protocol as part of a distributed architecture
of its own (or replace an existing architecture's wire protocol with SOAP).
Even so, SOAP offers many advantages, even as a wire protocol.

From Figure 1 you can see that the SOAP payload is encapsulated within the
SOAP envelope (which is itself part of the HTTP payload, assuming you're using
HTTP as your transport protocol). The SOAP envelope, in turn, consists of the
SOAP header and body. The SOAP header is optional, but, if present, must immediately
follow the opening envelope (root) XML tag. If it exists, you'll likely find
one or more header elements that provide meta-information regarding the method
call. This meta-information could be nearly anything, although the SOAP specification
uses the inclusion of a transaction ID as a specific example. The SOAP body
contains the serialized method arguments. The remote method name is to be used
to name the method call's XML element, and it must immediately follow the SOAP
body opening XML tag.

The data is serialized in XML using a combination of XML elements and attributes.
Even though SOAP specifies XML, which is text based, you can still identify
arguments by reference and create structures and unions just as you would using
a binary protocol.

SOAP and Scalability

SOAP commonly uses the HTTP protocol and is therefore very scalable in its
native form. It is arguably the most scalable protocol investigated in this
article, especially if the (stateless) HTTP request/response model is maintained.

SOAP and Performance

As a wire protocol, SOAP performance is somewhat degraded by the requirement
to extract the SOAP envelope from the transport packet and parse the contained
XML information. (Other wire protocols don't use XML, or even text, allowing
for optimized information extraction.) The XML processor must be loaded, activated,
and fed the XML information. Then the method call argument information must
be discovered (assuming the lack of an interface/method schema that would identify
the relevant information beforehand). This might not be a trivial undertaking
as XML processors grow to support more XML features (and therefore require more
system resources to operate). However, SOAP is quite interoperable, which perhaps
mitigates the XML processing if you consider the other protocol conversions
you must undertake to connect disparate computer architectures.

SOAP and Activation

Because SOAP is merely a wire protocol, it doesn't provide an activation mechanism.
This is not an omission but rather a deliberate act to relegate object activation
requirements to the distributed object architecture that implements the SOAP
protocol.

SOAP and State Management

SOAP is inherently stateless if it uses HTTP as its foundational transport.
HTTP is connectionless and dictates a request/response architecture. As with
some Internet applications, you can save object state between method invocations,
but this is outside the scope of the SOAP protocol itself no matter what transport
protocol you select.

SOAP and Garbage Collection

SOAP itself makes no attempt to manage orphaned objects or support remote garbage
collection. In fact, the specification explicitly states that this is not addressed
by SOAP. SOAP, as a protocol, cannot manage all aspects of the distributed object
architecture. A distributed object architecture that implements the SOAP protocol
would also need to implement the mechanics of garbage collection (timeouts,
pings, and so on).

SOAP and Security

Because SOAP is a wire protocol, SOAP does not implement security. However,
SOAP can use the HTTP protocol, allowing you to potentially employ application-level
security coupled with secure sockets or HTTPs. SOAP also mandates the use of
the SOAPAction HTTP header field, which allows your firewall (or equivalent
technology) to filter SOAP method invocations or deny SOAP processing entirely.
Your firewall would examine the SOAPAction header and filter the SOAP packet
based upon the object name, the particular method (remotable or not), or a combination
of the two.

Source: This article is excerpted from Understanding SOAP (http://www.mcp.com/sams/detail_sams.cfm?item=0672319225)
by Kennard Scribner and Mark C. Stiver(2000, Sams, ISBN 0672319225). Refer to
Chapter 1 of this book for more detailed information on the material covered
in this article.