Service Broker 发送的所有消息都是会话的一部分。 对话是两个服务之间的会话。 对话是两个服务之间可靠而持久的双向消息流。
对话提供一次顺序 (EOIO) 消息传递功能。 对话使用会话标识符和包含在每条消息中的序列号来标识相关的消息，并以正确的顺序传递这些消息。 对话是两个服务之间可靠的、持久性消息流。
对话会话有两个参与者。 “发起方”发起会话。 “目标”接受发起方发起的会话。 参与者是否发起会话决定该参与者可发送的消息，如会话约定中所指定的。 下面的关系图显示对话的消息流：
应用程序作为对话的一部分来交换消息。 当 SQL Server 接收到对话的消息时，会将该消息放入对话的队列中。 应用程序接收来自队列的消息，并在必要时处理该消息。 作为处理的一部分，应用程序可能会将消息发送到对话中的其他参与者。
可靠交付
对话包含自动消息回执确认，以确保可靠的传递。 Service Broker 将每个待发消息都保存在传输队列中，直到远程服务确认该消息。 有了这些自动确认消息，应用程序就不必再显式确认每条消息，从而可节省时间和资源。 在可能的情况下，确认消息可包含在对话的返回消息中。
注意
Service Broker 在内部处理确认消息。 这些消息不会显示在队列中，不会传递到应用程序。 Service Broker 不认为远程服务无法访问错误。 当远程服务无法访问时，Service Broker 会为该服务保存消息，直到该服务可访问或对话生存期过期为止。
对话生存期
消息在对话生存期期间可以在应用程序间进行交换。 对话生存期从本地 SQL Server 实例创建该对话时起，一直持续到应用程序显式结束该对话或收到与该对话关联的错误消息时为止。 每个参与者均有责任在应用程序收到指示错误的消息或结束会话的消息时显式结束会话。 在大多数服务中，其中一个参与者负责通过无错误地结束会话，指示会话完成且成功。 这是由目标还是发起程序完成，取决于会话的目的。
起始应用程序发起对话时，它的本地 Service Broker 会为该对话创建一个会话端点。 目标应用程序的本地 Service Broker 会在其实例收到该对话中的第一条消息时，为该对话创建一个会话端点。
对话还可以保证会话的生存期不超过指定的限制。 起始应用程序可以选择指定对话的最长生存期。 本地 Service Broker 和远程 Service Broker 都会跟踪此生存期。 当对话在最长生存期内保持活动状态时，对话的每一端都会在服务队列上显示超时错误消息，并拒绝对话的新消息。 对话永远不会超过对话启动时建立的最大生存期。 虽然会话结束后应用程序仍然可以接收已有的消息，但不会有新的消息进入该会话。 应用程序无法发送有关聊天的消息。
应用程序负责通过显式结束对话来指示何时完成对话。 Service Broker 永远不会自动结束对话。 对话将保留在数据库中，直到应用程序显式结束会话为止。 因此，即使对话超时或中转站报告错误，对话中的每个参与者也必须显式发出 END CONVERSATION 声明。
对话计时器
利用“会话计时器”，应用程序可以在特定时间接收消息。 会话计时器过期时，SQL Server 会在启动会话计时器的终结点的会话队列中插入会话的消息。 应用程序可以将会话计时器用于任何目的。 会话计时器的一个常见用途是响应远程服务响应的延迟时间。 另一个常见用途是创建以设定间隔向远程服务发送消息的服务。 例如，服务可以使用会话计时器，每隔几分钟报告一次 SQL Server 的当前状态。 应用程序还可以使用会话计时器在特定时间激活存储过程。 这使 Service Broker 可以支持预定活动。
会话中的每个参与者在每个会话中都可设置一个会话计时器。 对话计时器不会与其他参与者共享，会话计时器不会影响会话生存期。 相反，当计时器过期时，本地 Service Broker 会将超时消息添加到本地服务的队列中。 超时消息具有类型名称 https://schemas.microsoft.com/SQL/ServiceBroker/DialogTimer