Cross-platform alternative to COM

2020-05-23 20:32发布

问题:

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:

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.



回答2:

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.



回答3:

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



回答4:

Shouldn't Qt be an Alternative?

http://qt.io

AFAIKT you can use it at least on: Windows | Mac | Linux/X11 | Solaris | Embedded Linux | Windows Embedded | Green Hills Software INTEGRITY | QNX | VxWorks

That's quite much IMHO.



回答5:

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



回答6:

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.



回答7:

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).



回答8:

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.



回答9:

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!