10

Anything higher-level, and more comprehensive than pipes/sockets?

fakeleft
  • 2,830
  • 2
  • 30
  • 32
  • Thank you all - that was pretty much my sense of where things stood. I accepted @MarkR's answer as it seemed to wrap things up nicely. – fakeleft Jul 27 '09 at 07:15

7 Answers7

12

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.

Kitsune
  • 9,101
  • 2
  • 25
  • 24
  • 5
    "For interprocess communication, D-Bus is the standard mechanism." It is? Sockets, shared memory, message queues, and semaphores are what I would say if asked what the standard interprocess communications machanisms of any POSIX environment were. – smcameron Jul 26 '09 at 04:56
  • 4
    D-Bus is higher-level than the elementary mechanisms you list, more comparable to COM/DCOM, and widespread on Linux (all others are inherited from many other versions of Unix -- D-Bus is built on top on such lower-level mechanisms of course). – Alex Martelli Jul 26 '09 at 04:58
  • You can write Pigin IM controllers which work through D-Bus instead of a pigin plugin. Run dbus-monitor --session and you can see pigdin putting everything in your conversations out there on the D-Bus. – Sean A.O. Harney Jul 26 '09 at 05:15
  • I slightly adjusted that sentence to clarify that I was meaning wrt higher level infrastructure (as that's what the question was about). Also, D-Bus *is* becoming increasingly popular with lower level tools, such as PolicyKit and HAL. – Kitsune Jul 26 '09 at 17:37
  • Also, in additon, most every KDE application has a D-Bus interface (some interfaces are quite extensive). The Freedesktop.org's listing of projects which use it is *incredibly* incomplete. – Kitsune Jul 26 '09 at 17:39
  • No it isn't. "Becoming increasingly popular" isn't "standard". – Ben Jan 29 '12 at 22:21
  • "Becoming increasingly popular" was with respect to lower level tools. The movement to replace SUID/GUID apps on Linux is generally leveraging D-Bus's system bus to accomplish those replacements. Desktop Linux, on the other hand, already had widespread adoption of D-Bus even back in '09. It hasn't replaced sockets/pipes, but, it's not supposed to. Various specialized platforms often have their own mechanisms, but, those are generally platform dependent and would be even harder to call "standard" higher level Linux IPC mechanism. Don't assume all standards are de jure. – Kitsune Jan 31 '12 at 02:14
  • DBus is more like DDE than COM. That's fine for what it is doing. – Ben Mar 02 '12 at 10:11
10

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.

MarkR
  • 62,604
  • 14
  • 116
  • 151
  • Is Sun RPC -ONC does the same thing like COM/DCOM? – dexterous Apr 02 '14 at 05:13
  • [ONC RPC](https://en.wikipedia.org/wiki/Open_Network_Computing_Remote_Procedure_Call) is more on par with [DCE/RPC](https://en.wikipedia.org/wiki/DCE/RPC) or [MSRPC](https://en.wikipedia.org/wiki/Microsoft_RPC). Its IDL is much simpler, and it has less features. [Distributed COM](https://en.wikipedia.org/wiki/Distributed_Component_Object_Model) is based on MSRPC for communication, but it handles many complex things above that level, such as proxy object caching to avoid `AddRef` and `QueryInterface` round trips, pinging for garbage collection, COM-specific memory management, etc. – acelent Jul 22 '16 at 09:17
  • **Linux doesn't have anything like that**: I would say *dbus* comes pretty close: applications can expose rpc methods and events, you can introspect these methods and then call them remotely. **A lot of applications roll their own RPC libraries. Don't do that unless you have to, it's nasty** I definitely see the point. On the other hand I would say things like emacs and gimp have pretty nice RPC libraries. I guess the more complicated an application is the more it deserves its own rpc mechanism! – Att Righ Sep 03 '17 at 12:11
5
D-Bus
  • 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
UNO
  • 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.
XPCOM
  • 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

Community
  • 1
  • 1
LihO
  • 41,190
  • 11
  • 99
  • 167
4

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.

ars
  • 120,335
  • 23
  • 147
  • 134
3

You can check out Corba, it works on Linux and Windows as well.

On Freund
  • 4,376
  • 2
  • 23
  • 30
2

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

Sean A.O. Harney
  • 23,901
  • 4
  • 30
  • 30
1

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

Beached
  • 1,608
  • 15
  • 18
Ben
  • 34,935
  • 6
  • 74
  • 113