比pipe道/套接字更高层次,更全面吗?
是的,有很多东西,但没有一个像COM / DCOM那样是“标准”的。 至少在Windows中,COM / DCOM被“Windowsish”的东西所使用,而其他的RPC机制则被非Windows的东西所使用。
Linux没有这样的东西,相反,需要更高级RPC协议的东西通常使用他们的语言提供的任何东西,或者是一个最适合应用需求的特定的库。 例如Java中的RMI,Python的“pyro”模块等,它们将提供(一些)与DCOM的功能性奇偶校验。
Corba有点重量级,但有些人显然使用它。
很多应用程序都会自己调用RPC库。 不要这样做,除非你必须,这是讨厌的。
对于进程间通信, D-Bus是标准的更高级别的机制。 GTK和Qt都绑定了D-Bus,大多数桌面环境(或者至少GNOME和KDE)通过D-Bus公开了各种服务,许多桌面应用程序可以通过D-Bus接口进行控制。 系统总线对于使用标准系统服务来查找关于系统的各种低级信息也是有用的。
KDE4(基于Qt4)还包含一种名为KParts的技术,通常与Window的COM进行比较。
d总线
UNO
XPCOM
另一个可供选择的方法是Java RMI
这也是值得看到相关的问题:
在* nix系统上是否有与COM等价的功能? 如果不是,那么nix的可重用性是什么?
Linux / UNIX中COM编程的模拟
你可以看看Corba ,它也适用于Linux和Windows。
单声道项目跳转到头脑中。 主要是因为CLR / .NET是新的COM – 毕竟,COM最初是作为语言独立的,二进制兼容的对象出售的。
我猜DCOM(即COM与更长的线)将.NET远程? 或者可能有一些带有对象序列化的Web服务。 我相信Mono支持两者。
有Mozilla的XPCOM技术,跨平台组件对象模型。 在概念上类似于COM或DCOM。
下面是使用D-bus的相对较少的程序列表
DCOM在Linux上可用。 这不是“linux的做事方式”,但是,如果你想要“像DCOM,但Linux”,那么只需在Linux上使用DCOM,并做了…