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."
1. OMG Stable
2. ???
3. OMG Ponies!
Was hoping for an outline of Cobra Commander's long list of failures :(
Aw Frell this
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?
Let's do SOAs based on WebServices. Right now, right here.
... and so on, and so on...
The only Web-Service-Standard that's currently finalized and widely accepted is WS-I basic profile. So, no standard on...
- authentication (no, dear MS people, HTTP basic is _NOT_ sufficient for the IBM MQ guys)
- transaction management, transport and control (please say properietary soap headers)
- encryption (there IS a standard for XML encryption, but it's unsure how to use it within SOAP)
- naming services (UDDI is so dead, it's already smelling, go and find a public UDDI registry that's not just a webpage, that you can query via SOAP, IBM's developing a Websphere Naming Service, superb!)
-
Stuff that CORBA has been offering for nearly a decade! So why are webservices popular? Because of the technology? No way! They're freaking slow (our Java RMI services are nearly 50 times faster than those implemented with Apache Axis 1.4 here, and axis is pretty good). No, just because of the tools!
Go, build a Webservice with NetBeans and a client with VS.net 2005 and you will have to implement two or three lines of code... That would have been possible with CORBA, too! The fall of CORBA is just a matter of tools, the technology is clearly better, offers more features, is very performant.
But coding these days requires click and run...
Sad.
I was learning CORBA in 1997. Alas, it was another Sun driven technlogy, like Java, before Sun understood how the technology landscape was changing. The only FOSS CORBA implementation that came anywhere close to implementing CORBA 2.0 was Orbit, and I do not know if the developers didn't have the chops, or (more likely) they were swimming upstream against a Sun that was still either hostile to OSS or simply wrote it off as a non-factor. In the end CORBA suffered the same fate as Java for the same reason(s).
You can still use both
CORBA could *easily* be revived if Sun finally grasped the revolution in the market and decided to do so. Will they? Seeing as
BTW
Guns don't kill people; Physics kills people! - John Lithgow as Dick Solomon on Third Rock From The Sun
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.
This article is nothing but a hatchet job on a mature committee standard. Corba is not falling like DCOM, it's soaring like the Hindenburg.
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
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.
This is definitely a case where Microsoft's way of doing things was vastly superior. Whereas CORBA was designed by a committee of competitors who all wanted to sell object request brokers, COM was designed by a single company who wanted to sell software that could interoperate.
MS saw a need, designed something to fill that need, tweaked it until it worked, then released it. OMG designed something to fill that need, and more or less immediately released it. As a result, no two implementations of CORBA could talk to each other without buying another piece of software. Come to think of it, I don't really know why they didn't just copy COM -- at least it worked.
What they should have done was have a body of experts collaborate on a standard, implement it, tweak it until it worked, and then release it. This is why standards like IEEE 754 (floating point) and JPEG are so successful, while standards like CORBA and VRML2 are such crap. Once the dust settles on ODF, I'm afraid that ODF is going to end up like CORBA, with every program implementing it differently enough that adoption is hindered and it only gets used in-house by companies that mandate it.
dom
EJB 2.0 is just a part of CORBA 3.0 specification :)
So it's easy to understand why there is no a single CORBA 3.0 implementation.