Linux世界中最接近Windows COM/DCOM的东西是什么？

什么比管道/插座更高级,更全面？

1> Kitsune..：

---

对于进程间通信,D-Bus是标准的更高级别机制.GTK和Qt都具有D-Bus绑定,大多数桌面环境(或至少GNOME和KDE)通过D-Bus公开各种服务,许多桌面应用程序可以通过D-Bus接口进行控制.系统总线对于使用标准系统服务查找有关系统的各种低级信息也很有用.

KDE4(基于Qt4构建)还包括一种名为KParts的技术,通常与Window的COM进行比较.

---

"对于进程间通信,D-Bus是标准机制." 它是？如果询问任何POSIX环境的标准进程间通信机制是什么,我会说套接字,共享内存,消息队列和信号量.

---

D-Bus比您列出的基本机制更高级,更接近COM/DCOM,并且在Linux上广泛使用(所有其他版本都继承自Unix的许多其他版本 - D-Bus建立在这样的低级别上面当然的机制).

2> MarkR..：

---

是的,有很多东西,但没有一个像COM/DCOM那样"标准".至少,在Windows中,COM/DCOM由"Windowsish"使用,其他RPC机制由un-"Windowsish"使用.

Linux没有这样的东西,而是需要更高级别RPC协议的东西通常使用他们的语言提供的任何东西,或者最适合应用程序需求的特定库.例如,Java中的RMI,Python的"pyro"模块等,它将提供(某些)功能与DCOM的奇偶校验.

Corba有点重量级但有些人显然确实使用它.

很多应用程序都会使用自己的RPC库.除非你必须这样做,否则不要这样做,这是令人讨厌的.

3> LihO..：

---

公交车

D-Bus使用逻辑“ Bus”，已连接的应用程序可通过该“ Bus”进行通信

通过支持RPC和发布-订阅机制的简单对象模型进行通信

D-Bus包括用于对对象接口进行运行时查询的标准自省机制，连接到总线的应用程序可以查询对象的可用性，调用对象上的远程方法，并请求通知它们发出的信号

之前：GNOME Bonobo，KDE DCOP，CORBA，Sun RPC ...如今，人们似乎更喜欢D-Bus

联合国办事处

基于接口的组件模型，如COM和CORBA

所有UNO接口都必须从提供获取，发布和queryInterface方法（与COM相比）的接口派生。

UNO对象的寿命由全局引用计数控制。

组件仅通过其接口进行通信o每个组件都生活在Uno Runtime Environment（URE）中，在同一个URE中实例化的组件没有性能开销，例如，在C ++中，从组件A到B的调用只是一个虚拟通话

UNO接口在IDL中指定

异常用于错误处理。

XPCOM

类似于Microsoft COM

XPCOM中的接口在IDL的方言XPIDL中定义

缺点是XPCOM添加了许多代码来在不同的使用上下文之间编组对象，这导致基于XPCOM的系统中的代码膨胀

...另一种选择要考虑可能的Java RMI以及

还值得一提的是相关问题：
* nix系统上是否有与COM等效的东西？如果不是，那么* nix的可重用性方法是什么？
Linux / UNIX中COM编程的模拟