COM,COM+区别

（转载自http://www.chinabyte.com/20020208/217790.shtml）

COM的产生

在以前程序设计过程中，程序员把它们的函数库放在一个叫做目标(Object)文件的单独文件中，在这些文件中，包含了编译过的代码。当程序员要使用一个特别的目标文件的时候，他们把客户程序编译成机器代码，然后依靠动态链接的手段把客户程序联接到目标文件上，最后变成一个单一的可执行文件。这种作法的唯一的好处在于它节省了编译函数库的时间。但是它有许多的缺点，比如由于在每个单独的可执行文件中都有一个程序库包括在里面，浪费了许多存储空间；对应用程序的维护也是非常困难的，如果在函数库中发现了一个bug，整个可执行文件都要被重新编译和分发。

还有不只一个的严重的限制在里头，一个客户应用程序必须要和用同一种语言编制的函数库在一起才能使用。比如说，一个用QuickBasic写的客户应用程序就不能引用一个用C++写的函数库。

因此，微软公司出品了COM，COM仅仅只是一个规范。不管组件用什么语言写成，只要符合这个COM规范，就能被用任何一种语言写成的客户程序调用。此外，程序员不必再担心要去建立一个单一的可执行文件，因为组件是以GUID（Global Unique Identifier全球唯一标识符）来标识的。GUID是一个128位的号码，和一些相关的信息一起被放在系统的注册表中，用来唯一标识组件。客户应用程序只在运行期间才动态地建立一个组件的实例，并使用这个组件的功能，因此，只需要一个函数库的拷贝。它的缺点就是大家常常提到?quot;DLL地狱"。这个问题在一个DLL要被一个新版本的DLL所取代时引发。开发者不得不通过关闭所有的客户应用程序的方法（如果不行，还要关闭WWW服务）来达到清除所用对这个组件的引用的目的。有时所有的方法都还起不了作用，那你只好重新启动服务器后才能替换掉老的DLL。

COM+

为了让企业级的应用程序能使用上COM，它必需要有以下的特定的能力。

· 验证能力

· 对象池（Object Pooling）

· 事务处理

· 支持分布式架构

为了使开发者不必去为他们的组件添加这些能力，微软公司出品了DCOM（Distributed COM分布式COM）和MTS（Microsoft Transaction Server微软事务服务器）。使用这两种技术，开发者就可以把精力用在他们的商业逻辑上，而不必放在后台的他们的组件上。

DCOM是一个用于分布式的组件之间的通讯的RPC（Remote Procedure Call）协议。客户端向一个本地机的代理类发送请求，然后由代理类将这个请求隐含地给安装在远程机器上的"根"类，然后执行结果原路送回给代理类，最后代理类把它们回送给客户端。因此，客户程序的位置完全与组件的位置无关。DCOM的缺点在于，由于DCOM使用的是一个独立的硬件端口，而不是HTTP协议的80端口，所以在组件间通讯的过程中，必须保证这个端口是开着的。这是一个严重的安全问题。所以DCOM不能够轻易地穿越防火墙 Ҷƪл˵?