Anything higher-level, and more comprehensive than pipes/sockets?
Yes, there are lots of things, but there isn't one as "Standard" as COM/DCOM. At least, in Windows, COM / DCOM are used by "Windowsish" stuff, and other RPC mechanisms are used by un-"Windowsish" stuff.
Linux doesn't have anything like that, instead things which need higher level RPC protocols typically use whatever their language provides, or a specific library which best suits an app's needs. Examples of that would be RMI in Java, Python's "pyro" module, etc, which will provide (some) functional parity with DCOM.
Corba is a bit heavyweight but some people apparently do use it.
A lot of applications roll their own RPC libraries. Don't do that unless you have to, it's nasty.
For interprocess communication, D-Bus is the standard higher level mechanism. Both GTK and Qt have bindings for D-Bus, most desktop environments (or at least GNOME and KDE) expose various services via D-Bus, and many desktop applications can be controlled via a D-Bus interface. The system bus is also useful for finding out various low level information about the system using standard system services.
KDE4 (built upon Qt4) also includes a technology called KParts, which are often compared to Window's COM.
- D-Bus uses a logical "Bus" over which connected applications may communicate
- communication takes place via a simple object model that supports both RPC and publish-subscribe mechanisms
- D-Bus includes a standard introspection mechanism for the run-time querying of object interfaces, applications connected to the bus may query for the availability of objects, call remote methods on them, and request notification for the signals they emit
- before: GNOME Bonobo, KDE DCOP, CORBA, Sun RPC... nowadays people seem to prefer D-Bus
- interface based component model, as are COM and CORBA
- all UNO-interfaces must be derived from a interface that offers acquire, release, and a queryInterface method (comparable to COM)
- the lifetime of UNO-objects is controlled by global reference counting.
- components communicate only via their interfaces o each component lives in a Uno Runtime Environment (URE), there is no performance overhead for components, that are instantiated within the same URE, e.g., in C++, a call from component A to B is just a virtual call
- UNO-interfaces are specified in IDL
- exceptions are used for error handling.
- similar to Microsoft COM
- Interfaces in XPCOM are defined in a dialect of IDL called XPIDL
- disadvantage is that XPCOM adds a lot of code for marshalling objects between different usage contexts, which leads to code bloat in XPCOM based systems
...another alternative to consider might be Java RMI as well
It's also worth to see related questions:
Is there an equivalent to COM on *nix systems ? If not, what was the *nix approach to re-usability?
Analog of COM programming in Linux/UNIX
You can check out Corba, it works on Linux and Windows as well.
The Mono project jumps to mind. Mostly because the CLR/.NET is the new COM -- after all, COM was initially sold as language independent, binary compatible objects.
I guess DCOM (i.e. COM with a longer wire) would be .NET remoting? Or perhaps some web services with object serialization. I believe Mono supports both.
There is Mozilla's XPCOM technology, Cross Platform Component Object Model. Sort of similar to COM or DCOM conceptually.
Here is a list of the relatively few programs which do make use of the D-bus
DCOM is available on Linux. It isn't "the linux way of doing things", but hey, if you want "like DCOM, but Linux" then just use DCOM on Linux and have done...
来源：https://stackoverflow.com/questions/1183754/what-is-the-closest-thing-to-windows-com-dcom-in-the-linux-world