Catch up on stories from the past week (and beyond) at the Slashdot story archive


Forgot your password?

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."
This discussion has been archived. No new comments can be posted.

The Rise and Fall of Corba

Comments Filter:
  • 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?
  • 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.

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

  • by Anonymous Coward on Tuesday June 20, 2006 @02:05AM (#15566959)
    I knew Corba as the Common Object Request Broker Architecture. I knew it was middleware, but I never used it. I've use the entire LAMP stack to build killer web sites. Not one stitch of CORBA within it. You might argue that CORBA is middleware, and I'm not using it. Agreed. But as others have stated, the LAMP stack comes with piles of documentation. Corba usually insisted on a very specific basically had to know how it worked before being able to set it up and use it properly. Now CORBA is fading. When it's gone, I will remember it as technology that might have been ok, but no one will ever know, and now that it's gone, no one cares.
  • Why I think CORBA and other forms of RPC are a bad idea [].

    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 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 cryptoluddite ( 658517 ) on Tuesday June 20, 2006 @03:25AM (#15567154)
    The problem with CORBA was mostly the technicalities and 'grossness' of the design. Yes I used the Java bindings, and it was just crap. All these "helper" objects and peers and stubs and junk. You'd compile an IDL, which was some hacked up C++ interface which wasn't even C++, get a buttload of Java classes that did not act anything like any other Java object on the planet. Lots of 'icky' exceptions. It just, for lack of a better way to describe it, had no style.

    Try to teach CORBA to some normal programmer and they'll be thinking that creating their own wire protocol is probably going to be easier for 99% of the things they need to do. Seriously, you just don't look at CORBA bindings (for Java at least) and want to have anything to do with it. It's probably not so bad for C++ developers because they are used to a lot of noise and complexity, and they have templates and stuff to 'spray perfume' on CORBA and make it smell... better.

    But seriously, when your technology drains the life out of any competent developer who actually likes to program then you know something is very wrong.
  • Re:Gnome and CORBA (Score:3, Interesting)

    by WWWWolf ( 2428 ) <> on Tuesday June 20, 2006 @03:35AM (#15567197) Homepage

    Ayup, GNOME has their own implementation of CORBA stuff, called ORBit [].

    Bonobo is the component framework in GNOME, and is built atop CORBA.

    AFAIK they're still pretty much in use.

  • by Anonymous Coward on Tuesday June 20, 2006 @03:45AM (#15567233)

    I've used both CORBA and Ice.

    Check out Ice. You will experience a rush of "the good"!

    STL, baby.
  • 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 [] 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....

  • Re:zeroC ICE (Score:1, Interesting)

    by Anonymous Coward on Tuesday June 20, 2006 @04:39AM (#15567423)
    Note: I do not have any affiliation with ZeroC or Ice, just admiration.

    If you have used CORBA (especially the C++ bindings), I definitely suggest that you
    try Ice.

    I evaluated XML-RPC, SOAP, CORBA, and Ice for my company.

    My recommendation was, crushingly, for ZeroC's Internet Communications Engine (ICE) technology. It totally
    rocks. It is what you should build SOAs upon.

    If you want good technology, that is.

    My company though my recommendations were interesting, but went with one of my least-suggested approaches, SOAP. The primary reason cited was that it is ubiquitous. See? If everyone is using something, it must be right to use it for everything.

    I'm gonna kick back for a couple of years, and wait for the moaning. I'm sure some "compression technology" or
    "deep refactoring" will come to the rescue.

    It all seems to be about mindset. And so very few companies really seem to "have it" when it comes to
    computers. It is almost as if the late 1970's and early 1980's PC era never really left us, those moments
    when real nerds had to have chops in order to /be/ nerds. If you had a personal computer, you built it. If
    you owned one that you didn't build, you at least could still program it.

    Now, bozos not always but very often make our technology decisions. They just don't know that they are
  • Re:Real reasons (Score:2, Interesting)

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

  • 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 sonofagunn ( 659927 ) on Tuesday June 20, 2006 @06:50AM (#15567763)
    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 has some good points on why we as an industry moved away from CORBA, but SOAP and web services are even worse in my opinion.
  • by supersnail ( 106701 ) on Tuesday June 20, 2006 @06:57AM (#15567785)
    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 without any architects/managers loosing face.

    Currently the only widespread use of CORBA is as the transport for J2EE, and yes they use a single IDL
    not too far removed form the one above.
  • 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).

  • Re:Real reasons (Score:2, Interesting)

    by Michi ( 41795 ) on Tuesday June 20, 2006 @09:03AM (#15568308) Homepage

    Trust me: Ice is better than CORBA, and by more than just a little bit :-)

    Unfortunately, Ruby has threading issues that prevent an Ice implementation for it. Otherwise, we would have done a Ruby binding long ago.



  • by guysmilee ( 720583 ) on Tuesday June 20, 2006 @09:14AM (#15568381)
    I am sure the author of this article is a fine individual ... however I am serious forced to question is opinions. CORBA is far from dead ... CORBA is in fact mandidated for use in every radio used US miltary, coastgaurd etc by 2010 (I believe). One only has to google for JTRS and start searching the links for SCA (the standard being used). And this is just the icing on the cake. CORBA itslef is a enormous overhead saving tool ... I have worked with far to many engineers that want to design there own msg'ing system between processors and devices ... without CORBA you are simply re-inventing the wheel. The CORBA community has already made its mistakes and corrections. And as for his assesment of the individuals contributing to the standard ... well he could not be more wrong ... these people are highly qualified/knowledgeable individuals building real systems and using CORBA to build real systems ... nothing is added to the CORBA spec ad-hoc. The biggest problem CORBA has with its addoption is its foot print size in embedded systems ... however thanks to modern memory sizes this is no longer a problem ... so in my humble opinion the author needs to wake up and jump back on the CORBA bandwagon ... otherwise he can go sit on his own and re-invent CORBA's past while CORBA moves on with life. Rant over :-)
  • I really like that word you coined: zealout. Sounds like a cross between zealot and sellout, which may be part of the reason for some of the problems with CORBA.
  • by SimHacker ( 180785 ) * on Tuesday June 20, 2006 @10:16AM (#15568920) Homepage Journal

    Phase Relationships in the Standardization Process [], 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

  • by Urusai ( 865560 ) on Tuesday June 20, 2006 @10:37AM (#15569114)
    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.
  • The CORBA Niche (Score:2, Interesting)

    by JoeRandomHacker ( 983775 ) on Tuesday June 20, 2006 @10:57AM (#15569279)
    For all its faults, CORBA does fill an important niche. As far as I know it is the only communication technology that features:

            High Performance (implementation dependent, of course)
            Language Interoperability (standard language bindings)
            OS Interoperability
            CPU Interoperability
            Vendor Independence
            Object Orientation
            Healthy Open Source Community

    I think we can agree that these are good things to have.

    There are a number of caveats, though:

          CORBA works best when you have tight integration between the client and the server. The more you try to put between the two (e.g. the public Internet) the more problems you will have.

          There is a good bit to learn to be able to design and build a CORBA-based system, from basic concepts to language bindings. Once you have it down most of it makes sense, and developing new applications can go fairly quickly, but it does take a while to get there. You might want to try starting with a Python ORB, since it is a lot easier to use than C++ or Java ORBs, and you can use Python later to build tests for your C++ or Java code.

          You have to ignore a lot of stuff. The bulk of the CORBA services out there aren't really useful; stick to things line Naming, Notification, and Trading. Some features like valuetypes are a pain to support, so are better ignored. CCM might be worth something eventually, but it would require really good vendor tools support, and it is better avoided for now. You can get by pretty well with the concepts in Henning and Vinoski's book, "Advanced CORBA Programming with C++".

          Interface evolution needs to managed carefully, since IDL is generally more rigid than XML.

    These caveats make CORBA inappropriate for a lot of projects, no question, but for those projects which have performance and interoperability requirements which match with CORBA's feature set, it is worthy of consideration.
  • Re:CORBA. (Score:3, Interesting)

    by cow-orker ( 311831 ) on Tuesday June 20, 2006 @12:16PM (#15569992)
    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 object references and speak the wire protocol. For the long version, here's CORBA in 5 Minutes [].

    Now why the confusing websites? Well, what would you do as a vendor? Tell your clients (managers!) that you're selling them an RPC library? No way! It has to be Object Oriented Middleware, it must be Enterprise, and everything ties into the mystic ORB. You absolutely need an ORB! Well, you didn't in the 80's, but this is the 21st century and there you need an ORB! Oh, and what a remarkable conincidence... we are just selling ORBs!

    Anyway, have a look at ORBit []. CORBA can actually be simple. It's commercial software that cannot.
  • by cow-orker ( 311831 ) on Tuesday June 20, 2006 @12:27PM (#15570134)
    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++? Okay, that mapping is crap. But why? People are constantly grappling with stuff they neither want nor need. Just don't use it, and optionally fix the faults in the things that are needed. (My wishlist: gimme a better C++ mapping that knows about STL, gimme me an ORB for Haskell, allow parametric polymorphism.)
  • 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.
  • Re:CORBA. (Score:3, Interesting)

    by jc42 ( 318812 ) on Tuesday June 20, 2006 @02:40PM (#15571187) Homepage Journal
    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 developers was usually "Hey, that's great; we'll look for places that we can use it effectively." Of course, not really having any idea what it did or how to use it effectively, we never found any places that we could use it. The obtuse examples didn't help; reading code that doesn't make sense without uderstanding what it's supposed to do isn't a very good way to convince your typical developer that it's something they want to use.

    In any case, there's not a lot of implementing you can do with just an acronym and management-level hype for "documentation".

    Thirdly, it was never compatible.

    Sort of a problem for something designed to solve cross-platform communication problems. (If that's actually what it was supposed to do; I'm still not sure about that. ;-)

    I got the idea from TFA that it was a protocol developed mostly by a number of vendors. Are there any cases where this has worked? All the successful standards that I know of were developed with a large government and/or academic contingent, usually both. Companies generally try to hide their secrets from competitors, which is somewhat of a problem when you're trying to get competitors' products to work together. Granted, Sun and Apple are semi-exceptions, but even there, trying to get them to work out a common protocol is just asking for indefinite bureaucratic delays. (That's a voice of experience talking there; again there might be exceptions that I don't know of.)

    I liked the comment in TFA that one of the problems was that Microsoft didn't adopt CORBA. My immediate thought was "Well, duh!" Of course, the XML crowd has been showing signs of nervousness about MS's involvement, especially when the news gets out that MS is applying for patents on XML encodings.

    I've often thought that one of the main reasons for the Internet's success is that it was developed (by government and academic developers) for several decades before either IBM or Microsoft noticed it.

    It sorta reminds me of a comment I read once from a biologist, to the effect that one of the major adaptive constraints on birds is that they have to somehow prevent predators from noticing their nests until the babies can fly.

  • 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 [] which uses CORBA heavily (at least in the TAO [] and JacORB [] 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 [] provides a competitor [] to CORBA and Web Services. And, you guessed it, that product addresses each and every flaw he outlines in his article [].

    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.

Perfection is acheived only on the point of collapse. - C. N. Parkinson