在评估不同的系统集成策略时，我遇到了一些鼓励的话，但也有一些对BizTalk Server感到沮丧的话。
使用BizTalk Server（从开发人员角度和业务用户）有哪些优缺点，公司是否也应考虑开源替代方案？有哪些可行的替代方案？
编辑：Jitterbit似乎是一个有趣的选择。开源，似乎很好地设计。这里的任何人都有使用它的经验吗？
答案 0 :(得分：30)
BizTalk Server的主要优势在于它提供了许多关于部署，管理，性能和可伸缩性的“管道”。通过Visual Studio，它还提供了一个用于开发解决方案的综合框架，通常只需要相对较少的代码。
其他人提到的沮丧和陡峭的学习曲线通常来自于使用BizTalk的错误目的以及对如何使用BizTalk和面向消息的系统的误解。学习曲线并不像大多数人所说的那样陡峭 - 基础学习的基本部分实际上侧重于将思维从程序化方法转变为无状态消息方法。
人们经常提到的一个缺点就是成本。标价似乎很高;但是，与您自己开发和支持功能所花费的金额相比，这是便宜的。
在考虑替代方案，甚至考虑BizTalk服务器之前，您应该考虑组织的集成方法及其长期目标。如果您希望使用集线器和辐条模型集成系统，BizTalk Server非常适用于BizTalk协调许多应用程序的活动。
还有其他集成模型 - 其中一种比较流行的是分布式总线（不要将其与术语“企业服务总线”或ESB混淆）。您还可以将BizTalk作为分布式总线工作，并提供可提供更直接支持的替代解决方案。其中一个替代解决方案是名为nServiceBus的开源解决方案。
在考虑是否使用像BizTalk这样的商业产品时，不论其他东西（开源还是内部开发），还要考虑维护和增强以及市场中必要技能的可用性。
我写了一些文章，详细介绍了我在这里讨论的要点 - 这里是链接：
答案 1 :(得分：23)
我对BizTalk的体验基本上是浪费时间。
当您进行B2B数据集成（这可能是任何企业应用程序中最难的部分）时，您需要自行解决方案，需要进行许多边缘情况和奇怪的小业务逻辑调整。
解析数据文件并将其转换为其他格式有多难？没那么难。除非你试图将像Biztalk这样臃肿的中间件系统注入其中间。
答案 2 :(得分：13)
作为一名BizTalk顾问，我必须至少部分同意Eric Z Beard，有很多边缘案例占用了大量时间。但是很多场景也处理得非常顺畅，所以这一切都取决于IMO。但当你（埃里克）打电话给BizTalk臃肿我不得不反对！我们发现它的性能和可靠性非常出色，它非常灵活，并且带有许多开箱即用的好适配器。
答案 3 :(得分：10)
BizTalk需要正确使用， 我是BizTalk开发人员，我对BizTalk的经验非常好。 它可靠，高性能，可扩展，包含许多内置的架构模式和内置组件，使集成变得简单快捷，您可以获得安全性，重试，二次传输，验证，转换等......以及您没有构建的内容使用BizTalk，您可以轻松地使用.NET代码进行自定义，它基本上是一个很难获得的集成系 但是，您需要知道如何正确实现BizTalk，而不是一旦我遇到实现的解决方案，并且通常也会错误地构建。
但BizTalk的真正好处在于，您可以实施小型解决方案并扩展规模，而大型供应商的大多数其他集成系统只会销售整个集成包，而且成本更高。
BizTalk被认为是微软公司最复杂的服务器。
所以任何认为BizTalk不是很好的人都知道BizTalk时期。
答案 4 :(得分：8)
我们在公司评估了BizTalk，真的很失望。
我们正在使用IBM WebSphere Transformation Extender（它也有很多（其他）问题），与WTX相比，BizTalk的映射工具是一个笑话。
图形工具实际上并不适用于复杂的映射（我们在重复组中有几百个字段的模式），如果你做的不仅仅是通常的“concat名字和姓氏命名”映射，你会感到厌倦图形方法的例子（例如图形映射器中functoid的参数没有标记，并且将字段连接到这些参数的顺序很重要）。
XSLT-Mapper可以使用，但不是很有说服力，甚至微软代表告诉我们使用像XMLSpy这样的工具来安装XSLT并将生成的XSL文件加载到BizTalk中。
映射的第三种方法是使用C＃-Code进行映射，这对我们来说是不可接受的一般方法（我们不想教给每个人C＃）。
除了映射工具，我们不喜欢BizTalk中的部署。为了部署您的流程，您需要在不同的工具和位置进行大量设置。我们希望在BizTalk中找到类似于Java Web应用程序的WAR文件的机制，这样您就可以为管理员提供整个流程解决方案的一个存档，并且可以部署它。
答案 5 :(得分：6)
自2004年版以来，我们一直在使用BizTalk，现在混合使用2006 R2和2004版本。我发现学习曲线非常严重，解决方案的开发时间并不总是很快。这些肯定是缺点。 BizTalk真正擅长的地方在于它的容错能力，保证交付能力和性能。您可以放心，数据不会丢失。一般来说，如果系统停机，BizTalk将处理这种情况并且一旦系统恢复运行就会成功交付，因此重试功能和容错稳健性已经大局化。所有这些问题，如停机时间等，在集成场景中都很重要，由BizTalk处理 此外，一般来说，在开发解决方案时，BizTalk通过将所有内容作为xml处理来抽象本机系统的通信协议和数据格式，因此在开发解决方案时，您通常不必编写特定于这些系统的代码，而是使用BizTalk xml框架。
在去年，我们为HL7路由实现了一个名为Mirth的java开源引擎。我发现，出于HL7的目的，BizTalk的HL7适配器是一个可以使用的挑战。管理层指出我们使用Mirth进行HL7路由。在学习曲线方面BizTalk垮台，Mirth弥补。开发解决方案要容易得多。欢乐的问题在于它实际上并没有任何保证。大多数适配器（hl7除外）都没有重试功能，所以如果你想要，你必须自己编写。其次，如果欢乐会失败，可以失去约会。我会称之为非常容易使用（虽然没有文档），但我很难将其称为企业解决方案。我要查看其他人提到的jitterbit。
答案 6 :(得分：4)
我们使用BizTalk已经有几年了，但是我们为自己的自定义框架放弃了它，这样可以提供更大的灵活性。
答案 7 :(得分：4)
答案 8 :(得分：2)
在OSS领域（虽然我从未将它们用作个人的BizTalk替代品 - 这是轶事），您可以使用其中一个Java / J2EE消息传递引擎，例如OpenMQ（这是Sun企业版）重新加入，没有支持）。如果您需要Orchestration / Choreography（即SOA / ESB片段），您可以查看Apache Mule
之类的内容。答案 9 :(得分：2)
我在使用BizTalk和进行B2B集成方面的经验是，大多数组织并不真正进行架构优先设计或完全理解xml标准。大多数人倾向于编织物体，并希望它们成为有意义的模式。在企业环境中，这是倒退的。
BizTalk确实有一个学习曲线，但是一旦你得到它，你将获得耐用性，性能，真正的可扩展性和可扩展性。像大多数人所说的那样，最好确保它满足您的需求并将您的需求扭曲到BizTalk。
过去我曾使用过BizTalk 2004到2009，以及另一款名为webMethods的产品。
答案 10 :(得分：0)
我对JitterBit没有直接的经验，但我从同事那里听到了非常好的东西。
答案 11 :(得分：0)
我找到了阿帕塔尔（无法发布网址，但谷歌找到了它），同时寻找比BizTalk便宜的解决方案。我还没试过这个。
我的上一家公司有很多问题，BizTalk过于复杂和不稳定，但我不禁想到这主要取决于顾问所做的实施。