我的一个要求是在共享托管解决方案中,我能保证的唯一依赖是sql 2005及更高版本…这直接引导我直接进入sql Service Broker.
如果听起来我正试图将ESB功能塞进SSB ……我想我是……
我的问题是：有没有人知道一个.NET API或框架,它位于sql Service Broker之上并且已经提供了大量的管道工程？
如果我使用纯ADO.net,我可以通过调用存储过程将项添加到队列,但是然后：
>对于谈话的性质,我会为每条消息进行一次对话吗？
>如果是,我是否会丢失顺序消息处理？
>我如何接收消息(我知道t-sql中的接收语法),我是否在消息循环中重复调用存储过程以尝试
从队列中获取消息？
>或者我会等待吗？保持连接打开并永久执行存储过程？
> sql Service Broker不支持独白对话,但我读过它们可以实现…
正是这些问题让我希望已经存在一个已经完成所有这一切的.net解决方案.
解决方法
但NServiceBus支持Service Broker作为传输,参见Using NServiceBus and ServiceBroker.net,并且有像A simple wrapper API for SQL Service Broker and an ITransport plugin for NServiceBus这样的github项目.虽然不完全是主流,但确实存在一些支持和社区努力.
作为ESB,我认为由于缺乏真正的pub-sub和广播,你会遇到问题. sql Server 2012能够向多个目标发送消息,请参见如何Multicast messages with SQL Server Service Broker,但您仍需要从头开始实现pub-sub基础结构(发布主题,订阅者等). MySpace做到了这一点并且是一项重大努力,见Scale out SQL Server by using Reliable Messaging.我的观察指的是SSB的低级直接使用,我从未使用过NServiceBus所以我无法分辨它是如何抽象/暴露unicast / broadcast / multicast / pub-sub的SSB.
至于您的具体问题,我建议您阅读Writing Service Broker Procedures和Reusing Conversations.
