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 组合的生命期管理

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

优化网络的来回旋程

设计分布式应用的一个普遍问题是减少不同机器上组件之间在网络上的过度的来回绕圈数。在Internet上，每一次网络绕圈就会引入１秒甚至更多的延迟。即使在速度快的局域网上，旋程时间也是以微秒来计算的──它超过了本地操作所需时间的量级。

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

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

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

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

图１０　组件模型：客户端的缓存

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

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

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

图11　索引指示

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

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

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

图12 用custom协议代替DCOM