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."
Where comes the Sun ... ???? (Score:5, Informative)
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
Re:Where comes the Sun ... ???? (Score:5, Informative)
Re:Real reasons (Score:5, Informative)
Re:OpenOffice and GNOME use CORBA. (Score:5, Informative)
D-BUS [freedesktop.org]
Re:What a ridiculous trend... CORBA to WebServices (Score:2, Informative)
And no, Axis isn't pretty good, is just as bad as the IBM stuff (probably written by IBM employees, though released through Apache foundation). It's slow and bloated and generates the most horrible code I have ever seen.
You're right about RMI though, it's very fast and extensible.
Re:Where comes the Sun ... ???? (Score:3, Informative)
CORBA? Sun driven? Everyone else did have more complete Corba implementation than Sun in their JDK.
1997... I can't claim that my memory is correct on that matter, but sometime before 2000, JacORB [jacorb.org] provided a FOSS CORBA 2.0 Java implementation, which surpassed Suns by leaps.
Re:Real reasons (Score:3, Informative)
CORBA was a great idea implemented complexly. People don't like complex.
I should mention that the author of the article works for a company which sells a product they claim is "better then corba". I have never used their products so I can't say anything about it but it's something to keep in mind.
BTW zeroc guys do you have ruby bindings in the works?
Re:One man's simplicity... (Score:5, Informative)
Re:The parable of the two elephants (Score:1, Informative)
Not as bad as all that! (Score:2, Informative)
CORBA is alive and well in TAO (Score:3, Informative)
Yeah, it's got CORBA's steep learning curve, but once you're there, you can write distributed systems that perform much better than any web service platform will ever perform. It's FOSS, completely free for any use, unlike Michi Hennigs' ICE. I respect the hell out of Michi. I love ICE, but Zero-C's commercial usage fees are way too high for me to consider for any of my company's efforts. So I went back to TAO for my distributed computing needs and I'm as happy as can be.
I think you're missing some standards... (Score:5, Informative)
authentication: HTTP Basic over HTTPS, or certificate based authentication over HTTPS
transaction management: WS-Coorination.
I mean, you can use WS-Security; WS-SecureConversation and all that XMLSecurity jazz, but frankly, why bother when HTTPS just plain woks? (You probably have to give up on the 'firewall friendly' approach of everything over port 80, but that is a significant step forward in my book.)
naming: I'll give you that. UDDI feels overengineered for what it's normally used for. On the other hand, why are you looking for a public UDDI registry? The Registry is essentially the single point of contact for a particular application; thus you normally would want to keep some level of control over it. On the other hand, for public acces web serivces, have a look at Xmethods (which does offer a UDDI query interface).
Oh, and I disagree that Axis is any good at all, especially not in performance terms. In fact, Axis 1 is the second slowest (and second worst) way of using SOAP (Axis 2 is the only thing worse). If you want something fast, try GSOAP and C++. (To elaborate: every call made with Axis is essentially a dynamic call, the 'compilation' just writes code to change the defaults. This is a very poor design if you want performance, as you can optimise a SOAP engine a lot if you know the schema at compile time - and I'argue that's the most common use case.
Web serivces have the potential to be approximately the same speed as CORBA, if they're not, look at your middleware.
Java RMI can always be faster, because it knows that the classes is needs are already on both sides of the wire or that it can get the actual class directly. That's not possible in a language independant system, where instead you have to give a description of the objects. Also, RMI can pass richer objects than SOAP can, (SOAP is can't pass objects with methods, just data holders). That allows for better architectures to be generated, also improving speed.
Re:I hate to not bash MS on /. but... (Score:4, Informative)
CORBA, on the other hand, is heavily used in telecom, aerospace, financial, and high-performance, realtime scientific and control applications. Check out Doug Schmidt's TAO [wustl.edu] if you want to see what complete free, open-source CORBA can do. And stop bothering us with MS's abortive attempt at the same.
Re:Gnome and CORBA (Score:4, Informative)
Re:good technologies left behind by stupid mediocr (Score:1, Informative)
Re:Boneheaded sysadmin port blocking (Score:3, Informative)
On the ports, the biggest problem was applications (not necessarily the corba orb - don't remember from my one project with it) wanted a range of ports rather than a specific port. Had we been able to say port 4567 or something like that, our security folks would have been more than happy to open up the firewall a bit. Many of the product we were wanting to use would try to use ports 3000-4000 or something silly like that.
Re:Biased opinion from Henning (Score:4, Informative)
Correct--I decided to do something better than CORBA after slaving my guts out for seven years trying to make CORBA better, and largely getting nowhere. Eventually, I realized that there was only so much sh*t I could push uphill and decided to focus my efforts on something more productive.
> The concepts like the POA are too over engineered, but the underlying ideas of language neutrality, a simple interface definition language and a common wire protocol have not been bettered.
I beg to differ. The CORBA POA interface requires over 200 lines of IDL definitions when, in fact, I can provide all of the functionality of the POA, plus some extra, in just over 30 lines.
Yes, language neutrality is a good idea. No, CORBA IDL is *not* simple, not by a long shot. (Look at the last section of the Slice chapter in the Ice manual for some of the reasons.)
IIOP is a very poorly designed protocol that has more flaws than a dog has fleas. Among them a quite major one that prevents efficient implementation of notification services. (See the Ice manual for details.)
> One area where CORBA is particularily useful, is in event or notification based systems.
The CORBA event and notification service are interface nightmares, and cannot be efficiently implemented due to design flaws in IIOP. (See http://groups.google.com.au/group/comp.object.cor
> Most recently, I used CORBA to replace a SOAP based system. Compared to SOAP, the CORBA based system was faster, easier to work with and far more reliable.
I don't doubt that. It's very hard to beat the ineptitude of SOAP and WS. Now, if you had used Ice to do the same thing, you would probably have done it in half the time, with half the pain, and twice the performance
Cheers,
Michi.
Re:Where comes the Sun ... ???? (Score:3, Informative)
I was learning CORBA in 1997. Alas, it was another Sun driven technlogy, like Java, before Sun understood how the technology landscape was changing.
Bullshit. Sun was pushing RMI by 1997. CORBA is a standard backed by the hundreds of companies that signed up to the OMG. (At my side are some NextSTEP developer manuals which I'm amused to see even have an OMG logo on them).
The only FOSS CORBA implementation that came anywhere close to implementing CORBA 2.0 was Orbit
Bullshit again. Go check out omniORB, MICO, JacORB and TAO for starters. All open source, all actively maintained and all supporting CORBA version 2.0 or higher.
In the end CORBA suffered the same fate as Java for the same reason(s).
So, CORBA is like Java. Ubiquitous in big companies and capable of producing highly scalable systems with excellent reliability, but not popular with PHP wheenies on Slashdot.
Re:IDL (Score:2, Informative)
That is true for CORBA, but it is not true for Ice. Have a look at http://www.triodia.com/staff/michi/connections/is
Cheers,
Michi.
RMI is better, in a Java-only world (Score:3, Informative)
Actually, the ability of RMI to depend on a common code execution on either side of an RMI link (at least when using JRMP, the original wire-level protocol for Java-to-Java RMI) means you can do a good number of tricks that you can't easily do with CORBA. You can pass classes (not just objects) from JVM to JVM. You can operate with distributed garbage collection and multithreading out of the box. You never have to worry about whether your native Double class has the same representation and semantics as the equivalent class on the far side of the RMI link. You can pass any arbitrary object to the other side of the link and know that it will be reconstituted properly, without having to re-do parts of your design in IDL.
RMI is tragically flawed by its limitation to the Java environment, but within that environment, it is a superb solution, providing simple and flexible support for distributed object systems. Want security? Wrap your RMI communications in SSL and turn on cryptographically random ID codes for your distributed objects. Want the ability to penetrate firewalls? Encapsulate your RMI calls in HTTP. Want to have your software automatically bounce from system to system? Java's ability to transparently pass serialized remote object references makes it a snap.
As the article says, CORBA was crippled from birth by its creators' insane idea to deliver a set of castle-in-the-sky specs without testing them out with actual implementations. CORBA 1.0 couldn't even speak from ORB to ORB over the Internet, for pete's sake.
This wasn't my impression of things... (Score:3, Informative)
If it's on the same network segment, it just finds the NamingService object on the
segment (If you've properly started it...) and just works. I know, I've designed
massively distributed trasaction processing systems with it that had to handle situations
like vending a toll gate with a vehicle going through it to speeds up to 55 mph.
Now, to be sure, this is more the ACE/TAO people's doing, but there's NOTHING in CORBA
that requires all the noise that you typically see with other ORB implementations. And
CORBA's neither slow nor cumbersome- it's all in the ORB implementations. Of which, many
just plain flat suck.
Re:CORBA. (Score:3, Informative)
If you'd RTFA, you'd understand that that's exactly why it failed. Corba is badly designed, and overly complex for what it does.
First of all it's a lot of hype. Today, it might sound daft, but when CORBA was envisioned, everybody did not use http and XML for everything. So if you wanted two or more programs to talk to each other, you'd need to invent a new protocol. And people did just that all of the time, with varying success. Of course, there would have been money to be saved, if everybody could agree on a common protocol. But nobody but salespeople could have come up with the idea of making the common protocol using "objects" instead of clients and servers. Almost all CORBA-lingo is equally daft and misleading.
Secondly, it never worked. There's never existed, and probably will never exist, an implementation of CORBA that has all the features in the standard. And at least at the time I used it, every implementation was buggy, forcing some of the top programmers in our organization had to become "CORBA-experts", so that we would be able to use CORBA at all. This was a waste of talent, as this was the guys with 10-30 years of domain-specific knowledge and experience who used their time on CORBA instead.
Thirdly, it was never compatible. Every revision of the Corba standard to date, and every implementation by every vendor, were incompatible. And it's not just a question of search and replace in your code-base. Implementations are incompatible in semantically interesting ways that are relevant and important for application developers. It's called "vendor lock-in".
And fourth, it was overly complex. A simple "Hello World" CORBA-program that merely contacts the naming service and looks up the IOR to get a reference to a remote object, which it calls at least one method on, has to be about 100 lines of code. The verbosity of CORBA in this respect is staggering, especially when you see that it's intended to be an improvement over earlier systems, such as DCE (itself overly complex, but still...).
Ok, our organisation still uses CORBA, and are even quite happy about it (today). But it has cost us a lot of money in the past. On the other hand, todays web-services would be totally inadequate for us, so the only other alternative would be to roll our own again...
Re:What a ridiculous trend... CORBA to WebServices (Score:3, Informative)
Trust me when I say this: CORBA for C++ is much worse!
I've tried both, and CORBA in java was such a relief from doing it in C++, I almost started thinking CORBA was sane, and only the C++ bindings sucked. Therefore I'm very happy for your perspective and insight.
Re:I think you're missing some standards... (Score:3, Informative)
Because HTTPS only offers point-to-point security. If you need to encrypt or authenticate through a web service proxy (e.g. an ESB) you can't guarantee or prove the security of the document from point A to B to C. Also, SOAP can run over SMTP and other transport protocols. So if either of those situations are a requirement for your architecture, HTTPS doesn't just plain work.
Re:interop killed CORBA (Score:3, Informative)
No
Yes. We use Java for our clients, and C++ for our servers. Works great on Linux, HP, AIX, Windows, and Solaris with very little cross-platform issues. Your assertion that language interpoerability failed is incorrect - it works as designed and works well.
What it all does, and why Linux/Unix lacks it (Score:3, Informative)
What all these systems do is quite similar. The basic idea is this:
This all originated as an internal mechanism within Visual Basic and was responsible for its success. Alan Cooper had finally implemented a reasonably idiot-proof way to make A talk to B. That's why Visual Basic controls were so powerful. Then Microsoft made it a general-purpose mechanism. The Unix/Linux world didn't pick up on this for a long time. The Gnome and OpenOffice people get it, and their stuff plays well together. Most other extensibility is a master-slave relationship, usually involving "plug-ins", "toolbars", or "scripting".
Part of the problem is that the main languages in the Unix/Linux world are C and C++, which have no introspection. If you have a structure, and you need to go through all its fields and get their name and type info so you can format and marshall them for transmission, there's no way to do that from within C or C++, other than by writing glue code by hand for each interface. Preprocessors have been built to deal with this problem (ones exist for OpenRPC and SOAP), but they're clunky and complicate the build process. CORBA requires that you define each interface in its own special language, IDL. The Java world has a solution to this problem, but it's Java-only. Microsoft has put extensions into their various dialects of C and C++ to deal with this, but they were too Microsoft-specific to go into the standard. So making A talk to B without extra work remains hard in the Unix/Linux world.
Re:What a ridiculous trend... CORBA to WebServices (Score:3, Informative)
No, the ORB vendors should provide all of the spec'ed functionality. And to be fair, they tend to do a very good job at this completeness. As a programmer who uses CORBA (omniORB, ACE+TAO, and VisiBroker), I only *use* 10% of the features. I never use: POA interceptors, POA policies (hardly at all), Trading Service, AVService, etc.
There are a few features that are almost never implemented by the ORB vendors, such as the TypedEvent interfaces to the NotificationService. That is one of those stupid features that the domain specialists (e.g. IT people from the Healthcare industry) put into the spec, without knowing how difficult and inefficient it would be to implement and use. The ORB vendors responded by ignoring that feature (mostly out of necessity).