WS-I BP does allow rpc/literal, but Microsoft refuses to support it. Also,
SOAP 1.2 makes support for the RPC convention optional. I take these two
facts as an indication that rpc/literal has no future.
Note that rpc/encoded and rpc/literal are extremely different creatures. The
SOAP RPC convention is very much dependent on the SOAP encoding data model
(design to represent object graphs). The WSDL rpc/literal style is dependent
on XML schema (designed to represent tree structures), and it's designed as
a "convenient subset" of doc/literal. Personally I don't think it adds all
that much convenience because the tooling should generate your WSDL and
schema definitions for you. I view not having a schema of the message
structure as much more of an inconvenience.
As Marc Hadley (Sun rep to W3C XMLP) explained to me:
<atm> my comments in brackets </atm>
<marcHadleyExplanation>
"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).
</marcHadleyExplanation>
<atm>
For each node in the serialized message, SOAP encoding will
generate either an element or a reference to an element.
</atm>
<marcHadleyExplanation>
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.
</marcHadleyExplanation>
<atm>
Note that in rpc/literal the XML schema defines the serialized form
of the parameter *types*, but not of the parameter *elements*. My
objection to using rpc/literal is that you don't have a schema of
the actual message structure, only of various complex types within
the message structure, so message validation is much more complicated.
</atm>
<marcHadleyExplanation>
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."
</marcHadleyExplanation>
And just to finish off the thought -- wrapped doc/literal produces a very
close approximation of rpc/literal, except that you must use XML schema to
describe the operation's wrapper element and all of the actual parameter
elements. I say "approximation" because in wrapped doc/literal, you may want
to namespace qualify your parameter elements, but in rpc/literal, the
parameter elements are always unqualified.
Anne
-----Original Message-----
From: Elliot Metsger [mailto:[EMAIL PROTECTED]
Sent: Wednesday, August 18, 2004 4:00 PM
To: [EMAIL PROTECTED]
Subject: Re: WSDL2Java overloading functions
Anand et. al,
Can you offer your perspective on the interoperability of rpc/lit in the
future? Dosen't the WS-I Basic Profile 1.0 go a ways to reducing
opportunities for interoperability issues?
Thanks,
Elliot (a ws newbie)
Anand Natrajan wrote:
> Charles and Steve,
>
> Mostly for my curiousity, are you using an rpc/encoded service or a
> document/literal service? My information may be wrong, but I believe the
> latter doesn't support overloaded methods. Given that the web services
> world is moving to doc/lit, having overloaded methods may be ill-advised
> for future compatibility.
>
> Anand
>
