获取通知
许多应用程序不需要为了接收或处理查询通知而包含代码。当 SqlDependency 对象管理通知订阅时，该对象会自动监视该订阅。通知消息到达后，SqlDependency 对象将调用在 SqlDependency 对象中注册的事件处理程序。使用此方法时，不需要执行特殊工作来接收通知。使用 SqlDependency 的应用程序不需要接收或处理通知消息。
但是，如果应用程序使用通知请求，则该应用程序必须监视队列，并对通知消息做出响应。在这种情况下，需要为接收通知的服务编写处理消息的应用程序。请求通知的应用程序可以是处理消息的应用程序，或者您也可以编写其他应用程序来接收并响应查询通知消息。
SQL Server 使用通知 ID 和已提交的实际查询的组合跟踪通知订阅。如果应用程序使用同一个通知 ID 请求两个不同查询的通知，SQL Server 将使用同一通知 ID 创建两个订阅。但是，如果应用程序使用同一个通知 ID 请求同一查询的通知两次，SQL Server 将使用第二个请求中指定的超时值创建一个订阅。
通常，数据库中运行的应用程序是消息到达后由队列激活的存储过程。这些存储过程可以使用 Transact-SQL 或 .NET 语言之一进行编写。较少使用的方法包括将应用程序作为计划作业运行，或使用启动任务在后台连续运行存储过程。
通常，在数据库外运行的应用程序使用下列方法之一接收消息：
应用程序可以定期轮询队列来查看消息是否已到达。
应用程序可以使用 RECEIVE 语句的 WAITFOR 子句来阻止对 RECEIVE 语句执行批处理或存储过程，直到该语句至少返回一行。
应用程序可以为接收通知的队列上的 QUEUE_ACTIVATION 事件创建事件通知。然后，该应用程序可以使用上面两个策略之一监视接收激活事件的服务。
不太常用的方法包括使用 WMI 监视队列激活，或编写执行某些外部操作的公共语言运行时 (CLR) 存储过程以对消息做出响应。
由于查询通知对话始终包含单个通知消息，因此处理查询通知的应用程序必须在接收消息之后结束会话。否则，对话最终将超时。如果查询通知对话超时，则 SQL Server 会将对话超时错误记录在 SQL Server 错误日志中。
有关编写使用 Service Broker 的应用程序的详细信息，请参阅用 Service Broker 编程的优点。有关如何启动使用 Service Broker 的应用程序的详细信息，请参阅选择启动策略。