让WCF服务知道SQL Server Service Broker消息已到达

Question

我正在研究从NServiceBus迁移到SQL Server Service Broker。

我遗失的一件是“提升事件”部分。当消息到达NServiceBus时，它会在我的代码中引发一个事件。这很有效。

对于SQL Server Message Broker，我可以想到两种方法：

• 创建一个CLR sproc以让我的SQL Server调用我的WCF服务
• 让我的WCF服务不断轮询数据库以查看是否有新消息。
  • 这可能会在WCF中出现超时问题。

我已经尝试了第二个选项与其他应用程序（不是Service Broker应用程序），但效果不佳。

我最喜欢第一个，但对我来说似乎非常传统。

在我开始编码之前，我想我会问我是否错过了这里的大图。其他应用程序如何使用SQL Server Service Broker执行此操作？

注意：我目前使用NServiceBus解决方案每天处理大约50万条消息。我需要我的解决方案足够强大，以处理那种通过。

Answer 1

使用SQL Server Service Broker，您无需轮询。 WAITFOR (RECEIVE ...)构造是非轮询并阻塞，直到消息可用于处理（不仅仅是'到达'，它还考虑correlated locking）。 Service Broker还使用internal activation，完全无需外部服务，并按需自动运行代码。为了记录，我知道使用Service Broker和激活的系统每分钟处理1/2万条消息。

但尚不清楚所有这些如何与WCF集成。如果两个端点都是使用SQL Server Service Broker进行通信的SQL Server实例，则WCF没有太多空间。

Answer 2

我很好奇 - 是什么让你决定离开NServiceBus？

另外，您是否考虑过使用SQL Server传输（v4中的新增功能）来处理此集成方案？最后，我建议从讨论组中查看这个帖子以获得一些指示：

http://groups.yahoo.com/neo/groups/nservicebus/conversations/topics/17931

Answer 3

Service Broker External Activator怎么样？如果你想尝试一下，那么方法将是......，

1. 创建一个EXE，我更喜欢的控制台或Windows，但最好是启用命令行。
2. 创建实际的消息队列，并在外部激活队列填充消息后立即推送消息。 创建单独队列的原因是因为Microsoft提供的解决方案无法使用命令行将消息传递给其他应用程序，如果我们从MS获取源代码，那么它将成为良好的增强和完整的解决方案。 < / LI>

   它将如何运作......？

   1. Windows服务正在不断轮询外部激活 队列，收到一条消息，它将执行EXE [在服务配置中指定]。
   2. 将立即从外部激活队列中清除消息，执行的应用程序将调用WCF服务。
   3. WCF服务将读取排队的实际消息并启动其进程。
   4. 让WCF调用async，以便启动器exe不会持续很长时间[如果你需要异步，请选择你]

   注意：您必须小心设置configuration外部激活窗口服务。

   没有Service Bus这是唯一有效的解决方案，我们确实使用过它。