在非Windows世界中的COM？ [英] COM in the non-Windows world?
问题描述
希望这个问题不会太含糊。通读COM规范和Don Box的Essential COM书籍，有很多关于 COM解决的问题的讨论-它们都听起来很重要，相关且当前。
因此，COM地址在其他系统（Linux，Unix，OSX，Android）上如何处理）？我在想类似的东西：
- 编译器和编译器版本之间的二进制兼容性
- 二进制组件重复使用
- 编译应用程序，使其具有运行时依赖关系，而不是加载时依赖关系（以便即使缺少依赖项也可以运行）
- 从库自身的语言之外的其他语言访问库功能
- 对开销不同的进程中加载的组件的开销较低的远程过程调用
- 等（我确定列表还在继续）
我基本上只是想了解为什么在Linux上运行CORBA不像COM是Windows上的东西（如果有任何意义）。
最后，COM是C / C ++吗？几次我都听到有人说.NET使COM过时，但没有真正解释它们的含义。
在本文的其余部分中，我将使用Linux作为开源软件的示例。在我提到 Linux的地方
COM与.NET
COM实际上并不限于C和C ++ ，. NET实际上也不能替代COM。但是，.NET在某些情况下确实提供了COM的替代方法。 COM的一种常见用法是提供控件（ActiveX控件）。 .NET为控件提供/支持自己的协议，该协议允许某人用一种.NET语言编写控件，并使用其他任何.NET语言的控件-或多或少与COM在.NET外部提供的同类控件相同。
同样，.NET提供Windows Communication Foundation（WCF）。 WCF实现了SOAP（简单对象访问协议）-最初可能很简单，但是充其量只是变得简单得多。无论如何，WCF提供了许多与COM相同的功能。尽管WCF本身特定于.NET，但它实现了SOAP，并且使用WCF构建的SOAP服务器可以与没有WCF的实现进行通信（反之亦然）。既然您提到了开销，那么可能值得一提的是WCF / SOAP往往会增加COM的开销（根据情况，我发现开销几乎等于开销的两倍）。
< h1>需求差异
对于Linux，前两点的相关性往往相对较低。大多数软件都是开源的，无论如何，许多用户习惯于从源代码构建。对于此类用户，二进制兼容性/重用几乎没有影响（或根本没有影响）（实际上，相当多的用户可能会拒绝所有未以源代码形式分发的软件）。尽管二进制文件通常是分发的（例如，带有apt-get，yum等），但它们基本上只是缓存为特定系统构建的二进制文件。也就是说，在Windows上，您可能只有一个二进制文件可用于从Windows XP到Windows 10的任何版本，但如果使用apt-get，例如Ubuntu 18.02，则安装的是专门为Ubuntu 18.02构建的二进制文件，而不是试图与Ubuntu 10或更高版本的所有版本兼容的计算机。
在缺少组件时能够加载和运行（功能降低）的情况通常也是封闭的源问题。闭源软件通常具有多个版本，它们具有不同的功能来支持不同的价格。供应商可以方便地构建主应用程序的一个版本，并根据提供/省略的其他组件来提供不同级别的功能。
主要是为了支持不同的价格水平。如果该软件是免费的，则只有一个价格和一个版本：很棒的版本。
再次访问语言之间的库功能往往更多地基于源代码，而不是二进制接口，例如使用 SWIG 允许使用来自Python和Ruby等语言的C或C ++源代码。同样，COM基本上可以解决主要由于缺乏源代码而引起的问题。在使用开放源代码软件时，根本就不会出现问题。
在其他过程中进行编码的低开销RPC再次似乎主要源于封闭源代码软件。当/如果您希望Microsoft Excel能够使用一些内部材料，在Adobe Photoshop中，您使用COM来让他们交流。这增加了运行时开销和的额外复杂性，但是当其中一部分代码由Microsoft拥有，而另一部分代码由Adobe拥有时，这几乎就是您所需要的。
b $ b源代码级别共享
但是，在开源软件中，如果项目A具有某些对项目B有用的功能，那么您可能会看到大多数）项目A的分支，以将该功能转换为一个库，然后将该库链接到项目A的其余部分和项目B中，并且很可能也链接到项目C，D和E中-所有这些都不会增加开销COM，跨过程RPC等。
现在，请不要误会我的意思：我不是在充当开源软件的代言人，也不是说封闭源代码很糟糕，而开放源代码总是非常优越的。我 am 所说的是，COM主要是在二进制级别定义的，但是对于开放源代码软件，人们往往会更多地使用源代码。
Of当然，SWIG只是在源代码级别支持跨语言开发的几种工具中的一个示例。尽管SWIG被广泛使用，但COM在一个相当关键的方式上不同于它：使用COM，您可以使用一种单一的中性语言定义一个接口，然后生成适合该接口的一组语言绑定（代理和存根）。这与SWIG截然不同，在SWIG中，您直接从一种来源与一种目标语言进行匹配（例如，绑定以使用Python中的C库）。
二进制通信
在某些情况下，至少具有一些类似于COM提供的功能很有用。这些导致了在很大程度上类似于COM的开源系统。例如，许多开源桌面环境使用/实现D-bus。在COM主要是RPC之类的地方，D-bus主要是在组件之间发送消息的公认方式。
D-bus确实指定了它称为对象的事物。其对象可以具有可以向其发送信号的方法。尽管D-bus本身主要是根据消息传递协议来定义的，但编写代理对象相当简单，以使在远程对象上调用方法看起来很像在本地对象上调用方法。最大的区别是COM具有一个编译器。可以采用协议规范，并自动为您生成这些代理（以及远端的相应存根以接收消息，并根据接收到的消息调用适当的功能）。这不是D-bus本身的一部分，但是人们已经编写了一些工具来采用（例如）接口规范，并根据该规范自动生成代理/存根。
因此，尽管两者并不完全相同，有足够的相似性，D总线可以（并且经常）用于与COM相同的许多事情。
与DCOM相似的系统
COM还允许您使用DCOM（分布式COM）构建分布式系统。也就是说，在一个系统上，您在一台机器上调用一个方法，但是（至少有可能）在另一台机器上执行该调用的方法。这增加了更多的开销，但是由于（如上有关D总线的指出），RPC基本上是与连接到末端的代理/存根进行通信，因此以分布式方式做相同的事情很容易。但是，开销上的差异往往会导致需要设计系统才能正常工作，因此，与本地系统使用完全相同的系统作为分布式系统的实际优势往往很小。
这样，开源世界提供了用于执行分布式RPC的工具，但通常不会努力使它们看起来与非分布式系统相同。 CORBA是众所周知的，但通常被认为是庞大而复杂的，因此（至少以我的经验），当前的使用是很少的。 Apache Thrift 提供了一些相同的常规类型的功能，但以一种更简单，更轻量的方式提供。尤其是在CORBA试图提供一套完整的分布式计算工具（从身份验证到分布式计时的所有功能都完整）的情况下，Thrift更加严格地遵循Unix哲学，试图满足一个需求：从一个代理生成代理和存根。界面定义（以中性语言编写）。如果您想使用Thrift来做类似CORBA的事情，那么您无疑可以，但是在构建呼叫者和被呼叫者彼此信任的内部基础结构的更典型情况下，可以避免大量的开销和只是从事手头的业务。同样， google RPC 提供与Thrift大致相同的功能。
OS X特定
可可提供分布式对象。
Apple还提供了 XPC 。 XPC比RPC更注重进程间通信，因此我认为它与D-bus相比，与COM更直接。但是，就像D-bus一样，它具有与COM相同的基本功能，但形式不同，它更加注重通信，而不太像本地函数调用那样（现在无论如何，许多人更喜欢使用消息传递而不是RPC） ）。
摘要
开放源代码软件在设计中具有足够多的不同因素，因此对提供与Microsoft COM相同功能组合的产品的需求较少在Windows上提供。 COM在很大程度上只是一个试图满足所有需求的工具。在开放源代码世界中，提供单一，全面的解决方案的动力越来越小，并且越来越倾向于使用一套工具，每种工具都能做得很好，可以将其组合成满足特定需求的解决方案。 p>
Apple OS X的商业化定位可能（至少可以说）比大多数更纯粹的开源世界更接近COM。
Hope this question isn't going to be too vague. Reading through the COM spec and Don Box's Essential COM book, there is plenty of talk of the "problems that COM solves" - and they all sound important, relevant and current.
So how are the problems that COM addresses dealt with on other systems (linux, unix, OSX, android)? I'm thinking of things like:
- binary compatibility across compilers and compiler versions
- binary component reuse
- compiling an application such that it has run-time dependencies rather than load-time ones (so that it runs even when a dependency is missing)
- access to library functionality from languages other than the library's own
- reasonably low-overhead remote procedure calls to components loaded in the address space of a different process
- etc (I'm sure the list goes on)
I'm basically just trying to understand why for instance on Linux CORBA isn't a thing like COM is a thing on Windows (if that makes any sense). Does maybe software development on Linux subscribe to a different philosophy than the component-based model proposed by COM?
And finally, is COM a C/C++ thing? Several times I've come across comments from people saying COM is made "obsolete" by .NET but without really explaining what they meant by that.
For the remainder of this post, I'm going to use Linux as an example of open-source software. Where I mention "Linux" it's mostly a short/simple way to refer to open source software in general though, not anything specific to Linux.
COM vs. .NET
COM isn't actually restricted to C and C++, and .NET doesn't actually replace COM. However, .NET does provide alternatives to COM for some situations. One common use of COM is to provide controls (ActiveX controls). .NET provides/supports its own protocol for controls that allows somebody to write a control in one .NET language, and use that control from any other .NET language--more or less the same sort of thing that COM provides outside the .NET world.
Likewise, .NET provides Windows Communication Foundation (WCF). WCF implements SOAP (Simple Object Access Protocol)--which may have started out simple, but grew into something a lot less simple at best. In any case, WCF provides many of the same kinds of capabilities as COM does. Although WCF itself is specific to .NET, it implements SOAP, and a SOAP server built using WCF can talk to one implemented without WCF (and vice versa). Since you mention overhead, it's probably worth mentioning that WCF/SOAP tend to add more overhead that COM (I've seen anywhere from nearly equal to about double the overhead, depending on the situation).
Differences in Requirements
For Linux, the first two points tend to have relatively low relevance. Most software is open source, and many users are accustomed to building from source in any case. For such users, binary compatibility/reuse is of little or no consequence (in fact, quite a few users are likely to reject all software that isn't distributed in source code form). Although binaries are commonly distributed (e.g., with apt-get, yum, etc.) they're basically just caching a binary built for a specific system. That is, on Windows you might have a single binary for use on anything from Windows XP up through Windows 10, but if you use apt-get on, say, Ubuntu 18.02, you're installing a binary built specifically for Ubuntu 18.02, not one that tries to be compatible with everything back to Ubuntu 10 (or whatever).
Being able to load and run (with reduced capabilities) when a component is missing is also most often a closed-source problem. Closed source software typically has several versions with varying capabilities to support different prices. It's convenient for the vendor to be able to build one version of the main application, and give varying levels of functionality depending on which other components are supplied/omitted.
That's primarily to support different price levels though. When the software is free, there's only one price and one version: the awesome edition.
Access to library functionality between languages again tends to be based more on source code instead of a binary interface, such as using SWIG to allow use of C or C++ source code from languages like Python and Ruby. Again, COM is basically curing a problem that arises primarily from lack of source code; when using open source software, the problem simply doesn't arise to start with.
Low-overhead RPC to code in other processes again seems to stem primarily from closed source software. When/if you want Microsoft Excel to be able to use some internal "stuff" in, say, Adobe Photoshop, you use COM to let them communicate. That adds run-time overhead and extra complexity, but when one of the pieces of code is owned by Microsoft and the other by Adobe, it's pretty much what you're stuck with.
Source Code Level Sharing
In open source software, however, if project A has some functionality that's useful in project B, what you're likely to see is (at most) a fork of project A to turn that functionality into a library, which is then linked into both the remainder of project A and into Project B, and quite possibly projects C, D, and E as well--all without imposing the overhead of COM, cross-procedure RPC, etc.
Now, don't get me wrong: I'm not trying to act as a spokesperson for open source software, nor to say that closed source is terrible and open source is always dramatically superior. What I am saying is that COM is defined primarily at a binary level, but for open source software, people tend to deal more with source code instead.
Of course SWIG is only one example among several of tools that support cross-language development at a source-code level. While SWIG is widely used, COM is different from it in one rather crucial way: with COM, you define an interface in a single, neutral language, and then generate a set of language bindings (proxies and stubs) that fit that interface. This is rather different from SWIG, where you're matching directly from one source to one target language (e.g., bindings to use a C library from Python).
Binary Communication
There are still cases where it's useful to have at least some capabilities similar to those provided by COM. These have led to open-source systems that resemble COM to a rather greater degree. For example, a number of open-source desktop environments use/implement D-bus. Where COM is mostly an RPC kind of thing, D-bus is mostly an agreed-upon way of sending messages between components.
D-bus does, however, specify things it calls objects. Its objects can have methods, to which you can send signals. Although D-bus itself defines this primarily in terms of a messaging protocol, it's fairly trivial to write proxy objects that make invoking a method on a remote object look pretty much like invoking one on a local object. The big difference is that COM has a "compiler" that can take a specification of the protocol, and automatically generate those proxies for you (and corresponding stubs in the far end to receive the message, and invoke the proper function based on the message it received). That's not part of D-bus itself, but people have written tools to take (for example) an interface specification and automatically generate proxies/stubs from that specification.
As such, although the two aren't exactly identical, there's enough similarity that D-bus can be (and often is) used for many of the same sorts of things as COM.
Systems Similar to DCOM
COM also allows you to build distributed systems using DCOM (Distributed COM). That is, a system where you invoke a method on one machine, but (at least potentially) execute that invoked method on another machine. This adds more overhead, but since (as pointed out above with respect to D-bus) RPC is basically communication with proxies/stubs attached to the ends, it's pretty easy to do the same thing in a distributed fashion. The difference in overhead, however, tends to lead to differences in how systems need to be designed to work well, though, so the practical advantage of using exactly the same system for distributed systems as local systems tends to be fairly minimal.
As such, the open source world provides tools for doing distributed RPC, but doesn't usually work hard at making them look the same as non-distributed systems. CORBA is well known, but generally viewed as large and complex, so (at least in my experience) current use is fairly minimal. Apache Thrift provides some of the same general type of capabilities, but in a rather simpler, lighter-weight fashion. In particular, where CORBA attempts to provide a complete set of tools for distributed computing (complete with everything from authentication to distributed time keeping), Thrift follows the Unix philosophy much more closely, attempting to meet exactly one need: generate proxies and stubs from an interface definition (written in a neutral language). If you want to do those CORBA-like things with Thrift you undoubtedly can, but in a more typical case of building internal infrastructure where the caller and callee trust each other, you can avoid a lot of overhead and just get on with the business at hand. Likewise, google RPC provides roughly the same sorts of capabilities as Thrift.
OS X Specific
Cocoa provides distributed objects that are fairly similar to COM. This is based on Objective-C though, and I believe it's now deprecated.
Apple also offers XPC. XPC is more about inter-process communication than RPC, so I'd consider it more directly comparable to D-bus than to COM. But, much like D-bus, it has a lot of the same basic capabilities as COM, but in different form that places more emphasis on communication, and less on making things look like local function calls (and many now prefer messaging to RPC anyway).
Summary
Open source software has enough different factors in its design that there's less demand for something providing the same mix of capabilities as Microsoft's COM provides on Windows. COM is largely a single tool that tries to meet all needs. In the open-source world, there's less drive to provide that single, all-encompassing solution, and more tendency toward a kit of tools, each doing one thing well, that can be put together into a solution for a specific need.
Being more commercially oriented, Apple OS X probably has what are (at least arguably) closer analogs to COM than most of the more purely open-source world.
这篇关于在非Windows世界中的COM？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
