On Mar 25, 2004, at 7:37 AM, Anne Thomas Manes wrote:
>
> 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.
>
One of the problems with the SOAP 1.1 spec is that section 5 (SOAP
Encoding) conflates the underlying data model with one possible
serialization of that model. Section 7 (RPC Representation) describes
the use of SOAP for RPC and uses terms defined in section 5 to describe
the representation of RPC. Thus there's a dependency on the data model
described in section 5 (a graph) but not necessarily on the SOAP
encoding (the serialization). SOAP 1.2 makes this much clearer with a
separate data model (part 2, section 2) and an explicit note of the
dependency in the rpc representation (part 2, section 4):
"The SOAP encodingStyle attribute information item (see SOAP 1.2 Part
1 [SOAP Part 1] SOAP encodingStyle Attribute) is used to indicate the
encoding style of the RPC representation. The encoding thus specified
MUST support the 2. SOAP Data Model. The encoding style defined in 3.
SOAP Encoding supports such constructs and is therefore suitable for
use with the SOAP RPC Representation."
As I described earlier in this thread, WSDL rpc/literal is just a
subset of document/literal that normally just describes a tree
structure rather than a more general graph and is therefore not really
suitable for use with the SOAP rpc representation. rpc/literal is much
closer to document/literal than it is to rpc/encoded. I agree there are
some similarities between the WSDL terms used for rpc/literal and those
used in SOAP rpc convention, but the underlying data models are
different.
> 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.
The association isn't between rpc and the encoding, its between rpc and
the data model. I don't think the SOAP 1.1 authors were really thinking
in terms of WSDL, that came later. Only rpc/encoded is really suitable
for use with the SOAP rpc convention. rpc/literal is just a WSDL
convention that cuts down the amount of schema definitions you need.
> (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)
>
Can you point me to the Microsoft definition of the wrapped convention
? JAX-RPC added support for rpc/literal because that's what WS-I
defines in the Basic Profile, you make it sound like this was added as
the result of some whim.
> 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.
>
Its straightforward to synthesize a schema for the contents of the SOAP
body from an rpc/literal WSDL.
> 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.
>
See sections 6.4.1 and 6.4.3 of JAX-RPC 1.1.
Marc.
> 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
>
>
---
Marc Hadley <marc.hadley at sun.com>
Web Products, Technologies and Standards, Sun Microsystems.
- application/pkcs7-signature attachment: smime.p7s