制定 Service Broker 开发计划
设计 Service Broker 应用程序时，请考虑下列事项：
关于期望的应用程序输入和输出类型以及输入和输出量的标准。
期望的应用程序的要求。
如果您了解这些因素，便可开发出满足业务目标的系统。
计划清单
计划应用程序时，请考虑下列问题：
Service Broker 在应用程序中扮演何种角色？
此问题的答案有助于您计划应用程序使用的消息类型、应用程序的结构以及应用程序的存储和处理需要。
例如，您的应用程序可以使用 Service Broker 将消息保存在队列中直至有可用的资源来处理这些消息，从而处理消息到达速率的峰值。在这种情况下，应用程序使用的消息类型应密切匹配现有应用程序的输入和输出。您可以根据现有的工作负荷估计应用程序的存储和处理需要。
相反，如果设计新的应用程序，请仔细考虑哪些操作最能受益于 Service Broker。使用 Service Broker 经常能在可预测处理时间和可靠性之间达到最佳平衡，而常规应用程序在这种情况下则会完全失败。
例如，联机订单输入应用程序不必完全处理订单，也不必在提交订单时提供最终确认。相反，该应用程序可以将订单提交给服务，由该服务处理订单并通过电子邮件提供最终确认。通过采用这种设计，即使网络问题阻止应用程序确认订单，订单应用程序也可以继续接受订单。网络问题解决后，应用程序便可处理订单。在这种情况下，应用程序的存储和处理需求取决于预期的订单数、每个订单消息的大小以及每个订单所需的处理时间。
会话需要哪些信息才能完成所需任务？各个端点在相互提供这些信息时交换的是怎样的消息架构？
大多数服务交换半结构化信息。因此，XML 编码是一个不错的选择。二进制编码对于交换二进制文件（如图像）非常有用。当消息仅传达其到达的情况时，请使用空消息。
通过选择正确的消息类型，以后很可能就不用更新应用程序。根据消息类型编码，更新可包括任何内容，从必须更新 XML 架构文件到必须对应用程序进行重大的编码更改。如果有些数据项虽然目前并不需要但以后可能需要，则有必要包括它们。如果在架构中一开始定义这些元素，则在支持它们时将不必更改架构。
消息处理逻辑将在何处运行？
您可以将应用程序设计为由 Service Broker 激活的存储过程、后台服务、预定的事件或外部应用程序。最终的决定取决于 Service Broker 在应用程序中所扮演的角色。例如，如果应用程序处理以可预测的速率到达的连续消息流，则可以使用后台服务。如果应用程序必须根据到达的消息数进行动态伸缩，则可以使用由队列激活的存储过程。如果应用程序在队列中保留消息，并在设置时间处理所有消息，则可以使用预定的事件来启动该应用程序。
如果程序需要访问数据库外部的资源（如网页或文件），则可以使用外部应用程序。使用外部应用程序可提高应用程序的伸缩性，因为处理发生在中间层服务器而非数据库服务器上。扩展使用 Service Broker 的应用程序非常容易，因为 Service Broker 提供了对队列的远程事务访问。可以向数据库发送 Transact-SQL 命令并处理结果的任何应用程序都可以使用 Service Broker。
每个外部程序都与使用队列的其他程序相隔离。因此，外部程序不需要特别的预防措施来管理对队列的访问。另外，如果连接在应用程序处理消息时失败，事务将回滚，Service Broker 将把该消息返回给队列。网络问题不会导致应用程序丢失消息。
您计划采用何种技术来实现应用程序？
您可以采用既能连接到数据库又能在 SQL Server 中运行 Transact-SQL 语句的任何技术来实现外部应用程序。然而，应用程序通常是用与 .NET Framework 兼容的语言及 ADO.NET 语言开发的。您可以用 Transact-SQL 语言或任何一种与 .NET Framework 兼容的语言来实现存储过程。Transact-SQL 可对数据库引擎提供更好的性能。符合 CLR 的语言可为占用大量处理器资源的应用程序提供更高的灵活性、更严格的程序流控制、更好的性能，并可提供对 .NET Framework 的直接访问。
您的应用程序使用得最为频繁的服务器组件将是哪些？
与您的系统管理员进行协作，共同确保有充足的资源来达到最佳的应用程序性能。了解您将使用最为频繁的组件。例如，如果应用程序使用队列来平衡处理工作负荷，或者开启消息保持功能，请确保有充足的磁盘空间可供队列增长。相反，消息传递量较大但队列等待时间较短的应用程序可能使用更多的网络带宽，但会占用更少的磁盘空间。
消息是否具有不同的优先级？
在负荷很重的系统中，Service Broker 会话优先级有助于确保重要的工作不会被大量不重要的工作所阻塞。会话优先级还会启用支持不同服务级别的设计。