DCOM（分布式组件对象模型,分布式组件对象模式）是一系列微软的概念和程序接口，利用这个接口，客户端程序对象能够请求来自网络中另一台计算机上的服务器程序对象。DCOM基于组件对象模型（COM），COM提供了一套允许同一台计算机上的客户端和服务器之间进行通信的接口（运行在Windows 95或者其后的版本上）。

Microsoft Distributed Component Object Model（DCOM）是Component Object Model（COM）的扩展，它支持不同的两台机器上的组件间的通信，而且不论它们是运行在局域网、广域网、还是Internet上。借助DCOM你的应用程序将能够任意进行空间分布。

由于DCOM是COM这个组件技术的无缝升级，所以你能够从你现有的有关COM的知识中获益，你的以前在COM中开发的应用程序、组件、工具都可以移入分布式的环境中。DCOM将为你屏蔽底层网络协议的细节，你只需要集中精力于你的应用。

例如，你可以为一个网站创建应用页面，其中包括了一段能够在网络中另一台更加专业的服务器电脑上处理（在将它们发送到发出请求的用户之前）的脚本或者程序。使用DCOM接口，网络服务器站点程序（现在以客户端对象方式发出动作）就能够将一个远程程序调用（RPC）发送到一个专门的服务器对象，它可以通过必要的处理，并给站点返回一个结果。结果将发送到网页浏览器上。

DCOM还可以工作在位于企业内部或者除了公共因特网之外的其他网络中。它使用TCP/IP和超文本传输协议。DCOM是作为Windows操作系统中的一部分集成的。DCOM将很快在所有的主流unix平台和IBM的大型服务器产品中出现。DCOM替代了OLE远程自动控制。

在提供一系列分布式范围方面，DCOM通常与通用对象请求代理体系结构（CORBA）相提并论。DCOM是微软给程序和数据对象传输的网络范围的环境。CORBA则是在对象管理组织（OMG）的帮助下，由信息技术行业的其他商家提供赞助的。

Microsoft的分布式COM（DCOM）扩展了组件对象模型技术（COM）,使其能够支持在局域网、广域网甚至Internet上不同计算机的对象之间的通讯。使用DCOM，你的应用程序就可以在位置上达到分布性，从而满足你的客户和应用的需求。

因为DCOM是世界上领先的组件技术COM的无缝扩展，所以你可以将你现在对基于COM的应用、组件、工具以及知识转移到标准化的分布式计算领域中来。当你在做分布式计算时，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方面的经验运用到基于DCOM的分布式应用中去。

任何为分布式应用开发的组件都有可能在将来被复用。围绕组件模式来组织开发过程使得你能够在原有工作的基础上不断的提高新系统的功能并减少开发时间。基于COM和DCOM的设计能使你的组件在现在和将来都能被很好到使用。

当你开始在一个真正的网络上设计一个分布式应用时，以下几个相互冲突的设计问题会很清楚地反映出来：

相互作用频繁的组件彼此间应该靠得更近些。

某些组件只能在特定的机器或位置上运行。

小组件增加了配置的灵活性，但它同时也增加了网络的拥塞。

大组件减少了网络的拥塞，但它同时也减少了配置的灵活性。

当你使用DCOM时，这些设计上的限制将很容易解决，因为配置的细节并不是在源码中说明的。DCOM使得组件的位置对你来说完全透明，无论它是位于客户的同一进程中或是在地球的另一端。在任何情况下，客户连接组件和调用组件的方法的方式都是一样的。DCOM不仅无需改变源码，而且无需重新编译程序。一个简单的再配置动作就改变了组件组件之间相互连接的方式。

DCOM的位置独立性极大地简化了将应用组件分布化的任务，使其能够达到最合适的执行效果。例如，设想某个组件必需位于某台特定的机器上或某个特定的位置，并且此应用有许多小组件，你可以通过将这些组件配置在同一个LAN上，或者同一台机器上，甚至同一个进程中来减少网络的负载。当应用是由比较少的大组件构成时，网络负载并不是问题，此时你可以将组件放在速度快的机器上，而不用去管这些机器到底在哪儿。

图4显示了相同的“有效性检查组件”在两种不同情况下是如何分别配置的。一种情况是当“客户”机和“中间层”机器之间的带宽足够大时，它是怎样配置在客户机上的；另一种情况是当客户进程通过比较慢的网络连接来访问组件时，它又是怎样配置在服务器上的。

图4 位置独立性

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

在设计和实现分布式应用系统时，一个普遍的问题就是为开发一个特定的组件而选择语言以及工具的问题。语言选择是一个典型的在开发费用、可得到的技术支持以及执行性能之间的折衷。作为COM的扩展，DCOM　DCO具有语言独立性。任何语言都可以用来创建COM组件，并且这些组件可以使用更多的语言和工具。Java，微软 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的位置独立性编程模型使得随着应用增加而改变配置设计变得容易了。最初，一个功能简单的服务器就可以容纳所有的组件。随着需求的增加，其它的机器被添加进来，而组件能够不做任何代码上的改动就被分步到这些机器中去。

功能的发展：版本化

除了随着用户的数量以及事务的数量而扩展规模外，当新的特性加入时应用系统也需要扩展规模。随着时间的推移，新的任务被添加进来，原有的任务被更新。传统的做法是或者客户进程和组件都需要同时被更新，或者旧的组件必须被保留直到所有的客户进程被更新，当大量的地理上分布的站点和用户在使用系统时，这就成为一个非常费力的管理问题。

DCOM为组件和客户进程提供了灵活的扩展机制。使用COM和DCOM，客户进程能够动态地查询组件的机能。一个COM组件不是将其机能表现为一个简单、统一的方法和属性组，而是对于不同的客户进程表现为不同的形式。使用特定特性的客户进程只需要访问它所需要使用的方法和属性。客户进程也能够同时使用一个组件的多个特性。当新的特性加入组件时，它不会影响不涉及这些特性的老的客户进程。

用这种方法来组织组件，使得我们能够有一种新的方法来发展组件功能：最初的组件表现为诸如COM界面的一套核心特性，这些特性是每个客户进程都需要使用的。当组件需要新的特性时，大多数（甚至是全部）的界面仍然是必须的，我们根本无须更改原来的界面就可以将新的功能和属性放到附加的界面中去。老的用户进程就好像什么事也没发生似的继续访问核心界面。新的客户进程既可以测试新的界面是否存在以便能使用它，也可以仍然只使用原来的界面。

图8 健壮的版本发展

因为在DCOM编程模型中机能被分组放入界面中，你可以设计使用老的服务器程序的新的客户程序，也可以设计使用老的客户程序的新的服务器程序，或者将这些混合起来以便能够适合你的需求和编程资源。使用传统的对象模型时，那怕是对一个方法的细微改动都可能在根本上改变客户和组件之间的协议。在一些模型中，可以将方法加到方法队列的队尾，但是却不能在老的组件上测试新的方法。从网络发展的前景看来，这些事情将会变得越来越复杂：编码以及其它的一些功能典型地依赖于方法和参数的顺序。增加或改动方法和参数也会显著地改变网络协议。DCOM为对象模式和网络协议设计了一个简单、优雅和统一的方法来解决这些问题。

如果最初的执行性能不能让人满意的话，可扩展性就不会带来太多好处了。经常考虑到更多更好的硬件会使得应用向下发展是非常有益的，但是这些需求是怎样的呢？这些尖端扩展特性是否有用呢？是否对从COBOL到汇编这每一种语言的支持会危害到系统的执行性能呢？使组件能够在地球的另一面运行的能力是否妨碍了当它和客户在同一个进程中时的执行性能呢？

在COM和DCOM中，客户并不能自己看到服务器，但是除非是在必要的情况下，否则客户进程决不会被系统组件将自己同服务器分开。这种透明性是通过一个简单的思想来实现的：客户进程同组件交互的唯一方式就是通过方法调用。客户进程从一个简单的方法地址表（一个“vtable”）中得到这些方法的地址。当客户进程想要调用一个组件中的某个方法时，它先得到方法的地址，然后调用它。在COM和DCOM模型中调用一个传统的C或汇编函数的唯一开支就是对方法地址的简单查询。如果组件是和客户运行在同一个线程中的过程中组件，那么无需调用任何COM或系统代码就可以直接找到方法的地址，COM仅仅只定义了找到方法地址表的标准。

当用户和组件不是那么靠近──在另一个线程中，在另一个程序中或者在地球另一面的一台机器中时情况又是怎样的呢？COM将它的远程过程调用（RPC）框架代码放到vtable中，然后将每个方法调用打包放到一个标准的缓冲器结构中，这个缓冲器结构将被发送给组件，组件打开包并且重新运行最初的方法调用。从这方面来说，COM提供了一个面向对象的RPC机制。

这种RPC机制的速度有多快呢？下面是需要考虑的不同的性能尺度：

一个“空”方法调用有多快？

“真正的”需要发送和接收数据的方法调用有多快？

在网络上转一圈有多快？

下表显示了COM和DCOM的一些真实的执行性能参数，使我们能够对DCOM和其它的协议的相关的执行性能有一定的了解。

开始两列表示一个“空”方法调用（发送和接收一个4字节长的整数）。最后两列可以认为是一个“真正的”COM方法调用（50字节长的参数）。

此表显示了进程中组件是怎样得到零开支的执行性能的（第一排和第二排）。

进程之间的方法调用（第三排和第四排）需要将参数存入缓冲器并将其发送给其它的进程。在一个标准的桌面办公系统硬件中，每秒钟大约可以执行2000个方法调用，这可以满足大多数的执行性能需求。所有的本地调用是完全由处理器速度（一定程度上由存储器容量）决定的，并且能够很好地适用于多处理器型机器。

远程调用（第五排和第六排）主要受限于网络速度，同时可以看出DCOM的开支大约比TCP/IP多了35%（TCP/IP的循环时间是两秒）。

微软很快会提供许多平台上的正式的DCOM性能参数，它将显示出DCOM与客户数量以及服务器中处理器数量相关的扩展能力。

分布式应用利用了网络的优点将组件结合到一起。理论上来说，DCOM将组件在不同的机器上运行这一事实隐藏起来。实际上，应用必须考虑到网络连接带来的两个主要限制：

带宽：传递给方法调用的参数的大小直接影响着完成方法调用的时间。

潜在问题：物理距离以及相关的网络器件（例如路由器合传输线）甚至能使最小的数据包都被显著地延迟。

DCOM怎样帮助应用解决这些局限呢？DCOM自己将网络循环时间最小化，使得避免网络中潜在的拥塞成为可能。DCOM选择了TCP/IP协议套件中的无连接UDP协议作为自己的传输协议。协议的无连接特性使得DCOM能够将许多低级别的确认包和实际的数据以及地址合法性检查（pinging）信息混合起来从而改善了性能。即使是运行在面向连接的协议上，DCOM也优于传统的面向特殊应用的协议。

大多数的应用级别的协议需要某种从头到尾地管理。当客户机出现了严重的硬件故障或者客户和组件之间的网络连接中断已经超过一定时间时，应该及时通知组件。

解决这一问题的一个普遍方法是个一段时间（Pinging）发送保持活跃keep-alive消息。如果服务器在一定的时间间隔内没有收到一条ping消息，它就断定客户进程“死掉了”。

DCOM对每台机器使用一个keep-alive消息。即使一台客户机使用了某一台服务器上的100个组件，仅仅只要一条ping消息就能使所有这些客户连接保持活跃状态。为了将所有的ping消息组合起来，DCOM使用delta pinging机制来将这些ping消息的大小最小化。对于这100个连接，它并不是发送100个客户标识符，而是创造了一个可变标识符来重复代表这100个引用。当引用集改变时，仅仅只是两套引用的相交的部分被互相交换。最终，DCOM将所有ping消息转化为正常消息。只有当对于服务器来说，某台客户机完全是空闲的时，它才定时发送ping消息（每隔两分钟一次）。

图9 组合的生命期管理

COM允许多个应用（甚至来自不同的卖主）共享一个简单而且优化的生命期管理和网络错误检测协议，这样可以显著地减少带宽。如果在一台服务器上运行使用100个不同的传统协议的100个不同的应用，对于每一个客户连接上的每一个应用来说，服务器都要接收一条ping消息。只有这些协议当在它们的pinging策略上相互合作时，整个网络的开销才有可能减少。而DCOM在任意的基于DCOM的协议中自动地提供了这种协作。

设计分布式应用的一个普遍问题是减少不同机器上组件之间在网络上的过度的来回绕圈数。

在Internet上，每一次网络绕圈就会引入1秒甚至更多的延迟。即使在速度快的局域网上，旋程时间也是以微秒来计算的──它超过了本地操作所需时间的量级。

减少网络绕圈数的一个普遍的方法是将多个方法调用捆绑起来。DCOM将这种技术扩展使用，用来解决诸如连接一个对象或者创造一个对象查询对象的机能的任务中。这种技术对于一般组件的不足之处是它在本地和远程情况下的编程模型差别太大。

例子：一个数据库组件提供了一个能够分行或多行显示结果的方法。在本地的情况下，开发者只需使用这个方法将结果一列一列地加入列表框即可。而在远程的情况下，每列出一行就会引起一定的网络旋程。使用批量方式的方法需要开发者分配一个能容纳查询出的所有列的缓冲器，然后在一次调用将其取回并将其一列一列地加入到列表框中。因为编程模型变化很大，开发者需要对设计作大的改动以便应用能够在分布式环境中有效地工作。

DCOM使得组件开发者能够轻易地执行批量技术而无需客户端也使用批量形式的API。DCOM的marshling机制使得组件可以将代码加到客户端，这叫作“代理对象”，它可以拦截多个方法调用并将其捆绑到一个远程调用中去。

例子：因为应用系统的逻辑结构的需要（列表框API的要求），上面例子的开发者仍然需要一个一个地列举方法。然而，为了列举查询结果的第一次调用应用中特殊的代理对象，它取得了所有列（或者一批列）并将其CPU缓存到代理对象中。后来的调用就自接从这个缓存中发出，就避免了网络旋程。开发者仍然使用一个简单的编程模型，而整个应用却得到了优化。

DCOM同样允许从一个组件到另一个组件的有效的指引。如果一个组件保存了到另一台机器上的一个组件的索引，它可以将其传递给在第三方机器上运行的一个客户进程（假设此客户进程正在使用另一台机器上运行的另一个组件）。客户进程使用此索引就可以直接和第二个组件通讯。DCOM缩短了这种索引，并且使得第一个组件和机器可以完全从这个过程中脱离出来。这使得能够提供索引的传统的目录服务适用于远程组件的范围。

例1：一个棋类应用系统能够使正在等待对手的用户将自己登录到一个棋类目录服务中。其它的用户可以浏览并查询正在等待对手的用户的列表。当一个用户选择了自己的对手后，棋类目录服务系统将对手的客户组件索引返回给该用户。DCOM自动连接两个用户，目录服务系统无需涉及任何其它的事务处理过程。

例2：一个“经纪人”组件监控着运行着同一个组件的二十台服务器，它监测服务器的负载量和服务器的加入和删除情况。当一个客户需要使用该组件时，它连接到“经纪人”组件，此组件返回负载最轻的服务器上的一个组件的索引。DCOM自动连接客户和服务器，此时“经纪人”组件和以后的过程就无关了。

如果需要的话，DCOM甚至允许将组件插入任意一个传统的协议中，这个协议可以使用不在DCOM机能范围内的方法。组件可以使用传统的配置方法将任意的代理对象放到客户进程中，此进程能够使用任何协议将信息传回组件。

例1：一个服务器端组件可以使用一个ODBC连接来和一个SQL Server数据库通讯。当客户取得对象后，客户机直接和SQL Server数据库（使用ODBC）比使用DCOM和服务器通讯，同时服务器和SQL Server数据库通讯更有效。在DCOM的传统配置情况下，数据库组件能够将自己复制到客户机上，并将自己同SQL Server相连接，而此时客户并没有意识到自己已经不再和服务器上的数据库组件相连了，而是和该组件的一个本地复本连接着。

例2：一个商业系统需要两种通讯机制，一种是从客户端到中央系统的一条安全而经过鉴定的通道，它用来发出和撤消命令；另一种是一条分布式的通道，它用来将命令信息同时发送给连接在系统上的客户。使用DCOM的安全而同步的连接方式可以简单而有效地操作客户机/服务器之间的通道，同时广播通道需要一种更为尖端的机制，它使用多点广播技术以便容纳大量的侦听者。DCOM允许将传统的协议（“可靠的广播协议”）无缝地插入到应用系统的体系结构中：一个数据接收端组件能够将此协议封装起来，并使其对客户和服务器完全透明。当用户数量少安装量小时，标准的DCOM点到点协议就足够了；而对于有很多用户的站点来说，就需要使用高级的广播协议。DCOM将来会提供一个标准的多通道广播传输协议，它能够无缝地移植到应用系统中。

使用网络来将应用系统分布化是一个挑战，这不仅是因为带宽的物理限制以及一些潜在的问题，而且也由于它产生一些诸如关系到客户间、组件间以及客户和组件之间的安全问题。因为现在的许多操作可以被网络中的任何一个人访问，所以对这些操作的访问应该被限制在一个高级别上。

如果分布式开发平台没有提供安全支持，那么每一个分布式应用就必需完成自己的安全机制。一种典型的方法是用某种登录的方法要求用户通过用户名及密码的检测，这些一般来说都是被加密了的。应用系统将通过用户数据库或者有关目录来确认以上用户身份，并返回动态的标识符以便用户以后用来进行方法调用。以后每次涉及到调用有安全检查的方法时，用户都需要通过这种安全认证。每个应用系统都要存储和管理许多用户名和密码，防止用户进行未授权的访问，管理密码的改动以及处理在网络上传递密码而带来的危险。

因此glue必需提供一个安全性框架来确切地区分不同的用户或者不同组的用户以便系统或应用有办法知道谁将对某组件进行操作。DCOM使用了Windows NT提供的扩展的安全框架。Windows NT提供了一套稳固的内建式安全模块，它用来提供从传统的信用领域的安全模式到非集中管理模式的复杂的身份确认和鉴定机制，极大地扩展了公钥式安全机制。安全性框架的中心部分是一个用户目录，它存储着用来确认用户凭据（用户名、密码、公钥）的必要信息。大多数并非基于Windows NT平台的系统提供了相似或相同的扩展机制，我们可以使用这种机制而不用管此平台上用的是哪种安全模块。大多数DCOM的unix版本提供了同Windows NT平台相容的安全模块。

DCOM无需在客户端和组件上进行任何专门为安全性而做的编码和设计工作就可以为分布式应用系统提供安全性保障。就象DCOM编程模型屏蔽了组件的位置一样，它也屏蔽了组件的安全性需求。在无需考虑安全性的单机环境下工作的二进制代码能够在分布式环境下以一种安全的方式工作。

DCOM通过让开发者和管理员为每个组件设置安全性环境而使安全性透明。就象Windows NT允许管理员为文件和目录设置访问控制列表（ACLs）一样，DCOM将组件的访问控制列表存储起来。这些列表清楚地指出了哪些用户或用户组有权访问某一类的组件。使用DCOM的设置工具（DCOMCNFG）或者在编程中使用Windows NT的registry以及win32的安全函数可以很简单地设置这些列表。

只要一个客户进程调用一个方法或者创建某个组件的实例，DCOM就可以获得使用当前进程（实际上是当前正在执行的线程）的用户的当前用户名。Windows NT确保这个用户的凭据是可靠的，然后DCOM将用户名正在运行组件的机器或进程。然后组件上的DCOM用自己设置的鉴定机制再一次检查用户名，并在访问控制列表中查找组件（实际上是查找包含此组件的进程中运行的第一个组件）。如果此列表中不包括此用户（既不是直接在此表中又不是某用户组的一员），DCOM就在组件被激活前拒绝此次调用。这种安全性机制对用户和组件都完全是透明的，而且是高度优化的。它基于Windows NT的安全框架，而此框架是Windows NT操作系统中最经常被使用（也是最完美的！）的部分，对每一个对文件或者诸如一个事件或信号的同步线程的访问都需要经过相同的访问检查。Windows NT能够和同类的操作系统以及网络操作系统竞争并超过它们的事实可以显示出这种安全性机制是多么有效。

DCOM提供了一个非常有效的缺省的安全性机制，它使开发员能够在无需但心任何安全性问题的情况下开发出安全的分布式应用

对某些应用系统来说，仅仅是组件级的访问控制列表是不够的，因为一个组件中的某些方法是只能被特定的用户访问的。

例子：一个商务结算组件可以有一个方法用来登录新事务，以及另一个方法用来获得已经存在的事务。仅仅只有财务组（“Accounting”用户组）的成员才能够添加新事务，同时仅仅只有高级管理人员（“Upper Management”用户组）才能查看事务。

正如上一部分所说，应用系统能够通过管理自己的用户数据库以及安全凭据来达到本身的安全。然而，在一个标准的安全框架下工作将会给最终用户带来更多的好处。没有一个统一的安全性框架时，用户需要为他们所使用的每一个应用记住和管理相应的登录凭据。开发者为每一个组件靠虑到安全性问题。

DCOM通过加入Windows NT提供的非常灵活的安全性标准将安全性用户化的要求简化为对某些特定组件和应用的需求。

使用DCOM安全性标准的应用达到上面例子所要求的有所选择安全性呢？当一个方法调用来到时，组件要求DCOM提供客户的身份。然后根据其身份，被调用线程就仅仅执行允许该客户执行的安全对象中的某些操作。接着组件就试着访问诸如登录字之类的安全对象，这些对象中有一个访问控制列表ACL，如果访问失败，说明客户不在ACL中，组件就拒绝方法调用。通过根据所调用的方法的不同而选择的不同的登录字，组件就能够用一种非常简单，但却灵活而有效的方式提供有选择的安全性。

组件也能够很轻易地得到客户的用户名并且利用它在自己的数据库中查找有关的许可和策略。这一策略使用了Windows NT的安全性框架（密码/公钥，传输线上加过密的密码等等）所提供的鉴定机制。应用系统无需为储存密码和其它有关的敏感信息担心。新版本的Windows NT将提供一个扩展的目录服务，它允许应用系统将用户信息存储到Windows NT的用户数据库中。

DCOM的做法更为灵活。组件能够要求不同级别的加密以及不同级别的鉴定，同时可以在自己进行身份认证时阻止组件使用自己的凭据。

设计在Internet上工作的应用系统时需要面对两个主要问题。

即使是在最大的公司，在Internet上用户的数量都会比原来提高好几个数量级。

最终用户希望对他们所使用的所有应用使用相同的公钥或密码，即使这些应用是由不同的公司所提供的。提供服务的公司不能在应用系统或安全性框架中储存用户的私人密码。

DCOM使用了Windows NT的安全框架（参看安全性部分）。Windows NT的安全性体系结构提供了多个安全性模块，其中包括：

Windows NT NTLM鉴别协议，它在Windows NT 4.0以及以前版本的Windows NT中使用。

Kerveros Version 5鉴别协议，它在处理Windows NT中以及Windows NT间的访问时代替NTLM成为最主要的安全性协议。

分布式密码鉴定（DPA），诸如MSN和CompuServe这些最大的Internet成员组织中的某些公司所使用的共享的密码鉴别协议。

它被用来完成Windows NT 4.0中的SSL/PCT协议。下一版本的Windows NT将加强对支持SSL 3.0客户鉴定系统的公钥协议的支持。

一个DCE提出的安全性模块，它可以作为第三方工具加在Windows NT中。

所有这些模块都是在标准Internet协议上工作的，都各有其优缺点。NTLM安全性模块以及在Windows NT 5.0中替代它的基于Kerberos的模块都是私人密钥基础协议。它们在集中式管理环境以及使用相互或者单方面信任关系的基于Windows NT服务器的局域网中是非常有效而安全的。对大多数UNIX系统来说，都可以使用NTLM来进行商业实现。（例如AT\u0026T的“Unix系统的高级服务器（Advanced Server for Unix Systems）”）。

使用Windows NT 4.0的目录服务，可以很好地扩展到大约100000个用户。使用Windows NT 5.0的扩展目录服务，一个Windows NT域控制器可以扩展到大约一亿个用户。通过将多个域控制器结合到Windows NT 5.0的目录树中，在一个域中所能支持的用户实际上是无限的。

Windows NT 5.0的基于Kerberos的安全性模块引入了例如在客户进行身份认证时对组件行为的控制等更先进的安全性概念。它在执行鉴别时比NTLM安全性提供模块所占用的资源更少。

Windows NT 5.0还提供了基于安全性模块的一个公共密钥。这一模块可以在基于Windows NT的应用以及基于DCOM的应用中将对于安全性凭据的管理分布化。使用公共密钥进行身份鉴别不如使用私人密钥有效，但是它允许在无需储存客户的私人凭据的情况下进行身份鉴别。

因为有如此多的互不相同的基本的安全性提供模块（私人密钥，公共密钥）可以被使用，所以基于DCOM的分布式应用系统可以无需对其进行任何改动就能完成甚至更为先进，对安全性敏感的应用。Windows NT的安全性框架使得无需牺牲灵活性和执行性能就能很容易地扩展应用并保证应用的安全性。

一个分布式应用系统越成功，由于用户数量的增长而给应用系统中的所有组件带来的负载就越高。一个经常出现的情况是即使是最快的硬件的计算能力也无法满足用户的需求。

这一问题的一个无法必免的解决方案是将负载分布到多个服务器中去。在“可扩展性”部分简要地提到了DCOM怎样促进负载平衡的几种不同的技术：并行配置，分离关键组件和连续进程的pipelining技术。

“负载平衡”是一个经常被使用的名词，它描叙了一整套相关技术。DCOM并没有透明地提供各种意义上的负载平衡，但是它使得完成各种方式的负载平衡变得容易起来。

解决负载平衡的一个方法是不断地将某些用户分配到运行同一应用的某些服务器上。因为这种分配不随网络状况以及其它因素的变化而变化，所以这种方法称为静态负载平衡。

基于DCOM的应用可以很容易地通过改变登记入口将其配置到某些特定的服务器上运行。顾客登记工具可以使用win32的远程登记函数来改变每一个客户的设置。在Windows NT 5.0中，DCOM可以使用扩展的目录服务来完成对分布的类的储存，这使得将这些配置改变集中化成为可能。

在Windows NT 4.0中，应用系统可以使用一些简单的技术达到同样的效果。一个基本的方法是将服务器的名字存到诸如数据库和一个小文件这样的众所周知的集中环境中。当组件想要和服务器相连接时，它就能很轻易地获得服务器的名字。对数据库或文件内容的改动也就同时改变了所有的用户以及有关的用户组。

一个灵活得多的方法使用了一个精致复杂的指示组件。这个组件驻留在一台为大家所共知的服务器中。客户组件首先和此组件连接，请求一个指向它所需服务的索引。指示组件能够使用DCOM的安全性机制来对发出请求的用户进行确认，并根据发出请求者的身份选择服务器。指示组件并不直接返回服务器名，它实际上建立了一个到服务器的连接并将此连接直接传递给客户。然后DCOM透明地将服务器和客户连接起来，这时指示组件的工作就完成了。我们还可以通过在指示组件上建立一个顾客类代理店之类的东西而将以上机制对客户完全屏蔽起来。

当用户需求增加时，管理员可以通过改变组件而为不同的用户透明地选择不同的服务器。此时客户组件没有做任何改动，而应用可以从一个非集中式管理的模式变为一个集中式管理的模式。DCOM的位置独立性以及它对有效的指示的支持使得这种设计的灵活性成为可能。

静态负载平衡方法是解决不断增长的用户需求的一个好方法，但它需要管理员的介入，并且只有在负载可预测时才能很好地工作。

指示组件的思想能够提供更加巧妙的负载平衡方法。指示组件不仅可以基于用户ID来选择服务器，它还可以利用有关服务器负载、客户和可用服务器之间的网络拓朴结构以及某个给定用户过去需求量的统计数字来选择服务器。每当一个客户连接一个组件时，指示组件将其分配给当时最合适的可用的服务器。当然，从客户的观点看来，这一切都是透明发生的。这种方法叫做动态负载平衡法。

对某些应用来说，连接时的动态负载平衡法可能仍然是不充分的。客户不能被长时间中断，或者用户之间的负载分布不均衡。DCOM本身并没有提供对这种动态重连接以及动态的方法分布化的支持，因为这样做需要对客户进程和组件之间相互作用的情况非常熟悉才行，此时组件在方法激活过程中保留了一些客户的特殊的状态信息。如果此时DCOM突然将客户和在另一台机器上的另一个不同的组件再连接，那么这些信息就丢失了。

然而，DCOM使得应用系统的设计者能够很容易地将这种逻辑结构清楚地引入到客户和组件之间的协议中来。客户和组件能够使用特殊的界面来决定什么时候一个连接可以被安全地经过再寻径接到另一台服务器上而不丢失任何重要的状态信息。从这一点看来，无论是客户还是组件都可以在下一个方法激活前初始化一个到另一台机器上的另一个组件的再连接。DCOM提供了用来完成这些附加的面向特殊应用的协议的所有的丰富的协议扩展机制。

DCOM结构也允许将面向特殊组件的代码放到客户进程中。无论什么时候客户进程要激活一个方法时，由真实组件组件所提供的代理组件在客户进程中截取这一调用，并能够将其再寻径到另一台服务器上。而客户根本无需了解这一过程，DCOM提供了灵活的机制来透明的建立这些“分布式组件”。

有了以上独特的特性，DCOM使得开发用来处理负载平衡和动态方法寻径的一般底层结构成为可能。这种底层结构能够定义一套标准界面，它可以用来在客户进程和组件之间传递状态信息的出现和消失情况。一旦组件位于客户端的部分发现状态信息消失，它就能动态地将客户重连接到另一台服务器上。

例子：微软的事务服务器（以前叫做“Viper”）使用这一机制来扩展了DCOM编程模型。通过一套简单的标准状态信息管理界面，事务服务器能够获得必要的信息来提供高级别的负载平衡。在这种新的编程模型中，客户和组件之间的相互作用被捆绑到事务中，它能够指出什么时候一系列的方法调用所涉及的组件的状态信息都是清楚的。

DCOM提供了一个用来完成动态负载平衡的强大的底层结构。简单的指示组件在连接时可以用来透明地完成动态服务器分配工作。用来将单一的方法调用再寻径到不同的服务器的更尖端的机制也能够轻易地完成，但是它需要对客户进程和组件之间的相互作用过程有更为深入的了解。微软的完全基于DCOM建立的事务服务器（“Viper”）提供了一个标准的编程模型用来向事务服务器的底层结构传递面向这一附加的特殊应用的有关细节问题，它可以用来执行非常高级的静态和动态的重配置与负载平衡。

容错性对于需要高可靠性的面向关键任务的应用系统来说是非常重要的。对于错误的恢复能力通常是是通过一定量的硬件、操作系统以及应用系统的软件机制来实现的。

DCOM在协议级提供了对容错性的一般支持。前面的“应用系统间的共享式连接管理”部分所描叙的一种高级pinging机制能够发现网络以及客户端的硬件错误。如果网络能够在要求的时间间隔内恢复，DCOM就能自动地重新建立连接。

DCOM使实现容错性变得容易起来。一种技术就是上一部分所说的指示组件的技术。当客户进程发现一个组件出错时，它重新连接到建立第一个连接的那个指示组件。指示组件内有哪些服务器不再有效的消息，并能提供在另一台机器上运行的这一组件的一个新的实例。当然，在这种情况下应用系统仍然需要在高级别上（一致性以及消息丢失问题等）处理错误的恢复问题。

因为DCOM可以将一个组件分别放到服务器方和客户方，所以可以对用户完全透明地实现组件的连接和重连接以及一致性问题。

例子：微软的事务服务器（“Viper”）提供了一个在应用级处理一致性问题的一般性机制。将多个方法调用组合到一个原子事务中就能够保证一致性，并使应用能够很容易地避免信息的丢失。

另一技术经常被称为“热备份”。同一服务器组件的两个复本并行地在不同的机器上运行，它们处理相同的信息。客户进程能够明确地同时连接这两台机器。DCOM的“分布式组件”通过将处理故障容许度的服务代码放到客户端使得以上过程对用户应用完全透明。另一种方法是使用另一台机器上运行的一个协作组件，由它代表客户将客户请求发送给那两个服务器组件。

当错误发生时试图将一个服务器组件转移到另一台机器上经事实证明是失败的。Windows NT组的最初版本使用了这一方法，当然它可以在应用级完成。DCOM的“分布式组件”使得完成这一机能更容易了，并且它对用户隐蔽了实现细节。

DCOM使得完成高级的容错技术变得更为容易。使用DCOM提供的部分在客户进程中运行的分布式组件技术能够使解决问题的细节对用户透明。开发者无需改动客户组件，甚至客户机进行重新配置就能够增强分布式应用系统的故障容许度。

如果不容易安装和管理的话，即使是最好的应用系统也是没有用的。对于分布式应用来说，能够集中管理和尽可能简单的客户安装过程是非常关键的。同时，提供一些办法使系统管理员能够在潜在的错误造成任何损害之前尽可能早的发现它对于分布式应用也是非常必要的。

DCOM提供了什么技术能够让一个应用更加易于管理呢？

简化客户端安装的一种普遍方法可以概括为一个词“稀薄的客户”，意思是驻留在客户端的机能越少，安装以及可能发生的维护问题也就越少。

然而，客户组件越“稀薄”，整个应用的用户友好度就越低，对网络和服务器的需求也就越高。稀薄的客户还不能充分利用当今桌面办工系统所能得到的强大的计算能力，而由于诸如字处理软件以及电子表格软件这些桌面生产应用系统本身就具有统一而庞大的特性，所以大多数用户对于这种系统的强大的计算能力的需求也不会减弱。因此在正确的级别实现“浓厚”对于分布式应用的设计来说是一个非常重要的决定。DCOM通过让开发者甚至管理员来选择每个组件的位置来促进配置的简单性和灵活性之间的平衡。可以通过对配置的简单改动使同一个事务组件（例如数据登录检查组件）分别在服务器和客户端执行。应用能够动态地选择所使用的用户界面组件（服务器上的HTML产生器或者客户端的ActiveX控件）。

保持“肥胖的”客户的一个最大的问题是将这些客户更新到最新版本的问题。现在通过对代码下载的支持，微软的Internet Explorer 3.0提供了解决这一问题的一个非常优雅的办法。只要用户在浏览一页页面，微软的Internet Explorer就会检查页面中所使用的ActiveX控件，并在必要时自动对其进行更新。应用也可以在不明确使用浏览器的时候使用这一被微软直接支持的特性（ActiveX的CoCreateClassFromURL函数）。

在Windows NT 5.0中，代码下载的概念将被扩展到本地COM类库中。这一类库将使用扩展目录来储存组件的配置信息和到实际代码的索引，它改变了当前使用的本地登记概念。这个类库将向Intranet（扩展目录）和Internet（代码下载，Internet路径搜索）提供代码仓库，并使它们对已存在的应用完全透明。

安装和更新服务器组件通常不是一个严重的问题。然而，在一个高度分布化的应用中，同时更新所有的客户一般来说是不太可能的。如第一部分中“功能的发展：版本化”部分所述的DCOM的健壮的版本化支持允许服务器在保持向后兼容的基础上加入新的功能。服务器组件既可以处理旧客户进程，又可以处理新客户进程。一旦所有的客户都被更新，组件就可以停止对新客户所不需要的功能的支持。

使用代码下载技术以及以后它的扩展技术，类库、管理员能够有效而安全地集中安装和更新客户，并能在不用削减太多功能的情况下将“肥胖的”客户变为灵巧的客户。DCOM对于健壮性版本化的支持使得无需先更新所有客户就可以更新服务器程序。