SOAP
As we saw in Chapter 1, SOAP is a lightweight protocol for exchange of information in a decentralized, distributed
environment. To achieve the goal of exchanging information, SOAP uses XML to encode its payload.
Let's look at an example that we will refine as we dig deeper into the specification:
Aside from the HTTP-specific data, the XML document above contains three parts specified by XML
elements (the meaning of each part will be explained further in subsequent sections):
- Envelope:
<SOAP-ENV:Envelope>
The SOAP envelope is analogous to a snail mail envelope, but without the address which is
the responsibility of the transport and included in the HTTP header. The envelope specifies
global settings such as the encoding.
- Header:
<SOAP-ENV: Header>
The header is optional. If it is present, it contains header entries that define SOAP settings,
such as the ultimate destination of a message (more on that later) and application-specific settings (the transaction identifier, for instance).
- Body:
<SOAP-ENV:Body>
The body must be present and must follow the header, if any. The body contains a message,
an RPC call, or a fault.
Unfortunately, software components sometimes fail, hence the necessity of having a standard
placeholder for exceptional situations like a version mismatch, or a badly formed request. The SOAP
fault (< SOAP-ENV: Fault>) is the placeholder for bad news.
Before we dig deeper into the specifications of the SOAP protocol, there are two points that are usually
misunderstood about SOAP and that are worth clarifying:
1. SOAP is a one-way protocol. SOAP does not require a response message to be sent as a response to the "request"
message. Despite the fact that the SOAP specification does not explicitly define how to
use SOAP with a messaging protocol, such as the Simple Mail Transport Protocol (SMTP),
the architects of SOAP have that feature in mind. The Apache SOAP implementation
supports SMTP as a transport.
2. SOAP is not (exclusively) an RPC protocol. SOAP is usually used to trigger a remote method call, but nothing in the protocol
specification forces a SOAP server to invoke a method as a result of a SOAP message being
received. We will see an example of this functionality in the Messaging section, where we will
describe a document-based protocol as opposed to a procedure-based protocol.
Looking at the SOAP 1.1 specification, we can see that Section 7 (Using SOAP for RPC) describes how to
use SOAP for RPC. Roughly, SOAP serializes a function call as an XML structure containing:
- A method name
- An optional method signature
- A list of arguments
- An optional header
The URI of the target object is not part of the serialized data: it is the responsibility of the transport protocol to carry the URI.
HTTP Bindings
Although it is possible to carry a SOAP payload using several HTTP methods, and even other protocols
than HTTP, the SOAP 1.1 specification only defines HTTP bindings for HTTP POST requests. The
definition of the SOAP bindings affects three areas of HTTP: the HTTP header, the HTTP response,
and the HTTP extension framework.
In an HTTP POST, the request (SOAP or other) is part of the body of the document, as opposed to
an HTTP GET where the request is part of the URL.
New on the Java Boutique:
New Review:
Time Management Made Easy with the Quartz Enterprise Job Scheduler
Why not just use the Java timer API? This open source scheduling
API boasts simplicity, ease-of-integration, a well-rounded feature
set, and it's free!
New Applet:
Reverse Complement
Reverse Complement is a simple applet that converts DNA or RNA
sequences into three useful formats.
Elsewhere on internet.com:
WebDeveloper Java
Lots of Java information on webdeveloper.com
WDVL Java
Thorough Java resource at the Web Developer's Virtual Library.
ScriptSearch Java
Hundreds of free Java code files to download.
jGuru: Your View of the Java Universe
Customizable portal with online training, FAQs, regular news updates, and tutorials.
