[Home] [By Thread] [By Date] [Recent Entries]
> > 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. - Dave
|

Cart



