DCOM概述DCOM的结构DCOM是组件对象模型（COM）的进一步扩展。COM定义了组件和它们的客户之间互相作用的方式。它使得组件和客户端无需任何中介组件就能相互联系。客户进程直接调用组件中的方法。图1说明了组件对象模型的表示法：图1同一进程中的COM组件在现在的操作系统中，各进程之间是相互屏蔽的。当一个客户进程需要和另一个进程中的组件通讯时，它不能直接调用该进程，而需要遵循操作系统对进程间通讯所做的规定。COM使得这种通讯能够以一种完全透明的方式进行：它截取从客户进程来的调用并将其传送到另一进程中的组件。图2表明了COM/DCOM运行库是怎样提供客户进程和组件之间的联系的。图2不同进程中的COM组件当客户进程和组件位于不同的机器时，DCOM仅仅只是用网络协议来代替本地进程之间的通讯。无论是客户还是组件都不会知道连接它们的线路比以前长了许多。图3显示了DCOM的整体结构：COM运行库向客户和组件提供了面向对象的服务，并且使用RPC和安全机制产生符合DCOM线路协议标准的标准网络包。图3DCOM:不同机器上的COM组件组件和复用大多数分布式应用都不是凭空产生的。现存的硬件结构、软件、组件以及工具需要集成起来，以便减少开发和扩展时间以及费用。DCOM能够直接且透明地改进现存的对COM组件和工具的投资。对各种各样组件需求的巨大市场使得将标准化的解决方案集成到一个普通的应用系统中成为可能。许多熟悉COM的开发者能够很轻易地将他们在COM方面的经验运用到基于DCOM的分布式应用中去。任何为分布式应用开发的组件都有可能在将来被复用。围绕组件模式来组织开发过程使得你能够在原有工作的基础上不断的提高新系统的功能并减少开发时间。基于COM和DCOM的设计能使你的组件在现在和将来都能被很好到使用。位置独立性当你开始在一个真正的网络上设计一个分布式应用时，以下几个相互冲突的设计问题会很清楚地反映出来：相互作用频繁的组件彼此间应该靠得更近些。某些组件只能在特定的机器或位置上运行。小组件增加了配置的灵活性，但它同时也增加了网络的拥塞。大组件减少了网络的拥塞，但它同时也减少了配置的灵活性。当你使用DCOM时，这些设计上的限制将很容易解决，因为配置的细节并不是在源码中说明的。DCOM使得组件的位置对你来说完全透明，无论它是位于客户的同一进程中或是在地球的另一端。在任何情况下，客户连接组件和调用组件的方法的方式都是一样的。DCOM不仅无需改变源码，而且无需重新编译程序。一个简单的再配置动作就改变了组件组件之间相互连接的方式。DCOM的位置独立性极大地简化了将应用组件分布化的任务，使其能够达到最合适的执行效果。例如，设想某个组件必需位于某台特定的机器上或某个特定的位置，并且此应用有许多小组件，你可以通过将这些组件配置在同一个LAN上，或者同一台机器上，甚至同一个进程中来减少网络的负载。当应用是由比较少的大组件构成时，网络负载并不是问题，此时你可以将组件放在速度快的机器上，而不用去管这些机器到底在哪儿。图4显示了相同的“有效性检查组件”在两种不同情况下是如何分别配置的。一种情况是当“客户”机和“中间层”机器之间的带宽足够大时，它是怎样配置在客户机上的；另一种情况是当客户进程通过比较慢的网络连接来访问组件时，它又是怎样配置在服务器上的。图4位置独立性有了DCOM的位置独立性，应用系统可以将互相关联的组件放到靠地比较近的机器上，甚至可以将它们放到同一台机器上或同一个进程中。即使是由大量的小组件来完成一个具有复杂逻辑结构的功能，它们之间仍然能够有效到相互作用。当组件在客户机上运行时，将用户界面和有效性检查放在客户端或离客户端比较近的机器上会更有意义；集中的数据库事务应该将服务器靠近数据库。语言无关性在设计和实现分布式应用系统时，一个普遍的问题就是为开发一个特定的组件而选择语言以及工具的问题。语言选择是一个典型的在开发费用、可得到的技术支持以及执行性能之间的折衷。作为COM的扩展，DCOM具有语言独立性。任何语言都可以用来创建COM组件，并且这些组件可以使用更多的语言和工具。Java，MicrosoftVisualC++，MicrosoftVisualBasic，Delphi，PowerBuilder和MicroFocusCOBOL都能够和DCOM很好地相互作用。因为DCOM具有语言独立性，应用系统开发人员可以选择他们最熟悉的语言和工具来进行开发。语言独立性还使得一些原型组件开始时可以用诸如VisualBasic这样的高级语言来开发，而在以后用一种不同的语言，例如VisualC++和Java来重新实现，而这种语言能够更好地支持诸如DCOM的自由线程／多线程以及线程共用这些先进特性。连接管理网络连接本身就比同一台机