什么是BizTalk Server的一些可行的替代scheme？
在评估不同的系统集成策略时，我遇到了一些鼓励的话，但也有一些比BizTalk Server更令人沮丧的话。
使用BizTalk Server（从开发人员和业务用户两方面）有什么优点和缺点？公司是否也考虑开源替代scheme？ 那里有什么可行的select？
编辑： Jitterbit似乎是一个有趣的select。 开源，似乎是很好的工程。 这里的任何人都有使用它的经验吗？
BizTalk Server的主要优点是它提供了围绕部署，pipe理，性能和可伸缩性的大量“pipe道”。 通过Visual Studio，它还为开发解决scheme提供了一个全面的框架，通常只需要相对较less的代码。
其他人提到的沮丧和陡峭的学习曲线通常来自使用BizTalk的错误目的，以及对如何使用BizTalk和面向消息的系统的一般误解。 学习曲线并不像大多数人所build议的那样陡峭 – 基础学习的基本部分实际上集中于将思维从程序方法转变为无状态的基于消息的方法。
人们经常提到的一个缺点就是成本。 贴纸价格似乎相当高， 然而，与您自己开发和支持function相比，这是相当便宜的。
在考虑替代scheme之前，或者考虑采用BizTalk服务器之前，应该考虑组织的整合方法，这是长期目标。 如果您想要集成使用集线器和辐条模型的系统，而BizTalk协调许多应用程序的活动，则BizTalk Server十分出色。
还有其他的集成模式 – 比较stream行的是分布式总线（不要把它与“企业服务总线”或ESB混淆）。 您还可以使BizTalk作为分布式总线工作，并且有替代解决scheme可以提供更直接的支持。 其中一种替代解决scheme是名为nServiceBus的开源解决scheme。
在考虑是否使用像BizTalk这样的商业产品时，还要考虑其他方面的问题（开源或内部开发），还要考虑维护和增强以及市场上必要技能的可用性。
我写了一些关于我在这里讨论的要点的更详细的文章 – 这里是链接：
- 为什么selectBizTalk？
- 十大BizTalk错误
- BizTalk Server中的可扩展性function
- 与nServiceBus开放源代码集成
我对BizTalk的经验基本上是浪费时间。
当您进行B2B数据集成（这可能是任何企业应用程序中最困难的部分）时，您只需要推出自己的解决scheme，就会遇到太多边缘情况和奇怪的小业务逻辑调整。
parsing数据文件并将其转换为其他格式有多困难？ 没那么难 除非你正在试图将一个臃肿的中间件系统（如Biztalk）注入到它的中间。
作为一名BizTalk顾问，我必须至less与Eric Z Beard达成一致，有很多边缘案例需要花费大量的时间。 但是，相当多的情况也是极其平稳的处理，所以这一切都取决于国际海事组织。 但是当你（Eric）称之为BizTalk臃肿时，我不得不不同意！ 我们发现，性能和可靠性非常好，它很灵活，并且附带了很多很好的适配器。
BizTalk需要正确使用，我是一个BizTalk开发人员，我的经验与BizTalk是相当不错的。 它的可靠性，高性能，可扩展性，包含大量内置的架构模式，并构build组件以使集成变得简单和快速，您可以获得安全性，重试，二次传输，validation，转换等等，以及您没有构build的内容与BizTalk，你可以很容易地与.NET代码定制，其基本上是一个辛苦得到的集成系统，你在一个盒子里得到这一切。 但是你需要知道如何正确地实现BizTalk，而不是一旦遇到实现的解决scheme，而且往往架构不正确。
但BizTalk的真正好处是可以实现小型解决scheme并扩大规模，而来自大型厂商的大多数其他集成系统只会销售可能花费更多的整个集成包。
BizTalk被认为是微软公司最复杂的服务器。
所以任何说BizTalk的人都不会知道BizTalk的时期。
我们在我们公司评估了BizTalk，真的很失望。
我们正在使用IBM WebSphere Transformation Extender（它也有很多（其他）问题），BizTalk的映射工具与WTX相比是一个笑话。
graphics工具对于复杂的映射（我们有重复组中的几百个字段的模式）并不是真正可用的，如果您比通常的“concat名字和姓氏名称”映射做的更多，那么您将厌倦graphics的方法（例如，graphics映射器中的functoid的参数没有标记，并且将字段连接到这些参数的顺序很重要）。
XSLT映射器是可用的，但并不真正令人信服，甚至微软代表告诉我们使用XMLSpy这样的工具用于XSLT，并将生成的XSL文件加载到BizTalk中。
第三种映射方法是使用C＃代码进行映射，这对于我们来说是不可接受的（我们不想教大家C＃）。
除了映射工具之外，我们不喜欢BizTalk中的部署。 为了部署您的过程，您需要在不同的工具和地点进行大量的设置。 我们曾希望find一种像BizTalk中的Java Web应用程序的WAR文件这样的机制，这样您就可以为您的整个stream程解决scheme提供一个归档文件给pipe理员，并且可以部署它。
自2004年以来，我们一直在使用BizTalk，现在已经有了运行版本2006 R2和2004的组合。 我发现学习曲线相当严峻，解决scheme的开发时间并不总是很快。 这些肯定是缺点。 BizTalk真正擅长的地方在于容错性，交付性和性能。 您可以放心，数据不会丢失。 重试function和容错稳健性在一般情况下都是在系统closures的情况下进行的，BizTalk将会处理这个问题，一旦系统重新联机，成功的交付将会发生。 所有这些在集成场景中重要的停机等问题都由BizTalk处理。
此外，一般来说，在开发解决scheme时，BizTalk通过将所有内容都作为xml进行处理来抽象本机系统的通信协议和数据格式，所以在开发解决scheme时，您通常不必编写特定于这些系统的代码，而是使用BizTalk xml框架。
在去年，我们为HL7路由实现了一个名为Mirth的java开源引擎。 我发现，对于HL7的目的，BizTalk的HL7适配器是一个挑战。 pipe理层指出我们使用Mirth进行HL7路由。 BizTalk在学习曲线方面跌倒的地方，欢乐弥补。 开发解决scheme要容易得多。 快乐的问题是它没有真正的交付。 大多数适配器（除了hl7）没有重试function，所以如果你想要，你必须写自己的。 其次，欢乐可能会失去date，如果它下降。 我会称之为非常容易使用（虽然没有文档），但我很难把它称为企业解决scheme。 我要去看看其他人提到的jitterbit 。
我们使用了BizTalk几年，但放弃了我们自己的定制框架，允许更多的灵活性。
在OSS领域（尽pipe我从来没有把它们作为一个BizTalk替代品 – 这是一个轶事），你可以使用Java / J2EE消息引擎之一，例如OpenMQ （这是Sun公司的一个重新引入并且没有支持）。 如果你需要编排/编排（如SOA / ESB），你可以看看Apache Mule
我在BizTalk和B2B集成方面的经验是，大多数组织并没有真正进行架构devise或者完全理解XML标准。 大多数人倾向于编织物品，并希望他们物化成意义模式。 在企业环境中，这是倒退的。
BizTalk确实有一个学习曲线，但一旦你得到它，你将获得持久性，性能，真正的可伸缩性和可扩展性。 就像大多数人所说的那样，最好确保它满足你的需求，并将你的需求扭曲到BizTalk。
在过去，我一直在使用BizTalk 2004到2009年，另一个产品叫做webMethods。
总是有Sun的（现在是Oracle） OpenESB框架。 它一般来说是Biztalk的一个更小，更轻的版本，但具有大致相同的function。
尽pipe如此，你还是可以写更多的代码。
它的开源也是如此。
我对JitterBit没有直接的经验，但我从同事那里听到了很多好消息。
我遇到了Apatar（无法发布url，但Google发现它），同时寻找比BizTalk便宜的解决scheme。 我还没有尝试一下。
我上一个公司在BizTalk方面太复杂了，但是我不禁认为这主要是由于顾问做的。
