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:
- The network is reliable.
- Latency is zero.
- Bandwidth is infinite.
- The network is secure.
- Topology doesn't change.
- There is one administrator.
- Transport cost is zero.
- 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.
