我正在快速尝试使用消息传递系统来处理流程良好的文件,这些文件采用了良好的解耦工作流系统。
使用上述框架的优缺点是什么?相比使用手动编写的MSMQ系统和带有WCF绑定和/或非MSMQ解决方案,使用它们的优势是什么?
我正在快速尝试使用消息传递系统来处理流程良好的文件,这些文件采用了良好的解耦工作流系统。
使用上述框架的优缺点是什么?相比使用手动编写的MSMQ系统和带有WCF绑定和/或非MSMQ解决方案,使用它们的优势是什么?
我建议避免使用手写解决方案,因为需要正确处理许多相当困难的问题,比如如何处理事务、异常如何导致回滚、如何停止无限回滚(毒消息)、如何与长时间运行的工作流程集成,以便状态管理边界对齐等等。
你可能需要一些持久化/事务性消息基础设施,如果不使用 MSMQ,则在 Microsoft 平台上,你只能选择 Service Broker 或其他替代方案,如 ActiveMQ。MSMQ 的好处是已经安装在所有 Windows 机器上,而 Service Broker 并没有。
在选择 NServiceBus、Mass Transit 和 Rhino Service Bus 之间,这个 Stackoverflow 答案比较 NServiceBus 和 MassTransit 是一个很好的开始。
在我们的 3.1 版本中,我们正在引入 NSB Studio - 一组 Visual Studio 集成建模工具,使你能够以更高层次的抽象来建模系统,并自动完成大部分 NServiceBus 的配置和初始化。我认为这真的让 NServiceBus 占据了优势。
免责声明:我是 NServiceBus 的作者。
NServiceBus是一个很好的产品,但要注意许可证问题。它有改变许可政策的倾向,根据作者的意愿。例如,可以查看旧版的许可信息。
在项目开发过程中可能会发现需要为NServiceBus支付大量费用。
免费版本也有性能限制。
MassTransit绝对免费开源,没有限制,并且是根据Apache 2.0许可证发布。
我没有使用Rhino Service Bus。
关于Rhino和NServiceBus的最新情况更新:
http://www.infoq.com/news/2012/04/nservicebus3-0
InfoQ询问Ayende:您以前为.NET编写过一个服务总线,即Rhino Service Bus。现在,Rhino Service Bus的用户是否应该重新考虑并转移到NServiceBus上?
Ayende回答:我建立Rhino Service Bus是在2008年左右,主要是因为当时我对其他服务总线的状态不满意,但那已经是4年前的事了。在此期间,我认为NServiceBus在成为易于使用的产品上取得了很大进展,并且具有更好的开箱即用的开发体验。如果我今天重新开始使用服务总线,我强烈怀疑我会自己构建。