6

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

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

我对 ESB 的一些基本原理是，总线会担心如何连接系统（每个系统都是不可知的，并且对任何其他系统一无所知）以及如何格式化/翻译信息。将来，很有可能将某些现有系统替换为我们公司家族中的新系统或系统。

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

不幸的是，在公司历史上（在我任命之前），引入 BizTalk 的初步尝试失败了，但我相信它有一席之地并且我可以交付它。

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

4

6 回答 6

6

好的。来自规范架构组的 Biztalk 的 ESB 指南 - http://msdn.microsoft.com/en-us/library/cc487894.aspx

我们在我工作的地方使用 BizTalk 来做很多事情。他有一些简单的积分。我们与高度定制的适配器和管道进行了一些更复杂的点集成。我们有针对客户主数据、产品信息和价格以及订单报价的部门企业系统集成。这些都是单独的 BizTalk 应用程序。有些很小，有些很大。我们主要使用 BizTalk 进行点对点/多点解决方案，而不使用 ESB 模式。ESB 的实现意味着总线本身的治理水平和总线上允许的企业消息标准。如果您将与具有大量不同格式的大量系统交互 - ESB 非常有意义。如果您想要实现的集成不那么雄心勃勃，那么 ESB 可能是矫枉过正。话虽如此，它是一个干净且可扩展的架构。您必须做出成本价值决定。

BizTalk 也是一个复杂的野兽，但所有的移动部件都具有一定程度的灵活性，非常棒。但要为学习曲线或一些顾问费用做好准备。

于 2008-12-05T03:31:56.613 回答
4

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

在大多数集成方案中，您可以在使用诸如 BizTalk 之类的东西之前走得更远。在使用 BizTalk 之前，我会确保不能更简单地进行集成。

仅当集成解决方案似乎需要以低延迟扩展到大容量时（它具有出色的异步发布-订阅机制），并且您需要容错（它具有冗余、扩展和消息重试功能）和对解决方案的治理（它有业务活动监控）你真的有强烈的论据来考虑使用 BizTalk。而且，如果您知道将来需要进行多种集成，那么使用 BizTalk 就会变得非常有吸引力。

另一方面，您需要确保具备操作该事物的技能。对于系统的开发人员来说，学习和范式转变需要一段时间。然而，它是在 .NET 和 SQL Server 中从头开始构建的，因此对工具和概念非常熟悉。

我认为关键是要正确考虑解决方案的概念架构，同时考虑到性能、可用​​性、可扩展性、弹性、健壮性和可扩展性等非功能性需求，并确保技术设计能够正确解决它们。您可能会发现，为 BizTalk 提供的开箱即用功能支付每个 CPU 许可证 35k 美元比为所有这些 NFR 进行开发更便宜。

此外，我最近在一个客户端实现了新的 ESB Toolkit 2.0，对此我感到非常满意。Itinerary（请参阅 Routing Slip 模式http://www.enterpriseintegrationpatterns.com/RoutingTable.html）处理功能确实使编写 Web 服务变得容易、灵活和快速。

于 2009-06-24T13:13:12.620 回答
2

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

就拥有成本（无支持成本）而言，设备将是 BizTalk 或任何其他软件解决方案，并且任何设备的性能都可能比 BizTalk 高一个数量级。

于 2008-12-04T18:04:08.023 回答
2

我倾向于避免使用 ESB 术语，因为我认为它严重超载；归根结底，在我听到的所有各种描述中，它只是一种模式，曾经 BizTalk 非常支持它。

那么 - 我认为 BizTalk 是否适合您想要做的事情？绝对是的。我认为避免点对点连接是正确的吗？也是的，但是，就像任何重用重构练习（包括任何 SOA 计划）一样，您必须考虑您期望有多少变化和现在多少重用来决定多远你正在“脱钩”练习。

于 2008-12-05T10:25:16.483 回答
1

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

于 2009-03-11T17:20:29.227 回答
0

这是一个非常独特的模式。通常，当您从系统 A 向系统 B 发送消息时，您会将系统 A 的格式直接转换为系统 B 想要的格式。当您拥有 ESB 时，您将系统 A 的消息转换为 ESB 格式（即通用 PO、订单等），然后转换为系统 B 所需的格式。这是对 1 的两次转换，而且总线模式需要每个消息都有一个动词（即添加、删除、更新等）。这是一个真正重要的区别，也是使 ESB 在与许多参与系统的集成中非常有用的原因。

于 2008-12-07T05:18:44.350 回答