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和其它的协议的相关的执行性能有一定的了解。
calls / sec ms / call calls / sec ms / call "Pentium?,,” in-process 3,224,816 0.00031 3,277,973 0.00031 "Alpha?," in-process 2,801,630 0.00036 2,834,269b 0.00035 "Pentium," cross-process 2,377 0.42 2,023 0.49 "Alpha," cross-process 1,925 0.52 1634 0.61 "Alpha," to Pentium remote 376 2.7 306 3.27
开始两列表示一个“空”方法调用（发送和接收一个4字节长的整数）。最后两列可以认为是一个“真正的”COM方法调用（50字节长的参数）。 此表显示了进程中组件是怎样得到零开支的执行性能的（第一排和第二排）。 进程之间的方法调用（第三排和第四排）需要将参数存入缓冲器并将其发送给其它的进程。在一个标准的桌面办公系统硬件中，每秒钟大约可以执行2000个方法调用，这可以满足大多数的执行性能需求。所有的本地调用是完全由处理器速度（一定程度上由存储器容量）决定的，并且能够很好地适用于多处理器型机器。 远程调用（第五排和第六排）主要受限于网络速度，同时可以看出DCOM的开支大约比TCP/IP多了35%（TCP/IP的循环时间是两秒）。 微软很快会提供许多平台上的正式的DCOM性能参数，它将显示出DCOM与客户数量以及服务器中处理器数量相关的扩展能力。
