Service-Oriented Architecture - Guide to Cloud Computing for Business and Technology Managers - page 163

format and usually relies on other application-layer protocols, most nota-
bly Remote Procedure Call (RPC) and HTTP for message negotiation and
transmission. SOAP can form the foundation layer of a Web Service protocol
stack, providing a basic messaging framework on which Web Services can
be built.
As a simple example of how SOAP procedures can be used, a SOAP mes-
sage can be sent to a Web Service-enabled website—for example, a house
price database—with the parameters needed for a search. The site returns an
XML-formatted document with the resulting data (prices, location, features,
etc.). Because the data are returned in a standardized machine-parseable for-
mat, it may be integrated directly into a third-party site.
The SOAP architecture consists of several layers of specifications for MEPs,
underlying transport protocol bindings, message processing models, and
protocol extensibility. SOAP is the successor of XML-RPC. SOAP makes use
of an Internet application-layer protocol as a transport protocol. Critics have
argued that this is an abuse of such protocols, as it is not their intended
purpose and therefore not a role they fulfill well. Proponents of SOAP have
drawn analogies to successful uses of protocols at various levels for tunnel-
ing other protocols.
Both SMTP and HTTP are valid application-layer protocols used as trans-
port for SOAP, but HTTP has gained wider acceptance because it works well
with today's Internet infrastructure; specifically, HTTP works well with
network firewalls. SOAP may also be used over HTTPS (which is the same
protocol as HTTP at the application level but uses an encrypted transport
protocol underneath) with either simple or mutual authentication; this is the
advocated WS-I method to provide Web Service security as stated in the WS-I
Basic Profile 1.1. This is a major advantage over other distributed protocols
such as GIOP/IIOP or DCOM, which are normally filtered by firewalls. XML
was chosen as the standard message format because of its widespread use
by major corporations and open-source development efforts. Additionally,
a wide variety of freely available tools significantly ease the transition to a
SOAP-based implementation.
The advantages of using SOAP over HTTP is that SOAP allows for easier
communication through proxies and firewalls than previous remote execu-
tion technology and is versatile enough to allow for the use of different
transport protocols. The standard stacks use HTTP as a transport protocol,
but other protocols are also usable (e.g., SMTP). SOAP is platform indepen-
dent and language independent, and it is simple and extensible.
Because of the verbose XML format, SOAP can be considerably slower
than competing middleware technologies such as CORBA (Common
Object Request Broker Architecture). This may not be an issue when only
small messages are sent. To improve performance for the special case of
XML with embedded binary objects, Message Transmission Optimization
Mechanism was introduced. When relying on HTTP as a transport pro-
tocol and not using WS-Addressing or an ESB, the roles of the interacting