Java Reference
In-Depth Information
SOAP stands for Simplified Object Access Protocol. It's a common way for systems to pass data back
and forth. One system makes a request, and another system sends a corresponding response, which may
trigger yet another request. The system that processes the request, and produces a response, may then
send a request. In this fashion the systems “play tag” with one another, until the data is properly
transmitted (or an error condition indicates that the systems should stop trying). Inter-system and inter-
process communication can get much more complex than a simple request-response cycle, but that's
beyond the scope of this topic.The purpose of this kind of protocol (SOAP is one of many such
standards) is to provide separate systems a way to communicate that has as few dependencies as
possible on the operating system or language. One system might be a Windows server running an
application written in C++, while another system might be a Linux server running a Java application, and
yet another system might be a supercomputer running an ADA application. Provided the other system
can recognize the request and generate an appropriate response, anything else is irrelevant. This makes
SOAP, and similar protocols, very useful to software developers. You can create all kinds of systems and
make them talk to one another. The Internet is the plumbing, but SOAP messages, and similar content,
constitute the water in the pipes (or the information in the network, to abandon the metaphor).
Requests and responses (the latter, in particular) can be very large, by the way. I once created a system
that shared insurance policy information with a national insurance clearing house. The responses in that
system were very large— often several megabytes of data. (Honestly, had I designed that system, I would
have sent a response that specified a location from which the other system could download a file
containing the policy. Huge responses can be problematic. The longer the message, the higher the
chance for corrupted data, and it's sometimes useful to store data for a time. It wasn't my decision to
make, though.)
The
xmlns:soap
attribute specifies the namespace for SOAP, so that any system receiving it can
recognize what kind of message it is (assuming the system knows about SOAP at all). (XMLNS stands for
XML NameSpace.) The
encodingStyle
element (itself a member of the soap namespace) specifies the
exact version of SOAP being used. The
soap:Body
namespace specifies a (fictional, in this case)
namespace for weather information. Note that each namespace has an alias (
soap
or
w
, in this
document). The aliases save the trouble of typing out the namespace for each element and, more
importantly, reduces the number of bytes going down the pipe. The relatively simple poem example has
no namespace declaration, which means that it uses the default XML namespace. Every XML element
has a namespace, even if it's only the default. In the SOAP example, you can see that a single XML
document can contain elements from multiple namespaces (a Microsoft Word document contains as
many as 14 different namespaces, just to show how complex things can get). Namespaces let different
organizations use the same elements without trampling one another when they get into the same
document. For example, if another organization produced weather information, they'd have their own
namespace, to prevent collisions with the
noaa
namespace.
XML and Streams
A stream is a collection of data meant to be read sequentially. That is, a stream is meant to be read one
byte at a time. It is generally said that such a block of data is serialized (meaning that it is ready to be
transmitted and read serially, which is another way to say one byte at a time).In Java (and in other many
other languages), XML is processed as streams. Reading XML is done by parsing
InputStream
objects,
and writing XML is generally done by creating
StreamResult
objects. When creating XML with
String
objects, the result is often still exported as an
OutputStream
, as some other process needs to receive a
stream to do its part in a larger process. For example, many systems produce large documents. In these
systems, you can create XML by using
String
objects, create an
OutputStream
from the result, and send
that stream as an
InputStream
to another object, which would produce a PDF file. The PDF file serves as
the final document, to be stored on a server, printed, or both.
