对话会话

Service Broker 发送的所有消息都是会话的一部分。对话是两个服务之间的会话。对话是两个服务之间可靠而持久的双向消息流。

对话提供一次顺序 (EOIO) 消息传递功能。对话使用会话标识符和包含在每条消息中的序列号来标识相关的消息,并以正确的顺序传递这些消息。对话是两个服务之间可靠的、持久性消息流。

对话会话有两个参与者。“发起方”发起会话。“目标”接受发起方发起的会话。参与者是否发起会话决定该参与者可发送的消息,如会话约定中所指定的。下面的关系图显示对话的消息流:

发起方与目标之间的消息流

应用程序作为对话的一部分来交换消息。当 SQL Server 接收到对话的消息时,SQL Server 会将该消息放入对话的队列中。应用程序接收来自队列的消息,并在必要时处理该消息。作为处理的一部分,应用程序可能会将消息发送到对话中的其他参与者。

可靠的传递

对话中包含自动消息回执确认信息,以确保可靠的传递。Service Broker 会将每条传出消息保存在传输队列中,直至远程服务对该消息做出确认。有了这些自动确认信息,应用程序就不必再显式确认每条消息,从而可节省时间和资源。在可能的情况下,确认消息可包含在对话的返回消息中。

注意注意

Service Broker 会对确认消息进行内部处理。这些消息不出现在队列中,而且也不传递到应用程序中。

Service Broker 不将无法访问远程服务视为错误。远程服务无法访问时,Service Broker 会保存该服务的消息,直到该服务可访问或对话生存期过期为止。

对话生存期

消息在对话生存期期间可以在应用程序间进行交换。对话生存期从本地 SQL Server 实例创建该对话时起,一直持续到应用程序显式结束该对话或收到与该对话关联的错误消息时为止。每个参与者均有责任在应用程序收到指示错误的消息或结束会话的消息时显式结束会话。在大多数服务中,其中一个参与者负责通过无错误地结束会话,指示会话完成且成功。此操作是由目标执行还是由发起方执行取决于会话的目的。

起始应用程序发起对话时,它的本地 Service Broker 会为该对话创建一个会话端点。目标应用程序的本地 Service Broker 在其实例收到该对话中的第一条消息时,为该对话创建一个会话端点。

对话还可以保证会话生存期不超出指定的时限。起始应用程序可以选择指定对话的最长生存期。本地 Service Broker 和远程 Service Broker 都会跟踪此生存期。如果对话在到达最大生存期时仍处于活动状态,会话的每一端都会将一条超时错误消息放在服务队列中,并拒绝新的对话消息。会话的生存时间从不会超出在对话开始时所建立的最大生存期。请注意,虽然会话结束之后应用程序仍可接收该会话的消息,但不会有该会话的新消息到达,应用程序也无法再发送有关该会话的消息。

应用程序负责通过显示地结束对话,来指示它们结束对话的时间。Service Broker 从不自动结束对话。对话将保留在数据库中,直到应用程序显式结束会话为止。因此,即使在对话超时或 Broker 报告错误时,会话中的各参与者也必须显式发出 END CONVERSATION 语句。

会话计时器

利用“会话计时器”,应用程序可以在特定时间接收消息。会话计时器到期时,SQL Server 会在启动会话计时器的端点处将一条会话消息插入到会话队列中。应用程序可以将会话计时器用于任何目的。会话计时器的一个常见用途是响应远程服务响应的延迟时间。另一个常见用途是创建以设定间隔向远程服务发送消息的服务。例如,服务可以使用会话计时器,每隔几分钟报告一次 SQL Server 的当前状态。应用程序还可以使用会话计时器在特定时间激活存储过程。这使 Service Broker 可以支持预定活动。

会话中的每个参与者在每个会话中都可设置一个会话计时器。会话计时器不与其他参与者共享,而且会话计时器不影响会话的生存期。当计时器过期时,本地 Service Broker 会将一条超时消息添加到本地服务队列中。超时消息的类型名称为 https://schemas.microsoft.com/SQL/ServiceBroker/DialogTimer