Web Services Composition and Geographic Information - Geographical Information Systems: Trends and Technologies - page 111

The Body contains the actual information of the SOAP message
intended for the ultimate recipient of the communication. The Body subject
can be any well-formed XML content, provided that such a content has a
namespace and does not contain any processing instruction or Document
Type Defi nition (DTD) reference (Erl 2005). A SOAP fault is a special type
of message used to communicate information about errors that may occur
during the message processing.
As for data encoding of the Body content, SOAP supports two main
styles: SOAP Remote Procedure Call (RPC) style and SOAP Document Style.
RPC is a style that offers the greatest simplicity and the idea behind it is
quite simple: a function available on a remote machine is invoked as if it was
a local function and the parameters it needs are sent through the network.
The returned value of the function is usually the expected result of the
computation. SOAP RPC exactly replicates this behaviour: the functionality
of a Web service is invoked by a SOAP message containing in its body the
parameters needed by the remote method. Differently, in a SOAP Document
Style the body content sent to a remote machine contains an entire XML
document without even requiring a returned value. When compared to
the RPC style, the Document Style has several advantages. In the RPC
messaging any change in the signature of the remote function involves
changes in all clients that use such a function; in contrast Document Style
rules are less restrictive. Moreover, the RPC style can also require higher
parsing times because of the necessity of having, every time, to perform
the marshalling of parameters (McCarthy 2002). The Document Style also
promotes loose coupling between producer and consumer messages, which
represents the commonly accepted solution.
As for the third component of a SOAP message, the Header fi eld, it
contains important information about how the message should be processed
and provides a generic mechanism for adding features (such as security and
transaction support) in a decentralized manner. It also provides options to
indicate whether the information contained in the Header is optional or
mandatory. Each element in the Header fi eld is called Header block and the
namespace of these blocks may be also different from the SOAP namespaces,
thus making the general structure of a SOAP Header quite fl exible. Such
fl exibility and extensibility are the basis of many important features present
in contemporary (Web services based) SOA implementations. In fact, a key
feature of the SOAP framework is its emphasis on creating messages that
are as self suffi cient as possible, a characteristic of the utmost importance in
a completely loosely coupled environment such as Web services (Erl 2005).
This independence of messages is achieved by adding other information
directly in the Header blocks thus avoiding services to store message specifi c
logic. Moreover, since the information is fully contained in the message itself,
the parts that communicate with each other do not need a prior agreement