Should I use CORBA, MessagePack RPC or Thrift, or something else entirely?

views:

150

answers:

Should I use CORBA, MessagePack RPC or Thrift, or something else entirely?

I'm writing software for a new hardware device which I want any kind of new third-party application to be able to access if they want to.

The software will be a native process (C++) that should be pollable by 3rd party games and applications that want to support the hardware device. Those 3rd party apps should also be able to receive events from the native process, on a subscribe basis. So aside from the native process, I'll also supply "connector" libraries to the 3rd party developers, for all platforms/languages that they might choose (Java, C++, Python etc.) to embed in their apps so they can easily connect to the device with hardly any extra code needing to be written by them. I want to target all desktop/laptop OS platforms, and have a pretty good idea of what functions I want to expose, but ideally I don't want to be too stuck (i.e. I want it to be elegantly scalable from both client and server perspectives).

I'm looking for reliability going forward, performance, maintainability going forward, and cross-platform/language flexibility going forward, and ease of development, in that order.

What should I use?

CORBA, MessagePack-RPC, Thrift, or something else entirely?

(I've omitted ICE because of it's licensing)

+1 A:

If ancient and heavyweight don't put you off, obsolete definitely should. Regardless, I can tell you what we've been using Google Protocol Buffers at work recently, and they're pretty easy to use.

From the developer's perspective, all you need to do is have a build of GPB (which really isn't that difficult), and then it will generate source files for you. The end result is a cross-platform binary message transport message passing interface (think XML and limited RMI, not MPI-like functionality).

We use it on Windows to talk to an Arm-based Linux system (TS-7200's from embedded arm) running the same software. to my knowledge, it is compatible with many languages.

San Jacinto 2010-08-26 12:41:26

Is this messaging? Very interesting! Given the flexibility, how would you recommend I use protobuf in my situation? I know it's "however you like" but I want every new part of my system to be backward-compatible with every old part. (this is looking ahead - I haven't started yet). What's the BEST way of achieving this?

Navigateur 2010-08-26 15:16:55

If you do a google search, you can find some documentation in their repo, which includes some best practices. It really depends on your exact situation. This isn't strictly messaging; it's a cross-platform/cross-system binary serialization method. If you want it merely for data transfer, you can do that. If you want to build an RMI framework, you can do that.

San Jacinto 2010-08-26 18:36:22

CORBA is the only free "RPC" thing that would work for my system right now, even though it scales very badly. Thrift isn't Windows-friendly yet. Neither is MessagePack-RPC yet available in all languages and OSs, even though it's still in development. If CORBA was elegantly scalable it probably wouldn't have become obsolete at all.

Protocol Buffers and messaging would work, I'd have to develop a both a client and service implementation for every platform/language. It would also be very scalable. I've decided on this.

Navigateur 2010-08-27 16:55:33

Why do you think CORBA "scales very badly"? There are plenty of very high volume systems that use CORBA in existence today.

Brian Neal 2010-08-27 23:45:42

Adding a new property, is this handled elegantly in CORBA when people are using old clients with the new server, or new clients with an old version of the server (both are possible in my case)? My impression is that CORBA breaks. This is bad - it needn't have been this way.. CORBA would have conquered the world if it seamlessly handled appending and removing properties and functions. People want to update their architectures all the time: Any required versioning, constraints and handling should be the developer's job outside CORBA. RPC itself should be 100% scalable/descalable.

Navigateur 2010-08-28 11:41:29

Not many RPC systems handle versioning seamlessly. One of the reasons is that it would incur excessive overhead on every single CORBA call.

Brian Neal 2010-08-30 00:07:56

Thrift or Message Pack is the best option going forward. Both are sleek, light weight and do not add much latencies to your process. They have support for most of the common languages, and are in Active Development. At the current stage I would prefer thrift personally but message pack does seem to promise a lot of features.

Thought thrift might not be as windows friendly as we want but people are using it on windows. This is a starter guide for thrift on windows. http://wiki.apache.org/thrift/ThriftInstallationWin32 Only installing and getting the Thrift compiler can be troublesome on windows. Using the generated files depend on the language you choose and lot of the languages have good support to run the files by importing thrift libraries. (Java it is very easy, MAVEN artifact)

There is a discussion on the RPC frameworks available at http://stackoverflow.com/questions/3624568/rpc-frameworks-available

CORBA according to me is old cumbersome and very heavyweight.

sheki 2010-09-12 10:06:17

ansaurus

tags:

views:

answers:

Should I use CORBA, MessagePack RPC or Thrift, or something else entirely?

related questions