COM在非Windows世界？

Question

希望这个问题不会太模糊.通过COM规范和Don Box的Essential COM书阅读,有很多关于"COM解决的问题"的讨论 - 而且它们听起来都很重要,相关且最新.

那么COM地址在其他系统(linux,unix,OSX,android)上处理的问题怎么样呢？我想的是:

• 跨编译器和编译器版本的二进制兼容性
• 二进制组件重用
• 编译一个应用程序,使其具有运行时依赖性,而不是加载时间依赖性(以便即使缺少依赖项也会运行)
• 从库以外的语言访问库功能
• 合理的低开销远程过程调用加载到不同进程的地址空间中的组件
• 等等(我确定这个清单还在继续)

我基本上只是想了解为什么例如Linux上的CORBA不是像COM这样的东西在Windows上(如果这是有道理的).Linux上的软件开发是否可以订阅与COM提出的基于组件的模型不同的理念？

最后,COM是C/C++的东西吗？有几次我遇到过人们的评论,他们说COM被.NET淘汰了,但没有真正解释他们的意思.

Answer 1

目前,让我们考虑一下Linux.

对于Linux,前两点往往具有相对较低的相关性.大多数软件都是开源的,许多用户习惯于在任何情况下从源代码构建.对于这样的用户,二进制兼容性/重用很少或没有后果(事实上,相当多的用户可能拒绝所有未以源代码形式分发的软件).

当组件丢失时能够加载和运行(具有降低的功能)也通常是闭源问题.封闭源软件通常具有多个版本,具有不同的功能以支持不同的价格.供应商可以方便地构建主应用程序的一个版本,并根据提供/省略的其他组件提供不同级别的功能.

这主要是为了支持不同的价格水平.当软件是免费的时,只有一个价格和一个版本:真棒版本.

再次访问语言之间的库功能往往更多地基于源代码而不是二进制接口,例如使用SWIG允许使用来自Python和Ruby等语言的C或C++源代码.同样,COM基本上解决了主要源于缺乏源代码的问题; 使用开源软件时,问题根本就不会出现.

低开销的RPC再次在其他进程中编码似乎主要源于封闭源软件.当/如果您希望Microsoft Excel能够在Adobe Photoshop中使用某些内部"东西"时,您可以使用COM让它们进行通信.这增加了运行时间开销和额外的复杂性,但是当其中一段代码由Microsoft拥有而另一块由Adobe拥有时,它几乎就是你所坚持的.

但是,在开源软件中,如果项目A具有一些在项目B中有用的功能,那么您可能会看到(最多)项目A的一个分支,将该功能转换为库,然后将其链接到两个库中项目A的剩余部分和项目B,很可能也是项目C,D和E - 所有这些都不会增加COM,跨程序RPC等的开销.

现在,不要误会我的意思:我不是试图充当开源软件的代言人,也不是说封闭源代码很糟糕,开源总是非常优秀.我我要说的是,COM为二进制级别主要定义,但对于开源软件,人们往往用源代码来处理更多的来代替.

编辑:我应该补充一点,SWIG只是支持源代码级跨语言开发的几个工具中的一个例子.虽然SWIG被广泛使用,但COM在一个相当重要的方面与它不同:使用COM,您可以用单个中性语言定义接口,然后生成一组适合该接口的语言绑定(代理和存根).这与SWIG完全不同,SWIG直接从一个源语言到一个目标语言进行匹配(例如,绑定以使用Python中的C库).

在开源世界中,还有一些工具可以在中性接口定义语言中定义接口,然后从该接口定义生成特定语言的绑定.CORBA是众所周知的,但通常被视为大而复杂,因此实际使用相当少.Apache Thrift提供了一些相同的一般类型的功能,但是更简单,更轻量级.特别是,在CORBA尝试为分布式计算提供一整套工具的地方(包括从身份验证到分布式时间保持的所有工具),Thrift更加紧密地遵循Unix理念,尝试满足一个需求:从一个生成代理和存根接口定义(用中性语言编写).如果你想用Thrift做那些类似CORBA的东西,你无疑可以,但在一个更典型的情况下建立内部基础设施,呼叫者和被叫者互相信任,你可以避免很多开销,只需继续处理业务手.

Answer 2

关于最后一个问题的快速回答:COM远未过时.Microsoft世界中几乎所有东西都是基于COM的,包括.NET引擎(CLR),包括新的Windows 8.x的Windows运行时.

以下是微软在最新的C++页面中对.NET所说的内容欢迎回到C++(现代C++):

C++正在经历复兴,因为权力再次成为王者.当程序员的生产力很重要时,Java和C#等语言很好,但是当权力和性能至关重要时,它们就会显示出局限性.为了实现高效率和高功率,特别是在硬件有限的设备上,没有什么能比现代C++更好.

PS:对于在.NET上投入超过10年的开发人员来说,这有点令人震惊:-)