The Rise and Fall of Corba 304
ChelleChelle writes "Chief scientist of ZeroC, Michi Henning, has an interesting look at the story behind CORBA a once-promising distributed computing technology. Henning provides more than a brief history, in addition to several reasons pinpointing why CORBA fell short, focusing specifically on the OMG's technology adoption process itself. Most interesting is the final discussion on what we can learn from CORBA's decline, particularly in reference to web services."
CORBA. (Score:5, Interesting)
Re:What a ridiculous trend... CORBA to WebServices (Score:5, Interesting)
CORBA is too complex, an overengineered attempt at creating a clockwork the size of Tokyo whereas a single wristwatch would have sufficed.
Yes, I have had to use it, unfortunately.
The OMG people are clever bunch, but why do they insist on making these superheavy monolithical monsters? Why not build interoperable but smaller things which you can grok immediately, almost via intuition?
Like you yourself put it indirectly via examples, developers like to develop systems which have the best supporting tools, systems which are the most intuitive and easiest to understand, systems which do not fight back when you try to do something, systems for which development is not an exercise in sado-masochism. So there's a design paradigm for you: make the APIs dead simple to use, and they will be used, a lot.
Nobody wants to hack around some big behemoth. It's about job ergonomics, really. If a chair doesn't feel right for your body, you don't sit in it.
Other failures (Score:3, Interesting)
It also seems that the vendors had a lot of problems agreeing. AFAIK it wasn't until version 2 that the on-the-wire format was specified. I can only speculate why.
But I must say that the IDL (interface definition language) is close to ideal. Looks a lot like Sun RPC, and way better than WSDL. It only lacks the versioning as the article also mentions.
Real reasons (Score:5, Interesting)
CORBA always required holes in firewall, more complicated to setup(as mentioned in article), poor/no load balancing/fault tolerance mechanism/ maintainability(probably this was not meant to be there, but very important for an ecommerce setup), poor QoS (this improved in CORBA 3.0 after Douglas Schmidt's and others contribution), security (though iiop over ssl appeared sometime later, security mechanisms for ecommerce were missing, that could bring collaboration from unknown consumers/providers.)
SOAP/xmlrpc address some of these issues nicely, and might become defacto tools for business to business integration. I had only one issue with it. The protocol is too verbose.
My 2 cents.
Corba, Corba: I hardly knew ye (Score:1, Interesting)
I took a close look at CORBA and wrote this (Score:4, Interesting)
Why I think CORBA and other forms of RPC are a bad idea [omnifarious.org].
Here is the paper in brief...
The speed of light is a constant. Latency will never improve beyond a certain point. For all but the simplest things, RPC is the wrong model for dealing with the problem of communicating with other systems.
Also, the abstraction layer of function calls is the wrong place to put the communication of disparate, unrelated systems. It encourages too many assumptions about the implementation of either side. There is too much hidden state in the caller and reciever of the messages.
The parable of the two elephants (Score:5, Interesting)
Imagine two superposed graphs, with time on the x axis. One is the rate of technical change. The other is the rate of adoption.
Standards activity needs to happen between the peak of technology development and the peak of adoption. Too early, and you standardize on immature technology that nobody will want. Too late, and the market has committed to somethign other than your standard.
Those two peaks in the charts are called the "two elephants". In fast-moving markets they move closer together, and the standards committee is "squeezed between two elephants".
Given that people were rushing to deploy immature technology for distributed apps, one factor in CORBA's troubles may have been that there was no room between the two elephants for a reference implementation or for nontrivial test deployments.
Re:What a ridiculous trend... CORBA to WebServices (Score:5, Interesting)
Try to teach CORBA to some normal programmer and they'll be thinking that creating their own wire protocol is probably going to be easier for 99% of the things they need to do. Seriously, you just don't look at CORBA bindings (for Java at least) and want to have anything to do with it. It's probably not so bad for C++ developers because they are used to a lot of noise and complexity, and they have templates and stuff to 'spray perfume' on CORBA and make it smell... better.
But seriously, when your technology drains the life out of any competent developer who actually likes to program then you know something is very wrong.
Re:Gnome and CORBA (Score:3, Interesting)
Ayup, GNOME has their own implementation of CORBA stuff, called ORBit [gnome.org].
Bonobo is the component framework in GNOME, and is built atop CORBA.
AFAIK they're still pretty much in use.
Re:Distributed applications (Score:1, Interesting)
I've used both CORBA and Ice.
Check out Ice. You will experience a rush of "the good"!
STL, baby.
Re:I took a close look at CORBA and wrote this (Score:4, Interesting)
The increasing amount of network-related latency dealt with in everyday communication generally means that in any reasonable interesting application, there are often large numbers of blocking calls that take a variable amount of time to return. Threads in and of themselves are truly not the answer, except possibly when used sparingly as part of a non-blocking system. (as an aside, I've found that as a Python developer, working with the Twisted Python [twistedmatrix.com] libraries was invaluable in my understanding of asychronous development techniques.)
With regards to the idea of function calls being an innappropriate abstraction for these mechanisms, I think the issue really depends on the implementation. The reasons I've used an RPC/IPC solution to communicate between processes (either locally or remotely) was because the various processes weren't closely related, and needed to have a common interface between them.
Making assumptions about implementation is an inherently bad programming habit, and has much farther reaching consequences. APIs would be essentially worthless if the developers made assumptions about how the work is done "behind the scenes". If you need intimate knowledge of the memory space of another process, it may be an indication to use process fork()ing to provide the same results.
anyways, my 2/100th of a dollar....
-phil
Re:zeroC ICE (Score:1, Interesting)
If you have used CORBA (especially the C++ bindings), I definitely suggest that you
try Ice.
I evaluated XML-RPC, SOAP, CORBA, and Ice for my company.
My recommendation was, crushingly, for ZeroC's Internet Communications Engine (ICE) technology. It totally
rocks. It is what you should build SOAs upon.
If you want good technology, that is.
My company though my recommendations were interesting, but went with one of my least-suggested approaches, SOAP. The primary reason cited was that it is ubiquitous. See? If everyone is using something, it must be right to use it for everything.
I'm gonna kick back for a couple of years, and wait for the moaning. I'm sure some "compression technology" or
"deep refactoring" will come to the rescue.
It all seems to be about mindset. And so very few companies really seem to "have it" when it comes to
computers. It is almost as if the late 1970's and early 1980's PC era never really left us, those moments
when real nerds had to have chops in order to
you owned one that you didn't build, you at least could still program it.
Now, bozos not always but very often make our technology decisions. They just don't know that they are
bozos.
Re:Real reasons (Score:2, Interesting)
Yes, you are correct. Although, it has trouble with NAT. I remember one case, where we had to drop CORBA and go for designing our own protocol, because clients behind NAT would never recieve the event.
Horrible, just horrible! (Score:5, Interesting)
This software was based on CORBA.
It was hoped that by installing this software on every server and workstation in every branch nationwide (typically only around 3 to 6 machines per branch, although there would eventually be over 2000 branches netweorked), it would be possible to determine that all servers were working properly.
However the memory and CPU footprint used by the monitoring tools was immense. More than half of the RAM in the servers was taken up just by the monitoring software CORBA services, and the CPU load was also huge.
We also had serious problems with firewalls. Far too many open ports for anyone's liking.
Re:What a ridiculous trend... CORBA to WebServices (Score:2, Interesting)
There are some environments, such as
The author has some good points on why we as an industry moved away from CORBA, but SOAP and web services are even worse in my opinion.
Re:What a ridiculous trend... CORBA to WebServices (Score:3, Interesting)
The killer for CORBA in the real world was how the f*** do you get 5000 copies of the IDL to 10 platforms at the same time?
The very few succesfull implementations of CORBA had a single IDL that went:
int msg_type;
long msg_length;
char[] msg_buffer;
Thus quietly dumping 97% of CORBA and implementing a solution that could more easily be done with BSD sockets but without any architects/managers loosing face.
Currently the only widespread use of CORBA is as the transport for J2EE, and yes they use a single IDL
not too far removed form the one above.
Re:What a ridiculous trend... CORBA to WebServices (Score:5, Interesting)
Your comment is similar to many of the other comments in this thread. You're right that the CORBA specifications are HUGE and overly complex. But here's one of the great things about CORBA: it can be easily 'subsetted'. I use CORBA every day. I use 10% of it's features, and it is beautiful. If you gave me an exam about the esoterica of CORBA, I would fail, but for the parts that my company uses, it's easy.
BTW, most of the huge CORBA spec that we ignore is stuff that isn't part of the SOAP spec anyway; SOAP isn't really comparable to CORBA, SOAP is comparable to IIOP (the most popular CORBA wire protocol). Saying that SOAP is better than CORBA because it's easier/simpler is kind of like saying that MS Works is better than MS Office because it's easier/simpler (no, that wasn't a great analogy, but at least it isn't an automotive analogy).
Re:Real reasons (Score:2, Interesting)
Trust me: Ice is better than CORBA, and by more than just a little bit :-)
Unfortunately, Ruby has threading issues that prevent an Ice implementation for it. Otherwise, we would have done a Ruby binding long ago.
Cheers,
Michi.
Oh man this peeves me off ... (Score:2, Interesting)
Re:What a ridiculous trend... CORBA to WebServices (Score:2, Interesting)
Phase Relationships in the Standardization Process (Score:4, Interesting)
Phase Relationships in the Standardization Process [archive.org], James Gosling, August, 1990. [see link for illustrations]
Toshi Doi of Sony describes the standardization process in terms of the diagram at left. The i axis describes level of interest and the t axis describes time. Ti describes technical interest, and Pi describes political interest. As time passes, technical activity declines as the technology becomes understood. Similarly, generally fueled by economic pressures, the political interest in a technology increases in some period.
For a standard to be usefully formed, the technology needs to be understood: technological interest needs to be waning. But if political interest in a standard becomes too large, the various parties have too much at stake in their own vested interest to be flexible enough to accommodate the unified view that a standard requires.
In this model, Ws is the `window of standardization' where technical interest is waning (i.e. the technology has become understood), but the political situation hasn't become too hotly contested for constructive negotiating.
This model has many interesting insights, but there is more complexity in the situation that can be explored. In the original model, the T and P curves are open ended. The situation is more like the diagram at left. These curves, Ta and Pa, represent technical activity and political activity. In general, technical activity precedes political activity. Both types of activity go through phases of different intensity. As these activities proceed, they produce results. The result curves are the integrals of the activity curves.
The integrals of these two curves are drawn at left. The integral of Ta is K (knowledge) and the integral of Pa is C (calcification - revealing a strong personal cynicism). Ss, the sensibility of standardization, is just K-C. The optimum time for standardizing a technology is when Ss is at a maximum, which will be in a region where knowledge is high, but calcification has not yet set in.
A very interesting quantity to observe is the phase relationship between Ta and Pa. When the maximum point on Pa follows the maximum point on Ta by a sufficient distance, there is a wide Ss window. A sensible standard can be fairly easily set since the political activity which leads to the standard has the necessary technical knowledge in hand when needed. If Pa lags Ta sufficiently, Ss will have a long high flat top, which forms a convenient table on which to work.
Consider moving Pa left, closer to Ta. When it is close to Ta, Ss will have a shallow and flat region where the upward slope of Ta matches Pa approximately. This region is the time of chaos. Before calcification builds up, there isn't enough knowledge to do anything sensible, by the time that there is enough knowledge, there's too much calcification to allow a sensible compromise to be reached. In between, the region is flat enough that there isn't a clearly defined optimum moment for developing a standard, so there is instead a drawn out period of chaotic bargaining and soul searching.
Consider moving Pa even farther left, until it is to the right of Ta. This is the worst case: Ss is always negative. The long flat minimum region is the time of panic where the political/economic process has decided that a technology needs to be standardized, but no one understands it. Standards get set by making random guesses that are not grounded in any technical reality, but are instead grounded totally on political expedience.
The case described in the previous diagram is impossible in practice. The very act of setting a standard inhibits technical activity
Re:What a ridiculous trend... CORBA to WebServices (Score:3, Interesting)
The CORBA Niche (Score:2, Interesting)
High Performance (implementation dependent, of course)
Language Interoperability (standard language bindings)
OS Interoperability
CPU Interoperability
Vendor Independence
Object Orientation
Healthy Open Source Community
I think we can agree that these are good things to have.
There are a number of caveats, though:
CORBA works best when you have tight integration between the client and the server. The more you try to put between the two (e.g. the public Internet) the more problems you will have.
There is a good bit to learn to be able to design and build a CORBA-based system, from basic concepts to language bindings. Once you have it down most of it makes sense, and developing new applications can go fairly quickly, but it does take a while to get there. You might want to try starting with a Python ORB, since it is a lot easier to use than C++ or Java ORBs, and you can use Python later to build tests for your C++ or Java code.
You have to ignore a lot of stuff. The bulk of the CORBA services out there aren't really useful; stick to things line Naming, Notification, and Trading. Some features like valuetypes are a pain to support, so are better ignored. CCM might be worth something eventually, but it would require really good vendor tools support, and it is better avoided for now. You can get by pretty well with the concepts in Henning and Vinoski's book, "Advanced CORBA Programming with C++".
Interface evolution needs to managed carefully, since IDL is generally more rigid than XML.
These caveats make CORBA inappropriate for a lot of projects, no question, but for those projects which have performance and interoperability requirements which match with CORBA's feature set, it is worthy of consideration.
Re:CORBA. (Score:3, Interesting)
Now why the confusing websites? Well, what would you do as a vendor? Tell your clients (managers!) that you're selling them an RPC library? No way! It has to be Object Oriented Middleware, it must be Enterprise, and everything ties into the mystic ORB. You absolutely need an ORB! Well, you didn't in the 80's, but this is the 21st century and there you need an ORB! Oh, and what a remarkable conincidence... we are just selling ORBs!
Anyway, have a look at ORBit [sf.net]. CORBA can actually be simple. It's commercial software that cannot.
Re:What a ridiculous trend... CORBA to WebServices (Score:3, Interesting)
More specifically, CORBA does what needs to be done. You want location transparency, so you need a wire protocol and object references that include endpoint adresses. You want language neutrality, so you need the IDL. These parts are necessary and not overly complicated. A Naming Service is probably a good idea, and it is still simple.
What are you doing that's complicated? Trading Service or stuff layered even on that? Useless junk. Programming in C++? Okay, that mapping is crap. But why? People are constantly grappling with stuff they neither want nor need. Just don't use it, and optionally fix the faults in the things that are needed. (My wishlist: gimme a better C++ mapping that knows about STL, gimme me an ORB for Haskell, allow parametric polymorphism.)
CORBA v ICE (Score:3, Interesting)
As for complexity, SOAP is heading the CORBA way, thanks to Microsoft, IBM et al. SOAP has lots of interoperability problems btn languages, Java and Perl for example.
You could use xml-rpc but most of the implementations are brain-dead, and unusable for complex apps.
If you have to go btn two languages, just use sockets.
Re:CORBA. (Score:3, Interesting)
Heh. This article was actually the first clue I've ever read that CORBA was anything but hype. I've run across the acronym a zillion times, but before today, I'd never actually read anything that got through my thick skull that it was a communication protocol, much less what problems it was designed to solve. Same with pretty much anyone that I worked with. When management pushed it on us (complete with the management-friendly hype but not much more), the reaction of the developers was usually "Hey, that's great; we'll look for places that we can use it effectively." Of course, not really having any idea what it did or how to use it effectively, we never found any places that we could use it. The obtuse examples didn't help; reading code that doesn't make sense without uderstanding what it's supposed to do isn't a very good way to convince your typical developer that it's something they want to use.
In any case, there's not a lot of implementing you can do with just an acronym and management-level hype for "documentation".
Thirdly, it was never compatible.
Sort of a problem for something designed to solve cross-platform communication problems. (If that's actually what it was supposed to do; I'm still not sure about that.
I got the idea from TFA that it was a protocol developed mostly by a number of vendors. Are there any cases where this has worked? All the successful standards that I know of were developed with a large government and/or academic contingent, usually both. Companies generally try to hide their secrets from competitors, which is somewhat of a problem when you're trying to get competitors' products to work together. Granted, Sun and Apple are semi-exceptions, but even there, trying to get them to work out a common protocol is just asking for indefinite bureaucratic delays. (That's a voice of experience talking there; again there might be exceptions that I don't know of.)
I liked the comment in TFA that one of the problems was that Microsoft didn't adopt CORBA. My immediate thought was "Well, duh!" Of course, the XML crowd has been showing signs of nervousness about MS's involvement, especially when the news gets out that MS is applying for patents on XML encodings.
I've often thought that one of the main reasons for the Internet's success is that it was developed (by government and academic developers) for several decades before either IBM or Microsoft noticed it.
It sorta reminds me of a comment I read once from a biologist, to the effect that one of the major adaptive constraints on birds is that they have to somehow prevent predators from noticing their nests until the babies can fly.
CORBA in embedded systems (Score:3, Interesting)
Thanks to Moore's law embedded systems have grown up enough to use CORBA. I know this because I work on a project [nasa.gov] which uses CORBA heavily (at least in the TAO [wustl.edu] and JacORB [jacorb.org] incarnations). Since CORBA has strong typing, it is attractive to developers who depend heavily on typeness to provide checks in systems where no one likes bugs. And really, who wants to write another middleware to deal with distributed systems? I sure don't.
There is no disclaimer in the article so I think it is worth mentioning that even though Michi was CORBA for all intents and purposes for a number of years, his current employer [zeroc.com] provides a competitor [zeroc.com] to CORBA and Web Services. And, you guessed it, that product addresses each and every flaw he outlines in his article [zeroc.com].
To be fair ZeroC and Michi do put their money where their mouth is by supplying Ice in source form, licensed under the GPL. Although I do not see them putting this in front of a body like the IETF or trying to get Ice bindings integrated into something like boost. This would really attack that one point in the article talking about having real systems implemented and having it in front of a standards body.
Now that I have put in the proper disclaimers, I have to say that having used CORBA the last 5 years I agree with Michi on every point. Our knowledge of POAs is just now getting to the point where we are comfortable using it in complex ways. We are only now willing to entertain the notion that we are actually using CORBA the right way. We have spent weeks reading, coding, recoding, testing and testing again to understand the spec and the real world usage. The learning curve is easily the steepest and tallest of any technology I have had to learn. I said "Amen" out loud when Michi mentions that people really screw up when they don't do it right.
Using CORBA as a real distributed object system is not possible unless the system is in a network that you have complete control over. Even now we use cumbersome workarounds to develop our system remotely because we can't use CORBA like we were supposed to. Thank you very little script kiddies for making us use firewalls every where! But if CORBA had been built with security in mind in the beginning at all, it would be vastly more useful then it is now.
And we have not moved on to things like Web Services precisely because we do not want to move away from type checking and we can see the train wreck associated to security. So we use CORBA the best we can (and we have been largely successful, BTW).
Now I am going back to checking whether try blocks have been done properly for the naming service code we have to implement because of the exact reasons Michi says most implementers need the CORBA naming service.