Slashdot Mirror
The Rise and Fall of Corba
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 might have been a great messaging infrastructure and all, but any corba websites I saw were confusing, over-diagrammed, impenetrably academic documents. Seriously, could you dumb it down a shade? Spare me your medical mumbo jumbo? Hello world apps?
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.
Initially the specifications for CORBA (object model, servers, language mapping, ...) were not free. Whenever I tried digging for details I ended up at a page which basically said "buy the expensive book". Of course they needed funding, but the lack of a free specification hindered adaption. I was also turned off by the continued references to UML (which was a new-fangled thing back then). When looking for hard details a floffy box does not help.
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.
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.
hilarious
I knew Corba as the Common Object Request Broker Architecture. I knew it was middleware, but I never used it. I've use the entire LAMP stack to build killer web sites. Not one stitch of CORBA within it. You might argue that CORBA is middleware, and I'm not using it. Agreed. But as others have stated, the LAMP stack comes with piles of documentation. Corba usually insisted on a very specific installation...you basically had to know how it worked before being able to set it up and use it properly. Now CORBA is fading. When it's gone, I will remember it as technology that might have been ok, but no one will ever know, and now that it's gone, no one cares.
Why I think CORBA and other forms of RPC are a bad idea.
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.
Need a Python, C++, Unix, Linux develop
I can't find a citation for this offhand but the original author, whoever it was, deserves credit.
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.
The problem with CORBA was mostly the technicalities and 'grossness' of the design. Yes I used the Java bindings, and it was just crap. All these "helper" objects and peers and stubs and junk. You'd compile an IDL, which was some hacked up C++ interface which wasn't even C++, get a buttload of Java classes that did not act anything like any other Java object on the planet. Lots of 'icky' exceptions. It just, for lack of a better way to describe it, had no style.
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.
Ayup, GNOME has their own implementation of CORBA stuff, called ORBit.
Bonobo is the component framework in GNOME, and is built atop CORBA.
AFAIK they're still pretty much in use.
Ricdude,
I've used both CORBA and Ice.
Check out Ice. You will experience a rush of "the good"!
STL, baby.
Note: I do not have any affiliation with ZeroC or Ice, just admiration.
/be/ nerds. If you had a personal computer, you built it. If
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.
Some years ago I worked on a roll-out of some systems management software at a large company.
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.
Have you ever developed web services? For the most part, it's even more complex. WSDL is more complex than IDL, for sure. Interfaces in WSDL often have to be awkward because they lack object orientedness. Callbacks are a real pain in the neck using SOAP. Performance sucks. Large objects suck. And as someone else said, SOAP is struggling to provide standards and features that were mature in CORBA for years.
.NET, that make developing web services a breeze.
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.
I always had the impression that nobody at OMG had ever worked on a real system in a real environment.
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.
Old COBOL programmers never die. They just code in C.
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).
Censorship is telling a man he can't have a steak just because a baby can't chew it. --Mark Twain
I am sure the author of this article is a fine individual ... however I am serious forced to question is opinions.
CORBA is far from dead ... CORBA is in fact mandidated for use in every radio used US miltary, coastgaurd etc by 2010 (I believe). One only has to google for JTRS and start searching the links for SCA (the standard being used). And this is just the icing on the cake.
CORBA itslef is a enormous overhead saving tool ... I have worked with far to many engineers that want to design there own msg'ing system between processors and devices ... without CORBA you are simply re-inventing the wheel. The CORBA community has already made its mistakes and corrections.
And as for his assesment of the individuals contributing to the standard ... well he could not be more wrong ... these people are highly qualified/knowledgeable individuals building real systems and using CORBA to build real systems ... nothing is added to the CORBA spec ad-hoc.
The biggest problem CORBA has with its addoption is its foot print size in embedded systems ... however thanks to modern memory sizes this is no longer a problem ... so in my humble opinion the author needs to wake up and jump back on the CORBA bandwagon ... otherwise he can go sit on his own and re-invent CORBA's past while CORBA moves on with life.
Rant over :-)
I really like that word you coined: zealout. Sounds like a cross between zealot and sellout, which may be part of the reason for some of the problems with CORBA.
Phase Relationships in the Standardization Process, 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
Take a look and feel free: http://www.PieMenu.com
A standard that is too broad is no standard at all. For instance, I could define a "universal language standard" that encompasses C++, C, Java, C#, D, Smalltalk, Lisp, Algol, Fortran, and S/360 assembler code. Now how dumb would that be? CORBA dumb, it seems.
For all its faults, CORBA does fill an important niche. As far as I know it is the only communication technology that features:
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.
Butbutbut... CORBA is simple! WTF are you doing?
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.)
Michi Henning owns a company which develops ICE...which is a competing product to CORBA. Nothing to see here, move along please.
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.
Patriotism is a virtue of the vicious
Thanks to Moore's law embedded systems have grown up enough to use CORBA. I know this because I work on a project which uses CORBA heavily (at least in the TAO and JacORB 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 provides a competitor to CORBA and Web Services. And, you guessed it, that product addresses each and every flaw he outlines in his article.
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.