我们应该引入BizTalk/ESB吗？

Question

我的公司即将实施一种新架构，我们已经在其中提出了BizTalk（我们是微软商店）作为SOA中的企业服务总线（ESB）（请不要引用面向服务的歧义）环境。

我们的业务是通过我们新的订单捕获GUI进行订单，它必须连接到我们的客户数据库，产品目录，订购系统和其他辅助系统，每个订单系统将作为WCF服务公开，然后将订单传递给我们订单管理和其他下游系统以实现并最终到我们的开票系统进行开票。目前，每个系统都有自己的图形用户界面，并使用手动过程在它们之间传递信息，以自动化和集成自然思想，即引入ESB来连接它们。

我对ESB的一些基本原理是，总线会担心如何连接系统（每个系统不可知且不知道任何其他系统）以及如何格式化/转换信息。未来一些现有系统很可能会换成我们公司系统内的新系统或系统。

这似乎对我有意义，但现在我遇到了一些阻力，为什么在点对点解决方案可以满足时引入它。

不幸的是，在公司历史（在我预约之前）初次尝试引入BizTalk失败，但我相信它有一个地方，我可以提供它。

我的问题可能不是关于BizTalk，而是ESB在我描述的场景中是否是一个好主意，什么时候引入ESB是有意义的？

Answer 1

我认为根据您描述的要求有一个数据中介是有意义的，但我个人认为BizTalk在您的情况下是最好的选择。 对于您所描述的集成类型，我会查看一个硬件数据代理设备。我见过的一些工作良好的是IBM DataPower，Vordel的设备和Layer7的设备。对于您将使用此类型的呼叫，设备是理想选择。他们提供路由，转换和翻译，另外他们还可以防止模式中毒等事情发生。他们还会通过将其链接到您的用户商店来处理授权，身份验证和审核（我猜你有一个基于您所描述的环境的Active Directory用户存储区，但它也可以与LDAP一起使用）

An设备将成为BizTalk或任何其他软件解决方案的成本（没有支持成本），任何设备的性能可能会击败BizTalk一个数量级。

Answer 2

好的。 ESB关于Biztalk的指导性建议 - http://msdn.microsoft.com/en-us/library/cc487894.aspx

我们使用BizTalk在工作中做了很多事情。他有一些简单的点integerations。我们有一些更复杂的点集成与hihgly定制adpaters和管道。我们为客户掌握，产品信息和价格以及订单报价而进行分部式企业系统集成。这些都是单独的BizTalk应用程序。有些相当小，有些相当大。我们主要使用BizTalk来在不使用ESB模式的情况下进行点对点/多点静音。 ESB的实施意味着公交车本身的治理水平以及公交车上允许的企业信息标准。如果您将与大量不同格式的大量系统进行交互，ESB具有很大意义。如果您想实现的集成不那么雄心勃勃，那么ESB可能会过度。这就是说，这是一个干净而可扩展的架构。你必须做出成本价值的决定。

BizTalk也是一个复杂的野兽，但与所有的运动部件来的灵活性，这是美好的水平。但要为学习曲线或顾问成本做好准备。

Answer 3

我倾向于避免ESB术语，因为我认为它严重超载;在一天结束的时候，在我听到的各种描述中，这只是一种模式，一次BizTalk支持得很好。

所以 - 我认为BizTalk会适合你想要做什么？绝对是的。 我是否认为避免点对点连接是正确的 - 是的，但是，像任何重构练习（包括任何SOA计划）一样，您必须考虑有多少变化，现在可以重复使用，以期决定如何远远地说，你正在采取“脱钩”的运动。

Answer 4

这是一个非常独特的模式。通常，当您从系统A发送消息到系统B时，您可以直接从系统A的格式转换为系统B所需的格式。当你有一个ESB时，你可以将系统A的消息转换为ESB格式（即通用PO，顺序等），然后转换为系统B所需的格式。这是一种两次转换，而不是1次，总线模式也需要每个messag eto都有一个动词（即添加，删除，更新等）。这是一个真正重要的区别，它使得ESB在与许多参与系统的集成中非常有用。

Answer 5

您需要谈论延迟和吞吐量。其他一切都只是喧哗。

Answer 6

我刚刚被同事问同样的问题，这就是我对他说：

在大多数集成场景，你可以去 很远使用的东西 喜欢的BizTalk之前。我会确保 在使用BizTalk之前，我无法完成集成更多 。只有

，如果它似乎整合 解决方案需要将规模扩大到高 容量低延迟（它有一个 梦幻般的异步 发布 - 订阅机制），以及你 需要容错性（它有 冗余，缩放和消息重试 功能）和治理通过 解决方案（它有业务活动 监测），你真的有 有力的论据考虑使用 BizTalk。如果你知道有 是多个未来的集成， 将需要然后它真的变得真正 使用BizTalk。

另一方面你需要使 肯定的技能可用 操作的东西。这需要花费一段时间 学习和系统的开发人员的范式转变。但是它从.NET 和SQL Server中完全构建而成，因此在工具和 概念中有很多熟悉的 。

我认为，关键是要得到一个解决方案 权考虑的 概念架构像 性能，可用性， 可扩展性，弹性，刚性， 和可扩展性，并确保他们的 非功能性需求 由 技术设计正确解决。你可能会发现它的 更便宜，支付35k $的CPU每个CPU 许可证为什么BizTalk为您提供了 框比开发这些所有这些 NFRs。

此外，我最近在客户端实现了新的ESB工具包2.0，我对此非常满意。行程（参见路由滑模http://www.enterpriseintegrationpatterns.com/RoutingTable.html）的处理功能确实使构建Web服务变得简单，灵活和快速。