WF 4或BizTalk 2010？

Question

我有一个问题 - BizTalk或WF？让我澄清一下,我意识到前三个工件背后的类似技术,并意识到我可以构建它们,但我没有发现它们是内置于WF,所以我试图理解为什么我会使用一个技术优于其他.

1. 转换
2. 绑定
3. 端口/适配器
4. BizTalk未来

转换

BizTalk本身支持的功能非常好,增强的设计人员可以启动,生成模式和地图的能力.此外,我喜欢所有内容都已转换的事实,因为我不必担心我的工作流程中的集成点,因为它始终采用一致的格式,这可以降低我的风险,因为我的集成变异 - 我只需要重构模式和映射.

相比之下,对于WF,我没有内置的豪华,所以我错过了什么或BizTalk在这里有+1？

绑定

绑定是BizTalk中另一个完全封装的功能.我可以将我的工作流设置为具有我想要的任何绑定,因为上述工件意味着在测试期间我可以绑定到文件系统并且在生产期间我可以绑定到服务.

相比之下,对于WF,我没有内置的豪华,所以我错过了什么或BizTalk在这里有+2？

端口/适配器

这很可能是BizTalk中存在的最大工件 - 恕我直言.将物理连接抽象为众多具体实现所需的工作量,特别是在一个非常庞大的组织中,其中一些具体的内容通过基本的文件系统而不是SOAP/REST,以及像IBM Mainframe和MSMQ这样的东西.BizTalk的物理端口适配器在向工作流发送消息之前通过转换自动运行原始数据,非常简单,优雅.

相比之下,对于WF,我没有内置的豪华,所以我错过了什么或BizTalk在这里有+3？

BizTalk未来

最后,我想提一下,根据我的研究,构建BizTalk的同一团队正在构建WF - 这太棒了!此外,微软的长期愿景是这个新的流行词"集成服务器",实际上是一大堆松散耦合的框架,提供了BizTalk今天的功能.由于Azure的努力,这项工作对我来说很有意义 - 我肯定会为此做出贡献.但是,我今天需要实现一个解决方案,这个解决方案将在15年后开始工作,但是如果我利用WF而不是BizTalk,我还需要了解我必须使用哪些部分来组合它.请告诉我你的经历.

Answer 1

(免责声明 - 我的WF经验限于WF3.0,所以我可能会支持最近的WF发展)

BizTalk最适合于系统间,跨部门和公司间集成+业务流程工作流(BPEL) - 即企业关注点.到目前为止,IMO WF已经更多地关注内部系统或应用程序问题.但毫无疑问,灰色地带越来越多,因为它们似乎正在向Azure + Appfabric汇聚.

您似乎正在考虑使用WF进行集成？

转换 - 在BizTalk中无疑是一件好事 - 鉴于您可以在XSLT中直观地或直接地映射,您可以快速转换Ports或Orchestrations上的消息格式,并将物理技术用作事后想法 - 即您可以在逻辑层面并没有在任何特定技术(MQ,WCF,SQL,FTP等)中"陷入困境".

一个警告 - 模式管理可能会变得非常痛苦 - 每条消息都有一个模式,需要在BizTalk上的所有应用程序中使用唯一的XMLNS#Root.您可以"不可知"并使用规范模式进行内部流程 - 因此需要良好的命名,配置和管理规则.如果要将BizTalk与许多WCF/WebService服务耦合,则模式管理变得特别繁琐 - 对于所使用的每个服务都会有一个请求和响应模式(如果使用MessageContract,则可以共享公共模式).

绑定 - 你几乎得到了它.此外,如果使用直接(消息框)绑定,则可以选择具有多个传入接收位置,或通过简单地添加具有适当过滤器的新端口来发送目标.这个pub-sub功能构成了Bizalk的ESB工具包的基础.不同环境的绑定(Dev,UAT,Prod等)也可以很好地管理.

适配器 - 同意 - 从文件切换到MQ系列就像更改端口配置一样简单.BizTalk与MSMQ和IBM MQ非常合作.

此外,不要低估管理和维护EAI/BP解决方案的工作量 - 集成通常对企业至关重要,跟踪错误和避免停机时间至关重要.BizTalk具有以下运营优势:

• 运营管理 - 跟踪/跟踪,暂停消息管理,SCOM集成包等
• 可扩展性/群集/故障转移功能,适配器重试,自动限制等
• 业务监控和事件 - BAM

IMO对BizTalk的重大'缺点'是:

• 成本
• 加速熟练开发的时间(BTS有它的怪癖,例如僵尸和在XLS和XML文件中定义BAM定义)
• 加快网络/管理专业人员的操作管理技能

结论:如果您正在使用少量非关键消息进行2或3个应用程序之间的集成,那么请使用专有或WF路由,但如果您正在寻找企业级解决方案,那么像BizTalk这样的EAI/BPEL引擎就是这样的向前.