Why has CORBA lost popularity? [closed]

Question

I've never heard anyone speak of CORBA in anything but derisive terms which is odd considering that 10+ years ago it was the bee's knees. Why did CORBA fall from grace? Was it purely that the implementations were bad or was there something more fundamental?

Mousebird

There's a section on it's problems and criticisms in the wikipedia article: en.wikipedia.org/wiki/Common_Object_Request_Broker_Architecture – Inconsonant

See https://mcmap.net/q/237838/-is-corba-legacy – Vitellus

The is-corba-legacy question doesn't address the reasons as to why it became legacy – Mousebird

As Sam mentioned you can lump DCOM and CORBA together and see why they couldn't compete with SOAP. – Quinquennium

Voting for re-open so that I can vote for close to migrate to programmers :) – Sororate

You clearly have not suffered it. – Ferrante

Answer 1

It's not just CORBA, it's RPC in general. This includes stuff like DCOM, Java-RMI, .NET Remoting and all the others as well.

The problem is basically that distributed computing is fundamentally different than local computing. RPC tries to pretend these differences don't exist, and makes remote calls look just like local calls. But, in order to build a good distributed system, you need to deal with those differences.

Bill Joy, Tom Lyon, L. Peter Deutsch and James Gosling identified 8 Fallacies of Distributed Computing, i.e. things that newcomers to distributed programming believe to be true, but that are actually false, which usually results in the failure of the project or a significant increase in cost and effort. RPC is the perfect embodiment of those fallacies, because it is built on those same wrong assumptions:

1. The network is reliable.
2. Latency is zero.
3. Bandwidth is infinite.
4. The network is secure.
5. Topology doesn't change.
6. There is one administrator.
7. Transport cost is zero.
8. The network is homogeneous.

All of this is true for local computing.

Take reliability, for example: if you call a method locally, then the call itself always suceeds. Sure, the called method itself may have an error, but the actual calling of the method will always succed. And the result will always be returned, or, if the method fails, an error will be signaled.

In a distributed system, this is not true: the act of calling the method itself may fail. I.e. from your end it looks like you called the method, but the call actually got lost on the network and never reached the method. Or, the method successfully received the call and performed the operation, but the result got lost on the way back to you. Or the method failed, but the error got lost.

Similar with latency: locally, calling a method is essentially free. The method itself may take an arbitrary amount of time to compute the answer, but the call is free. Over a network, a call may take hundreds of milliseconds.

That's why pretty much all RPC projects, including CORBA failed.

Note that the other way around works just fine: if you just pretend that all calls are remote calls, then the worst thing that can happen is that you lose a little bit of performance and your app contains some error handling code that will never be used. That's how Erlang works, for example.

In Erlang, processes always have separate heaps and separate garbage collectors, just like if they were running on different machines on different continents, even if those processes run on the same VM on the same CPU in the same address space. If you pass data from one process to another, that data is always copied, just like it would have to be, if the processes were on different machines. Calls are always made as asynchronous message sends.

So, making local and remote calls look the same is not the problem. Making them look like local calls is.

In CORBA, the problem is actually a bit more convoluted than that. They actually did make local calls look like remote calls, but since CORBA was designed by committee, remote calls were incredibly complex, because they had to be able to handle some incredibly absurd requirements. And that complexity was forced upon everybody, even for local calls.

Again, comparing to Erlang, the complexity is much lower. In Erlang, sending a message to a process is not more complex than calling a method in Java. The interface is basically the same, it's only the expectations that are different: method calls in Java are expected to be instantaneous and synchronous, in Erlang, message sends are expected to be asynchronous and have visible latency. But actually using them is not more involved than a simple local procedure call.

Another difference is that Erlang distinguishes between function calls, which can only happen inside a process and thus are always local, and message sends, which happen between processes and are assumed to be always remote, even if they aren't. In CORBA, all method calls are assumed to be remote.

Phasis

+1 Nice answer; I can see now why some developers seem to take such a dim view of .NET Remoting. However, if you are willing to accept the inherent limitations, .NET Remoting can be a decent point-solution for certain problems. I'm not sure that lumping it in with CORBA and DCOM is fair. – Chesterfield

The reason they failed is part proprietary protocol (and thus tricky to use with firewalls) and (in CORBAs case) part because they were designed by committee and bloated up horribly. SOAP is a case in point here too. But, the concept of making network calls easy is not the real problem. – Toothlike

I understand the problems, but what alternative do we have? If you don't want that huge xml-overhead you get with SOAP or XMLRPC and if you want to program in C (not C++), which technology do you use then? – Gunnar

This answer is completely wrong. In any similar solution you have to create code which deals with network errors. It is not true that Corba "pretends" that function calls go over network. On any network issue you will get an exception and your task as a programmer is to handle such cases. The only way your answer is valid is when developer of Corba application "pretends" that there is no network involved, but that stands for any software communication over the network. Actually various XML solutions for network communication have high overhead (because of XML text) and high processing load. – Packing

@Packing Would you have a better answer? I understand the questions is closed but I'm curious to see your reasoning. – Gesticulate

@Gesticulate Sorry for the late reply. It basically comes down to too complicated and too slow development. There are a lot of options to set up things right, the library has it's own types and other basic objects duplicating parts of standard library. There's reference counting of objects which is too complicated. The support has dropped and none of the big players use Corba. There are alternatives. For example any messaging engine combined with Google Protocol buffers do the same thing. – Packing

Answer 2

Distributed object technologies like CORBA and DCOM had problems with granularity - implementations tended to be too 'chatty' to perform well over a network - and generally leaked implementation details which made the solution fragile.

Service Orientation gained prominence as a reaction to those concerns.

Smutch

can you expand your answer about the advantages of Service Orientation versus CORBA? – Towroy

In a SOA model your calls across network boundaries are more explicit, and will usually encapsulate an entire unit of work within a single service call. The service interface is also easier to abstract from the underlying implementation to allow for implementation changes without breaking clients. – Smutch

Wrong. "too chatty"???? It solely depends on the developer how "chatty" he wants his software based on Corba to be, not on library itself. "Leaked implementation details"? It's the same for any network protocol which does not have encryption. You can use SSL in Corba for a long time already. Various network communication libraries mostly based on XML have high payload and processing overhead, but enable lazy programmers to create dirty code and beginners to advertise themselves as experts. – Packing