BizTalk是ESB吗？

Question

我正在研究架构模式，企业服务总线（ESB）。在阅读本文Enterprise Integration时，几乎没有经验，我想知道BizTalk是ESB还是EAI（Hub / Spokes或Bus）？

我找到了这个NServiceBus and Biztalk，将BizTalk描述为一个中央消息代理。

考虑其他ESB框架（NServiceBus和Rhino Service Bus）。这些框架没有处理消息的中心点。

Biztalk是EAI而不是ESB吗？

非常感谢

Answer 1

BizTalk被微软视为拥有ESB功能 - 请参阅BTS ESB toolkit

然而，术语“ESB”涵盖了非常broad field，并且关于ESB的确切定义存在很多主观性。恕我直言，BizTalk声称自己作为一个ESB是全面的（在＆gt; 2010年的术语定义中）存在弱点。

• 在ESB普及之前，BTS起源于Hub-and-Spoke EAI时代。
• BTS比同步过程更适合异步过程 - 延迟会因系统负载，节流状态等而异。
• 对于易于版本化服务和模式（需要新部署）而言，BTS很麻烦。
• 对于许多服务的管理来说，BTS很麻烦（例如，使用BizTalk作为所有5000个企业SOA / Web服务的外观会很痛苦）。

FWIW我们发现BTS非常适合：

• 我们所有的同步和异步EAI（即主要LOB系统之间和贸易伙伴之间的正式集成合同），以及大量适配器有助于集成大量协议。
• 用于业务流程和业务监控功能
• 解决事务和交付可靠性问题 - Biztalk具有重试，跟踪和恢复暂停消息的能力，这对于不可靠的网络或与不可靠系统的集成非常有用。

更新，带来一些进一步的比较经验

• BTS非常集中 - 最终，即使是多服务器的BizTalk群集/组也依赖于Sql-Server。基于队列的ESB产品往往更加分散（逻辑上和物理上），因此丢失一些端点或队列服务器不应该让整个企业失望。
• 许多基于队列的ESB都是基于开源技术，着眼于避免单一供应商锁定
• 许多当代ESB似乎采用commodity-computing方法进行扩展。使用BizTalk等产品进行扩展可能会变得非常昂贵。
• 从好的方面来说，不应低估BTS等商业产品的监控和管理功能 - 确保您考虑的任何ESB都具有足够的审计，仪表，重试和诊断（WMI / SNMP / SCOM等）功能 - 你需要一个仪表板来监控你的公共汽车的健康状况，没有比不知道消息在哪里更糟糕的了。在这里，集中管理和诊断是一个加号。

Answer 2

BizTalk是一个消息传递和工作流程编排平台，您可以在其上构建ESB行为和功能。为了简化和标准化BizTalk上的ESB实现，Microsoft发布了BizTalk ESB Toolkit - 一套指南，模式和代码。

EAI和BPM的概念已经存在了一段时间，因此有许多公司利用BizTalk为这些问题创建解决方案。在BizTalk服务器上托管完整ESB的公司要少得多，并且在WCF / WF / NServiceBus，当然还有Azure Service Bus的出现时，采用率肯定会降低。

总而言之，BizTalk开箱即用的是更糟糕的EAI或ESB，但是可以同时应对这个问题的许多开发人员。

Answer 3

通过“ EAI或ESB ”我假设您想知道BizTalk是否遵循Hub＆amp; Spoke或总线架构。

从架构模式的角度来看，集成解决方案大致属于两种模式中的一种 -

• Hub and spoke ： 这涉及集中式消息代理向各种接收者发送消息，而所有发送者仅将消息发送给该代理。 因此，发送者和接收者都不需要彼此了解。 这通常是许多人称之为EAI的内容（尽管绝对有可能实现遵循BUS模式的EAI解决方案）。 遵循此模式的解决方案易于开发和管理。所有路由逻辑都集中在一个地方进行管理 - 在集线器中。 但正如你所猜测的那样，这有一个明显的缺点 - 单点故障。如果集线器崩溃，一切都会停止。此外，这种模式不能很好地扩展。

• <强> BUS ： 围绕此模式开发的企业集成解决方案通常称为ESB。这里没有智能的中央权威。所有发件人都在公交车上发布消息。接收器需要足够智能，以确定哪些消息是针对它们的，并将它们从总线上取下。 因此，发送者和接收者只需要知道总线。但是这里的路由逻辑分布在接收器上，所以没有单点故障。此模型也具有高度可扩展性。然而，这些解决方案非常复杂且难以管理。

关于BizTalk遵循哪种模式的问题 - 它是这两种模式的混合。

集中式消息传递引擎以及中央 MessageBox数据库，其外观非常明显。这给人一种简单易用的管理方式，这是集线器方法的典型特征。

但是，如果你看一下BizTalk架构，可以将主机与主机实例分布在多个服务器上。也可以在不同的服务器上配置不同的BizTalk数据库，如MessageBox，Tracking，Ent SSO等。这使得BizTalk解决方案比普通的集线器实现更具可扩展性和容错性 - 这种行为通常归因于总线方法。

希望这能回答你的问题。

Answer 4

BizTalk肯定是ESB。 EAI更像是一个松散的概念 - 当然可以部署BizTalk来支持EAI，它也可以做更多的事情。

Answer 5

BizTalk不仅仅是一个ESB，但肯定符合要求。 This link有点老了，但回答了你的确切问题。

编辑：这是a more-recent MS link，其中涉及实施细节。

Answer 6

BizTalk既可以用作EAI，也可以用作ESB。

对于ESB，BizTalk服务器体系结构是发布 - 订阅的，可以将单个消息发布到充当消息传递主干总线的消息框中。该消息可以由订阅该消息的一个或多个目标系统接收。当然，使用BizTalk服务器可以获得更多功能和功能，例如映射器工具和管道组件的使用。

作为EAI使用，BizTalk为您提供管理业务逻辑的业务流程，LOB（业务线）adatpers以连接到系统（也是旧版），映射工具，规则引擎以及您需要的大量内容将公司内外的不同系统集成在一起。

Answer 7

绝对！ Biztalk来自EIS背景，这使得ESB成为跨越混合技术平台的面向服务架构的基础架构背板非常有意义。

在之前的公司，出于功能和低成本的原因，我们选择Biztalk优先于IBM ESB产品。

这是微软，所以你得到你付出的代价，但仍然值得研究。

Answer 8

Biztalk Server withot“ESB Toolkit”不是ESB。 由于以下原因：

1. 首先是合同，需要先建立消息类型。
2. 首先需要规划整个方案，以尽量减少变更的影响。
3. 更改需要部署，这会增加停机时间。

关于你的qustion，是的BizTalk Server是EAI产品

Answer 9

我同意这里所说的大部分内容。即使使用EBS工具包，BizTalk也可以作为一个全包的EBS解决方案。

要解决这里提出的几点......

  

•BTS比同步更适合异步过程   进程 - 延迟将根据系统负载而变化，   节流状态等。

默认情况下未更改的BizTalk主机不适合低延迟。但是那些主机应该被调整。开箱即用配置不适用于需要吞吐量的任何情况。在我进入BizTalk被避开的组织的经历中，总是有一个未经调整的单个主机设置位于其中间。这有点类似于在没有索引的dbms中生成表，遇到性能问题并说dbms本身很糟糕。

  

•对于易于版本化的服务而言，BTS很麻烦   模式（需要新部署）

与任何开发平台一样，您需要拥有部署策略。如果模式在命名空间中有版本，则无需重新部署任何内容。可以部署新版本而不会失去任何东西。

就服务端点而言，BizTalk可以在不使用IIS的情况下托管Web服务（BizTalk可以像IIS一样使用HTTP.SYS进行托管）。在BizTalk中托管进程服务只是导入绑定的问题，可以在不停止BizTalk中的任何操作的情况下完成。在这些端点中，您也可以实现版本控制（例如http：... / thing / v1，http：... / thing / v2等）。

无论如何〜5年过去了我确定你之前已经得出结论：）

Answer 10

BizTalk可以同时进行ESB和EAI，这取决于您如何设计biztalk应用程序。