DCOM认识2

wym

DCOM提供了一个对应用完全透明的分布式垃圾收集机制。DCOM是一个天生的对称性网络协议和编程模型。它不仅提供传统的单向的客户机－服务器之间的相互作用方式，还提供了客户机和服务器以及对等进程之间的丰富的交谈式的通讯方式。
　　可扩展性
　　分布式应用的一个重要因素是它的处理能力能够随着用户的数量、数据量所需性能的提高而增加。当需求比较小时，应用系统就比较小而速度快，并且它要能够在不牺牲性能和可靠性的前提下处理附加的需求。DCOM提供了许多特性来增强你的应用的可扩展性。
　　对称的多进程处理（SMP）
　　DCOM提高了Windows NT对于多进程处理的支持。对于使用自由线程模式的应用，DCOM使用一个线程队列来处理新来的请求。在多处理器机上，线程队列是由可利用的处理器的数量来决定的：太多的线程会导致经常性的上下文切换，而太少的线程又会使处理器处于空闲状态。DCOM只提供一个手工编码的线程管理器，从而使开发者从线程的细节中解脱出来并获得最好的性能。
　　DCOM通过使用Windows NT对于对称性多进程处理的高级支持功能就能轻易地将应用从一个单处理机扩展到庞大的多处理机系统上去。
[编辑本段]灵活的配置　　当负载增加时，即使你的预算支持你买一台最快的多处理机，它也有可能不能适应需求。DCOM的位置独立性提供了一个简单而便宜的方法来提高扩展性，那就是将分布性的组件放到其它的机器上。
　　对于无状态或无需和其它组件共享状态的组件来说，再配置是再容易不过的事了。对于这样一些组件来说，可以在不同的机器上运行它们的多个复本。用户负载可以被平等地分配到各个机器中去，甚至可以考虑到机器的处理能力以及当时负载这些因素来进行分配。使用DCOM，可以很容易地改变客户进程同组件以及组件之间的连接方式。同一组件无需作别的改动甚至无需重新编译就可以被动态地重新配置。所有必须做的工作只是更新登记、文件系统以及所涉及的组件所在的数据库而已。
　　例子：一个组织在多个地方有办工室，例如纽约、伦敦、旧金山和华盛顿等，它可以将组件安装到服务器上。两百个用户同时在能达到预期的性能的前提下访问五十个组件。当新的事务应用发送给用户时，应用系统中同时在使用一些现存的以及新的组件，服务器的负载增长到六百个用户，同时事务组件的数目增加到七十。有了这些附加的用户和组件后，峰值时间的响应时间变得不能接受。管理员将其中的三十个组件单独配置在另一台服务器上，而将二十个组件单独放在原来的服务器上，同时剩下的二十个组件同时在两台服务器上运行。
　　图5 并行配置http://hiphotos.baidu.com/sgsmyx/pic/item/8bda6e3ff23046e555e72347.jpg
　　绝大多数现实的应用系统都有一个或多个涉及到大多数操作的关键性组件。这种组件有数据库组件或者事务规则组件，它们必须被串行地执行以保证“先来的先服务”这一策略被执行。这些组件不能被复用，因为它们的唯一任务就是为应用系统的所有用户提供一个单一的时间同步点。为了增强分步式应用系统的整体功能，必须将这些瓶颈组件放到一个专门的、功能强大的服务器上去。DCOM可以使你早在设计阶段就将这些关键性组件分开，最初将多个组件放在一台功能简单的机器上，以后再把关键性的组件放到专门的机器上去。这一过程无需组件的再设计，甚至无需重新编译。
　　图6 关键性组件的分离http://hiphotos.baidu.com/sgsmyx/pic/item/209e99884f76ba9da5c2724a.jpg
　　DCOM对于这些决定性的瓶颈组件的处理使得整个任务能够迅速执行。这些瓶颈组件往往是过程执行序列的一部分，例如电子交易系统中的买卖命令，它们必须按照接收的顺序执行（先来的先被服务）。对于此问题的一个解决方法是将任务分成许多小的组件，并将这些组件配置到不同的机器上。这种效果类似于当今微处理器中的管道pipelining技术：第一个请求来了，第一个组件执行（例如一致性检查），然后将请求传递给下一个组件（例如，可能是更新数据库）。一旦第一个组件将一条请求传递给下一个组件，它就准备执行下一条请求。实际上有两台机器在并行的执行多个请求，并且能够保证按照请求来到的顺序执行。也可以在同一台机器上使用DCOM来达到同样的效果：多个组件在不同的线程或者不同的进程中执行。这种方法在以后可以简化扩展，我们可以将线程分布到一个带多处理器的机器上，或者可以将进程配置到不同的机器上。
　　图7 Pipelining http://hiphotos.baidu.com/sgsmyx/pic/item/298b00c2875cb83ce4dd3b47.jpg
　　DCOM的位置独立性编程模型使得随着应用增加而改变配置设计变得容易了。最初，一个功能简单的服务器就可以容纳所有的组件。随着需求的增加，其它的机器被添加进来，而组件能够不做任何代码上的改动就被分步到这些机器中去。
　　功能的发展：版本化
　　除了随着用户的数量以及事务的数量而扩展规模外，当新的特性加入时应用系统也需要扩展规模。随着时间的推移，新的任务被添加进来，原有的任务被更新。传统的做法是或者客户进程和组件都需要同时被更新，或者旧的组件必须被保留直到所有的客户进程被更新，当大量的地理上分布的站点和用户在使用系统时，这就成为一个非常费力的管理问题。
　　DCOM为组件和客户进程提供了灵活的扩展机制。使用COM和DCOM，客户进程能够动态地查询组件的机能。一个COM组件不是将其机能表现为一个简单、统一的方法和属性组，而是对于不同的客户进程表现为不同的形式。使用特定特性的客户进程只需要访问它所需要使用的方法和属性。客户进程也能够同时使用一个组件的多个特性。当新的特性加入组件时，它不会影响不涉及这些特性的老的客户进程。
　　用这种方法来组织组件，使得我们能够有一种新的方法来发展组件功能：最初的组件表现为诸如COM界面的一套核心特性，这些特性是每个客户进程都需要使用的。当组件需要新的特性时，大多数（甚至是全部）的界面仍然是必须的，我们根本无须更改原来的界面就可以将新的功能和属性放到附加的界面中去。老的用户进程就好像什么事也没发生似的继续访问核心界面。新的客户进程既可以测试新的界面是否存在以便能使用它，也可以仍然只使用原来的界面。
　　图8 健壮的版本发展http://hiphotos.baidu.com/sgsmyx/pic/item/785b2a383997ac2a96ddd841.jpg
　　因为在DCOM编程模型中机能被分组放入界面中，你可以设计使用老的服务器程序的新的客户程序，也可以设计使用老的客户程序的新的服务器程序，或者将这些混合起来以便能够适合你的需求和编程资源。使用传统的对象模型时，那怕是对一个方法的细微改动都可能在根本上改变客户和组件之间的协议。在一些模型中，可以将方法加到方法队列的队尾，但是却不能在老的组件上测试新的方法。从网络发展的前景看来，这些事情将会变得越来越复杂：编码以及其它的一些功能典型地依赖于方法和参数的顺序。增加或改动方法和参数也会显著地改变网络协议。DCOM为对象模式和网络协议设计了一个简单、优雅和统一的方法来解决这些问题。
　　执行性能
　　如果最初的执行性能不能让人满意的话，可扩展性就不会带来太多好处了。经常考虑到更多更好的硬件会使得应用向下发展是非常有益的，但是这些需求是怎样的呢？这些尖端扩展特性是否有用呢？是否对从COBOL到汇编这每一种语言的支持会危害到系统的执行性能呢？使组件能够在地球的另一面运行的能力是否妨碍了当它和客户在同一个进程中时的执行性能呢？
　　在COM和DCOM中，客户并不能自己看到服务器，但是除非是在必要的情况下，否则客户进程决不会被系统组件将自己同服务器分开。这种透明性是通过一个简单的思想来实现的：客户进程同组件交互的唯一方式就是通过方法调用。客户进程从一个简单的方法地址表（一个“vtable”）中得到这些方法的地址。当客户进程想要调用一个组件中的某个方法时，它先得到方法的地址，然后调用它。在COM和DCOM模型中调用一个传统的C或汇编函数的唯一开支就是对方法地址的简单查询。如果组件是和客户运行在同一个线程中的过程中组件，那么无需调用任何COM或系统代码就可以直接找到方法的地址，COM仅仅只定义了找到方法地址表的标准。
　　当用户和组件不是那么靠近──在另一个线程中，在另一个程序中或者在地球另一面的一台机器中时情况又是怎样的呢？COM将它的远程过程调用（RPC）框架代码放到vtable中，然后将每个方法调用打包放到一个标准的缓冲器结构中，这个缓冲器结构将被发送给组件，组件打开包并且重新运行最初的方法调用。从这方面来说，COM提供了一个面向对象的RPC机制。
　　这种RPC机制的速度有多快呢？下面是需要考虑的不同的性能尺度：
　　一个“空”方法调用有多快？
　　“真正的”需要发送和接收数据的方法调用有多快？
　　在网络上转一圈有多快？
　　下表显示了COM和DCOM的一些真实的执行性能参数，使我们能够对DCOM和其它的协议的相关的执行性能有一定的了解。
　　http://hiphotos.baidu.com/sgsmyx/pic/item/a71579d3f37a8b093bf3cf4c.jpg
　　开始两列表示一个“空”方法调用（发送和接收一个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消息，它就断定客户进程“死掉了”。
　　

Jamesliu2009

hhhhhhhhhhhhhhhhhhhhhhh