“排队组件 (QC)”是 COM+ 1.0 提供的主要服务之一。它避免了开发自己的体系结构来使用 MSMQ（或者某些其他异步机制），允许在客户机和服务器保持 COM 编程模型，并提供 MSMQ 在传输时提供的好处。它也对安全性、事务和错误处理提供大量支持。

在使用 MSMQ 时必须：

• 设计、构造、验证和分析自己的消息格式。
  
  
• 使用特殊 API 或对象模型来组织、发送和接收消息。
  
  
• 开发自己的消息接听者作为 Windows NT 服务，用于手动管理线程和安全性。
  
  
• 设计自己的方案来处理坏的消息处理。

排队组件全部都会做到！

访问下面的链接可以获得 QC 体系结构的简单概述。确定 QC 基础结构的所有部分，是有好处的。

排队组件的体系结构（英文）

查看下面的文章，可以获得有关排队组件的进一步信息。

MSJ：用 Windows 2000 排队组件构造存储转发机制（英文）
编写排队组件（英文）

在“活动目录”模式下安装 MSMQ

MSMQ 2.0 提供两个主要的安装选项：

1. “活动目录”模式，其中主域控制器（DC）保存所有机器、网络、队列等等的目录。
   
   
2. “工作组”模式，用于单独的 MSMQ 操作或 DC 无效时。

如果您有一个选项，在“活动目录”模式下安装 MSMQ。阅读下面的知识库文章可以获得更多信息。

参考

基本知识：确定是否在工作组或域模式下安装了 MSMQ 2.0 (Q248500)（英文）
信息：对 MSMQ 2.0 中 MSMQ COM 组件的改动 (Q247780)（英文）

构造异常类

“排队组件”有处理客户机（记录程序）端和服务器（回放）端异常的机制。该机制依赖于称为 IPlaybackControl 的接口和排队对象的“异常类”配置。

“异常类”是为了处理客户机或服务器上的错误而调用的 COM 对象。可在属性中指定它的 ProgID 或 CLSID（参见下面的图 2）。

图 2.为 Bank.CTransfers 指定异常类

为了获得最大效果，异常类必须支持两个（或更多）接口 — IPlaybackControl 以及排队对象的接口。例如，如果对象称为 CTransfers，那么它的异常类最好实现 IPlaybackControl 和 _ Ctransfers。下划线是 VB 添加的，用于命名类的默认接口。

Implements IPlaybackControl
Implements _CTransfers

IPlaybackControl 是有两个方法（FinalClientRetry 和 FinalServerRetry）的简单接口。QC 使用该方法通知正在处理客户机端或服务器端错误的异常类。在处理错误时，QC 首先将创建异常类的实例，根据需要调用 IPlaybackControl_FinalClientRetry 或 IPlaybackControl_FinalServerRetry，然后调用自定义接口（在 MSMQ 消息中记录）上的方法。

异常类的主要目的是：

• 提供要尝试什么操作的有用信息，例如方法调用、参数等等。在服务器上完成这项任务的最有效方式是将方法调用和参数记录在已知的日志中。在客户机上，该日志应该得到检查，并且将失败通知给最终用户，允许用户选择取消全部操作或者重试它。
  
  
• 提供错误发生的上下文信息。这是通常的记录，例如时间、计算机、线程 ID、活动 ID 等等。

在客户机上，当 MSMQ 不允许将消息传递到服务器队列时将发生 QC 错误（为安全起见是一个很好的例子），或者长时间过去了还没有连接到服务器。在消息的生存时间超时之前，或者如果服务器拒绝消息（安全性问题或者如果目标队列已经删除），MSMQ 将在出站队列中保留消息。默认的生存时间是数年，除非已经改写了队列别名中的到达队列时间消息属性。

在执行记录的调用的服务器上，QC 有一种重试机制，它每当被调用的方法返回错误、调用者没有得到验证或者事务失败时便开始工作。

参考

处理服务器端的错误（英文）
持续客户端失败（英文）
IPlaybackControl 引用（英文）
有害的消息（英文）

排队组件如何影响事务

当客户机通过 COM 或 DCOM（与排队组件相对）调用组件的事务行为时，可能会遇到很大的改变。

在被排队组件调用时，COM+ 播放器（读取 MSMQ 消息并执行您的组件上的记录的调用的基础结构代码）将在正确创建排队组件时开始新的事务。

这说明如果组件标记为“支持事务”，那么在被非事务 COM 客户机调用时，组件不会在事务下运行。但在作为排队组件调用时，组件将在事务下运行。

如果这不是预期的，并且改变了您预期的对象行为，那么请重新评估对象的事务设置。对象的事务属性不应该取决于它的调用者。

还有另一个问题要记住。当事务服务器端的组件通过 QC 调用其他服务器组件时，就存在两个不同的事务。调用者事务和排队组件的（被调用者）事务。请记住，它们是两个不同的事务。也可以认为该消息传递了事务的本身。第一个事务的失败将导致 MSMQ 消息无法传递，从而服务器对象不会执行。

如果第一个事务成功提交，那么将传递 MSMQ 消息。在接收端，播放器将开始第二个事务。第二个事务中的任何失败都不会对第一个事务有丝毫影响。

理解排队组件安全性的基本原理

在通过 DCOM 和通过排队组件调用对象时，安全性的工作情况会有所不同。在客户机上进行（或者记录）调用时，不会有安全性检查，因此所有方法调用似乎都会成功。QC 记录器在消息中注册了两个身份：在客户机上进行 QC 调用的身份和发送 MSMQ 消息的身份。

它们通常是相同的，但是当使用进程外服务器时，它们会有所不同。例如，如果与您交互的客户机有标识为 X 并且创建了 QC 实例的进程外服务器，那么您就是调用者，X 便是发送者。

如果两者是相同的，QC 播放器将根据方法的角色集来检查该身份，允许适当的访问。如果它们不相同，那么只有当消息发送者身份（在前面的例子中是 X）是服务器上“系统应用程序”的“QC 信任的用户”角色时，QC 才允许调用。

如果 QC 允许在服务器上执行调用，那么组件就可以使用 ObjectContext 的所有安全属性，例如 IsCallerInRole 来执行它的任务。

如果在调用中注册的身份与角色不符，或者发送者不受信任，那么会得到拒绝访问的错误。在设计应用程序时，请记住只有在服务器上传递和处理消息时才会发生这种情况，与客户机完全无关。

在所有 QC 情况下，由于实际调用者不存在（调用是从 MSMQ 消息中分析得到的），因此“模拟”是不可能的。

操作方式

在设计断开连接的应用程序时，请考虑到安全性是在服务器上、而不是客户机应用程序的控制范围内得到检查的。

参考

使用排队组件的安全性（英文）

仔细调试 QC

在调试排队组件时，请注意超时。简单来说，播放器启动事务。如果调试代码的时间太长，那么会超出事务的“分布式事务协调器 (DTC)”超时。这将导致事务失败，而且 QC 将重试回放消息。默认情况下 DTC 超时配置为 60 秒，这对任何相关调试来说都是不够的。

操作方式

在调试 QC 服务器时，请将 DTC 超时设置为大的值。从“我的电脑”中“组件服务 MMC 管理单元”的属性表上可以设置该值。通过“选项”选项卡上的“事务超时”可以输入以秒计的超时值。输入“0”将禁用超时。

该问题的典型症状是：

• “DTC 统计”上的“事务放弃”计数器在没有明显原因的情况下增加。
  
  
• 调用组件的异常类。

将应用程序标记为接听

在配置排队组件时，可能需要做的一件事情是将 COM+ 应用程序标记为“接听”。这样应用程序就可以监视 MSMQ 队列，并在 QC MSMQ 消息到达时自动选取和回放它。通过“COM+ 应用程序”属性页的“排队”选项卡可以将 COM+ 应用程序设置为“接听”，如图 3 所示。

如果不这样标记，那么包含记录的调用的消息将堆积在应用程序的 MSMQ 队列中，而得不到处理。

图 3. 将 COM+ 应用程序标记为接听 QC 消息