Whats Wrong With Corba

This topic lists things that some people don't like about the CommonObjectRequestBrokerArchitecture (CORBA).

Problems with CORBA in general:

The goals of being language-independent, platform-independent, and suitable for all distributed-systems development, along with a decade's worth of refinements and new features while maintaining backward compatibility, have led to a lot of complexity and bloat in the specifications and implementations.
There is a steep learning curve. Rummaging through the mountains of specs to find the 5% that is relevant to your needs can be frustrating.
Some of the language mappings seem "unnatural", leading to idiomatic CORBA-specific code that does not interface easily with standard libraries or third-party components. Many programmers have a hard time learning and understanding the rules of the mappings.
Versioning and compatibility of interfaces between versions of your business server. (Mismatches cause memory corruption and/or crashing.)
There is no inheritance for exceptions, so you cannot group common error types and handle them uniformly via a base exception class. This makes error handling a real pig, and not very extensible.
Can be difficult to use if server and/or client is behind a firewall or if network address translation is being used.
From the name, it sounds like something poisonous.
- ?!?!? Actually CORBA is Turkish and Serbian for soup.
- Our human resources department once asked us to give them an overview of our system, confusing CORBA with COBRA (For non-US readers: COBRA is the name of a legislative act that covers medical insurance and similar benefits.). When I was working on a CORBA implementation, my mother asked me why it is named after a snake. (For non-Indian readers: a cobra is a poisonous snake that is very common in India.)

Implementation issues:

Bad things happen if your client and server interfaces get out of sync. Typically, the server crashes.
- Though this is not a fault of CORBA per se - break dependencies at your own risk - but CORBA does have, at best, primitive IIOP versioning which can make it difficult to detect broken dependancies
- Two programs implementing the same interface can get out of sync only if you change IDL and don't recompile everything dependent. Folks, if you can't be bothered to use make, you shouldn't be programming at all.

Marketing and Cultural Issues:

The commercial CORBA implementations are obscenely expensive, and many customers are unwilling to trust the free/open-source implementations.
The major operating-systems vendors don't support it.
The language-specific or platform-specific alternatives to CORBA are generally a lot easier to use than CORBA, leading many developers to shy away.
CORBA doesn't get much press these days, leading many to believe that nobody is using it and so it is a dead technology. (In fact, it is used behind the scenes in a lot of financial, telecommunications, and defense systems. Many Java programmers are using CORBA all the time without knowing it.)

In addition to the real and current problems with CORBA listed above, there are some historical reasons that people don't like CORBA, and also some misconceptions about it that have discouraged use.

Historical Problems with CORBA (no longer true):

CORBA as a specification given by OMG has left it at mercy of the ORB vendors to have their own custom implementations with proprietary Extensions. Till a couple of years back, there was flood of CORBA implementations in the market from different vendors, none of which were fully compliant to the Specifications. It's a big headache to get objects converse between two ORB distributions (the recent INS or Interoperable Naming Specifications is a step towards bridging this gap).
- The above paragraph may have been true a few years ago, but today it is pretty easy to achieve interoperability between different vendors' ORBs, as long as stupid developers don't rely on proprietary features.
The most widely used CORBA implementations are slow, and make inefficient use of dynamically allocated memory.
- This is no longer true. Most modern CORBA implementations are pretty good. The problem is that people do dumb stuff with them.

Supposed Problems with CORBA (but not really problems with CORBA)

Doesn't provide any way to realize distributed GarbageCollection; not even refcounting.
- Anyone who thinks distributed garbage collection is a good idea doesn't know the first thing about distributed systems. This is the reason that COM is unscalable. What if your client goes away without decrementing the reference count? You get objects hanging around unable to be cleaned up. COM "fixes" this by regularly "pinging" the clients, but this make it completely unscalable. Instead, learn something about distributed systems design and architecture and *don't* expect distributed garbage collection to work scalably. It *can't*, as it relies fundamentally on global knowledge.
- The best way to implement distributed garbage collection is very application dependent. For some applications leases are best, for some reference counting, etc.
CORBA servers typically lack "heartbeat" functionality, and so may fail to automatically restart server processes.
- Continuous network pings bog network performance down noticeably.
As with any RPC protocol, network latency can become a big issue.
- This is not something that is "wrong" with CORBA. If network latency is an issue, you shouldn't be making calls across the network! You cannot design a distributed OO program in the same way as you design a single process OO program. Such a design will run very slow, but that's the fault of the design, not the middleware.
Error information gets lost if you let exceptions "leak" out of your server event handling procedures. So you end up having to put a large complex try-catch block in every method of every CORBA object.
- If you are not checking for errors, then there's something wrong with your code, not with CORBA. CORBA does more than many RPC systems (e.g. DCE, COM) to help you handle errors by translating errors into the native exception mechanism of the language. This is much more convenient than having to check COM HRESULT values. It stops errors "leaking out" of your event handling procedures.
CORBA applications take a very long time to compile (at least in C++). "Hello World" alone can take minutes.
- This is utterly false, and always has been. Never, in a single CORBA-enabled application that I've written, has it taken more than 3to 10 seconds to compile a single translation unit (e.g., .c file), depending on the size of the unit. Whoever wrote the above is either patently anti-CORBA/pro-COM or is flat out on crack. It really should be edited out of this page.

Supposed Problems with IDL:

Duplication of functionality: why have struct's when we have objects? Why the difference between arrays and sequences?
- There is a big difference between structs and objects. A struct is a bundle of data that is passed by value, whereas an object has a method-based interface and is passed by reference. Arrays and sequences are similar, but arrays are of fixed length and sequences are of variable length.
No support for generic types.
- "any" serves as a generic type.
There are three ways to get a value from a method: return, out argument, or in out argument. This nicely mimics the abilities of C++, but needlessly complicates the bindings for other languages, while adding no greater expressive power.
- These distinctions are necessary to provide the correct semantics without degrading performance unacceptably. "Return" and "out" are similar, so maybe one of them could be eliminated, but "in out" is different. COM and practically every other RPC-like technology have something similar.
In general, though IDL is in name "language neutral", in reality it seems rather slanted towards C++.
- IDL is not language neutral: it is IDL. (CORBA is language neutral.) But it made sense to base IDL syntax on something that already existed, and C/C++ were the in-vogue programming languages at the time.
- In practice, it is much easier to develop CORBA applications in Java or Python than in C++, so the idea that there is a pro-C++ bias in CORBA doesn't hold up.
Forward references to type definitions are not allowed, so you have to use special forward declarations, like C prototypes (come on, we've had two-pass compilers for decades and they work fine!). However, you can't use these to build straightforward recursive types (eg a struct Foo which contains a pointer to Foo), although, strangely, you are allowed to have members which are sequences of Foo [i'm still struggling with this - correct me if i'm wrong, and i'll get back in a few days with the gospel truth -- TomAnderson].
- You're right. There can't be pointers in IDL, presumably because that would make CDR a lot more complex. (Value types give you pointers, cyclic structures and everything; at the cost of implementing the marshalling yourself.) If you need a "pointer", you would use a sequence of maximum length 1. XDR did it the same way a whole decade earlier. Recursive types (unions with some recursive arms) would be nicer, though.
- Since CORBA 2.4 (circa 2000), there can be forward references.

CORBA has a reputation for being bloated and slow. The biggest reason for this was that Orbix, the market leader, truly was bloated and slow. But most CORBA implementations from the past couple of years work pretty well. Peformance is not much worse than just using raw sockets.

I had to use Orbix when it was first released and it was a real pig! It's not all their fault, though. The CORBA standards were very immature at the time and some parts were impossible to implement (e.g. Any values). However, the Iona business model was to SurfTheWaveOfMediocrity.

I've used GNOME's CORBA ORB, ORBit, and it's blisteringly fast. In-process objects are indistinguishable from non-CORBA objects in all but the most pathological cases (e.g., invoking a method a million times in a tight loop), and non-local objects are every bit as transparent as in-process objects. The ORB is very, very small too. Extremely well done piece of software. Before you go trashing CORBA, check out ORBit. It will fundamentally change what you think about CORBA.

The biggest problem with CORBA is that, because it has "objects", people treat it just like an object-oriented programming language, and ignore the fact that objects are communicating across a network. When designing CORBA systems, be sure to pay attention to the number of "round-trips" (request sends and result returns) needed to perform common operations. Object models that may work well inside a C++, Java, or Smalltalk program don't work when there is a few milliseconds of latency per call between the time that a client starts an invocation and when the result is received. (This is not really a problem with CORBA, but it is a problem seen in CORBA-based systems developed by dimwits.) See SessionFacade.

Another component technology rant... WhyAnotherComponentTechnology.

Many of the criticisms of CORBA on this page are either based upon old CORBA implementations, are based on misunderstandings about the design of distributed systems, or are just plain wrong. I'm going to delete the statements that have been refuted, unless someone thinks there is a good reason to leave them in place. -- KrisJohnson

I think the refuted statements have a value for historical reasons. They were true a while ago, and by the time they were refuted many projects experienced significant problems and Corba already had already gone out of hype. So those do have a role in WhatsWrongWithCorba. I used to like CORBA and orb implementation a lot and thought of it as such a cool idea - it also made me look good professionally, but lately I think of it as maybe it was way too complex all along. Given the experience of ErlangLanguage, and things like http://www.sics.se/~joe/ubf/site/home.html and other distributed frameworks, it certainly looks like distributed frameworks don't need to be as complex as Corba. Certainly, the fact that many orbs had many significant problems for a long time may be a warning sign of maybe AccidentalComplexity? -- CostinCozianu

I've moved them to the "Historical Problems with CORBA" and "Supposed Problems with CORBA" sections, rather than deleting them entirely. -- kj

For a detailed list of what is wrong with CORBA written by MichiHenning? (famed CORBA guru), see http://groups.google.com/groups?dq=&hl=en&lr=&ie=UTF-8&frame=right&th=67bb70d6d5c1204b&seekm=_MmSa.4709%24OM3.2483%40news-server.bigpond.net.au#link3. Note that Mr. Henning is hyping his own alternative to CORBA, the InternetCommunicationsEngine (Ice); see http://www.zeroc.com/iceVsCorba.html for more about flaws in CORBA that has been addressed in Ice.

CategoryCorba