I'm on a project using CORBA to read the data of objects that could be implemented in C++ or Java but conform to the same IDL. The pros are the idlj compiler and all the necessary code came free with Java. The con seems to be that I hear quite a bit that CORBA is old and not the latest and greatest. But I haven't heard names for anything that is better. Is there?
views:
151answers:
4Well, 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.
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.
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.
There's loads of ways to do inter-process communication. Off the top of my head here's a few.
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.