在评估不同的系统集成策略时，我听到了一些鼓励的话，但也遇到了一些对 BizTalk Server 感到沮丧的词。
使用 BizTalk Server 有哪些优点和缺点（无论是从开发人员的角度还是从业务用户的角度），公司是否也应该考虑使用开源替代方案？有哪些可行的替代方案？
编辑：Jitterbit似乎是一个有趣的选择。开源，似乎设计得很好。这里的任何人都有使用它的经验吗？
Kilhoffer
问问题
46849 次
12 回答
30
BizTalk Server 的主要优势在于它提供了大量围绕部署、管理、性能和可伸缩性的“管道”。通过 Visual Studio，它还为开发解决方案提供了一个全面的框架，通常只需要很少的代码。
其他人提到的挫折和陡峭的学习曲线通常来自于错误地使用 BizTalk 以及对如何使用 BizTalk 和一般面向消息的系统的误解。学习曲线并不像大多数人所说的那么陡峭——基础学习的基本部分实际上侧重于将思维从程序方法转变为无状态的基于消息的方法。
人们经常提到的一个缺点是成本。标价似乎相当高；但是，与您自己开发和支持功能所花费的金额相比，这很便宜。
在考虑替代方案或什至考虑 BizTalk 服务器之前，您应该考虑组织的集成方法及其长期目标。BizTalk Server 非常适合您想要使用中心辐射模型集成系统的情况，其中 BizTalk 协调许多应用程序的活动。
还有其他集成模型——其中一种更流行的是分布式总线（不要将其与术语“企业服务总线”或 ESB 混淆）。您还可以让 BizTalk 作为分布式总线工作，并且有替代解决方案可以提供更直接的支持。替代解决方案之一是称为 nServiceBus 的开源解决方案。
在考虑是否使用像 BizTalk 这样的商业产品时，除了其他东西（开源或内部开发），还要考虑维护和增强以及市场上必要技能集的可用性。
我写了一些文章，更详细地介绍了我在这里讨论的要点 - 以下是链接：
于 2009-06-05T16:27:31.563 回答
23
我对 BizTalk 的体验基本上是一种令人沮丧的浪费时间。
当您进行 B2B 数据集成（这可能是任何企业应用程序中最难的部分）时，您必须进行很多边缘案例和奇怪的小业务逻辑调整，您只需要推出自己的解决方案。
解析数据文件并将它们转换为不同的格式有多难？没那么难。除非您尝试将 Biztalk 之类的臃肿中间件系统注入其中。
于 2008-09-14T16:40:48.090 回答
13
作为一名 BizTalk 顾问，我必须至少部分同意 Eric Z Beard 的观点，有很多边缘情况会占用大量时间。但也有不少场景处理得非常顺利，所以这一切都取决于 IMO。但是当你（埃里克）称 BizTalk 臃肿时，我不得不不同意！我们发现它的性能和可靠性非常好，它很灵活，并且配备了许多开箱即用的优质适配器。
于 2008-09-26T11:00:02.323 回答
11
BizTalk 需要正确使用，我是一名 BizTalk 开发人员，我对 BizTalk 的体验非常好。它可靠、高性能、可扩展，包含许多内置架构模式和内置组件，使集成变得简单快捷，您可以获得安全性、重试、二次传输、验证、转换等......以及您没有内置的东西使用 BizTalk，您可以轻松地使用 .NET 代码进行自定义，它基本上是一个来之不易的集成系统，您可以在一个盒子中获得所有这些。但是您需要知道如何正确实施 BizTalk，而不是在我遇到实施且通常架构不正确的解决方案时。
但 BizTalk 的真正好处是您可以实施小型解决方案并扩大规模，而来自大供应商的大多数其他集成系统只会出售整个集成包，而这可能会花费更多。
BizTalk 被认为是微软公司最复杂的服务器。
所以任何说 BizTalk 不好的人都知道 BizTalk 时期。
于 2009-12-09T23:06:27.510 回答
8
我们评估了我们公司的 BizTalk，并感到非常失望。
我们正在使用 IBM WebSphere Transformation Extender（它也有很多（其他）问题），而 BizTalk 的映射工具与 WTX 相比简直就是个笑话。
图形工具实际上不适用于复杂的映射（我们有数百个重复组中的字段的模式），如果您做的比通常的“连接名字和姓氏”映射更多，您将厌倦图形方法（例如，图形映射器中 functoids 的参数没有标记，并且将字段连接到这些参数的顺序很重要）。
XSLT-Mapper 是可用的，但并不真正令人信服，甚至微软代表也告诉我们使用 XMLSpy 之类的工具进行 XSLT 并将生成的 XSL 文件加载到 BizTalk 中。
第三种映射方法是使用 C#-Code 进行映射，这对于我们来说作为一般方法是不可接受的（我们不想教每个人 C#）。
除了映射工具，我们不喜欢 BizTalk 中的部署。为了部署您的流程，您需要在不同的工具和位置进行大量设置。我们曾希望在 BizTalk 中为 Java Web 应用程序找到一种类似 WAR 文件的机制，以便您可以将您的整个流程解决方案的存档提供给您的管理员，他可以进行部署。
于 2008-10-09T20:10:48.630 回答
6
我们从 2004 版开始就一直在使用 BizTalk，现在混合使用了 2006 R2 和 2004 版本。我发现学习曲线非常严峻，解决方案的开发时间并不总是很快。这些绝对是缺点。BizTalk 真正擅长的地方在于它的容错性、保证交付和性能。您可以放心，数据不会丢失。重试功能和容错鲁棒性是内置的，所以一般来说，如果系统出现故障，BizTalk 将处理该问题，并且一旦系统重新上线，就会成功交付。所有这些在集成方案中很重要的问题（例如停机时间等）都由 BizTalk 处理。
此外，一般来说，在开发解决方案时，BizTalk 通过将所有内容都作为 xml 处理来抽象本机系统的通信协议和数据格式，因此在开发解决方案时，您通常不必编写特定于这些系统的代码，您可以使用 BizTalk xml框架。
去年，我们为我们的 HL7 路由实现了一个名为Mirth的 Java 开源引擎。我发现对于 HL7 而言，用于 BizTalk 的 HL7 适配器是一个挑战。管理层表示我们使用 Mirth 进行 HL7 路由。BizTalk 在学习曲线方面下降的地方，Mirth 弥补了。开发解决方案要容易得多。mirth 的问题在于它实际上并没有任何保证交付。大多数适配器（除了 hl7）都没有重试功能，所以如果你想要，你必须自己编写。其次，如果 Mirth 出现故障，它可能会丢失日期。我认为它非常易于使用（尽管没有文档），但我很难将其称为企业解决方案。我要去看看jitterbit这是别人提到的。
于 2008-10-16T18:38:05.650 回答
4
我们使用了 BizTalk 几年，但为了我们自己的自定义框架而放弃了它，该框架允许更大的灵活性。
于 2008-09-15T20:58:42.203 回答
4
于 2010-05-08T15:22:07.847 回答
2
在 OSS 领域（尽管我个人从未将它们用作 BizTalk 的替代品 - 这是轶事），您可以使用 Java/J2EE 消息传递引擎之一，例如OpenMQ（它是 Sun 企业的一个重新标记并且没有支持）。如果您需要在此之上进行编排/编排（即 SOA/ESB 部分），您可以查看Apache Mule之类的东西
于 2008-09-15T08:02:18.827 回答
2
我在 BizTalk 和 B2B 集成方面的经验是，大多数组织并没有真正进行架构优先设计或完全理解 xml 标准。大多数人倾向于编织对象并希望它们具体化为有意义的模式。在企业环境中，这是倒退的。
BizTalk 确实有一个学习曲线，但是一旦你得到它，你就会得到持久性、性能、真正的可伸缩性和可扩展性的回报。就像大多数人所说的那样，最好确保它满足您的需求并将您的需求扭曲到 BizTalk。
过去，我使用 BizTalk 2004 到 2009 年，以及另一个名为 webMethods 的产品。
于 2009-12-14T19:55:19.377 回答
0
我没有使用 JitterBit 的直接经验，但我从同事那里听到了很好的消息。
于 2008-09-15T08:12:31.517 回答
0
我在寻找比 BizTalk 更便宜的解决方案时遇到了 Apatar（无法发布 url，但谷歌找到了）。我还没有尝试过。
我上一家公司在 BizTalk 过于复杂和棱角分明方面遇到了很多问题，但我不禁认为这主要是由于顾问所做的实施。
于 2009-05-23T14:04:49.703 回答