订阅处理体系结构

收集完事件之后，Notification Services 就可以处理订阅并生成通知。生成器根据事件对订阅进行评估。

为了生成通知，应用程序开发人员需要为应用程序创建一条或多条规则。这些规则以 Transact-SQL 查询的方式编写，用于指定事件与订阅之间的关系以及生成通知必须满足的任何其他条件。

在简单的应用程序中，如果生成器触发了某条规则，应用程序会根据事件视图中当前显示的一批事件来评估所有可用的订阅。如果其中某个事件与一个订阅相匹配，通知生成器就会创建一个通知。此通知包含有关该事件的数据；此外，还会引用与订阅方、订阅方设备（有时包括还订阅方区域）以及进行分发所需的其他信息相关的数据。

基本订阅处理体系结构

通知不会在创建后立即发送。而是由生成器将通知写入内部通知表。当一批通知准备就绪后，分发服务器就会格式化和分发这些通知。

如果应用程序支持预定的订阅，则当生成器处理预定的订阅时，只会关注那些应进行评估的订阅。例如，如果生成器每 15 分钟运行一次，则生成器会在上午 8:00 对安排在上午 7:45 到 8:00 之间的所有订阅进行评估。

如果应用程序使用了历史数据，则应用程序会将此数据连同事件与订阅信息一起存储在一个补充表（称为历史记录）中，然后使用此数据来生成通知。

具有历史记录的订阅处理

生成器将根据由应用程序定义中的“量程”**持续时间所定义的计划来运行。量程决定了生成器唤醒和触发规则的频率。较短的量程间隔会导致生成器频繁地运行，并消耗较多的系统资源。较长的量程间隔则会导致事件到达与生成通知之间出现较长的延迟。

规则类型

生成器的运行取决于为应用程序定义的规则。可以创建下列类型的规则：

事件规则和预定规则用于指定触发规则后要执行的操作。每个操作都是一个 Transact-SQL 查询，用于定义生成器要执行的一组操作。这些查询可以生成通知，但也可以执行其他操作，例如维护历史记录数据。

事件规则和预定规则可以使用基于参数的简单操作，也可以使用较为灵活的条件操作：

“简单操作”**是指完整定义了通知生成查询（包括所有 WHERE 子句）的 Transact-SQL 查询。简单操作从订阅数据和事件数据获取 WHERE 子句表达式。例如，天气预报应用程序可允许订阅方指定一个市/县，以便接收其天气预报通知。此简单操作查询随后就会使用 WHERE 子句（例如 WHERE subscription.city = event.city），基于市/县名称来联接事件数据和订阅数据。
当规则使用简单操作时，订阅方需要提供查询参数，例如，市/县名称。
“条件操作”**允许订阅方完整定义其查询搜索条件。例如，您可以在订阅管理界面中完全公开事件数据架构，并允许订阅方基于此数据来创建他们自己的搜索条件，例如 WHERE event.State = Washington AND event.LowTemperature < 0。订阅管理界面可以简化这些搜索条件的编写工作，甚至简单到只需要从列表框中选择列和运算符，然后在文本框中输入值。

由于简单操作只生成了一组有限的搜索条件以供生成器进行评估，因此通常比条件操作执行得更好。条件操作功能更强大，但是增加了为事件规则或预定规则评估更多搜索条件的开销。