[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: So what do SOAP and XML-RPC buy you?
- From: David Brownell <email@example.com>
- To: Ken MacLeod <firstname.lastname@example.org>
- Date: Thu, 19 Apr 2001 10:39:31 -0700
> > If that's "any object defined using an Interface Definition Language
> > (IDL)" then that's less of an issue.
> I typically associate IDLs with APIs, so I'm not sure how that
> relates to "interoperable data"???
Having come at IDLs from the protocol world, I'm used to using
them to define message formats. Mapping those formats to some
programming language API is something tools vendors obsess on,
with the effect (maybe not intentional) of making customers forget
the original "interoperable message" problem that the IDL solves.
However it's true that not all IDLs maintain a clear distinction
between the "interoperable data" part of the message, and the
"message paradigm" imposed by a given envelope that is used
with that data. Request/response is pretty limiting if it's the only
message paradigm available to the application. Big systems
use reliable message queuing, multicasting, and so on; they
can't afford to be stuck with just RPCs.
> When I think of "interoperale data" at a higher level than straight
> XML (or via DOM), I'm thinking of data that interoperable because it
> is an encoding format (in XML), a la RDF, SOAP Encoding, or via some
> XML Schema magic yet to be developed, that unmarshals to something
> more approachable from programming languages than straight XML in a
> DOM or via SAX.
One can argue about that. At least the CORBA model views any
particular encoding as an implementation detail: you can encode the
same data using binary schemes (XDR, NDR, CDR for some RPCs)
or text schemes (CSV, any of numerous XML schema systems)
without changing the essential information.
Approachability from some programming language, just like marshaling,
is entirely separate from the question of what information is conveyed
by the data. Unmarshaling must make application-specific decisions
about things like whether sets should be represented as arrays or lists,
and which data may safely be discarded "early". Few RPC systems
let apps make those decisions where it's most efficient to do so.