WebReference.com - Part 2 of Chapter 3: Professional XML Web Services, from Wrox Press Ltd (1/5)
Professional XML Web Services
[The following is the second in a series of excerpts from Chapter 3 of the Wrox Press title, Professional XML Web Services. Ed.]
In order to build SOAP messages from our language of choice, we need to know how to serialize data. We need to know the rules for representing an integer, string, or floating point number in a SOAP message so that we can exchange messages freely between languages and platforms. The serialization of data inside a SOAP message is referred to as encoding. As this section focuses on the payload of the message, the XML in the examples represents only a SOAP message payload and not a complete message.
The ability to decide on a set of rules for representing data in a message is very important
to the open nature of SOAP. It doesn't do much good of course to define a set of rules if we cannot tell
what encoding rules were used to serialize a particular SOAP message. The
attribute defined by the SOAP specification is used to identify the encoding rules used in a particular
encodingStyle attribute is commonly located on the
element. It is possible, however, to use the
encodingStyle attribute on any element in a
SOAP message. Although the SOAP specification defines a set of encoding rules that map well to
programming constructs, there is no default encoding. This means that if the
encodingStyle attribute does not appear in the message, the receiver cannot make any
assumptions about how data will be represented within the message. By the same token, the zero length
encodingStyle="", is equivalent to a missing
encodingStyle attribute. In
either case, no
encodingStyle means that the implementation will have to try to figure
out how to deserialize data without any help.
What About XML Schemas?
Those familiar with XML Schemas may be wondering what relationship exists between encoding
and XML Schemas. Encoding can make use of XML Schemas. In the case of SOAP encoding, the URI used in the
encodingStyle attribute points to a schema. As we will see in the next section, the SOAP
encoding rules use XML Schemas heavily, relying on the XML Schema
datatypes namespace and
type attribute. The key difference is that encoding does not mandate XML Schemas.
Encoding rules are simply identified by a URI. The rules implied by that URI could be backed up by
nothing more than a verbal agreement, or possibly some written documentation. This allows developers
who do not necessarily need the capabilities of XML Schemas to forego their use and start sending
messages with encoding rules based on an accepted URI.
Although we can have encoding without a corresponding schema, it's not recommended. Most XML parsers will soon be schema-aware (in fact, some like Xerces already are), and we can save ourselves a lot of trouble when parsing messages if we rely on the parser and schema to validate and convert data instead of doing it manually.
The SOAP Specification defines a single set of encoding rules that are referred to as
SOAP encoding. SOAP encoding is based on XML Schemas and as such it closely models many of the
standard types and constructs that developers would be familiar with. The value of the
encodingStyle attribute for SOAP encoding is
which points to the XML Schema that defines the encoding rules.
Created: November 19, 2001
Revised: November 19, 2001