不使用 MSMQ 的 NServiceBus 替代方案

发布于 2024-08-06 01:49:06 字数 238 浏览 8 评论 0 原文

我认为标题概括了这一切......我们有一个 .NET 2.0 系统试图实现分布式发布/订阅模型。我遇到了 NServiceBus、RhinoBus 和 MassTransit。不幸的是,这些是基于 MSMQ 的。我的任务是找出使用不同消息传递替代方案的 pub/sub 替代方案...

寻求 MSMQ 替代方案的唯一原因是克服消息大小限制。由于我们的企业应用程序消息可能会由于每条消息的限制而被截断......

非常感谢任何指导

I think the title sums it all .... We have a .NET 2.0 system trying to implement a distributed pub/ sub model. I came across NServiceBus, RhinoBus and MassTransit. Unfortunately, these are MSMQ based. I am tasked to figure out pub/ sub alternatives that uses a different messaging alternatives ...

the only reason for seeking MSMQ alternatives is to overcome the message size restriction. Since our enterprise app messages can potentially get truncated due to per message restriction...

any guidance is much appreciated

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(7

晨光如昨 2024-08-13 01:49:07

呵呵,老问题了,但值得一提的是,NServiceBus 现在正在与其他开发者一起支持 ActiveMQ(作为一种替代方案)。也有人讨论实施“数据总线”来克服消息大小限制,但我不知道这的状态。

基础设施已经到位,可以插入不同的传输,我记得看到过有关使用 Sql Server Service Broker 的讨论,尽管我不知道这是否超出了最初的讨论。

Heh, old question, but worth mentioning that NServiceBus is now supporting ActiveMQ (as one alternatives) with others in development. There has also been talk of implementing a "Data Bus" to overcome the message size limitation, but I don't know the status of this.

The infrastructure is in place to plug in different transports, and I recall seeing discussions about utilizing Sql Server Service Broker, though I don't know if that was ever taken beyond initial discussions.

南风起 2024-08-13 01:49:07

NServiceBus 有一个路线图,其中指出他们打算提供一种更具可插拔性的传输,以允许替代方案MSMQ。

大众运输公司还表示,他们的目标是支持替代方案。

不幸的是,这些都还不存在。

There is a Roadmap for NServiceBus that states they intend to offer a more pluggable transport to allow alternatives to MSMQ.

MassTransit also suggest they are aiming to support alternatives.

Unfortunatley none of these are there yet.

云朵有点甜 2024-08-13 01:49:07

老问题但值得提供最新的答案。对于那些开发企业级应用程序的人来说,Windows Azure 服务总线自诞生以来确实取得了长足的进步,对于任何有兴趣实现发布/订阅模型的人来说,它都值得仔细研究。以下是 Windows Azure 服务总线的一些亮点...

  • 包括 Windows Azure 工具 SDK for .Net,这使得使用任何 .Net 语言进行开发都变得非常容易。

  • 有一个浏览器工具 这是一个 GUI 界面,可以轻松管理和测试队列。一个版本直接内置于 Visual Studio 中,另一个版本是独立应用程序。

  • 包含三种消息传递模型

    • 中继 - 旨在在本地应用程序和云应用程序之间进行通信
    • Pub/Sub - 在 Azure 中称为“主题”,它提供消息传递的发布/订阅模型。
    • 经纪人消息传递 - 消息传递分离,发送者和接收者不必同时在线。
  • 支持事务行为(保证消息传递)

  • 最重要的是,微软看到了云计算的未来,所以这只会变得更好。

  • 该技术最大的缺点是 Windows Azure 是为大型企业环境设计的,因此非常昂贵。

这是一个很好的网站,提供了有关 Windows Azure 服务最新功能的更多详细信息巴士

顺便说一句:我不以任何方式隶属于微软。我刚刚有使用 NServiceBus 的背景,发现很容易过渡到 Windows Azure 服务总线,因为模型相似。

Old question but worth provinding an up to date answer. For those developing enterprise level applications, Windows Azure Service Bus has really come a long ways since its inception and it is worth taking a close look at for anybody interested in implementing a pub/sub model. Here are some highlights of Windows Azure Service Bus...

  • Includes a Windows Azure Tools SDK for .Net which makes development very easy in any .Net language.

  • There is an Explorer Tool which is a GUI interface that provides ease of managing and testing your queues. One version is built right into Visual Studio and another is a stand-alone application.

  • Contains three messaging models

    • Relay - Designed to communicate between on-premise applications and cloud applications
    • Pub/Sub - Known as "Topics" in Azure, it provides the publish/subscribe model of messaging.
    • Brokers Messaging - decoupled messaging where the sender and reciever do not have to be online at the same time.
  • Supports transactional behavior (guarateeed delivery of messages)

  • Best of all, Microsoft sees a future in cloud computing so this will only get better.

  • The biggest disadvantage of this technology is that Windows Azure is designed for large scale enterprise environments and therefore is very expensive.

Here is a good web site that provides much more details about the latest capabilities of Windows Azure Service Bus

BTW: I am not affiliated with Micrsoft in any manner. I just come from a background of using NServiceBus and found it very easy to transition to Windows Azure Service Bus as the models are similar.

奈何桥上唱咆哮 2024-08-13 01:49:07

如果您有预算,您可以随时使用 Biztalk。

如果你想做一些更有趣的事情,你可以使用 Microsoft Azure 服务总线 http://www.microsoft .com/azure/servicebus.mspx

您可以使用 SQL 服务代理 http://msdn.microsoft.com/en-us/library/ms345108(SQL.90).aspx 。不确定是否有计划停止此功能。

或者,如果您想要最简单的方法,请使用 sql 表:)

If you have the budget for it you can always use Biztalk.

If you want to do something more interesting you could use Microsoft Azure Service Bus http://www.microsoft.com/azure/servicebus.mspx

You could use SQL service broker http://msdn.microsoft.com/en-us/library/ms345108(SQL.90).aspx . Not sure if there was a plan to discontinue this finctionality.

Or it you want the simplest thing that works, use a sql table :)

蘸点软妹酱 2024-08-13 01:49:07

我为此使用了几个数据库表。

I use a couple of database tables for this.

相思故 2024-08-13 01:49:07

如果您同意“经纪人”类型的方法,我目前正在查看 http://wso2 .com/products/enterprise-service-bus/ ??

If you are OK with a "broker" type approach I am currently looking at http://wso2.com/products/enterprise-service-bus/ ??

意犹 2024-08-13 01:49:07

我目前正在开发一个基于 WCF 的开源服务总线。您可以在这里找到它:http://rockbus.codeplex.com/。它支持动态(@运行时)订阅、订阅存储库(数据库)、可插入传输、基于 XPath 的基于内容的路由、通过 WCF 协议的事务交付、循环交付、可插入订阅评估等。看看吧!

I'm currently working on an open source WCF based service bus. You can find it here: http://rockbus.codeplex.com/. It supports dynamic (@run-time) subscriptions, subcription repository (database), pluggable transports, XPath based content-based routing, transactional delivery over wcf protocols, roundrobin delivery, pluggable subscription evaluation, and more. Have a look!

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文