DCOM概述
Microsoft的分布式COM（DCOM）扩展了组件对象模型技术（COM）,使其能够支持在局域网、广域网甚至Internet上不同计算机的对象之间的通讯。使用DCOM，你的应用程序就可以在位置上达到分布性，从而满足你的客户和应用的需求。
因为DCOM是世界上领先的组件技术COM的无缝扩展，所以你可以将你现在对基于COM的应用、组件、工具以及知识转移到标准化的分布式计算领域中来。当你在做分布式计算时，DCOM处理网络协议的低层次的细节问题，从而使你能够集中精力解决用户所要求的问题。
将应用分布化并不是问题的结束。分布式应用引入了一个全新的设计和扩展概念，它增加了软件产品的复杂性，但是带来了可观的回报。某些应用本身就带有分布性，例如多人对战游戏、聊天程序以及远程会议系统等等。因此，一种健壮的分布式计算框架所带来的好处是不言自明的。很多其它的应用也是分布式的，即它至少有两个组件运行在不同的计算机上，但是因为它不是为分布性应用而设计的，所以它们的规模和可扩展性就有很大的局限性。任何的工作流或群件应用程序，大多数的客户机/服务器应用程序一些桌面办公系统本质上都控制着它们的用户的通讯和协作。将这些系统作为分布式系统并能够在正确的地方运行正确的组件会给用户带来好处，并且使人们对网络和计算机资源的运用更加充满信心。设计应用程序时考虑到分布性，能通过在客户端运行组件使应用适用于具有不同性能的不同的客户。
设计应用时考虑分布性能够使系统在扩展上具有很高的灵活性。
分布式应用与它们的非分布式版本比起来具有更大的可扩展性。如果整个复杂应用的逻辑结构可以用一个简单的模型来表示，那么仅仅只有一种方法来增加系统的工作效率：用更快的机器，而无需的应用本身进行调整。虽然现在的服务器和操作系统升级很快，但是买一个同样性能的机器还是比将服务器的速度升级为原来的两倍所花的钱少。有了一个设计适当的分布式应用系统，一台功能不怎么强大的服务器就能够运行所有的组件。当负载增加时，可以将一些组件扩展到价格便宜的附加的机器上。
DCOM的结构
DCOM是组件对象模型（COM）的进一步扩展。COM定义了组件和它们的客户之间互相作用的方式。它使得组件和客户端无需任何中介组件就能相互联系。客户进程直接调用组件中的方法。图1说明了组件对象模型的表示法：
图1 同一进程中的COM组件
在现在的操作系统中，各进程之间是相互屏蔽的。当一个客户进程需要和另一个进程中的组件通讯时，它不能直接调用该进程，而需要遵循操作系统对进程间通讯所做的规定。COM使得这种通讯能够以一种完全透明的方式进行：它截取从客户进程来的调用并将其传送到另一进程中的组件。图2表明了COM/DCOM运行库是怎样提供客户进程和组件之间的联系的。
图2 不同进程中的COM组件
当客户进程和组件位于不同的机器时，DCOM仅仅只是用网络协议来代替本地进程之间的通讯。无论是客户还是组件都不会知道连接它们的线路比以前长了许多。
图3显示了DCOM的整体结构：COM运行库向客户和组件提供了面向对象的服务，并且使用RPC和安全机制产生符合DCOM线路协议标准的标准网络包。
图3 DCOM: 不同机器上的COM组件
大多数分布式应用都不是凭空产生的。现存的硬件结构、软件、组件以及工具需要集成起来，以便减少开发和扩展时间以及费用。DCOM能够直接且透明地改进现存的对COM组件和工具的投资。对各种各样组件需求的巨大市场使得将标准化的解决方案集成到一个普通的应用系统中成为可能。许多熟悉COM的开发者能够很轻易地将他们在COM方面的经验运用到基于DCOM的分布式应用中去。
任何为分布式应用开发的组件都有可能在将来被复用。围绕组件模式来组织开发过程使得你能够在原有工作的基础上不断的提高新系统的功能并减少开发时间。基于COM和DCOM的设计能使你的组件在现在和将来都能被很好到使用。
当你开始在一个真正的网络上设计一个分布式应用时，以下几个相互冲突的设计问题会很清楚地反映出来：
相互作用频繁的组件彼此间应该靠得更近些。 某些组件只能在特定的机器或位置上运行。 小组件增加了配置的灵活性，但它同时也增加了网络的拥塞。 大组件减少了网络的拥塞，但它同时也减少了配置的灵活性。当你使用DCOM时，这些设计上的限制将很容易解决，因为配置的细节并不是在源码中说明的。DCOM使得组件的位置对你来说完全透明，无论它是位于客户的同一进程中或是在地球的另一端。在任何情况下，客户连接组件和调用组件的方法的方式都是一样的。DCOM不仅无需改变源码，而且无需重新编译程序。一个简单的再配置动作就改变了组件组件之间相互连接的方式。
DCOM的位置独立性极大地简化了将应用组件分布化的任务，使其能够达到最合适的执行效果。例如，设想某个组件必需位于某台特定的机器上或某个特定的位置，并且此应用有许多小组件，你可以通过将这些组件配置在同一个LAN上，或者同一台机器上，甚至同一个进程中来减少网络的负载。当应用是由比较少的大组件构成时，网络负载并不是问题，此时你可以将组件放在速度快的机器上，而不用去管这些机器到底在哪儿。
图4显示了相同的“有效性检查组件”在两种不同情况下是如何分别配置的。一种情况是当“客户”机和“中间层”机器之间的带宽足够大时，它是怎样配置在客户机上的；另一种情况是当客户进程通过比较慢的网络连接来访问组件时，它又是怎样配置在服务器上的。
图4 位置独立性
有了DCOM的位置独立性，应用系统可以将互相关联的组件放到靠地比较近的机器上，甚至可以将它们放到同一台机器上或同一个进程中。即使是由大量的小组件来完成一个具有复杂逻辑结构的功能，它们之间仍然能够有效到相互作用。当组件在客户机上运行时，将用户界面和有效性检查放在客户端或离客户端比较近的机器上会更有意义；集中的数据库事务应该将服务器靠近数据库。
在设计和实现分布式应用系统时，一个普遍的问题就是为开发一个特定的组件而选择语言以及工具的问题。语言选择是一个典型的在开发费用、可得到的技术支持以及执行性能之间的折衷。作为COM的扩展，DCOM DCO具有语言独立性。任何语言都可以用来创建COM组件，并且这些组件可以使用更多的语言和工具。Java，Microsoft Visual C++，Microsoft Visual Basic，Delphi，PowerBuilder和Micro Focus COBOL都能够和DCOM很好地相互作用。
因为DCOM具有语言独立性，应用系统开发人员可以选择他们最熟悉的语言和工具来进行开发。语言独立性还使得一些原型组件开始时可以用诸如Visual Basic这样的高级语言来开发，而在以后用一种不同的语言，例如Visual C++和Java来重新实现，而这种语言能够更好地支持诸如DCOM的自由线程／多线程以及线程共用这些先进特性。
网络连接本身就比同一台机器中的连接更脆弱。当一个客户不再有效，特别是当出现网络或硬件错误时，分布式应用中的组件需要被加以注意。
DCOM通过给每个组件保持一个索引计数来管理对组件的连接问题，这些组件有可能是仅仅只连到一个客户上，也有可能被多个客户所共享。当一个客户和一个组件建立连接时，DCOM就增加此组件的索引计数。同理，当客户释放连接时，DCOM就减少此组件的索引计数。如果索引计数为零，组件就可以被释放了。
DCOM使用有效的地址合法性检查（pinging）协议来检查客户进程是否仍然是活跃的。客户机周期性地发送消息，当经过大于等于三次ping周期而组件没有收到ping消息时，DCOM就认为这个连接中断了。一旦连接中断，DCOM就减少索引计数，当索引计数为零时就释放组件。从组件的这一点看来，无论是客户进程自己中断连接这种良性情况，还是网络或者客户机崩溃这种致命情况，都被同一种索引计数机制处理。
在很多种情况下，组件和它的客户进程之间的信息流是没有方向性的：组件需要在客户端进行某些初始化操作，例如一个长进程的结束，用户所观看数据的更新，或者诸如电视以及多用户游戏这些协作环境中的下一条信息等。许多协议使得完成这种对称性的通迅十分困难。使用DCOM，任何组件都既可以使功能的提供者，有能是功能的使用者。通迅的两个方向都用同一种机制来管理使得完成对等通迅和客户机／服务器之间的相互作用一样容易。
DCOM提供了一个对应用完全透明的分布式垃圾收集机制。DCOM是一个天生的对称性网络协议和编程模型。它不仅提供传统的单向的客户机－服务器之间的相互作用方式，还提供了客户机和服务器以及对等进程之间的丰富的交谈式的通迅方式。
分布式应用的一个重要因素是它的处理能力能够随着用户的数量、数据量所需性能的提高而增加。当需求比较小时，应用系统就比较小而速度快，并且它要能够在不牺牲性能和可靠性的前提下处理附加的需求。DCOM提供了许多特性来增强你的应用的可扩展性。
对称的多进程处理（SMP）
DCOM提高了Windows NT对于多进程处理的支持。对于使用自由线程模式的应用，DCOM使用一个线程队列来处理新来的请求。在多处理器机上，线程队列是由可利用的处理器的数量来决定的：太多的线程会导致经常性的上下文切换，而太少的线程又会使处理器处于空闲状态。DCOM只提供一个手工编码的线程管理器，从而使开发者从线程的细节中解脱出来并获得最好的性能。
DCOM通过使用Windows NT对于对称性多进程处理的高级支持功能就能轻易地将应用从一个单处理机扩展到庞大的多处理机系统上去。
当负载增加时，即使你的预算支持你买一台最快的多处理机，它也有可能不能适应需求。DCOM的位置独立性提供了一个简单而便宜的方法来提高扩展性，那就是将分布性的组件放到其它的机器上。
对于无状态或无需和其它组件共享状态的组件来说，再配置是再容易不过的事了。对于这样一些组件来说，可以在不同的机器上运行它们的多个复本。用户负载可以被平等地分配到各个机器中去，甚至可以考虑到机器的处理能力以及当时负载这些因素来进行分配。使用DCOM，可以很容易地改变客户进程同组件以及组件之间的连接方式。同一组件无需作别的改动甚至无需重新编译就可以被动态地重新配置。所有必须做的工作只是更新登记、文件系统以及所涉及的组件所在的数据库而已。
例子：一个组织在多个地方有办工室，例如纽约、伦敦、旧金山和华盛顿等，它可以将组件安装到服务器上。两百个用户同时在能达到预期的性能的前提下访问五十个组件。当新的事务应用发送给用户时，应用系统中同时在使用一些现存的以及新的组件，服务器的负载增长到六百个用户，同时事务组件的数目增加到七十。有了这些附加的用户和组件后，峰值时间的响应时间变得不能接受。管理员将其中的三十个组件单独配置在另一台服务器上，而将二十个组件单独放在原来的服务器上，同时剩下的二十个组件同时在两台服务器上运行。
图5 并行配置
绝大多数现实的应用系统都有一个或多个涉及到大多数操作的关键性组件。这种组件有数据库组件或者事务规则组件，它们必须被串行地执行以保证“先来的先服务”这一策略被执行。这些组件不能被复用，因为它们的唯一任务就是为应用系统的所有用户提供一个单一的时间同步点。为了增强分步式应用系统的整体功能，必须将这些瓶颈组件放到一个专门的、功能强大的服务器上去。DCOM可以使你早在设计阶段就将这些关键性组件分开，最初将多个组件放在一台功能简单的机器上，以后再把关键性的组件放到专门的机器上去。这一过程无需组件的再设计，甚至无需重新编译。
图6 关键性组件的分离
DCOM对于这些决定性的瓶颈组件的处理使得整个任务能够迅速执行。这些瓶颈组件往往是过程执行序列的一部分，例如电子交易系统中的买卖命令，它们必须按照接收的顺序执行（先来的先被服务）。对于此问题的一个解决方法是将任务分成许多小的组件，并将这些组件配置到不同的机器上。这种效果类似于当今微处理器中的管道pipelining技术：第一个请求来了，第一个组件执行（例如一致性检查），然后将请求传递给下一个组件（例如，可能是更新数据库）。一旦第一个组件将一条请求传递给下一个组件，它就准备执行下一条请求。实际上有两台机器在并行的执行多个请求，并且能够保证按照请求来到的顺序执行。也可以在同一台机器上使用DCOM来达到同样的效果：多个组件在不同的线程或者不同的进程中执行。这种方法在以后可以简化扩展，我们可以将线程分布到一个带多处理器的机器上，或者可以将进程配置到不同的机器上。
图7 Pipelining
DCOM的位置独立性编程模型使得随着应用增加而改变配置设计变得容易了。最初，一个功能简单的服务器就可以容纳所有的组件。随着需求的增加，其它的机器被添加进来，而组件能够不做任何代码上的改动就被分步到这些机器中去。
