SQL Server Service Broker 为消息和队列应用程序提供 SQL Server 数据库引擎本机支持。这使开发人员可以轻松地创建使用数据库引擎组件在完全不同的数据库之间进行通信的复杂应用程序。开发人员可以使用 Service Broker 轻松生成可靠的分布式应用程序。
使用 Service Broker 的应用程序开发人员无需编写复杂的内部通信和消息，即可跨多个数据库分发数据工作负荷。因为 Service Broker 会处理会话上下文中的通信路径，所以这就减少了开发和测试工作。同时还提高了性能。例如，支持网站的前端数据库可以记录信息并将进程密集型任务发送到后端数据库以进行排队。Service Broker 确保在事务上下文中管理所有任务以确保可靠性和技术一致性。
1.会话体系结构
所有 Service Broker 应用程序都通过“会话”（即可靠的、长时间运行的异步消息交换）进行通信。Service Broker 在会话中使用以下对象。
| 对象 | 定义 |
|---|---|
| 消息 | 消息是服务间交换的数据。 每个消息都属于一个会话，并具有特定的消息类型。 |
| 对话会话 | 对话是两个 Service Broker 服务间的双向会话。 对话为 Service Broker 提供了一次顺序 (EOIO) 消息传递功能。 每个对话属于一个会话组，并遵循特定的约定。 |
| 会话组 | 会话组标识共同完成同一项任务的多个会话。Service Broker 使用会话组来管理消息锁定，这可以帮助应用程序开发人员管理并发。 应用程序开发人员还利用会话组协助管理状态。 |
2.服务体系结构
- 消息类型 — 定义应用程序间交换的消息的名称。 还可以选择是否验证消息。
- 约定 — 指定给定会话中的消息方向和消息类型。
- 队列 — 存储消息。 这种存储机制使服务之间可以进行异步通信。Service Broker
队列还有其他优点，比如自动锁定同一个会话组中的消息。 - “服务”— 是可寻址的会话端点。Service Broker 消息从一个服务发送到另一个服务。
服务指定一个队列来保存消息，还指定一些约定，约定指明该服务可作为“目标”。 约定向服务提供一组定义完善的消息类型。
在设计时，Service Broker 应用程序指定以下对象：
Service Broker 应用程序使用上述列表中的 SQL Server 对象进行会话。 SQL Server 中任何可运行 Transact-SQL 语句的程序均可使用 Service Broker。 应用程序可以是以 Transact-SQL 编写的或以符合 CLR 的语言编写的存储过程，也可以是连接到 SQL Server 实例的外部程序。
以下关系图说明 Service Broker 服务：
如图所示，ProcessExpenses 约定指定三种消息类型：SubmitExpense、AcceptDenyExpense 和 ReimbursementIssued。 该约定列出执行退款任务的会话所需的消息类型。 ProcessExpenses 约定控制 ProcessExpense 服务和发起与 ProcessExpense 服务间会话的任何服务之间的所有会话。 ProcessExpense 服务将传入消息和传出消息存储在 ExpenseQueue 队列中。 ExpenseProcessing 存储过程从此队列接收消息并处理消息，在需要答复的情况下再将消息发回队列以路由到相应的 Broker。
网络传输与远程安全机制
| 主题 | 说明 |
|---|---|
| 远程服务绑定 | 说明如何设置 Broker 用于建立对话安全模式的证书。 对话安全模式为到特定服务的会话提供端到端的加密和远程授权。 |
| 路由 | 说明如何指定服务及包含服务的数据库的位置。 Service Broker 传递消息时需要路由。 默认情况下，每个数据库都包含一个路由，该路由指定未定义其他路由的服务将在当前实例中传递。 |
| Service Broker 端点 | 说明如何配置 SQL Server 以通过 TCP/IP 连接发送 |
生成使用 Service Broker 的应用程序
- 用户通过用户界面提交退款申请。应用程序运行 ExpenseSubmission 存储过程，此过程创建一条 SubmitExpense消息。SubmitExpense 服务启动与 ProcessExpense 服务的会话，然后将 SubmitExpense 消息发送给ProcessExpense 服务。
- Service Broker 接收 ProcessExpense 服务的 SubmitExpense 消息，并将消息放到ExpenseQueue 队列中。ExpenseQueue 队列激活 ProcessExpense 存储过程，此过程将SubmitExpense 消息从队列中取出并进行处理。然后，ProcessExpense 存储过程创建一条AcceptDenyExpense 消息，并将此消息发送到 SubmitExpense 服务。如果支出请求被拒绝，则ProcessExpense 存储过程将结束会话。
- Service Broker 将 SubmitExpense 服务的 AcceptDenyExpense 消息放到该服务的队列中。如果ProcessExpense 过程结束了会话，则 Service Broker 将一条 EndDialog 消息放到 Expenses队列中。该队列激活 ExpenseSubmission 存储过程，此过程将 AcceptDenyExpense消息从队列中取出并进行处理。如果 ExpenseSubmission 存储过程在队列中找到 EndDialog 消息，则此过程就结束会话。
- 如果支出请求被接受，则 ProcessExpense 服务创建并发送一条 ReimbursementIssued消息，确认付款已发出，然后结束会话。Service Broker 将这些消息放到该服务的队列中。此队列激活
ExpenseSubmission 过程，此过程对 ReimbursementIssued 消息进行处理。然后此过程对 EndDialog消息进行处理，并结束会话。
如图所示，首先创建 SubmitExpense、AcceptDenyExpense 和 ReimbursementIssued 消息类型。然后基于这些消息类型创建 ProcessExpenses 约定，它提供一个架构，使会话能够完成退款任务。ProcessExpenses 约定控制 ProcessExpense 服务与 SubmitExpense 服务间的所有会话。ProcessExpenses 约定及其使用的消息类型必须同时存在于特定的数据库中，这些数据库是与拥有基于此约定的会话的所有服务相关的数据库。
Service Broker 在 SubmitExpense 服务的队列中存储发送给该服务的消息。ExpenseSubmission 存储过程接收来自此队列的消息、处理这些消息，如果需要答复的话，则将消息发送到另一服务。
Service Broker 在 ProcessExpense 服务的队列中存储发送给该服务的消息。ExpenseProcessing 存储过程接收来自此队列的消息、处理这些消息，如果需要答复的话，则将消息发送到另一服务。