I am curious if it even makes consider BizTalk for the implementation of a pub/sub messaging architecture (basically what you can do with NServiceBus or MassTransit is all I really need). My manager tends to want to stick with frameworks provided directly from Microsoft and so as part of my due diligence as to which one to use I need to give a good set of pro/cons for both sides. Any guidance would be greatly appreciated!
问问题
9990 次
4 回答
11
Broker 的主要缺点之一是版本和升级非常困难。您必须停止消息流才能升级特定端点。服务总线允许端点自治并独立升级。
然后是规模上的差异。使用代理的趋势是向上扩展（垂直）而不是为向外扩展（水平）而构建的服务总线。您还必须通过某种 HA 设置（通常是集群）使代理具有高可用性。再加上这样做的软件成本可能会变得非常昂贵。
特别是 NSB 将提供付费支持模式，因此如果您的经理担心在出现问题时没有人在电话的另一端，您可以购买支持。
于 2010-09-14T12:45:24.770 回答
8
Biztalk 是一个代理，更适合不同业务服务范围内的 EAI。服务总线是根本不同的。比较可以在这里找到：
http://docs.particular.net/nservicebus/architecture/nservicebus-and-biztalk
如果您可以分享您的一些要求，我也许可以提供更多指导。
于 2010-09-14T06:21:06.180 回答
7
值得注意的是，BizTalk 是用于企业应用程序集成（EAI——正如 Andreas 提到的）的服务器产品。它比框架更复杂。
Microsoft 确实有可在 BizTalk 中使用的 Enterprise Service Bus Toolkit，因此您可以将 BizTalk 环境称为 ESB。他们认为的“ESB”可能不是您认为的 ESB。您可以查看他们的 ESB 工具包页面 ( http://msdn.microsoft.com/en-us/biztalk/dd876606.aspx )，但其中包括以下内容：
- 动态（即在运行时）消息转换和翻译。
- 消息路由可以是基于内容的、基于行程的或基于上下文的，并且在运行时确定。
当然，发布-订阅模式与使用服务总线不同。
无论您是否使用 ESB 工具包，BizTalk都可以很好地完成 pub-sub。将单个消息发布到 BizTalk“消息框”非常简单，并将消息路由到任何和所有订阅者。pub-sub 解决方案意味着 BizTalk 充当代理，但这有助于保证不会丢失消息，并跟踪所有消息。BizTalk pub-sub 解决方案具有内置的扩展点，允许我们添加、更改或删除终结点，而不会影响解决方案的其余部分。
话虽如此，您的要求可能并不要求广泛的消息可靠性、监控和跟踪，因此 BizTalk 可能不是最适合您的。这是一项巨大的投资，而且由于该产品可以同时做这么多不同的事情，乍一看可能会让人望而生畏。
一本名为《Microsoft 平台上的应用架构模式》的新书刚刚出版，其中涵盖了大部分内容。该书的作者之一，Richard Seroter，也发表了 SOA Patterns with BIzTalk Server 2009，如果您决定为您的公司使用 BizTalk，这将是必不可少的读物。
于 2010-10-07T18:18:26.130 回答
5
我同意 Andreas - BizTalk 通常更适合“增值”集成和业务流程管理，而不是 ESB 类型的活动。BizTalk 擅长：
- BPEL
- 长期运行/有偿交易
- EAI
- 经纪/映射
- 协议更改（MQ 到 WCF，平面文件到 SAP 等）
- 电子数据交换、射频识别
但是，已经努力将 BizTalk 用作服务总线，尤其是ESB 工具包
于 2010-09-14T07:47:00.643 回答