Java Reference
In-Depth Information
With RPC/encoded, SOAP encoding is typically used to serialize complex types, causing you
to lose the more specific and sophisticated functionality you get with XML schemas.
RPC/literal
This is a weird choice. Specifying RPC/literal prevents you from being able to perform
schema-based validation. It is complicated by the fact that RPC/literal must handle both RPC
element naming conventions and WSDL namespaces.
RPC/literal strips you of the benefits of working with document/literal, but it does offer an
advantage over RPC/encoded in that it is WS-I compliant. Despite this fact, Microsoft offers
only limited support for this style, so it is rarely used.
Document/literal
This is the best choice to ensure interoperability with services and clients written on other
platforms. You can use any XML validator to validate the contents of the message. With doc-
ument/literal, your operation type gets written as a complex type declared in your schema.
It's interesting to note that .NET initially supported only document/literal. Document/literal
does away with the operation name inside the SOAP message. RPC focuses on the method
call, whereas document focuses on the document instance you are sending.
Document/encoded
The combination of document and encoded is dead. Nobody uses it. Even in the earliest days
of JAX-RPC this mode was not supported. Just pretend it doesn't exist.
Using parameter styles
In JAX-WS, there are two choices for specifying the parameter style: wrapped or bare. The
parameter style indicates how parameters will be encapsulated. WSDL itself does not make
this distinction. The choice is only relevant for a document/literal style service. The following
sections discuss the differences.
Wrapped
Using the wrapped parameter style indicates that the child of the
<soap:body>
will be a wrap-
per element that is named for the operation. As a wrapper, it is not part of the payload. The
advantage here is that a SOAP engine will have a clear and simple naming convention during
unmarshaling.
With document/literal wrapped services that define their schemas externally, you have the best
chance for ensuring interoperability, and for leveraging the built-in advantages of schema re-
