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 Anonymous Coward on Tuesday June 20, 2006 @01:33AM (#15566871)
    1. OMG Stable
    2. ???
    3. OMG Ponies!
  • by Ka D'Argo (857749) on Tuesday June 20, 2006 @01:33AM (#15566873) Homepage
    Thought it said "The Rise and Fall of Cobra".

    Was hoping for an outline of Cobra Commander's long list of failures :(

  • CORBA. (Score:5, Interesting)

    by Anonymous Coward on Tuesday June 20, 2006 @01:41AM (#15566890)
    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?
    • Re:CORBA. (Score:3, Informative)

      by joto (134244)
      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

      • Re:CORBA. (Score:3, Interesting)

        by jc42 (318812)
        First of all it's a lot of hype.

        Heh. This article was actually the first clue I've ever read that CORBA was anything but hype. I've run across the acronym a zillion times, but before today, I'd never actually read anything that got through my thick skull that it was a communication protocol, much less what problems it was designed to solve. Same with pretty much anyone that I worked with. When management pushed it on us (complete with the management-friendly hype but not much more), the reaction of the
    • Re:CORBA. (Score:3, Interesting)

      by cow-orker (311831)
      Well, you can. It's actually dead simple: CORBA is RPC, just that you don't address some particular service, you invoke a method on an object reference, which contains the servers address. Add in an interoperable binary protocol, a standard language to define interfaces and some standard mappings to common programming languages, that's all there is to it. Services are completely optional, the ORB, commonly depicted as an all encompassing cloud with mystic abilities, is just a support library to decode ob
  • Let's do SOAs based on WebServices. Right now, right here.

    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!)
    - ... and so on, and so on...

    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.
    • by Anonymous Coward on Tuesday June 20, 2006 @01:52AM (#15566920)

      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.

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

        There are some environments, such as .NET, that make developing web services a breeze.

        The author
      • 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 witho
      • 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++?
    • by Anonymous Coward

      The fall of CORBA is just a matter of tools, the technology is clearly better, offers more features, is very performant.

      Well one reason CORBA tools sucked was that it was over-engineered: intended to solve world hunger, clean up the environment, produce a fresh and pleasing scent and tuck you into bed at night - oh yeah and be the glue for distributed systems too. Web-service oriented protocols are simpler because they try to do less. Simpler protocols means that tools are easier to produce, which means

      • by indifferent children (842621) on Tuesday June 20, 2006 @08:09AM (#15567994)
        Well one reason CORBA tools sucked was that it was over-engineered: intended to solve world hunger...

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

        • How about saying a paved road is better than a dirt bike? :)
        • 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.
    • 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

      There may be some truth to this (I've never used those tools), but that's not saying much. You've just built a self-contained "hello world" client and service, accepting all the defaults. Now, take a complicated, pre-existing service, using some non-default binding and non-trivial schemas, and integrate a client for it into a large existing application. I tried this recently usin

    • Different people need different things. For many companies being productive - i.e. having appropriate tools - is everything. In many cases tt doesn't matter if you have to roll your own or use a non-standards compliant protocol, as long as you can get the functionality out the door in a matter of months, not years.

      Like the article said, CORBA is a niche product for those who absolutely need it.
    • by Anonymous Coward
      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 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.
      • 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
    • - authentication (no, dear MS people, HTTP basic is _NOT_ sufficient for the IBM MQ guys)

      WS-Security [coverpages.org], an OASIS standard [oasis-open.org] (like OpenDocument Format), has been around since 2001. You may wish to update your SOAP knowledge.

      But coding these days requires click and run...

      No: it's all about the APIs and who's making them available. Got CORBA bindings for Google? How 'bout the National Weather Service? If nothing else, people are publishing SOAP APIs that we actually want to use. That alone makes it much more interesting that competing RPC protocols.

  • 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.
    • by maelstrom (638) on Tuesday June 20, 2006 @02:26AM (#15567015) Homepage Journal
      As a member of the open source community, I have decided to revive the OMG group. To put focus on our roots, we shall be called the Object Management Freedom Group or OMFG for short. Any takers?
    • 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.
    • 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 omniO

  • by 21mhz (443080) on Tuesday June 20, 2006 @01:45AM (#15566899) Journal
    From TFA:
    Many of the APIs were complex, inconsistent, and downright arcane, forcing the developer to take care of a lot of detail. In contrast, the simplicity of component models, such as EJB, made programming a lot simpler
    Wow. If EJB (pre-3.0) is simple in comparison, no wonder CORBA never really took off.
  • by mshurpik (198339) on Tuesday June 20, 2006 @01:51AM (#15566917)
    It's not surprising that an early middleware app like Corba failed because it was being developed at a time when the concept of middleware was just a buzzword. The article mentions the "fracturing" of the middleware market and the over-reliance on "screen scraping" technologies like HTTP+CGI. In other words, it wasn't until the standardization of the web platform (Apache+PHP+MySql or IIS+ASP+SqlServer) that people even knew what middleware was supposed to look like, and this standardization didn't happen, actually, until after the dot-com boom was over.

    • by Anonymous Coward

      Some of the technical problems of CORBA went beyond a misunderstanding of what it actually needed to do. The biggest failure from my point of view was uneeded extra state that had to be synchronized. The hardest part of distributed systems is synchronization of views, so anything that makes this harder makes the entire system more brittle. Using CORBA always started out easy enough and then got nastier and nastier as development went on. Good riddance to bad rubbish really.

    • What do you mean by "middleware was just a buzzword"? That nobody really understood it? The article claims the opposite, that many qualified experts, who knew exactly what they were doing, worked on CORBA. I believe him. The point of the article is that even with capable people involved, standards groups tend to produce crap. Are you saying that middleware not a buzzword now? It seems to be more so than ever. What makes you believe that people understand middleware better now? And what do "Apache+P
    • by Beryllium Sphere(tm) (193358) on Tuesday June 20, 2006 @03:22AM (#15567143) Homepage Journal
      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.
      • by SimHacker (180785) * on Tuesday June 20, 2006 @10:16AM (#15568920) Homepage Journal

        Phase Relationships in the Standardization Process [archive.org], James Gosling, August, 1990. [see link for illustrations]

        This is a moderately sarcastic note on the phases that the standardization process goes through, and the relationship between the level of technical and political interest in a topic. It is purely a personal view.

        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

  • Other failures (Score:3, Interesting)

    by isj (453011) on Tuesday June 20, 2006 @01:55AM (#15566933) Homepage
    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.
  • by wysiwia (932559) on Tuesday June 20, 2006 @01:57AM (#15566939) Homepage
    Why should anybody create a distributed application when a simple library API is almost always sufficient. Why making something more complex than necessary. In most cases component APIs are rather stable as soon as all the missing pieces from early beta versions are solved. Yet even if they change it's possible to handle most cases without any intermediate interface definition etc.

    Prof. Wirth always said: "Make everything as simple as possible but not simpler". While Prof. Wirth as made many things too simple (to prove his statement true) any component system is yet much too complex for any locale task and many times also even for distributed tasks. I'm still waiting for a component system which is as easy usable as a simple library API.

    O. Wyss
    • > Prof. Wirth always said: "Make everything as simple as possible but not simpler"

      I think you will find that quote is usually attributed to Albert Einstein not some Swiss guy.
       
      • I think you will find that quote is usually attributed to Albert Einstein ...

        Yet Prof. Wirth used it all the time even if he wasn't original author. I wouldn't be surprised if it isn't Einstein either. So while people get known to use a quote that never implies they've invented it.

        I'm using the term "schitter bis bewölkt" (sorry German) on all possible occasions and if I ever get as famous as Einstein, people would certainly attribute it to me albeit I definitely can't reclaim authorship. ;-)

        O. Wyss
    • by Ricdude (4163) on Tuesday June 20, 2006 @02:11AM (#15566977) Homepage
      Um, there are instances where you *want* to distribute an application across several machines, and not have to worry about the details of implementing a robust inter-process communication layer yourself. Once you get past the boilerplate code of creating an object, publishing it's reference, and locating that object, CORBA breaks down into simple function calls.

      I just wish they'd create a C++ mapping that allowed for STL compliant sequences, and std::string compatibility...
    • The threading issue is siply non trivial, and there are going to be errors of different kinds on a distributed system, rather than on a local system... somebody tripped over the cord! and the like...

      I don't know much about this stuff, but I'd stop waiting...

      Conventions for passing data drrm important.. and I would assume that you could get by omiting some of the failsafes if your application allowed for it, and have a simpiler time dealing with this stuff.

      --Am I talking out of the wrong orifice?
    • "Make everything as simple as possible, but not simpler"

      Wirth may have said it, but I think Einstein said it first.
    • Why should anybody create a distributed application when a simple library API is almost always sufficient.

      People rarely start out with the goal of buiding a distributed application. It's either a question of scalability, or simply requirements issues such as interaction with multiple systems, distributed transactions etc.

      Also, in the Java and DCOM/MTS systems, there's not an enormous difference between using the distributed component and using a library API, which is also component-based. The simplicity is
  • by Anonymous Coward on Tuesday June 20, 2006 @02:01AM (#15566947)
    Just look at all the projects built on Corba like the Berlin Project [fresco.org] and then you tell me Corba is dead.

    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.

    • Just look at all the projects built on Corba like the Berlin Project and then you tell me Corba is dead.

      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.

      Isn't Gnome based on Corba ? Not that that's neccessarily good publicity for Corba, since Gnome is a huge mess with scalability problems: try opening a 100+ Eye of Gnome windows sequentially, waiting until the processor goes idle before opening the next, and notic

    • Seems like the only thing keeping CORBA alive these days is Gnome [gnome.org].

      If I understand things right, it is a very fundamental part of the architecture, so it's not likely to go away any time soon.

  • Real reasons (Score:5, Interesting)

    by William Robinson (875390) on Tuesday June 20, 2006 @02:04AM (#15566956)
    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.

    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.

    • 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.
    • Re:Real reasons (Score:3, Informative)

      by killjoe (766577)
      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
      • Re:Real reasons (Score:2, Interesting)

        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.

        Yes, you are correct. Although, it has trouble with NAT. I remember one case, where we had to drop CORBA and go for designing our own protocol, because clients behind NAT would never recieve the event.

        • Don't worry IPV6 will take care of the problem by making NAT obselete. BHAHAHAHAHA.

          Sorry dude I couldn't resist. This industry cracks me up sometimes.

          Anyway, I feel your pain. I really do. NAT has been my nemesis all too frequently.
    • Hm, I'm sure your complaints are valid, but it also looks as if they are mostly implementation-dependent.

      I'd wager the guess that CORBA applications can be well distributed (i.e. allow load balancing) and that an ORB could also include QoS features. Fault tolerance... are you talking about network errors, or simple return values in contrast to exceptions?

      Maintainability is clearly a bigger problem, as APIs evolve, but no technology can really solve that one, it's an organisational problem.
    • Re:Real reasons (Score:3, Insightful)

      by dan the person (93490)
      CORBA always required holes in firewall, more complicated to setup(as mentioned in article), poor/no load balancing/fault tolerance mechanism/ maintainability

      Right, so SOAP gets around this problem by reusing port 80 which on insecure networks sometimes has an unrestricted hole in the firewall already. In secure environments, you still have to put a new server in the DMZ whether it's port 80 your talking on or port 9001.

      As for load balancing and fault tolerance, Websphere here load balances CORBA clients ov
  • Why I think CORBA and other forms of RPC are a bad idea [omnifarious.org].

    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.

    • by Moebius Loop (135536) on Tuesday June 20, 2006 @04:01AM (#15567286) Homepage
      I'm not sure I agree with your chief argument, WRT latency in RPC calls. The answer to this is to use asyncronous development techniques as part of your IPC.

      The increasing amount of network-related latency dealt with in everyday communication generally means that in any reasonable interesting application, there are often large numbers of blocking calls that take a variable amount of time to return. Threads in and of themselves are truly not the answer, except possibly when used sparingly as part of a non-blocking system. (as an aside, I've found that as a Python developer, working with the Twisted Python [twistedmatrix.com] libraries was invaluable in my understanding of asychronous development techniques.)

      With regards to the idea of function calls being an innappropriate abstraction for these mechanisms, I think the issue really depends on the implementation. The reasons I've used an RPC/IPC solution to communicate between processes (either locally or remotely) was because the various processes weren't closely related, and needed to have a common interface between them.

      Making assumptions about implementation is an inherently bad programming habit, and has much farther reaching consequences. APIs would be essentially worthless if the developers made assumptions about how the work is done "behind the scenes". If you need intimate knowledge of the memory space of another process, it may be an indication to use process fork()ing to provide the same results.

      anyways, my 2/100th of a dollar....

      -phil
  • by Animats (122034) on Tuesday June 20, 2006 @02:21AM (#15566999) Homepage

    The intercommunication system within OpenOffice, the mechanism that allows embedding spreadsheets and drawings in other documents, is CORBA-based. Sort of. Actually, it's something called UNO, which started life as CORBA but went off in an XML direction.

    GNOME also uses CORBA internally. But its CORBA isn't compatible with the one from OpenOffice.

    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.

    • 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]
    • The intercommunication system within OpenOffice, the mechanism that allows embedding spreadsheets and drawings in other documents, is CORBA-based. Sort of. Actually, it's something called UNO, which started life as CORBA but went off in an XML direction.

      So, kind of an embrace-and-extend of CORBA?
       
    • 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 wa
  • Scary... (Score:4, Insightful)

    by Gorimek (61128) on Tuesday June 20, 2006 @02:21AM (#15567001) Homepage
    I worked with CORBA around 1997-98. It was one of several new technologies in our project, and we never really got it to work properly. Everything was just really complex and error prone. The company got closed for many reasons, but our stuff didn't help things much.

    Recently I've done a lot of XML Web Services work. This can actually be made to work, but it feels a lot more like filling out your tax returns than programming. Everything is really verbose, and you have to tell the system the same thing over and over.

    I never really connected dots until I read this article, but it is pretty much the same uneasy feeling I have about this that I had about CORBA. And the article even explains how they're similar!

    Not that that has to mean they're destined for identical paths, or that I'm a visionary who can sense the fate of a technology years in advance, but it does make me a bit happier that I quit that job last week.
  • Didnt Gnome used CORBA at some point ?

    I remember there was something called Bonobo...

    Is that still going on, or was that just a fad ?

  • I knew CORBA was doomed when Netscape announced it would use IIOP as its distributed server protocol, back in 1996. Because I never saw a single simple implementation. I'd be surprised it's taking so long to die, except that's the main purpose of OMG's long list of giant corporations which saw HTTP as "the new EDI".
  • by Frankie70 (803801) on Tuesday June 20, 2006 @03:05AM (#15567111)
    CORBA was an open standard.
    COM was a propreitary standard.

    But still COM succeeded much more than CORBA.

    Dox Box's book "Essential COM" has a foreword by Charlie Kindel (one of Microsoft's
    COM/ATL developers) which discusses this.

  • Anybody who had to deal with the woeful implementation of naming services in CORBA, who stupidly subjected themselves to cross-platform / cross language system implementations (try Visual C++ on NT talking to Smalltalk systems on SUN == headaches and midnight support calls every day) will tell you CORBA was a crock. Anybody stupid enough to listen to Microsoft when they said they would fix the DCOM dropouts / timeout issues when the system would stop talking to other DCOM clients (requiring server reboots)
  • by Black Parrot (19622) on Tuesday June 20, 2006 @03:55AM (#15567257)
    > focusing specifically on the OMG's technology adoption process itself.

    Calling themselves "OMG" probably didn't do much to encourage adoption.
  • by Anonymous Coward on Tuesday June 20, 2006 @04:25AM (#15567374)
    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
    • 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.
  • by shippo (166521) on Tuesday June 20, 2006 @04:52AM (#15567458)
    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.
  • by bytesex (112972) on Tuesday June 20, 2006 @05:08AM (#15567499) Homepage
    CORBA tried to do too many things at once; not only was it supposed to be some kind of OO-RPC, it also specced a declaration language (IDL), which was replaced at some stage by an XML-variant, which it wanted to also use to incorporate data- and other resources, plus some kind of 'discovery' broadcasting protocol that you could use to find (distributed, of course) CORBA servers around you, oh, and object serialization in weird strings. On top of all that, you had to leave your blood, soul and first born child at the omg website in order to obtain documentation, because, as these guys felt it, they had gold in their hands, and they wanted to cash in on it good. And it _was_ good, but it was just that because of this in-built obscurity (in turn caused by its complexity and omg's secretiveness), nobody could really tell where CORBA stood; was it some kind of transactioning system a la the kind that IBM mainframes have ? Was it OO-RPC (but then, why not use RPC) ? Then all kinds of competing tech started to overtake it (java RMI, XML-RPC based tech) to which the omg only vaguely responded (the XML declaration thingy) but couldn't really, because of the moloch that CORBA had become. And thus they faded into obscurity.

    The moral of the story ? When you want to sell a protocol or a language, be as simple as you can (modularize) and be as open as you can (throw it around, even) Otherwise, if you're not IBM or Sun or Oracle, you will not make it.
  • by Anonymous Coward on Tuesday June 20, 2006 @05:09AM (#15567507)
    From an OOP point of view CORBA's core architecture is basically very, very good.

    They screwed up the details. Mr. Henning's point of view is much more informed than mine,
    but I want to emphasise this: they got a lot right.

    Look at SOAP and the "Web Services" trend: like the language-du-jour, "everyone" seems to
    think it is something new, something great. Why do we need another MS-DOS every five to nine
    years? Percieved convienence is the usual answer.

    At my company, a major retailer in our market, we're now taking a legacy codebase that is far
    from perfect but nonetheless innovative and moving it all to silver-bullet platforms. You know
    the ones I'm talking about. The full-meal deal: all our problems solved.

    Even though the language we're "moving up to" is basically 1957 technology billed as cutting-edge,
      with a bloated description system being used to transfer what amount to fixed-field data records,
    and all of that piped through another bloated and basically silly but extremely trendy RPC mechanism,
    it's all supposedly for the best. Not.

    See the trend? Why are we always in a hurry, for everything? Sure, you can swing to a point where everything
    is crufty and convoluted (like CORBA), but you can get good things when you think about it a while.

    That brings me to Ice.

    I have a workmanlike understanding of CORBA. From that base, I have an equal understanding-- and appreciation--
    for Ice, gained in much less time. Of course, a lot of that is because the whole paradigm (Ice /does/ keep a lot of the things that were VERY GOOD about CORBA!) wasn't new, but let me say that Ice is a dream in many ways. The C++ bindings are a perfect start. For casual use, blissful. (Great job, guys!)

    What's my point? Okay. First, understand Michi Henning's article. Now, with that understanding, pretend that
    you're in a meeting in which SOAP and certain other "modern technologies" are all being suggested. Take the
    time to absorb the scene. Is the "modern" technology really and truly innovative, or is it just-- and this is /USUALLY/ the case-- crap?

    -Anon.

    (I have no association with ZeroC, by the way.)

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

  • Is XML-RPC still in use? The Wikipedia entry says it has now evolved into SOAP, which if I remember correctly from the last time I used it is not true as they are different, albeit closely related, protocols and SOAP is not a superset of XML-RPC.

    I coded a distributed application (a word game) with XML-RPC for a client some years back having been given the choice of language and communications option. I looked at SOAP at the time, but used XML-RPC as it was very simple to implement with a straightforward A
  • Hey, I've hated CORBA/OMG/DOE at least since 1992, so I really loved that article. The author hit the nail on the head!

    From: Don Hopkins
    Date: Sat, Feb 27 1993 4:17 am
    Email: hopkins@cs.cmu.edu (Don Hopkins)
    Groups: comp.object

    Svante Kleist (etxs...@garboa03.ericsson.se) wrote:

    I simply wonder if there are other ongoing efforts with similar scopes and ambitions to those of OMG? (i.e. where are IBM?..)

    Does anybody know?

    Well, there was the Strategic Defense Initiative (Star Wars), but they kin

  • by Goonie (8651) * <robert.merkel@benamb r a . org> on Tuesday June 20, 2006 @08:10AM (#15567999) Homepage
    The article mentioned CORBA's problems with dealing with firewalls.

    Correct me if I'm way off base here, but it seems like the following happened with regards to ports:

    1. In the beginning, services were allocated to different ports, with HTTP going to port 80.
    2. Sysadmins decided to block everything but port 80.
    3. Stuff needed to be put through the firewall.
    4. Rather than developing procedures to get ports opened, everything but port 80 stayed blocked.
    5. Protocols were designed to use port 80 to get through firewall.
    6. Selective port firewalling became useless because everything uses port 80.

    Clearly, blocking ports selectively is not a sufficient security measure, but being able to block services based on the ports they use is a handy tool to have in the armoury. Isn't it? And isn't it one we've thrown away because sysadmins have been to anally retentive?

    • 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
  • CORBA v ICE (Score:3, Interesting)

    by hachete (473378) on Tuesday June 20, 2006 @12:31PM (#15570165) Homepage Journal
    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.
  • by ehovland (2915) * on Tuesday June 20, 2006 @02:55PM (#15571316) Homepage

    Thanks to Moore's law embedded systems have grown up enough to use CORBA. I know this because I work on a project [nasa.gov] which uses CORBA heavily (at least in the TAO [wustl.edu] and JacORB [jacorb.org] 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 [zeroc.com] provides a competitor [zeroc.com] to CORBA and Web Services. And, you guessed it, that product addresses each and every flaw he outlines in his article [zeroc.com].

    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.

A meeting is an event at which the minutes are kept and the hours are lost.

Working...