BizTalk Server有哪些可行的替代方案？
在评估不同的系统集成策略时，我遇到了一些鼓励的话，但也有一些对BizTalk Server感到沮丧的话。
使用BizTalk Server有哪些利弊(从开发人员和业务用户的角度来看)，公司还应考虑使用开源替代方案吗？有哪些可行的替代方案？
编辑：Jitterbit似乎是一个有趣的选择。开源，并且经过精心设计。这里的任何人都有使用它的经验吗？
解决方案
回答
我在BizTalk方面的经验基本上是令人沮丧的时间浪费。
在进行B2B数据集成时(可能是任何企业应用程序中最难的部分)，我们需要进行很多极端的工作，并且对业务逻辑所做的很少的怪异调整，我们只是需要推出自己的解决方案。
解析数据文件并将其转换为其他格式有多困难？没那么难。除非我们试图将像Biztalk这样的庞大的中间件系统注入其中。
回答
在OSS领域(尽管我个人从未使用过它们作为BizTalk的替代品，这是轶事)，我们可以使用Java / J2EE消息传递引擎之一，例如OpenMQ(这是Sun企业版，改头换面并且没有支持)。如果我们还需要编排/编排(即SOA / ESB部分)，则可以考虑使用Apache Mule之类的工具
回答
我没有JitterBit的直接经验，但我从同事那里听到了很多很好的消息。
回答
我们使用BizTalk已有两年时间，但是放弃了我们自己的自定义框架，从而获得了更大的灵活性。
回答
作为BizTalk顾问，我必须至少部分同意Eric Z Beard的观点，其中很多情况都需要大量时间。但是，在相当多的情况下也可以极端平滑地处理，因此这完全取决于IMO。但是，当我们(埃里克)打电话给BizTalk感到blo肿时，我不得不不同意！我们发现，性能和可靠性非常出色，它非常灵活，并且开箱即用地附带了许多优质的适配器。
回答
我们在公司对BizTalk进行了评估，感到非常失望。
我们正在使用IBM WebSphere Transformation Extender(它也有很多(其他)问题)，并且与WTX相比，BizTalk的映射工具是一个玩笑。
图形工具并不是真正适用于复杂的映射(我们在重复组中有包含数百个字段的架构)，如果我们做的比通常的" concat名字和姓氏到名字"映射更多，我们将对图形感到厌倦方法(例如，未标记图形映射器中函子的参数，并且将字段连接到这些参数的顺序很重要)。
XSLT-Mapper是有用的，但并不是真正令人信服的，甚至Microsoft代表也告诉我们使用XMLSpy之类的工具进行XSLT并将生成的XSL文件加载到BizTalk中。
第三种映射方法是使用C＃代码进行映射，这对于我们来说是不可接受的常规方法(我们不想教每个C＃)。
除了映射工具，我们不喜欢BizTalk中的部署。为了部署流程，我们需要在不同的工具和位置进行大量设置。我们希望希望能找到一种机制，例如BizTalk中用于Java Web应用程序的WAR文件，以便我们可以将整个过程解决方案的一个存档提供给管理员，然后管理员可以对其进行部署。
回答
自2004年以来，我们一直在使用BizTalk，现在混合运行了2006 R2和2004版本。我发现学习曲线非常严峻，解决方案的开发时间并不总是很快。这些绝对是缺点。 BizTalk真正擅长的地方在于其容错能力，保证的交付和性能。我们可以放心，数据不会丢失。重试功能和容错鲁棒性具有很强的说服力，因此，一般来说，如果系统出现故障，BizTalk将处理此问题，并且一旦系统恢复联机，便会成功交付。 BizTalk处理在集成方案中很重要的所有这些问题，例如停机时间等。
此外，一般而言，在开发解决方案时，BizTalk通过将所有内容都处理为xml来抽象本机系统的通信协议和数据格式，因此在开发解决方案时，通常不必编写特定于那些系统的代码，而使用BizTalk xml框架。
回答
去年，我们为HL7路由实现了一个名为Mirth的Java开源引擎。我发现出于HL7的目的，用于BizTalk的HL7适配器是一个挑战。管理层表示我们将Mirth用于HL7路由。 BizTalk在学习曲线方面下降的地方，Mirth弥补了。开发解决方案要容易得多。欢乐的问题在于，它实际上并没有任何保证的交付。大多数适配器(hl7除外)都没有重试功能，因此，如果我们需要编写自己的适配器。第二，如果速度不佳，Mirth可能会失去约会。我会说它非常易于使用(尽管没有文档)，但是很难将其称为企业解决方案。我要检查一下别人提到的抖动比特。
我在寻找比BizTalk便宜的解决方案时遇到了Apatar(无法发布url，但Google找到了)。我还没有尝试。
回答
我的上一家公司遇到了很多问题，因为BizTalk过于复杂和坎，但我不禁认为这主要取决于顾问所做的实施。
BizTalk Server的主要优点是，它为部署，管理，性能和可伸缩性提供了很多"管道"。通过Visual Studio，它还提供了用于开发解决方案的综合框架，通常只需很少的代码。
其他人经常提到的挫败感和陡峭的学习曲线来自出于错误目的使用BizTalk以及对一般如何使用BizTalk和面向消息的系统的误解。学习曲线并不像大多数人所建议的那样陡峭，实际上，基础学习的本质部分实际上集中在将思维从程序方法转变为基于无状态消息的方法。
人们经常引用的一个缺点是成本。标价似乎很高。但是，与我们自己开发和支持功能所花费的金额相比，这是便宜的。
在考虑替代方案甚至是BizTalk Server之前，我们应该考虑组织的集成方法及其长期目标。 BizTalk Server非常适合需要使用中心辐射型模型来集成系统的情况，在该模型中BizTalk协调了许多应用程序的活动。
还有其他集成模型，一种比较流行的模型是分布式总线(不要将其与"企业服务总线"或者ESB混淆)。我们还可以使BizTalk充当分布式总线，并且有替代解决方案可以提供更直接的支持。替代解决方案之一是称为nServiceBus的开源解决方案。
在考虑是否使用诸如BizTalk之类的商业产品时，会讲一些其他东西(开源或者内部开发)，还要考虑维护和增强功能以及市场上必要技能的可用性。
- 为什么选择BizTalk？
- 十大BizTalk错误
- BizTalk Server中的可扩展性功能
- 与nServiceBus的开源集成
回答
我写了一些文章，其中更详细地介绍了我在此处讨论的要点：链接：
BizTalk需要正确使用，
我是BizTalk开发人员，我在BizTalk方面的经验非常好。
它可靠，高性能，可扩展，包含许多内置的架构模式和内置组件，以使集成变得容易和快速，我们可以获得安全性，重试，二次传输，验证，转换等...以及我们从未拥有的任何内置内容使用BizTalk，我们可以轻松地使用.NET代码进行自定义，它基本上是一个很难获得的集成系统，并且所有这些都可以在一个盒子中获得。
但是，我们需要知道如何正确地实现BizTalk，而不是一旦我遇到了实施不当且经常设计错误的解决方案。
但是BizTalk的真正好处是，我们可以实施小型解决方案并扩大规模，而大型供应商提供的大多数其他集成系统仅会出售整套集成套件，而该套件的价格可能更高。
BizTalk被视为Microsoft公司中最复杂的服务器。
回答
因此，任何说BizTalk不好的人都知道BizTalk时期。
我在BizTalk和进行B2B集成方面的经验是，大多数组织并没有真正进行架构优先设计或者完全了解xml标准。大多数人倾向于编织对象，并希望它们具体化为有意义的模式。在企业环境中，这是倒退。
BizTalk确实具有学习曲线，但是一旦获得它，我们就会获得持久性，性能，真正的可伸缩性和可扩展性的奖励。就像大多数人所说的那样，最好确保它满足需求并将需求扭曲到BizTalk。
回答
过去，我一直使用BizTalk 2004到2009，以及另一种名为webMethods的产品。
始终有Sun的(现在是Oracle)OpenESB框架。一般来说，它是Biztalk的较小，较轻的版本，但几乎具有相同的功能。
但是，我们确实可以使用它编写更多的代码。
段落数量不匹配
