Linux 世界中最接近 Windows COM/DCOM 的是什么？
声明：本页面是StackOverFlow热门问题的中英对照翻译，遵循CC BY-SA 4.0协议，如果您需要使用它，必须同样遵循CC BY-SA许可，注明原文地址和作者信息，同时你必须将它归于原作者（不是我）：StackOverFlow
原文地址: http://stackoverflow.com/questions/1183754/
Warning: these are provided under cc-by-sa 4.0 license. You are free to use/share it, But you must attribute it to the original authors (not me):
StackOverFlow
What is the closest thing to Windows COM/DCOM in the Linux world?
提问by fakeleft
Anything higher-level, and more comprehensive than pipes/sockets?
有什么比管道/套接字更高级、更全面的东西吗？
采纳答案by MarkR
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.
是的，有很多东西，但没有一个像 COM/DCOM 那样“标准”。至少，在 Windows 中，COM/DCOM 被“Windowsish”的东西使用，而其他 RPC 机制被非“Windowsish”的东西使用。
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.
Linux 没有类似的东西，需要更高级别的 RPC 协议的东西通常使用它们的语言提供的任何东西，或者最适合应用程序需求的特定库。这方面的例子是 Java 中的 RMI、Python 的“pyro”模块等，它将提供与 DCOM 的（某些）功能奇偶校验。
Corba is a bit heavyweight but some people apparently do use it.
Corba 有点重量级，但显然有些人确实在使用它。
A lot of applications roll their own RPC libraries. Don't do that unless you have to, it's nasty.
许多应用程序都推出了自己的 RPC 库。除非万不得已，否则不要这样做，这很讨厌。
回答by Kitsune
For interprocess communication, D-Busis 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.
对于进程间通信，D-Bus是标准的高层机制。GTK 和 Qt 都绑定了 D-Bus，大多数桌面环境（或至少 GNOME 和 KDE）通过 D-Bus 公开各种服务，许多桌面应用程序可以通过 D-Bus 接口进行控制。系统总线对于使用标准系统服务查找有关系统的各种低级信息也很有用。
KDE4 (built upon Qt4) also includes a technology called KParts, which are often compared to Window's COM.
KDE4（建立在 Qt4 之上）还包括一项称为 KParts 的技术，通常将其与 Window 的 COM 进行比较。
回答by LihO
- 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
- D-Bus 使用逻辑“总线”，连接的应用程序可以通过它进行通信
- 通信通过一个支持 RPC 和发布订阅机制的简单对象模型进行
- D-Bus 包括一个标准的内省机制，用于对象接口的运行时查询，连接到总线的应用程序可以查询对象的可用性，调用它们的远程方法，并请求它们发出的信号的通知
- 之前：GNOME Bonobo、KDE DCOP、CORBA、Sun RPC……现在人们似乎更喜欢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.
- 基于接口的组件模型，COM 和 CORBA 也是如此
- 所有 UNO 接口都必须派生自提供获取、释放和查询接口方法的接口（类似于 COM）
- UNO 对象的生命周期由全局引用计数控制。
- 组件仅通过它们的接口进行通信 o 每个组件都存在于 Uno 运行时环境 (URE) 中，在同一 URE 中实例化的组件没有性能开销，例如，在 C++ 中，从组件 A 到 B 的调用只是一个虚拟通话
- UNO 接口在 IDL 中指定
- 异常用于错误处理。
- similar to Microsoft COM
- Interfaces in XPCOM are defined in a dialect of IDL called XPIDL
- disadvantageis that XPCOM adds a lot of code for marshalling objects between different usage contexts, which leads to code bloat in XPCOM based systems
- 类似于 Microsoft COM
- XPCOM 中的接口是用一种称为 XPIDL 的 IDL 方言定义的
- 缺点是XPCOM为在不同使用上下文之间编组对象添加了大量代码，这导致基于XPCOM的系统中的代码膨胀
...another alternative to consider might be Java RMIas well
...另一种选择要考虑可能的Java RMI以及
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
还值得一看相关问题：
*nix 系统上是否有与 COM 等效的内容？如果不是，*nix 的可重用性方法是什么？
Linux/UNIX 中 COM 编程的模拟
回答by On Freund
回答by ars
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.
突然想到 Mono 项目。主要是因为 CLR/.NET 是新的 COM —— 毕竟，COM 最初是作为独立于语言的、二进制兼容的对象出售的。
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.
我猜 DCOM（即带有更长线路的 COM）将是 .NET 远程处理？或者也许是一些具有对象序列化的 Web 服务。我相信 Mono 支持两者。
回答by Sean A.O. Harney
回答by Ben
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...
DCOM 在 Linux 上可用。这不是“Linux 的做事方式”，但是，嘿，如果您想要“像 DCOM，但是 Linux”，那么只需在 Linux 上使用 DCOM 就可以了……
