在评估不同的系统集成策略时,我遇到了一些鼓励的话,但也有一些关于BizTalk Server的挫败感.
使用BizTalk Server(从开发人员的角度和业务用户)有什么优缺点,公司是否也应该考虑开源替代品？有哪些可行的替代方案？
编辑:Jitterbit似乎是一个有趣的选择.开源,似乎很好地设计.这里的任何人都有使用它的经验吗？
BizTalk Server的主要优点是它提供了许多关于部署,管理,性能和可伸缩性的"管道".通过Visual Studio,它还提供了一个用于开发解决方案的综合框架,通常只需要相对较少的代码.
其他人提到的挫折和陡峭的学习曲线通常来自于使用BizTalk的错误目的以及对如何使用BizTalk和面向消息的系统的误解.学习曲线并不像大多数人所说的那样陡峭 - 潜在学习的基本部分实际上侧重于将思维从程序化方法转变为无状态的基于消息的方法.
人们经常提到的缺点是成本.标价似乎很高; 但是,与您自己开发和支持功能所花费的金额相比,这是便宜的.
在考虑替代方案或甚至考虑BizTalk服务器之前,您应该考虑组织的集成方法及其长期目标.如果您希望使用集线器和辐条模型集成系统,BizTalk Server非常适合,其中BizTalk协调许多应用程序的活动.
还有其他集成模型 - 其中一种比较流行的是分布式总线(不要将其与术语"企业服务总线"或ESB混淆).您还可以将BizTalk作为分布式总线工作,并提供可提供更直接支持的替代解决方案.其中一个替代解决方案是名为nServiceBus的开源解决方案.
在考虑是否使用像BizTalk这样的商业产品时,要比其他东西(开源或内部开发),还要考虑维护和增强以及市场中必要技能的可用性.
我写了一些文章,详细介绍了我在这里讨论的要点 - 这里是链接:
为什么选择BizTalk？
十大BizTalk错误
BizTalk Server中的可扩展性功能
与nServiceBus开源集成
我对BizTalk的体验基本上是浪费时间.
当您进行B2B数据集成(这可能是任何企业应用程序中最难的部分)时,您只需要推出自己的解决方案,就会有很多边缘情况和奇怪的小业务逻辑调整.
解析数据文件并将其转换为其他格式有多难？没那么难.除非你试图将像Biztalk这样臃肿的中间件系统注入其中.
作为一名BizTalk顾问,我必须至少部分同意Eric Z Beard,有很多边缘案例占用了大量时间.但是很多场景也处理得非常顺畅,所以这一切都取决于IMO.但当你(埃里克)打电话给BizTalk臃肿我不得不反对!我们发现它的性能和可靠性非常出色,它非常灵活,并且配备了许多开箱即用的好适配器.
BizTalk需要正确使用,我是BizTalk开发人员,我对BizTalk的体验非常好.它可靠,高性能,可扩展,包含许多内置的架构模式和内置组件,使集成变得简单快捷,您可以获得安全性,重试,二次传输,验证,转换等......以及您没有构建的内容使用BizTalk,您可以轻松地使用.NET代码进行自定义,它基本上是一个很难获得的集成系 但是,您需要知道如何正确实现BizTalk,而不是一旦我遇到实现的解决方案,并且通常也会错误地构建.
但BizTalk的真正好处在于,您可以实施小型解决方案并扩展规模,而大型供应商的大多数其他集成系统只会销售整个集成包,而且成本更高.
BizTalk被认为是微软公司最复杂的服务器.
所以任何一个说BizTalk不是很好的人都知道BizTalk时期.
我们在公司评估了BizTalk,真的很失望.
我们正在使用IBM WebSphere Transformation Extender(它也有很多(其他)问题),与WTX相比,BizTalk的映射工具是一个笑话.
图形工具实际上不适用于复杂的映射(我们在重复组中有几百个字段的模式),如果你做的不仅仅是通常的"concat名字和名字命名"映射,你会厌倦图形方法(例如,图形映射器中functoid的参数未标记,并且将字段连接到这些参数的顺序很重要).
XSLT-Mapper可以使用,但不是很有说服力,甚至微软代表告诉我们使用像XMLSpy这样的工具来安装XSLT并将生成的XSL文件加载到BizTalk中.
第三种映射方法是使用C#-Code进行映射,这对于我们来说是不可接受的一般方法(我们不想教给每个人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除外)都没有重试功能,所以如果你想要,你必须自己编写.其次,如果欢乐会失败,可以失去约会.我会称之为非常容易使用(虽然没有文档),但我很难将其称为企业解决方案.我要去看看jitterbit 这是别人提到的.
京公网安备 11010802040832号 | 京ICP备19059560号-6 