views:

151

answers:

4

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?

+1  A: 

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.

bmargulies
A: 

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.

Frank Bollack
Protocol buffers looks after serialising data, but it doesn't specify the inter-process communication, does it ? CORBA covers the serialisation/representation, plus remote method invocation, object brokers etc.
Brian Agnew
+1  A: 

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.

anon
Correction; ORB implementations can be proprietary, but there are several open-source ORB implementations. The reason those open-source implementations can exist is because CORBA is an open spec. Not so from proprietary solutions such as the TIBCO suggestion.The last sentence is the best advice.
Chris Cleeland
+2  A: 

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.

Glen
Thanks for the wise advice and for all the other answers too. I'm new at inter-process communication and it's still flexibly early in the development process, so I am glad to now know of these other technologies before getting too invested in CORBA just because it's what I have now.
Pete
If you're early enough in your product's development then I'd think long and hard about using CORBA. I'm not saying don't use it, but if you do then you should have some really good reasons for using it (though that applies to any technology decisions)
Glen