Marc,
You've explained the difference between encoded versus literal. I recognize
that from a SOAP implementor's point of view, the most critical facet of
message serialization is the data model (graph versus tree) and once you
decide on tree, the actual message construction is pretty straight-forward,
regardless of whether you're building the structure based on a schema or a
defined convention. So I understand your comment that rpc/literal is a
subset of document/literal.
But I'm having a lot of trouble accepting your assertion that rpc/literal
doesn't rely on SOAP Section 7. SOAP Section 7 defines the convention used
to construct an rpc-style message.
The tight association in your mind between SOAP Section 7 (RPC) and SOAP
Section 5 (encoding) reinforces my claim that the SOAP spec authors
intended people to use rpc/encoded versus doc/literal and they hadn't
expected people to use rpc/literal. (perhaps that's what Roberto meant by
NIH? but I could accuse the JAX-RPC community of the same sentiment --
Microsoft defined the wrapped convention, and many Java SOAP
implementations had followed suit long before anyone implemented support
for rpc/literal)
In any case, I like rpc/literal much better than rpc/encoded because at
least it gives me a schema of the message parameters. But doc/literal is
still the better practice. It gives me a schema of the entire contents of
the SOAP Body.
What I'd really like to see is the JAX-RPC team define a specification for
the wrapped convention. Wrapped is a *programming* convention, so it falls
within the purview of a language community to define it. SOAP defines a
wire protocol -- it doesn't define programming conventions. WSDL describes
the protocol and the message exchange patterns, but not programming
conventions. The language community has to define the programming conventions.
Sunil points out two issues with wrapped:
1- there's no rule governing dispatching
2- You must create a wrapper element for each operation
The first point isn't really true. The convention requires that the wrapper
element for the parameters be the same as the operation name. On the wire,
there's not a lot of difference between wrapper/doc/literal and
rpc/literal. In both situations, the child element of the SOAP body
contains the operation name.
I really don't think it's too terribly onerous to create a wrapper element
for each operation. It's a good practice. Besides -- tooling can generate
it for you. The WS-I BP requires that each operation must have a unique
signature, and the signature is determined by the qname of the child
element of the SOAP body. As long as you have a unique signature, there's
no difficulty in dispatching the request. In the wrapped convention, the
wrapper element -- the qname of the child element of the SOAP body -- is
the same as the operation name. It's pretty straight forward.
Anne
At 05:39 PM 3/24/2004, you wrote:
>On Mar 24, 2004, at 3:56 PM, Anne Thomas Manes wrote:
>>
>> Okay, perhaps I am confused. Perhaps you can help me understand it better.
>The main difference is in the data model that underlies the two. SOAP
>encoding is built on a directed edge-labeled graph whereas rpc/literal is
>built on a tree structure. WSDL rpc/encoded uses XML schema to describe
>the abstract types of operation parameters rather than their actual
>serialized form (SOAP encoding does that). rpc/literal is really just a
>convenient subset of document/literal where XML schema is used to describe
>the serialized form of an operation's parameter types but not the
>serialization of the so called wrapper elements that represent the
>operations themselves.
>
>You could use rpc/literal or document/literal to describe the
>serialization of a directed edge labelled graph but it requires each node
>in the tree to be a choice between a value or a reference to a value and
>this gets pretty ugly pretty quickly.
>
>Does that help ?
>Marc.
>
>---
>Marc Hadley <marc.hadley at sun.com>
>Web Products, Technologies and Standards, Sun Microsystems.
>
>
~~~~~~~~~~~~~~~~~~
Anne Thomas Manes
VP & Research Director
Burton Group
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe_at_jax-rpc.dev.java.net
For additional commands, e-mail: users-help_at_jax-rpc.dev.java.net