我是一个sql Server Service Broker新手，我试图把握最好的方式来设置Service Broker(看似简单)的用例：我想创建一个简单的工作队列，其中一个应用程序将工作项目放入队列和单独的应用程序从该队列中拾取工作项并处理它们。第一个应用程序不需要从第二个应用程序获取状态消息。我希望队列生活在一个单一的sql Server实例中。
最让我困惑的是如何对话/对话与这种情况有关。我知道您只能在对话/对话框的上下文中发送/接收消息，但由于两个应用程序之间没有任何来回的喋喋不休，所以创建新会话的正确时间是什么时候都感到失落。两个极端的选择似乎是：
>每次我排队一个工作项，我开始一个新的对话。所以每个对话最终都只有一个消息。
>在部署时，我手动创建一个无限寿命的会话。当它是排队工作项目的时候，我总是发送它作为单一对话的一部分。
去这些路线的后果是什么？
此外，在第一种情况下，似乎我需要做一些END CONVERSATION，以使sql Server能够在内部清理资源。有没有什么指导，什么时候把这些放在正确的地方？ (或者最终可能依靠谈话超时才能更好吗？)
解决方法
你应该从自己的谈话中的每个工作项开始。生产者(发起者)开始一个对话并发送描述工作项的消息，然后提交。消费者(目标)接收消息(或被激活)，检查有效负载以了解工作项详细信息，执行工作，然后结束对话并提交。所产生的EndDialog消息将被发送回发起程序服务队列，并且启动器队列上的激活过程通过结束发起方的对话来响应。
这是最简单的部署，让它运行起来将确保您有一个良好的基础建立。当生产者进入工作项目时，不要将角落和结束发起方的对话框，这是fire-and-forget and has several draw backs。
如果您具有高性能要求(每秒超过200个请求)，则必须更明确地开始管理对话。我在reusing conversations for performance reasons有一个博客条目。在接收端我建议阅读Writing Service Broker Procedures。
我也有一个博客条目，几乎完成你所需要的，尽管它不调度工作项，而是启动自定义过程：Asynchronous procedure execution。
如果您决定从激活的上下文中使用工作项，从而利用激活的良好的自我平衡功能，那么您需要使用understand the EXECUTE AS context under which activation occurs。
