在评估不同的系统集成策略时，我听到了一些关于 BizTalk Server 的鼓励的话，但也听到了一些沮丧的话。
使用 BizTalk Server 有哪些优点和缺点（无论是从开发人员的角度还是从业务用户的角度），公司是否也应该考虑开源替代方案？有哪些可行的替代方案？
EDIT: 抖动位 http://www.jitterbit.com/似乎是一个有趣的选择。开源并且似乎设计得很好。这里有人有使用它的经验吗？
BizTalk Server 的主要优点是它提供了大量有关部署、管理、性能和可扩展性的“管道”。通过 Visual Studio，它还提供了用于开发解决方案的综合框架，通常只需相对较少的代码。
其他人提到的挫败感和陡峭的学习曲线通常来自于将 BizTalk 用于错误的目的，以及对如何使用 BizTalk 和面向消息的系统的误解。学习曲线并不像大多数人想象的那么陡峭 - 底层学习的基本部分实际上侧重于将思维从过程方法转变为无状态的基于消息的方法。
人们经常提到的一个缺点是成本。标价似乎相当高；但是，与您自己开发和支持功能所花费的金额相比，这很便宜。
在考虑替代方案甚至考虑 BizTalk 服务器之前，您应该考虑组织的集成方法及其长期目标。如果您想要使用中心辐射模型来集成系统（其中 BizTalk 协调许多应用程序的活动），BizTalk Server 非常有用。
还有其他集成模型 - 更流行的模型之一是分布式总线（不要将其与术语“企业服务总线”或 ESB 混淆）。您还可以让 BizTalk 作为分布式总线工作，并且还有其他解决方案可以提供更直接的支持。替代解决方案之一是名为 nServiceBus 的开源解决方案。
在考虑是否使用 BizTalk 等商业产品还是其他产品（开源或内部开发）时，还要考虑维护和增强以及市场上必要技能集的可用性。
我写了一些文章，更详细地介绍了我在这里讨论的要点 - 以下是链接：
- 为什么选择 BizTalk？ https://web.archive.org/web/20110210195911/http://artofbabel.com/specials/50-why-biztalk.html
- BizTalk 十大错误 https://web.archive.org/web/20100913035417/http://artofbabel.com/columns/top-x/49-top-10-biztalk-server-mistakes.html
- BizTalk Server 中的可扩展性功能 https://web.archive.org/web/20110210194635/http://artofbabel.com/specials/58-extensibilityfeaturesinbiztalkserver.html
- 与 nServiceBus 的开源集成 https://web.archive.org/web/20120314180441/http://artofbabel.com/specials/55-open-source-integration-with-nservicebus.html
本文内容由网友自发贡献，版权归原作者所有，本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容，请联系:hwhale#tublm.com(使用前将#替换为@)
