使用BizTalk而不是NServiceBus或MassTransit的优点/缺点

Question

我很好奇,如果它甚至考虑BizTalk实现发布/子消息传递架构(基本上你可以用NServiceBus或MassTransit做我真正需要的).我的经理倾向于坚持直接从微软提供的框架,因此作为我尽职调查的一部分,我需要为双方提供一套良好的利弊.任何指导将不胜感激!

Answer 1

Broker的主要缺点之一是版本和升级非常困难.您必须停止消息流以升级特定端点.服务总线允许端点自治并独立升级.

然后在规模方面存在差异.对于Broker而言,倾向于将这些(垂直)扩展到服务总线,而服务总线是为扩展(水平)而构建的.您还必须通过某种HA设置(通常是群集)使Broker高度可用.这与软件成本相结合可能会成本相当高昂.

特别是NSB将提供付费支持模式,因此如果您的经理对于在出现问题时没有人在另一端有人感到紧张,您可以购买支持.

Answer 2

Biztalk是一个经纪人,更适合在不同商业服务范围内的EAI.服务总线根本不同.可以在这里找到比较:

http://docs.particular.net/nservicebus/architecture/nservicebus-and-biztalk

如果您可以分享您的一些要求,我可以提供更多指导.

Answer 3

值得注意的是,BizTalk是企业应用程序集成的服务器产品(EAI - 正如Andreas所提到的).它比框架更复杂,更复杂.

Microsoft确实可以在BizTalk中使用企业服务总线工具包,以便您可以将您的BizTalk环境称为ESB.他们认为"ESB"可能不是您认为的ESB.您可以查看他们的ESB工具包页面(http://msdn.microsoft.com/en-us/biztalk/dd876606.aspx),但它包括以下内容:

• 动态(即在运行时)消息转换和转换.
• 消息路由可以是基于内容的,基于行程的,或基于上下文的,并且在运行时确定.

当然,发布 - 订阅模式与使用服务总线不同.

的BizTalk 确实做酒馆子好了,无论是否使用ESB工具包.将单个消息发布到BizTalk"消息框"非常简单,并将消息路由到任何和所有订阅者.pub-sub解决方案意味着BizTalk充当代理,但这有助于确保不会错过消息,并跟踪所有消息.BizTalk pub-sub解决方案具有内置的可扩展性点,允许我们添加,更改或删除端点,而不会影响解决方案的其余部分.

总而言之,您的要求可能无法规定广泛的消息可靠性,监控和跟踪,因此可能BizTalk不是最适合您的.这是一项巨大的投资,由于该产品可以同时完成许多不同的事情,因此乍看之下可能令人生畏.

刚刚出版了一本名为"微软平台上的应用架构模式"的新书,其中涵盖了大部分内容.其中一本书的作者Richard Seroter也发布了带有BIzTalk Server 2009的SOA模式,如果你决定为你的公司选择BizTalk,这将是必不可少的阅读.

Answer 4

我和Andreas在一起 - BizTalk通常更适合'增值'集成和业务流程管理,而不是ESB类型的活动.BizTalk擅长:

• BPEL
• 长期运行/补偿交易
• EAI
• 经纪/制图
• 协议更改(MQ到WCF,平面文件到SAP等)
• EDI,RFID

但是,已经努力将BizTalk用作服务总线,尤其是ESB工具包