Java Reference
In-Depth Information
Because document messages represent complete and self-describing entities rather than meth-
od parameters, which are available to you as the SOAP message payload, document style al-
lows greater processing flexibility. You can create the incoming payload as a complete XML
document and run XSL transformations against it, validate it according to a schema, or manu-
ally massage it however you like.
Maintaining state is easier with document style because you have only a single entity rather
than a set of entities to manage.
Use
The soap:body element's use attribute specifies the manner in which the body content of your
SOAP message will be serialized into XML. Possible values are “literal” or “encoded”. Lit-
eral indicates that your message will be serialized as an XML document, whereas “encoded”
indicates that a default SOAP encoding will be applied to it.
Style and use combinations
In the following sections, let's look at the implications of combining the style and uses in vari-
ous ways.
RPC/encoded
There is a single strength to RPC/encoded: WSDLs written with this formatting are the most
simple and straightforward to read.
Everything else is bad news. The WS-I recommends that the soap:body have only one child
element. RPC/encoded violates this recommendation by allowing multiple children of the
SOAP body element. Using this style means that complex types will be SOAP encoded and
referenced by “href” elements that point to multiref elements outside the operation wrapper
element. This makes the message harder to read and understand.
RPC/encoded bindings must maintain type encoding information for every parameter, adding
unnecessary overhead to every invocation. This formatting style has the worst performance of
all the possible styles.
NOTE
RPC/encoded is not compliant with WS-I Basic Profile 1.1, so it's not a good candidate for creating
web services you expect to interoperate with clients or services implemented with a different plat-
form.
Search WWH ::




Custom Search