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
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.
Figure 1 shows you the SOAP packet layout.
Figure 1 The SOAP packet layout.
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.