Forgot your password?
typodupeerror

The Rise and Fall of Corba 304

Posted by ScuttleMonkey
from the always-easier-in-hindsight dept.
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."
This discussion has been archived. No new comments can be posted.

The Rise and Fall of Corba

Comments Filter:
  • by Zero__Kelvin (151819) on Tuesday June 20, 2006 @01:44AM (#15566898) Homepage
    FTA:
    CORBA 2.0 in 1997. ... CORBA's future looked rosy indeed.
    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 .... but why would you?

    CORBA could *easily* be revived if Sun finally grasped the revolution in the market and decided to do so. Will they? Seeing as .NET/MONO is the only real competitor, they have an obligation to the community to do so IMNSHO. Will Sun step up to the plate and figure out that they have a very real obligation to the future? Hmmm ....

    BTW .. OMG was just a Sun directed organization ....
  • by timeOday (582209) on Tuesday June 20, 2006 @01:54AM (#15566928)
    CORBA could *easily* be revived if Sun finally grasped the revolution in the market and decided to do so.
    I don't think so. I spent almost 3 years working on an abstraction layer over CORBA so the other members of my (very large) development team could use it without being specialists. It's true that CORBA does everything, and does it well, but it's just too much.
  • Re:Real reasons (Score:5, Informative)

    by The Pim (140414) on Tuesday June 20, 2006 @02:23AM (#15567009)
    The article focuses on market conditions and forces as reasons behind CORBA's downfall. Having worked on CORBA, I can say there are some technical reasons too.
    I don't think you read to the second page, where he says:
    No matter how much industry hype might be pushing it, if a technology has serious technical shortcomings, it will eventually be abandoned. This is where we can find the main reasons for CORBA's failure.
    This is the point of the article: You have to get the design basically right for a standard to fly, but getting the design basically right (not even all the way right) in a standards process is darn hard. Frankly, we need standards for standards groups, since they keep making the same mistakes and ignoring the very wise and practical advice of people like Michi Henning.
  • by Stalyn (662) on Tuesday June 20, 2006 @02:51AM (#15567081) Homepage Journal
    The UNIX/Linux world has never really had a good way for applications on the same machine to intercommunicate in a subroutine-like way. Microsoft has OLE/COM/DCOM/ActiveX, which is clunky but always available. In the Linux/Unix world, there's nothing you can assume is always there. There's OpenRPC, there's CORBA (in about five incompatible forms), there's Java RMI, and there are various kludges built out of pipes. But there's been no convergence in two decades.

    D-BUS [freedesktop.org]
  • by Anonymous Coward on Tuesday June 20, 2006 @02:56AM (#15567094)
    Unfortanly the IBM MQ and WebSphere (WAS, WPS, LWP) (in fact, all IBM software) is complete crap; slow, bloated and unstable. iSeries and zSeries are actually very good hardware though.

    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.
  • by Yokaze (70883) on Tuesday June 20, 2006 @03:32AM (#15567188)
    Alas, it was another Sun driven technlogy, [...]

    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)

    by killjoe (766577) on Tuesday June 20, 2006 @03:52AM (#15567248)
    One thing that gets overlooked with CORBA is the the stateful two way communication between the clients and the servers. The server can raise an event and tell the client to do something. That's just not possible with web services where constant polling is the order of the day.

    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?
  • by Cyberax (705495) on Tuesday June 20, 2006 @04:32AM (#15567396)
    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.
  • by Anonymous Coward on Tuesday June 20, 2006 @05:06AM (#15567494)
    That is analogy described in Tanenbaum's book "Computer Networks."
  • by codonaill (834165) on Tuesday June 20, 2006 @05:52AM (#15567614)
    CORBA is hard, it really is - but it's not impossible to work with. When CORBA started, the distributed development world was hugely different to what we have now - there were very few code-generation tools at the time. It was originally C++ and the Java mapping never really took off. However it was the seeds of the J2EE movement that came after it - read the EJB 1.0 spec and you can see the influence of CORBA on it. In fact, I seem to remember that it mentioned that CORBA should be used to handle persistence. (Which is bizarre, as the OMG persistence specs were always terrible, and the implementations worse). Things have changed though, and the whole web/firewall/security issues did kill it off in front-end situations (anyone remember CORBA Applets?). However, it's still alive and kicking deep inside in telephone networks, aviation industries, stock brokerages and much more. It'll be decades before the existing applications are removed. I still come across sites that have a CORBA infrastructure playing some part of the Middleware architecture - and working well for years. Bad? Maybe, but it works.
  • by michaelwatson (445677) on Tuesday June 20, 2006 @06:17AM (#15567678)
    Y'all talk about CORBA as if it were really dead. Hello? Check out Doug Schmidt's The ACE Orb (TAO). Can you say high performance FOSS distributed computing platform, in use in some of the most demanding of applications and demanding environments in the world?

    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.

  • by DarkMan (32280) on Tuesday June 20, 2006 @06:26AM (#15567695) Journal
    encryption: HTTPS
    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. .NET web services are about 2 or 3 times faster than Axis, from our benchmarks (which did use stateful web services via WSRF, but I don't believe that distorts the timings apprechiably.) GSOAP is about 5 times faster.

    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.
  • by michaelwatson (445677) on Tuesday June 20, 2006 @06:39AM (#15567740)
    What planet have you been on? I'm actually an MS fan, but in this case, I have to say that you've missed the boat. CORBA and COM have little to do with one another. One is limited to a single machine (COM). The other is a distributed communications technology (CORBA). True, Microsoft has a distributed version of COM (DCOM), but it's nearly impossible to deploy unless you've got a rocket-science-equivalent degree in Windows security permissions. You say "MS saw a need, designed something to fill that need, tweaked it until it worked, then released it." Yes, they did. And DCOM stank to high heaven. Even Microsoft doesn't talk about it anymore.

    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)

    by 21mhz (443080) on Tuesday June 20, 2006 @06:51AM (#15567767) Journal
    GNOME is steering away from CORBA, to the point of rewiring their next major release for D-BUS [freedesktop.org]. I believe this includes Bonobo.
  • by Anonymous Coward on Tuesday June 20, 2006 @07:17AM (#15567834)
    As someone who was worked in both, rather that the position you outline, in my experience, it is the case that in the "real world" more people are more stupid and therefore take longer to learn things.
  • I was going to tag this as insightful, but figured I would add to it rather than mod.

    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.
  • by Michi (41795) on Tuesday June 20, 2006 @10:14AM (#15568894) Homepage
    > Hennings opinions should be taken with a pinch of salt. While he co-authored the bet known book on CORBA, he has since left the CORBA arena following the merger of his own company with IONA, and is now pushing an alternative technology called ICE.

    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.corb a/browse_frm/thread/6f47a3d21cd0d9dc/f597718937b8a 3f3?lnk=st&q=3eXDf.916%24k6.18007%40nasal.pacific. net.au&rnum=1&hl=en#f597718937b8a3f3 [google.com.au]).

    > 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.
  • by LizardKing (5245) on Tuesday June 20, 2006 @10:25AM (#15568995)

    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)

    by Michi (41795) on Tuesday June 20, 2006 @10:49AM (#15569218) Homepage
    > The big problem with IDL-based RPC is that it becomes essentially impossible to version your APIs.

    That is true for CORBA, but it is not true for Ice. Have a look at http://www.triodia.com/staff/michi/connections/iss ue8.pdf [triodia.com] "Can a Leopard Change its Spots?" for a versioning mechanism that allows you to seamlessly version an application without breaking backward compatibility.

    Cheers,

    Michi.
  • by jonabbey (2498) * <jonabbey@ganymeta.org> on Tuesday June 20, 2006 @11:01AM (#15569317) Homepage

    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.

  • by Svartalf (2997) on Tuesday June 20, 2006 @11:27AM (#15569569) Homepage
    When I used TAO, it just all snapped together. Minimal noise. No goofy setup, etc.
    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)

    by joto (134244) on Tuesday June 20, 2006 @12:02PM (#15569867)
    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?

    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...

  • by joto (134244) on Tuesday June 20, 2006 @12:08PM (#15569913)
    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.

    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.

  • by _fuzz_ (111591) <me@@@davedunkin...com> on Tuesday June 20, 2006 @12:23PM (#15570076) Homepage
    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.)

    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.

  • by BattleTroll (561035) <battletroll2002@yahoo.com> on Tuesday June 20, 2006 @12:24PM (#15570091)
    "Anyone here ever REALLY try to use CORBA across languages and platforms?
    No ... seriously, using something besides Java on both ends."

    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.

  • by Animats (122034) on Tuesday June 20, 2006 @01:45PM (#15570743) Homepage

    What all these systems do is quite similar. The basic idea is this:

    • There's some way to find out what other programs are running that are willing to talk, a "resource location" protocol.
    • Once you find out who's willing to talk, there's a way to find out what messages they understand and their formats. That's the key to all this.
    • Then, hopefully, there's some security mechanism which decides who's allowed to make which calls to whom.
    • Then, the caller and callee can communicate in a subroutine-like way, with some assurance that they're talking the same language.

    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.

  • by indifferent children (842621) on Tuesday June 20, 2006 @02:23PM (#15571034)
    Subsetting must hurt compatibility though - different vendors will implement different "10%"s of the features.

    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).

One good reason why computers can do more work than people is that they never have to stop and answer the phone.

Working...