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

Question

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)

Handicap

CORBA is ancient. It's also heavyweight and obsolete. There's almost certainly a better solution. – Cantaloupe

skaffman, the adjectives ancient, heavyweight and obsolete don't put me off at all. The amount of memory per ORB is only a few megabytes, which might be bad for embedded, but absolutely fine for desktop computers, and the performance is fast. I'm concerned about performance speed, cross-platform flexibility, ease of development, maintainability, and reliability going forward. As long as it's the best in these departments overall, it doesn't matter what anyone else "thinks" about it, nor it doesn't have to be "the latest fad", it would win. I just wonder if it's the best for what I'm doing. – Handicap

We simply can't answer a question this open-ended without knowing your requirements, what your software is/does, the target audience, upgrade path, platforms it will run on, etc. – Coeducation

This isn't really a question for stackoverflow. You could make any of those technologies work. Its too subjective a question. What is best for you may not be best for someone else. What you need to do is to do some homework and try out each of those things and then judge for yourself what is the best fit for your application. – Coeducation

It's the most important decision I have to make. I want to avoid pitfalls that I might not be able to foresee, even if it works in the short-term. I don't think that all options are equivalent going forward. There are so many possible real insights that I could learn from other people's long experiences in cross-platform/language integration which I can't possibly be expected to gather purely with my own experimentation in the relatively short space of time I need to make the decision. – Handicap

I understand that, but StackOverflow isn't setup for this type of discussion. From the FAQ: Avoid asking questions that are subjective, argumentative, or require extended discussion. This is not a discussion board, this is a place for questions that can be answered! Personally I don't think a lot of people have investigated all of the things you mentioned. I have used CORBA but none of the others. CORBA gets a bad rap, but in practice you only have to use a small portion of it. It isn't that bad. I'd investigate Thrift and ICE if I were doing a new project that required an RPC layer. – Coeducation

Answer 1

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.

Handicap

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

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. – Handicap

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

Answer 2

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 RPC frameworks available?

CORBA according to me is old cumbersome and very heavyweight.

Scriptwriter

Answer 3

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.

Paradigm

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? – Handicap

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. – Paradigm

Answer 4

I'm currently using Apache Thrift for a Hospital Manager project. It is better than CORBA in many areas, not to mention it is lightweight and much easier to implement and understand. The learning curve for Thrift is definitely subtle compared to CORBA, but the documentation for Thrift is the worst thing.

I'm using a Ruby Thrift server to which Obj-C and Java clients connect. The Thrift parser or "compiler" does a pretty good job generating source files for the languages you want, although it is far too verbose. I would definitely look into implementing Thrift, or Google ProtoBuffs if I was starting a new project, since CORBA is really outdated, and might not implement new technologies in the future, not to mention that there are many vulnerabilities and exploits targeting CORBA that will not get patched since it's not in development anymore, presenting some serious security holes on your new project.

Thrift supports many programming languages: C++, Java, Python, PHP, Ruby, Erlang, Perl, Haskell, C#, Objective-C, JavaScript, Node.js, Smalltalk, OCaml and Delphi as of this writing. Supporting multiple languages is key, I think, for the purpose of your project.

Soutache

I went with ZeroMQ in the end. You might want to check it out. It's really cool because you can make it as extendable as you like (in terms of adding/removing properties etc.). – Handicap