COM/DCOM简述

　　这些组件对象能够互相通信与交互，而与它们的语言、分布及原始平台无关。COM规程包括一套标准API、一个标准的接口集以及COM用于支持分布式计算的网络协议。而DCOM模型则是一套用于分布式环境中的COM对象，在DCOM环境中，位于一个网络上的COM对象能与位于另外一个网络上的COM对象进行通讯。一般咱们能够把COM看做是某种（软件）打包技术，即把它看做是使软件的不一样部分按照必定的面向对象的形式，组合成能够交互的过程和一组支持库。COM对象能够用C++、JAVA和VB等任意一种语言编写，而且能够以DLL或做为不一样过程工做的执行文件的形式来实现。使用COM对象的客户端，无需关心对象是用什么语言写的，也无需关心它是以DLL、仍是以另外的过程来执行的。从速度上来看，COM(动态链接库形式)与客户共同存在于同一内存空间,调用速度快,DCOM的速度只有COM的万分之一。 其实，DCOM自己就是COM的一种表现形式,可是因为你们听见COM通常就把它当成在本地执行的COM,而DCOM固然就是分布的COM,在网络上的另外一台计算机上执行。COM有两种存在形式,动态链接库和可执行程序,但DCOM必须是可执行程序。由于DCOM不可能在客户程序的内存空间运行,因此不能是动态链接库。从另外一方面来讲，DCOM为面向对象的分布式计算定义了跨平台服务（或抽象），其中包括链接组件、建立组件、组件的定位、激活组件的方法以及一个安全性框架。除了这些以外，DCOM仅仅使用了每个平台上都有的服务来完成多线程化和并发控制、用户界面、文件系统之间的相互做用、非DCOM网络的相互做用以及实际的安全性模块。

　　

DCOM有如下几个特色：

1. DCOM的结构特色。

　　DCOM是组件对象模型（COM）的进一步扩展。COM定义了组件和它们的客户之间互相做用的方式，它使得组件和客户端无需任何中介组件就能相互联系。当客户进程和组件位于不一样的机器时，DCOM仅仅只是用网络协议来代替本地进程之间的通信。不管是客户仍是组件都不会知道链接它们的线路比之前长了许多。

　　2.组件与复用。

　　就目前的应用状况来看，大多数的分布式应用都不是凭空产生的，现存的硬件结构、软件、组件以及工具须要集成起来，以便减小开发和扩展时间以及费用。DCOM可以直接且透明地改进现存的对COM组件和工具的投资。对各类各样组件需求的巨大市场使得将标准化的解决方案集成到一个普通的应用系统中成为可能。许多熟悉COM的开发者可以很轻易地将他们在COM方面的经验运用到基于DCOM的分布式应用中去。任何为分布式应用开发的组件都有可能在未来被复用。围绕组件模式来组织开发过程使得你可以在原有工做的基础上不断的提升新系统的功能并减小开发时间。基于COM和DCOM的设计能使你的组件在如今和未来都能被很好到使用。

 　　3.DCOM位置独立性。

　　你开始在一个真正的网络上设计一个分布式应用时，如下几个相互冲突的设计问题会很清楚地反映出来：(1)相互做用频繁的组件彼此间应该靠得更近些。(2)某些组件只能在特定的机器或位置上运行。(3)小组件增长了配置的灵活性，但它同时也增长了网络的拥塞。(4)大组件减小了网络的拥塞，但它同时也减小了配置的灵活性。若是咱们使用DCOM组件技术，这些设计上的限制将很容易解决，由于配置的细节并非在源码中说明的。DCOM使得组件的位置对你来讲彻底透明，不管它是位于客户的同一进程中仍是位于地球的另外一端。在任何状况下，客户链接组件和调用组件的方法的方式都是同样的。DCOM不只无需改变源码，并且无需从新编译程序。一个简单的再配置动做就可改变组件与组件之间相互链接的方式。 DCOM的位置独立性极大地简化了将应用组件分布化的任务，使其可以达到最合适的执行效果。例如，设想某个组件必须位于某台特定的机器上或某个特定的位置上，而且此应用有许多小组件，你能够经过将这些组件配置在同一个LAN上，或者同一台机器上，甚至同一个进程中来减小网络的负载。当应用是由比较少的大组件构成时，网络负载并不

是问题，此时你能够将组件放在速度快的机器上，而不用去过问这些机器到底在哪儿。 下图显示了相同的“有效性检查组件”在两种不一样状况下是如何分别配置的。一种状况是当“客户”机和“中间层”机器之间的带宽足够大时，它是怎样配置在客户机上的；另外一种状况是当客户进程经过比较慢的网络链接来访问

组件时，它又是怎样配置在服务器上的。

        有了DCOM的位置独立性，应用系统能够将互相关联的组件放到靠地比较近的机器上，甚至能够将它们放到同一台机器上或同一个进程中。即便是由大量的小组件来完成一个具备复杂逻辑结构的功能，它们之间仍然可以有效地相互做用。当组件在客户机上运行时，将用户界面和有效性检查放在客户端或离客户端比较近的机器上会更有意义；集中的数据库事务应该将服务器靠近数据库。

 　　4.DCOM的语言无关性

在设计和实现分布式应用系统时，一个广泛的问题就是为开发一个特定的组件而选择语言以及工具的问题。语言选择是一个典型的在开发费用、可获得的技术支持以及执行性能之间的折衷。做为COM的扩展，DCOM具备语言独立性。任何语言均可以用来建立COM组件，而且这些组件可使用更多的语言和工具。Java，MicrosoftVisualC++，MicrosoftVisualBasic，Delphi，PowerBuilder和MicroFocusCOBOL都可以和DCOM很好地相互做用。 由于DCOM具备语言独立性，应用系统开发人员能够选择他们最熟悉的语言和工具来进行开发。语言独立性还使得一些原型组件开始时能够用诸如VisualBasic这样的高级语言来开发，而在之后用一种不一样的语言，例如VisualC++和Java来从新实现，而这种语言可以更好地支持诸如DCOM的自由线程／多线程以及线程共用这些先进特性。

 　　5.DCOM的链接管理

网络链接自己就比同一台机器中的链接更脆弱。当一个客户再也不有效，特别是当出现网络或硬件错误时，分布式应用中的组件须要被加以注意。DCOM经过给每一个组件保持一个索引计数来管理对组件的链接问题，这些组件有多是仅仅只链接到一个客户上，也有可能被多个客户所共享。当一个

客户和一个组件创建链接时，DCOM就增长此组件的索引计数。同理，当客户释放链接时，DCOM就减小此组件的索引计数。若是索引计数为零，组件就能够被释放了。 DCOM使用有效的地址合法性检查（pinging）协议来检查客户进程是否仍然是活跃的。客户机周期性地发送消息，当通过大于等于三次ping周期而组件没有收到pinging消息时，DCOM就认为这个链接中断了。一旦链接中断，DCOM就减小索引计数，当索引计数为零时就释放组件。从组件的这一点看来，不管是客户进程本身中断链接这种良性状况，仍是网络或者客户机崩溃这种致命状况，都被同一种索引计数机制处理。 在不少种状况下，组件和它的客户进程之间的信息流是没有方向性的：组件须要在客户端进行某些初始化操做，例如一个长进程的结束，用户所观看数据的更新，或者诸如电视以及多用户游戏这些协做环境中的下一条信息等。许多协议使得完成这种对称性的通信十分困难。使用DCOM，任何组件都既可使功能的提供者，有能是功能的使用者。通信的两个方向都用同一种机制来管理使得完成对等通信和客户机／服务器之间的相互做用同样容易。 DCOM提供了一个对应用彻底透明的分布式垃圾收集机制。DCOM是一个天生的对称性网络协议和编程模型。它不只

提供传统的单向的客户机－服务器之间的相互做用方式，还提供了客户机和服务器以及对等进程之间的丰富的交谈式的通信方式。

 　　6.DCOM的可扩展性

提供传统的单向的客户机－服务器之间的相互做用方式，还提供了客户机和服务器以及对等进程之间的丰富的交谈式的通信方式。 6.DCOM的可扩展性 分布式应用的一个重要因素是：它的处理能力可以随着用户的数量、数据量所需性能的提升而增长。当需求比较小时，应用系统就比较小而速度快，而且它要可以在不牺牲性能和可靠性的前提下处理附加的需求。DCOM提供了许多特性来加强你的应用的可扩展性。

　　7.对称的多进程处理（SMP）

 　　DCOM提升了WindowsNT对于多进程处理的支持。对于使用自由线程模式的应用，DCOM使用一个线程队列来处理新来的请求。在多处理器机上，线程队列是由可利用的处理器的数量来决定的：太多的线程会致使常常性的上下文切换，而太少的线程又会使处理器处于空闲状态。DCOM只提供一个手工编码的线程管理器，从而使开发者从线程的细节中解脱出来并得到最好的性能。DCOM经过使用WindowsNT对于对称性多进程处理的高级支持功能就能轻易地将应用从一个单处理机扩展到庞大的多处理机系统上去。

 　　8.灵活的配置

　　当负载增长时，即便你的预算支持你买一台最快的多处理机，它也有可能不能适应需求。DCOM的位置独立性提供了一个简单而便宜的方法来提升扩展性，那就是将分布性的组件放到其它的机器上。 对于无状态或无需和其它组件共享状态的组件来讲，再配置是再容易不过的事了。对于这样一些组件来讲，能够在不一样的机器上运行它们的多个复本。用户负载能够被平等地分配到各个机器中去，甚至能够考虑到机器的处理能力以及当时负载这些因素来进行分配。使用DCOM，能够很容易地改变客户进程同组件以及组件之间的链接方式。同一组件无需道别的改动甚至无需从新编译就能够被动态地从新配置。全部必须作的工做只是更新登记、文件系统以及所涉及的组件所在的数据库而已。 举个例子来讲：一个组织在多个地方有办公室，例如纽约、伦敦、旧金山和华盛顿等，它能够将组件安装到服务器上。两百个用户同时在能达到预期的性能的前提下访问五十个组件。当新的事务应用发送给用户时，应用系统中同时在使用一些现存的以及新的组件，服务器的负载增加到六百个用户，同时事务组件的数目增长到七十。有了这些附加的用户和组件后，峰值时间的响应时间变得不能接受。管理员将其中的三十个组件单独配置在另外一台服务器上，而将二十个

组件单独放在原来的服务器上，同时剩下的二十个组件同时在两台服务器上运行。 绝大多数现实的应用系统都有一个或多个涉及到大多数操做的关键性组件。这种组件有数据库组件或者事务规则组件，它们必须被串行地执行以保证“先来的先服务”这一策略被执行。这些组件不能被复用，由于它们的惟一任务就是为应用系统的全部用户提供一个单一的时间同步点。为了加强分布式应用系统的总体功能，必须将这些瓶颈组件放到一个专门的、功能强大的服务器上去。DCOM可使你早在设计阶段就将这些关键性组件分开，最初将多个组件放在一台功能简单的机器上，之后再把关键性的组件放到专门的机器上去。这一过程无需组件的再设计，甚至无需从新编译。 DCOM对于这些决定性的瓶颈组件的处理使得整个任务可以迅速执行。这些瓶颈组件每每是过程执行序列的一部分，例如电子交易系统中的买卖命令，它们必须按照接收的顺序执行（先来的先被服务）。对于此问题的一个解决方法是将任务分红许多小的组件，并将这些组件配置到不一样的机器上。这种效果相似于当今微处理器中的管道pipelining技术：第一个请求来了，第一个组件执行（例如一致性检查），而后将请求传递给下一个组件（例如，多是更新数据库）。一旦第一个组件将一条请求传递给下一个组件，它就准备执

行下一条请求。实际上有两台机器在并行的执行多个请求，而且可以保证按照请求来到的顺序执行。也能够在同一台机器上使用DCOM来达到一样的效果：多个组件在不一样的线程或者不一样的进程中执行。这种方法在之后能够简化扩展，咱们能够将线程分布到一个带多处理器的机器上，或者能够将进程配置到不一样的机器上。