views:

554

answers:

8

I've been enamoured with component based programming (be it with COM, another system, or just using the paradigm in plain C++). It requires a bit of getting used to, if one is usually used to the "traditional" OOP model, but it's definetely worth it. It's made my code more maintainable and easier to extend.

The project I'm currently working on is using the paradigm, but no set system. However, I'd really like to find some sort of system I could use with the following requirements. Switching over from what I have now to a new system would take a bit of time, but I'd save a multiple of that time later.

The requirements:

  1. Cross-platform
  2. Fast
  3. Works well with C++
  4. Supports cross-process marshalling

Let me elaborate on those requirements:

Cross-Platform

Basically, I need it to work on Windows and Mac. Linux would be nice, but is not in any way essential. Also, it really needs to fulfil the other requirements for all platforms. There's a COM for Mac, which would be ideal but it doesn't support requirement 4. Additionally, it must support both GCC and MSVC.

Fast

This is where CORBA unfortunately loses, even though it fulfils the other three requirements. In-process method calls need to be as fast as possible (ideally, like COM), since some of the routines might also be called from an audio interrupt.

Works well with C++

... I guess this one is mostly obvious. I don't mind not using C++ classes to implement components, though that would definetely be helpful, and the alternative must still be easy to use, especially since eventually I intend to release an API for 3rd party extensions.

Supports cross-process marshalling

By that I mean at least being able to serialize the calls. If this is done via code generated from an IDL, that's perfectly fine with me, and I also don't mind implementing the cross-process communication itself.

COM would be great, but it doesn't meet requirement 1 fully. CORBA would be great too, but it doesn't meet requirement 2 (even with the fastest ORB out there). XPCOM might not meet requirement 2, and doesn't work with MSVC so doesn't meet requirement 1.

Any ideas what else is out there? My next step would be to roll my own using protobufs or something similar, but of course I'd like to avoid that.

Update

To elaborate - an audio interrupt in this context can be as low as 2-3ms. That time isn't even available in full to me, as other components need to process in that time, and my software is itself wrapping another piece of software that needs to process in that time. This is why both in-process and cross-process marshalling needs to be extremely fast.

+1  A: 

CORBA would certainly be an answer - you should test it before you dismiss it based on speed.

A definite alternative would be XPCOM http://en.wikipedia.org/wiki/XPCOM - lack of MSVC does not mean not cross platform.

Good Luck

sdg
Can you recommend an ORB implementation? I've tried to find a webpage comparing different ORBs based on speed, to see if there is one that is fast enough, but I've had no luck with that.
arke
You really don't want to use CORBA if you can possibly avoid it - trust me on this one.
anon
TAO, "The ACE Orb" http://www.cs.wustl.edu/~schmidt/TAO.html is one very well respected implementation.
sdg
I think corba is a non-starter if you want in-proc speed.
Tim
+1  A: 

For maximum breadth, I'd just use web services. A service-oriented approach is very close to a component-oriented approach, as only the service contracts (interfaces) are exposed, and no details of the inner workings of the service need ever be known by the clients.

John Saunders
His performance requirements probably preclude that as an option (though I agree, an HTTP-based service of any sort is a good start).
Tom
Indeed, while it sounds good in principle, the requirement to run this in an audio interrupt just doesn't make this feasible, unfortunately.
arke
Didn't see the interrupt requirement. Surprised to hear there's a COM implementation that can handle that.
John Saunders
In-Proc COM calls are just virtual function calls, so really fast. Cross-process COM calls are serialized into a binary stream and sent using window messages, which are optimized to hell (since Win32 basically revolves around window messages).
arke
@arke: thanks, I knew those things, and am surprised there's an implementation of COM that does those things easily from a hardware interrupt, in Kernel mode. I'm sure there are Windows Kernel calls that can be made, but don't know that I'd call them "easy".
John Saunders
Oh, that's what you meant. Sorry, that's an error on my part on terminology - I didn't mean a literal audio interrupt in Kernel mode, but in user mode, usually triggered from an ASIO driver. Just some leftover terminology from old times :)
arke
I think the performance factor is a killer for this
Tim
A: 

Take a look at the AF Architecture:

"Af-Arch is a complete set of libraries and tools which allows to develop distribuited system especially designed to face problems about bussiness applications."

I know it works with linux and windows. I also know it has a very fast C API and C# bindings for it.

Jorge Córdoba
It looked appealing at first, but this somewhat put me off: "The Af-Arch programming model consists on a TCP client-server system based in a XML-formatted message exchange on top of the BEEP Core protocol.". I fear this won't fulfil my speed requirements. :/
arke
A: 

Why do you think that CORBA is not fast enough? Have you measured things recently?

Modern implementations of CORBA can make remote calls in less than 150 usecs. Way below your 2msec budget. Modern implementations of CORBA can optimize in-process calls to basically two virtual function calls, though that usually requires the application to forgo some features (interceptors for example.) Even a full featured in the worst case scenario local calls are a couple of lookups + some virtual calls, I do not have numbers handy, but I am certain it is below 50 usecs.

Check this out for some performance numbers:

http://www.dre.vanderbilt.edu/Stats/performance.shtml

coryan
+1  A: 

You say CORBA would be great. I can only assume you have never used it. It is sprogramming nightmnare, and doesn't offer the portability it claims. I would only use it if an existing application already implemented it. However, I wouldn't chuck it out on performance grounds - I've mnever experienced any performance problems with any of the CORBA implementations I've used.

anon
A: 

ICE from ZeroC http://www.zeroc.com/ is another alternative.

For those CORBA old-timers, Michi Henning was one of the gurus of the day. He is now with ZeroC. It is an open-source, cross-platform, including all your targets (including Linux), system.

C++ is only one of the languages, and ICE's C++ bindings are significantly better than the CORBA C++ bindings are.

sdg
A: 

Take a look at D-Bus (yes, for windows too), which is the modern spiritual heir of various componentry frameworks (CORBA, Gnome Bonobo, KDE's DCOM).

If the cross-process marshalling turns out to be a performance problem, look to move the heavy lifting to shared memory (boost.interprocess will help keep it cross-platform).

timday
A: 

I think you should take a look into VortexLibrary.

It is a complete BEEP implementation which provides a good foundation to develop any peer to peer application protocol. It already integrates authentication (using SASL) and secure connections (using TLS), both optionals.

Vortex also includes an implementation of the XML-RPC profile with an IDL compiler which should provide you with the enough foundation for the marshalling stuff....and the best is that you can later provide a more particular protocol, on top of the same session, to do binary transfer without being limited by XML-RPC.

It is programmed with C but also works with c++. Currently it is running, with regression tests ensuring its function under Linux, Windows and MAC.

Cheers!