Slashdot Mirror

← Back to Stories (view on slashdot.org)

The Rise and Fall of Corba

Posted by ryuzaki0 on 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."

8 of 304 comments (clear)

  1. Where comes the Sun ... ???? by Zero__Kelvin · · Score: 5, Informative
    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 ....
    --
    Guns don't kill people; Physics kills people! - John Lithgow as Dick Solomon on Third Rock From The Sun
    1. Re:Where comes the Sun ... ???? by timeOday · · Score: 4, Informative
      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.
  2. Re:Real reasons by The+Pim · · Score: 4, Informative
    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.
    --

    The evaluation of an action as 'practical' . . . depends on what it is that one wishes to practice.
  3. Re:OpenOffice and GNOME use CORBA. by Stalyn · · Score: 4, Informative

    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

    --
    The best education consists in immunizing people against systematic attempts at education. - Paul Feyerabend
  4. Re:One man's simplicity... by Cyberax · · Score: 5, Informative

    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.

  5. I think you're missing some standards... by DarkMan · · Score: 4, Informative

    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.

  6. Re:I hate to not bash MS on /. but... by michaelwatson · · Score: 4, Informative

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

  7. Re:Biased opinion from Henning by Michi · · Score: 4, Informative

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

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