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.

Well, there s always SOAP, which is the more common technology for this set of things these days. It s not as tight a binding but it works.

I really can t imagine choosing CORBA if I were starting a new project, and I ve used it quite a bit in the past. It is truly horrible to program for. There are a lot better alternatives out there, thogh many of them are proprietory (as are most CORBA ORBs, of course), such as TIBCO. In any event, you should never choose a technology simply because it happens to be installed on your PC.

Take a look at Googles Protocol Buffers.

What Are Protocol Buffers?

Protocol buffers are Google s language-neutral, platform-neutral, extensible mechanism for serializing structured data – think XML, but smaller, faster, and simpler. You define how you want your data to be structured once, then you can use special generated source code to easily write and read your structured data to and from a variety of data streams and using a variety of languages – Java, C++, or Python.

Taken from the FAQ:

How do protocol buffers differ from ASN.1, COM, CORBA, Thrift, etc?

We think all of these systems have strengths and weaknesses. Google relies on protocol buffers internally and they are a vital component of our success, but that doesn t mean they are the ideal solution for every problem. You should evaluate each alternative in the context of your own project.

It is worth noting, though, that several of these technologies define both an interchange format and an RPC (remote procedure call) protocol. Protocol buffers are just an interchange format. They could easily be used for RPC – and, indeed, they do have limited support for defining RPC services – but they are not tied to any one RPC implementation or protocol.

Check out the Internet Communication Engine (ICE).

Read the comparison between CORBA and ICE.

ICE is much, much cleaner, and more powerful, with a shorter learning curve. Documentation extensive and comprehensive (the best I ve seen), and there is about 50 example programs in all of the supported languages. IMHO, there s really no comparison.