我对windows COM和它背后的思想有一定的了解。我想知道*nix系统是否有等价物,或者为什么没有?
发布于 2010-06-18 00:17:02
Unix模型是围绕轻量级进程的概念构建的,这些轻量级进程通过套接字、管道、信号和命令行相互通信。从历史上看,Unix没有线程( POSIX线程模型只有10年左右的历史),但Unix上的进程总是比Windows上的进程便宜得多,因此将功能分解到单独的可执行文件中要比让单个程序变得更大更有性能。
在COM中,您可以定义允许共享内存通信的二进制接口。COM与面向对象的范例绑定在一起。在经典的Unix模型中,您定义了面向流的接口,允许在没有共享内存的情况下通过管道进行通信。从概念上讲,这更接近于函数式编程范例。
Unix模型鼓励制作可以通过轻量级“外壳”轻松耦合在一起的小程序,而COM模型鼓励制作公开可供其他大型程序重用的“组件”的大型程序。这实际上是一种苹果和橙子的比较,因为这两种模型都针对不同的场景提供了优点和缺点。
当然,现代Unix系统可以具有类似COM的功能。Mozilla拥有XPCOM,这是一个基于与COM相同的原则构建的跨平台框架。GNOME很长一段时间都在使用Bonobo,它在概念上与COM的前身Microsoft OLE非常相似。但最近版本的GNOME已经从Bonobo转向了D-Bus,后者更像是一种事件/消息传递模式。
发布于 2010-06-18 00:47:40
最接近的可能是D-Bus。D-Bus是一个轻量级的进程间通信协议和对象请求代理(ORB),与COM非常相似,并且受到COM和D-Bus的前身DCOP (KDE)和CORBA (GNOME)以及Netlink (Linux Kernel)的很大启发。
在D-Bus之前,两个主要的Unix桌面环境都有自己的组件模型和桌面总线。GNOME有基于CORBA的Bonobo,KDE有基于DCOP的KParts。Linux内核有Netlink,这是内核和用户空间之间的通信协议,例如,当您配置网络接口时,iproute2工具就会使用Netlink。
内核开发人员不断收到要求将Netlink作为用户空间程序之间通信的单独部分的请求,但是他们担心这会导致功能膨胀和维护问题。最后,在自由桌面组织(其目标是创建cros桌面标准)的保护伞下,KDE和GNOME开发人员聚集在一起,基于DCOP和Netlink的最佳部分开发了一个IPC消息传递系统,结果是D-Bus。
在GNOME和KDE的当前版本中,D-Bus已经完全取代了CORBA和DCOP,因此可以在KDE中运行GNOME应用程序,反之亦然,保真度更高。D-Bus还被许多其他桌面环境和应用程序采用,不仅在Linux上,而且在其他Unix系统上,以及OSX甚至Windows上。
一个至少应该提到的替代方案是Mozilla的XPCOM,它是一个受CORBA和COM启发的跨平台对象模型。(实际上,XPCOM是跨平台组件对象模型的缩写。)它使用一种与CORBA非常相似的IDL,称为XPIDL。然而,据我所知,没有人真正使用XPCOM,它被评论家以及Firefox和其他Mozilla应用程序的开发人员视为臃肿的主要来源之一,Mozila开发人员实际上正在积极减少XPCOM的使用,特别是在像Gecko这样的组件中。
然而,正如@Daniel Pryden指出的那样,在不需要与桌面紧密集成的情况下,Unix中已经有很多东西应该优先于D-Bus。我说的是管道、命名管道和套接字等东西。
发布于 2010-06-17 23:53:45
最近的可能是CORBA
https://stackoverflow.com/questions/3063321
复制相似问题