我有一个问题 - BizTalk 还是 WF?让我澄清一下,我意识到前三个工件背后的类似技术,并意识到我可以构建它们,但我没有发现它们是 WF 内置的,所以我试图理解为什么我会使用一个技术优于其他。
- 转型
- 绑定
- 端口/适配器
- BizTalk 未来
转型
BizTalk 本身支持生成模式和映射的能力,增强了设计器的启动能力,这非常好。此外,我喜欢一切都被转换的事实,因为我不必担心我的工作流程中的集成点,因为它始终采用一致的格式,这降低了我的风险,因为我的集成发生了变化——我只需要重构模式和映射.
相比之下,使用 WF,我没有内置那种奢华,所以我错过了什么还是 BizTalk 在这里有 +1?
绑定
绑定是 BizTalk 中另一个完全封装的功能。我可以将我的工作流程设置为具有我想要的任何绑定,因为上述工件意味着在测试期间我可以绑定到文件系统,而在生产期间我可以绑定到服务。
相比之下,使用 WF,我没有内置那种奢华,所以我错过了什么还是 BizTalk 在这里有 +2?
端口/适配器
这很可能是 BizTalk 中存在的最大工件 - 恕我直言。将您的物理连接抽象为众多具体实现所需的工作量,尤其是在一个非常大的组织中,其中一些具体实现超越了基本的文件系统与 SOAP/REST 相比,并进入了 IBM 大型机和 MSMQ 之类的东西。BizTalk 的物理端口适配器在向工作流发送消息之前通过转换自动运行原始数据,非常简单、优雅。
相比之下,使用 WF,我没有内置的那种奢华,所以我错过了什么还是 BizTalk 在这里有 +3?
BizTalk 未来
最后,我想提一下,根据我的研究,构建 BizTalk 的同一团队正在构建 WF——这太棒了!此外,Microsoft 的长期愿景是这个新的流行词“集成服务器”,实际上是提供 BizTalk 现在所做的大量松散耦合框架。由于 Azure 的努力,这种努力对我来说很有意义——我确信它对此做出了贡献。但是,我今天需要实施一个可以在 15 年后工作的解决方案,但我还需要了解如果我利用 WF 而不是 BizTalk,我必须使用哪些部分来组合它。请把你的经验告诉我。