Issues with Corba Communication

Issues with CORBA communication

The problem was nothing to do with the code. It was something to do with connectivity.

On the LINUX box, cmrheldv, I had to edit the /etc/hosts file and change the 127.0.0.1 to the real ip for the localhost.

http://jeewesley.blogspot.com/2008/12/glassfish-ejb3-remote-interface-on.html

Is there anything better than CORBA for interlanguage program communication?

There's loads of ways to do inter-process communication. Off the top of my head here's a few.

• SOAP
• XML-RPC
• Sockets

However, before you switch you need to ask yourself

• What are the benefits of the new protocol
• What pain are you experiencing with CORBA? Sure it's a mature technology, but that in itself isn't a reason to ditch it, if it's meeting your requirements.
• How long will it take to switch to whatever new protocol you choose.

Removing CORBA (or any protocol/stack/library) because you heard that there was something better, shinier, cooler out there isn't a good idea.

Removing them because they're causing you specific problems, or because the new thing allows you to do something specific that can't be done with the existing tech is a good reason to switch.

Why has CORBA lost popularity?

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.

C++ CORBA DII issues

Managed to fix by changing object reference from _ptr to _var. I wrote a small test application to verify this. After changing the pointer type its behaving as expected serving the responses. So the problem was getting the initial reference to the interface.

Is CORBA legacy?

There are still situations where CORBA could be a good answer:

• when you are building a distributed
  system involving multiple programming
  languages and multiple platforms,
• when your system entails sending
  complex data structures ... and SOAP
  doesn't cut it,
• when you have high rates of messaging
  ... and HTTP doesn't cut it, or
• when you have to interact with
  existing CORBA clients and/or
  services.

But having said that, there are alternatives that do what CORBA does, only better ... or so they claim. For example ZeroC's ICE

EDIT @fnieto chimes in to say (or imply) that ICE is not free, but TAO is.

This is inaccurate and misleading.

1. ICE is GPL'ed software, and is available for free download. You only needed to pay for ICE if you / your company are not prepared to live with the terms of the GPL. (Or if you need support.)
2. I used ICE as an example of an alternative to CORBA. TAO is CORBA. The ICE authors make a credible case as to why they can get better performance by not being CORBA compliant.
3. TAO is by no means the only free / open-source CORBA implementation. I can think of 3 others, off the top of my head.

The down-side of ICE is lack of interoperability with CORBA middleware stacks, but in my experience interoperability of different CORBA implementations could also be problematic. (Things may have improved in that area ... but I haven't done any CORBA work since ~2002, so I'm a bit out of touch.)

org.omg.CORBA:MARSHAL & org.omg.CORBA.BAD_PARAM error

As to an advice of a friend the org.omg.CORBA.MARSHAL is thrown, if server and client work with different lib-Versions.
I cannot explain how it could happen to my project, nevertheless this particular error disappeared on its own :-/

The actual Problem in my case was an org.omg.CORBA.BAD_PARAM Exception, which was caused by the following line of code:

public static void write (final org.omg.CORBA.portable.OutputStream _output, final de.tc.app.lamo.comm.STZFlugereignis _vis_value) {
    ...
    _output.write_string((java.lang.String)_vis_value.flugNr);
    ...
    }

Where _vis_value.flugNr was null.

So a NullPointerException actually, but hidden by VisiBroker under CORBA-Exception together with the relevant stack trace.

A simpler CORBA protocol? does it exist?

A CORBA client talking to a CORBA service - how do you expect them to speak anything else?

What CORBA functionality do you want to use?

Do you already have this client and server, or are you just thinking about how to implement them?

I don't see why implementation is that difficult, once you have IDL. You'll use tools to help with the rest. And management will be difficult regardless of protocol. What are you imagining will be simpler?

I would consider ditching CORBA for an HTTP-based protocol. CORBA has virtually disappeared for a reason - simple and open win. HTTP based services can be implemented in the language of your choice - Java, C#, or something else - and can communicate with any client that can make an HTTP connection. That's worth something if you're still in the design phase.

---

Related Topics