@Now I'm confused - thrift Vs corba
Before I start, generally one shouldn't be dealing with serialisatioin except as an abstracted layer which you can cleanly and easily swap out for another, thus rendering the details (whether XML/ASN.1/roll-yer-own) irrelevant.
Probably mentioned 50+ times above but bears repeating.
Now to the point, I came across thrift before and was curious about where corba fell down in the eyes of the thrift developers. I wrote to Mark Slee thus (slightly redacted):
quite by chance I came across your paper Thrift: Scalable across
Language Services Implementation. I found it very readable and clear.
Your conclusions section makes very brief comparisons between Thrift and
similar technologies. I've heard nothing good about SOAP, and COM is
Microsoft-proprietary, so not with a bargepole. The comparison that
does interest me is with CORBA. You describe it as debatably
overdesigned, but is this a problem in itself? If you don't have to
implement it, it's not your problem (granted, managing it might get a
bit painful). You describe it as having a cumbersome installation;
while this is undoubtedly not a good thing, it doesn't seem to be a very
big thing and conceivably could be automated. The one description that
may possibly be damning is calling it a heavyweight, but I don't know
whether that refers to its installation size and complexity, or its
performance. If it is an issue of performance then that's the killer
blow, but if not then all other problems of
overdesign/installation/whatever appeared to me to be minor -- at least
compared with the effort of writing Thrift.
So if you could spare a moment to elaborate, what was the problem with
CORBA that forced you down the road to writing your own interoperability
He replied thusly (likewise slightly redacted, permission granted to post it here)
1/ CORBA requires a heavy CORBA stack. The developer has to *learn*
CORBA whereas Thrift aims to let the developer use standard native code.
i.e. in Thrift you get to use HashMap in Java, std::map in C++,
2/ CORBA does some really complicated things that aren't usually
necessary. i.e. it has the notion of remote objects, rather than just
thinking of it as sending data back and forth. This makes it slower and
3/ It's not just that it's heavy to install, it's heavy to run and a lot
more runtime overhead than Thrift, which is designed to be as
lightweight as reasonably possible.
4/ Doesn't have transparent application-versioning support like Thrift
(i.e. changing object definitions on one side but not the other).
5/ Not protocol-agnostic. Thrift lets you use Binary, or ASCII, or JSON,
or XML and switch between them pretty easily.