本文介绍 Service Broker 激活的选项。
Service Broker 支持异步排队的消息传送。 由于会话可能持续数天、数月甚至数年，因而许多应用程序都使用激活来实现动态伸缩。 本节介绍启动使用 Service Broker 的应用程序的一些常用策略。
启动策略
启动应用程序的策略分为四大类：
内部激活
基于事件的激活
计划任务
启动任务
每种激活策略都具有不同的优点。 应用程序可以合并使用这些策略。 例如，应用程序可以在大多数时间将内部激活与少量队列读取器一起使用，但在一天中的某些时间，它可以启动更多的队列读取器。
内部激活
使用 Service Broker 内部激活时，Service Broker 队列监视器在必要时直接激活存储过程。 这通常是最直接的方法。 通过使用存储过程的直接激活，无需在应用程序中编写其他代码来管理激活。 但是，内部激活要求将应用程序编写为 SQL Server 存储过程。 如果使用内部激活，则将应用程序编写为不再有消息需要处理时退出。
基于事件的激活
某些应用程序在响应特定事件时运行。 例如，可以在计算机上的 CPU 使用率低于特定级别时运行应用程序，也可以在创建新表时运行日志记录应用程序。
Service Broker 外部激活是基于事件的激活的特例。 为了进行外部激活，应用程序在响应 QUEUE_ACTIVATION 事件时启动。
对于可由事件通知触发的事件，可以将基于事件的激活与 Service Broker 内部激活相结合。 在此情况下，可对接收事件通知的队列使用内部激活。 激活存储过程将接收通知消息并启动应用程序。
对于其他事件，可以使用 SQL Server 代理在运行 SQL Server 的计算机上启动作业。 可以编写从远程计算机监视 Windows Management Instrumentation (WMI) 事件的应用程序。 此应用程序可以在发生 WMI 事件时在运行 SQL Server 的计算机上启动任务。
如果使用基于事件的激活，则应用程序通常在不再有消息需要处理时退出。
计划任务
使用预定任务时，应用程序按照设定的计划激活。 此策略对于批处理应用程序非常方便。 作为预定任务运行的应用程序可在不再有消息需要处理时退出，或者程序可在特定时间退出。
例如，如果一个应用程序处理的是发往一个供应商的多个订单，该应用程序可以在白天存储消息，然后在夜间处理消息以将这些订单生成为发往该供应商的单个订单。 在此情况下，该应用程序可以使用 SQL Server 代理作业在每晚的特定时间将其启动。
启动任务
某些应用程序通常在每次计算机启动时或在 SQL Server 启动时启动一次。 这些任务的例子包括 SQL Server 中的启动存储过程、Windows 启动组中的应用程序或 Windows 服务。 在此情况下，应用程序持续保持运行状态，并在消息到达时处理消息。 当消息到达队列时，连续运行的应用程序不需要启动时间。 但是，由于应用程序在没有任何消息时不会退出，因此即使程序没有工作，程序也会消耗资源。
此策略对于处理恒定消息流的应用程序以及对于在启动过程中占用资源相对较多的应用程序可能颇为有用。