二.COM+系统服务介绍
COM+的系统服务充分体现了COM+的特征，通过这些系统服务，我们可以很容易地开发出多层结构的应用系统，因为这些系统服务本身已经满足了多层应用的一些基本要求。COM+以系统服务的形式为应用提供了许多新特性，这有多方面的好处，首先，客户或者组件程序可以直接利用这些系统服务，避免了底层的细节处理，减少开发成本，降低代码量，同时也减小了犯错误的可能性；其次，有一些系统服务涉及到较复杂的逻辑，可能要访问底层的系统资源，应用层很难实现这些系统服务；另外，使用系统服务可增强可靠性，因为这些系统服务已经经过严格的测试，应用系统要获得同样的可靠性需要很昂贵的代价。
COM+的系统服务有的从MTS继承过来，有的是新增加的。这一部分重点对新增的一些系统服务作初步的介绍，包括队列组件、负载平衡、内存数据库和事件服务，最后介绍其他一些在MTS中已经引入的、但COM+又增强了的系统服务，包括事务、对象池、安全模型以及管理特性。
1.COM+队列组件
我们知道，COM客户与远程组件之间的交互是基于RPC连接的，客户连接到一个组件对象，请求指定的接口，然后通过接口指针执行同步调用。虽然COM也允许异步调用，但客户与组件的生存期必须保持一致，调用必须在连接有效期范围内进行。
COM+除了支持这种基于RPC连接的运行方式，它还支持另一种运行模式，我们称为基于消息的通讯过程，它可以有效地把客户与组件的生存期分离开。这种模式通过COM+的队列组件服务实现，图6是队列组件的基本模型结构。
图6 队列组件模型结构图
队列组件并没有使用直接的RPC连接，而是采用了底层的消息系统MSMQ(Microsft Message Queue Server)。通过底层的队列机制，客户与组件的生存周期可以被分离在不同的时间点上。客户程序不再直接调用组件对象，它利用消息机制与组件对象进行通讯，即使组件对象并没有运行，客户程序仍然可以执行操作。
COM+应用可以以透明方式支持同步和异步两种调用方式，当客户和组件程序建立了连接之后，客户以同步方式直接调用组件的方法；如果客户与组件没有建立直接的连接，那么客户以异步方式与组件进行通讯。如果组件对象被标识为“队列化”，那么它支持队列方式运行，于是一个被称为“COM+记录器”的代理对象自动把所有该组件的调用请求记录到一个永久队列中，该队列被保存在客户机上；以后当客户机连接到网络上，位于服务器上的“COM+播放器”从永久队列中获得调用信息，执行真正的调用操作。队列组件以透明的方式把同步和异步两种程序运行方式统一在一个单一的编程(www.cppentry.com)模型中，所以COM+应用系统为获得异步特性并不需要作额外的工作。我们仍然可以按通常的方式开发组件和客户程序，但是由于队列方式的特殊性，所以组件必须满足两个限制条件：第一，组件的接口成员函数只能有输入参数，不能包含输出参数，这些输入参数将被传递到MSMQ消息中；第二，组件接口成员函数的返回值HRESULT的含义不能与应用相关，它不标识与应用有关的信息。
在队列组件的异步交互过程中，客户程序创建一个组件对象，它实际上创建了一个记录器代理对象，所有的调用都通过记录器进行，记录器把调用请求记录下来，然后通过MSMQ传递到服务器组件，服务器上的播放器再执行这些方法调用。使用这种异步方法的难点在于，客户程序如何获得返回信息，这包含几种可能情况以及解决办法：第一，客户并不关心执行结果；第二，我们可以用响应队列来实现客户程序；第三，客户也可以把自己的一些特征信息传递给组件对象，以便组件对象以同样异步的方式通知客户应用。选择什么样的解决方法取决于应用的需要，我们可以灵活使用各种技术。
队列组件对于分布式应用非常有意义，尤其是在慢速网络上运行的应用系统，这种机制可以保证应用系统能够可靠地运行。在应用系统包含大量客户节点但服务器数量又比较少的情况下，客户应用程序可以把它们的请求放到队列中，当服务器负载比较轻的时候再处理这些请求，因此队列机制也从另一个角度实现了应用系统的负载平衡以及可伸缩特性。
2.COM+事件模型
COM不仅定义了客户调用组件对象的通讯过程，它也定义了反向的通讯过程，这就是COM可连接对象(connectable object)机制。组件对象定义了出接口(outgoing interface)的所有特征，客户程序实现出接口，当客户程序与对象建立连接之后，客户通过连接点对象建立它与客户端接收器对象之间的反向连接。实际上，这时的连接点对象成了接收器对象的客户方。
COM的可连接对象有很大的优势，它的扩展能力非常强，几乎总是可以满足应用的需要。但是从实际应用的情况来看，它也存在一些缺点，表现在以下几个方面：第一，事件源和客户方紧紧绑定在一起，双方程序代码依赖于出接口的定义，我们必须在编译时刻知道对方的信息；第二，源对象需要编写大量代码来支持这种机制，尤其是为了支持多通道事件；第三，连接点接口的设计模式并没有考虑到分布式环境的特点，所以它在分布式环境下并不很有效。
COM+事件模型改进了COM的可连接对象机制，它采用了多通道的发布/订阅(multicasting publish/subscribe)事件机制，它允许多个客户去“订阅”事件，这些事件由各种组件对象“发布”。COM+事件服务维护一个事件数据库，数据库包含各种事件、发布者、订阅者以及所有的订阅信息。当发布者激发事件时，COM+事件服务对事件数据库中有关的订阅信息进行检查，然后通知对应的订阅者。COM+事件模型基本结构如图7所示。
图7 COM+事件模型结构图
COM+事件模型通过事件类来传递源对象的出接口事件信息，以便它可以与客户方的入接口事件方法相匹配，这种方式与COM可连接对象机制很类似，所以老式的COM组件和客户程序可以很方便地使用新的COM+事件模型。
COM+事件模型用中心服务和中心管理的方式把发布者与订阅者之间的依赖关系分离开，它用事件类作为发布者和订阅者之间的中间对象，发布者必须通过事件类发布信息。事件类是由COM+事件服务提供的对象，它实现了事件接口，所以对于发布者来说，它扮演了订阅者的角色。当发布者要激发事件时，它创建一个事件类对象，调用相应的事件方法，然后释放对象的接口。COM+事件服务会决定如何通知订阅者，决定什么时候通知订阅者。如同队列组件情形一样，发布者和订阅者的生存时间可以被分离，从这个意义上讲，所有事件接口函数只能包含输入参数。
订阅者订阅事件也很方便，它只要通过COM+事件服务创建一个订阅对象，并注册到事件数据库中，以后它就会接收到来自发布者的事件通知。
COM+事件系统不仅仅为应用程序提供事件服务，它也为操作系统的内部实现提供事件服务，比如，它也用来实现Windows 2000的底层系统事件通知服务(SENS)，包括用户登录事件、网络连接事件等等，我们可以创建和注册一个订阅对象来接收这些系统事件。这是COM+事件系统的一个应用，当然接收这种系统事件必须符合一定的安全策略。
|