3.负载平衡
负载平衡是分布式应用的一种高层次需求，如果没有很好的工具支持，那么实现负载平衡需要付出很大的代价。我们可以使用DCOM和MTS的配置特性实现静态负载平衡，但是要实现真正的动态负载平衡并不容易，我们很难根据当前系统的负载状态把对象创建请求传递到负载最轻的机器上，我们必须编写大量的代码来间接支持这种特性。
COM+提供了一个负载平衡服务，它可以以透明方式实现动态负载平衡。但是为了使组件支持负载平衡，首先我们必须定义一个应用群集(application cluster)，应用群集是指一组已经安装了服务器端组件的机器(至多可达8台机器)，然后我们把一台机器配置成负载平衡路由器(router)，负载平衡路由器会把对象的创建请求传递到应用群集中的某一台机器上。
COM+负载平衡以NT系统服务的形式运行在路由器机器上，当路由器的SCM(Service Control Manager)接收到远程创建对象请求时，它把请求传递到负载最轻的机器上。实现负载平衡的一个难点是如何确定应用群集中的哪台机器是负载最轻的。COM+负载平衡引擎使用缺省的负载平衡算法，它根据每台机器上每个对象实例的方法调用的响应时间作为参考值计算出负载平衡参数，这种算法不一定是最佳算法，但对于大多数应用已经足够了。COM+也允许应用程序使用自定义的负载平衡引擎。
COM+负载平衡应用模型中对象创建过程如图8所示。
图8 负载平衡模式下对象创建示意图
客户程序仍然可以按通常的方式创建远程对象，在CoCreateInstanceEx函数中指定路由器机器名，当创建成功之后，它得到的对象实例运行在当前负载最轻的服务器上。路由器检查COM+目录，看请求创建的组件对象是否支持负载平衡，如果是，则它根据路由算法，把创建请求路由到负载最轻的服务器上。然后，应用群集中的服务器接收到创建请求之后，它就创建对象，并把对象引用直接返回给客户机。因此，一旦对象已经被成功创建，那么客户与对象之间的连接是直接进行的，而不必再通过路由器。
COM+应用程序的负载平衡特性并不需要编写代码来支持，客户程序和组件程序都可以按通常的方式实现。因此，获得负载平衡特性不是一种程序设计和开发的行为，而是一种配置行为，通过配置实现分布式应用程序的负载平衡。当然我们在编写负载平衡组件时，要避免使用与当前机器环境相关的信息，比如当前机器的名字或者依赖与本地机器上某个路径下的某个文件，等等。
4.内存数据库(IMDB)
COM+的内存数据库(In Memory Database)服务是一个全新的服务，它用于保存应用的非永久状态信息。我们知道，对于以数据为中心的应用软件，为了提高系统的运行效率，它应该尽可能让更多的数据驻留在内存中，尤其是客户程序频繁访问的数据信息。IMDB是一个驻留在内存中的支持事务特性的数据库系统，它可以为COM+应用程序提供快速的数据访问。
IMDB的基本功能在于优化数据查询和数据获取，它可以装载后台数据库系统中的数据表，也可以装载应用程序的非永久数据信息。使用IMDB的最典型的例子是Web应用，它把客户频繁访问的数据信息放在IMDB中，以便成百上千的客户得到快速的响应。因为物理内存容量越来越大(在机器上安装2GB物理内存已经成为现实)，并且价格越来越便宜，所以通过IMDB，我们只要增加物理内存就可以提高系统的响应速度，而且把频繁访问的数据从数据层移到业务层可以有效地减少网络流量。图9给出了基于IMDB的Web应用基本结构。
图9 基于IMDB的Web应用结构示意图
IMDB的接口为OLE DB和ADO，所以组件对象可以通过这些标准接口访问IMDB。由于IMDB是内存中的数据库，所以IMDB只对本机器上的COM+组件有效，也就是说，IMDB不支持分布式概念，并且多个IMDB机器不能装入同一个数据表，如果多个组件要共享IMDB中的信息，那么这些组件必须运行在同一台机器上。
IMDB以NT系统服务的形式运行在服务器上，在服务启动时，IMDB从后台数据库中把所有指定的数据表装入到共享内存中。IMDB以整个数据表为单位装载数据，如果内存不够，装不下整个表，那么IMDB会产生错误。组件对象通过进程内代理对象访问IMDB中的数据表。因为IMDB为了使数据访问尽可能快速，它并没有实现SQL查询处理器，所以我们不能使用SQL命令访问IMDB数据，只能通过标准的ISAM技术访问IMDB数据，也就是说我们必须通过索引访问数据。
IMDB不仅可以把数据表缓冲起来，它也可以管理应用系统的非永久状态信息，如果运行在同一台机器上的不同组件需要共享大量的信息，那么选择IMDB是一个理想的解决方案。
5.对其他服务的增强
前面介绍的几个系统服务是COM+针对分布式应用新增加的服务，这些服务以及其他一些原先在MTS中已经提供的服务合起来构成了COM+的底层服务体系。我们知道，COM已经提供了组件对象与客户程序之间的基本通讯过程，包括对象创建、跨进程机制、接口管理等等，而COM+提供的底层服务则着眼于一些高层次的应用需求，特别是构建大型软件系统或者分布式软件系统需要支持的一些特性。下面对COM+在MTS基础上增强的一些服务作一简要说明。
(1) 事务特性。
事务允许组件可以把一组独立的操作形成一个整体操作，事务操作要么成功，要么失败。COM+仍然支持MTS的事务语义，通过SetAbort或SetComplete完成事务操作。COM+还支持其他的事务操作模式，如果一个对象被标为“AuotAbort”，那么在事务操作过程中，若发生异常，则系统自动调用SetAbort。同样地，如果一个对象被标为“AutoComplete”，那么在每一个方法调用之后，除非此方法显式调用了SetAbort，否则系统会自动调用SetComplete。而且COM+还支持BYOT(Bring Your Own Transaction)，即允许COM+组件参与非MTS事务处理环境管理的事务。
(2) 安全性。
COM+的安全模型仍然沿用了MTS的基于角色的安全模型，根据用户的角色访问应用的有关功能模块。这种安全模型需要开发人员与管理人员协同完成，在开发阶段，开发人员负责定义各种角色，并且在实现组件功能时，只允许指定角色的用户才可以执行这些功能；在配置阶段，管理员负责为所有的角色指定有关的用户帐号。COM+扩充了MTS安全模型，它允许开发人员和管理员指定到方法一级的安全控制，在MTS安全模型中，我们只能在MTS包一级指定安全角色。通过COM+对象环境信息，COM+的安全模型更为细致，比如，它允许开发人员控制每一个接口、或者每一个方法如何扮演客户，等等。
(3) COM+对象池。
对象池是指把对象的实例保留在内存中，以便当客户请求创建对象时可以马上用到这些对象。对象池如同IMDB一样，完全是出于效率考虑的原因，用来建立大型的应用系统。对象池的概念在MTS 2.0中已经被引入了，因为MTS组件的IObjectControl接口的三个成员函数Activate、Deactivate和CanBePooled用于对象池的管理。但是MTS 2.0实际上并没有支持对象池，也就是说，不管对象是否支持对象池缓存操作，它的IObjectControl::CanBePooled函数永远不会被调用到。COM+继承了MTS对象池的概念，并且真正实现了对象池的功能。
(4) 管理服务。
在本文第一部分我们已经看到了COM+管理程序，它代替了MTS管理程序(MTS Explorer)和DCOM配置程序(DCOMCNFG.EXE)。对于多层结构应用，COM+管理程序是个不可缺少的工具，应用系统的安全特性以及事务特性等基本配置都需要通过管理程序实现。由于MMC界面操作简单、直观，所以管理员无须学习其他的管理工具，就可以配置所有的应用系统。而且COM+管理程序支持脚本语言，因此，开发人员和管理员可以创建一些脚本代码以便实现管理工作的自动化。COM+还引入了一个新的“ApplID”，它是一个128位GUID，标识一个与一组属性值相联系的CLSID。通过“ApplID”，管理员可以为应用配置和维护多个版本。
这一部分重点讨论了COM+的各个系统服务，尤其是COM+新增加的几个系统服务，这些系统服务使COM+更加适合于分布式应用的开发。有些系统服务并不需要COM+应用通过编程(www.cppentry.com)来获得，比如负载平衡和队列组件服务等；而有的服务则可以简化编程(www.cppentry.com)模型，比如事件服务；其他有一些服务可以用来提高系统的性能，比如内存数据库、对象池等。
|