WF 4 还是 BizTalk 2010？

Posted 2023-02-15

【中文标题】WF 4 还是 BizTalk 2010？

【英文标题】：WF 4 or BizTalk 2010?

【发布时间】：2012-03-25 08:08:02

【问题描述】：

我有一个问题 - 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，我必须使用哪些部分来组合它。请提供您的经验。

【参考方案1】：

（免责声明 - 我的 WF 经验仅限于 WF3.0，所以我可能落后于最近的 WF 发展）

BizTalk 最适合跨系统、跨部门和跨公司的集成 + 业务流程工作流 (BPEL) - 即企业关注点。 到目前为止，IMO WF 更多地定位于内部系统或应用程序问题。 但毫无疑问，灰色区域越来越多，因为两者似乎都在向 Azure + Appfabric 融合。

您似乎正在考虑集成 WF？

转换 - 在 BizTalk 中无疑是一件好事 - 鉴于您可以在 XSLT 中可视化或直接映射，您可以快速转换端口或编排上的消息格式，并将物理技术用作事后诸葛亮 - 即您可以在逻辑级别实现您的设计，并且不会在任何特定技术（MQ、WCF、SQL、FTP 等）中“陷入困境”。

一个警告 - 架构管理可能会变得相当痛苦 - 每条消息都有一个架构，它需要一个唯一的 XMLNS#Root 跨 BizTalk 上的所有应用程序。而且您可以“不可知论”并为您的内部流程使用规范模式——因此需要良好的命名、配置和管理规则。 如果您将 Bi​​zTalk 耦合到大量 WCF/WebService 服务，则架构管理会变得特别繁重 - 每个使用的服务都会有一个请求和响应架构（如果您使用 MessageContract，您可以共享通用架构）。

绑定 - 你已经掌握了。此外，如果您使用直接（消息框）绑定，您可以选择具有多个传入接收位置，或者通过简单地添加具有适当过滤器的新端口来发送目标。这种发布-订阅功能构成了 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 引擎会成为前进的方向。

【参考方案2】：

很棒的帖子和答案。

既然 WF Manager 可用，人们是否开始看到客户考虑将 WF 用于集成项目？由于缺乏成熟的托管环境，以前我从未真正看到有人考虑将 WF + WCF 用于除小规模或小众领域之外的任何领域。人们是否开始在现实世界中看到这种变化？

我还可以就斯图尔特提到的缺点添加我的观点吗？我不同意他的cmets 100％。

成本

成本不再像以前那样成为问题。 Azure 上的 BizTalk 可以为您改变这种情况，因此您可以使用现收现付模式进行设置。当您考虑解决方案类型的范围时，仍然存在许可成本（仅每月），但您可以构建其不差的物有所值的解决方案。我认为人们经常难以量化定制构建解决方案的成本，并且只是假设因为 biztalk 获得了许可证，所以它一定更贵。当人们争论 BizTalk 的成本时，我经常会问，当他们只能使用共享文件夹和电子邮件时，为什么还要使用 Sharepoint 进行协作。我认为成本是相对的，对于某些公司来说，如果您只有几个集成流程，它可能会比您获得的价值更高，但对于其他公司来说，这可能是一笔巨大的投资。

加速/开发

我同意 biztalk 是一种专业技能，但它与任何其他平台上的开发人员并没有什么不同。有时，一家公司希望将一个没有经验的 .net 开发人员放到 sharepoint 或 dynamics CRM 上，然后想知道他们为什么会犯错误，你不需要成为一个天才来解决这个问题。有一些很好的资源可以帮助您成为 biztalk 开发人员，尤其是与一些竞争对手的产品相比，我认为这是对 WF 的优势。 BizTalk 开发的主要风险在于，如果您不知道自己在做什么，那么您很容易将其做得非常糟糕。这是业内常见的错误，但我也多次看到其他平台实现也这样做过

（关于“WF 作为竞争对手”的说明，我将 WF 视为 BizTalk 所做工作的一部分的竞争对手，但从长远来看，我认为它们在某些情况下也会相互补充）

加速/管理

这与您将要推出的任何新产品实际上并没有什么不同，您的公司需要与您的 IT 专业人员合作，让他们能够支持和维护您使用的任何产品。获得一个优秀的 BizTalk 管理员并不是一件容易的事，但是有很多资源可以培训人员，如果您想外包，也有合作伙伴可以在这个领域。

虽然 WF 是一个更简单的产品，但我不太确定从管理员的角度来看，它的实现方面是否会简单得多。您仍然需要一个性能非常好的 SQL Server。用于管理员的 WF 工具还不够成熟，而且我认为 WF 管理的支持空间还不够成熟。

您可能想查看下面的书，其中有一章（我认为是 7）关于他们考虑 BizTalk 或 WF + AppFabric 的场景，一些有趣的讨论点

http://www.packtpub.com/applied-architecture-patterns-microsoft-platform/book#chapter_7