创建 Service Broker 消息类型
“消息类型”定义特定类型消息的名称以及 Service Broker 对该类消息执行的验证。若要确定您的应用程序要使用的消息类型，请首先规划应用程序必须执行的任务以及执行每个任务所需的数据。
应用程序的最常用方法是组织这些消息，以便每个消息都包括任务的一个步骤所需的信息。如果每个消息包含任务的一个步骤的信息，则应用程序可以轻松地接收消息，完成步骤，并在一个事务中发送响应。因此，对于许多应用程序来说，确定消息类型和消息内容的最简单方法是确定应用程序执行的任务的事务边界。每个不同的步骤为一个事务，每个事务与服务之间互相交换的消息类型相对应。状态信息、结果或输出也属于消息类型。
Service Broker 通信协议旨在使用此消息处理样式。对话协议将大消息分成片段以便于传送，并保证大消息不会阻止小消息进行传输。
选择验证类型
为消息指定何种验证类型取决于消息的内容。通常的做法是在测试过程中使用最具限制性的验证，然后选择限制性较小的验证，以便在部署应用程序时提高性能。例如，可以通过用于指定 NONE 验证的消息正文的形式交换类型化的 XML 文档。在这种情况下，您的应用程序会在处理 XML 时验证该消息。
消息的网络格式包括消息类型的名称。因此，通常对消息类型名称进行选择以避免出现排序规则问题和命名冲突问题。有关命名的详细信息，请参阅 命名 Service Broker 对象。
指示成功和失败
应用程序通常不会定义新的消息类型来指示成功或失败，而是使用 END CONVERSATION 语句来指示会话的完成和任务的成功完成。如果任务失败，请包括 WITH ERROR 选项以在会话中返回错误消息。
通常，只有一个会话参与者可以在任务完成时结束会话。而另一个参与者只能发出 END CONVERSATION 以响应 End Dialog 或 Error 消息。服务的文档通常在会话成功完成时指定由哪个参与者结束会话。此文档旨在帮助避免出现任一参与者结束会话，或一个参与者结束会话而另一个参与者仍继续执行任务的情况。两个端点必须都能够处理错误消息，因为 Service Broker 内部消息已传递给两个端点。例如，如果在对话框关闭之前对话生存期过期，则两个端点均会收到一条 Service Broker 错误消息。
任一参与者可以随时结束出现错误的会话。有关处理 Service Broker 错误消息的讨论，请参阅处理 Service Broker 错误消息。