15

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

  1. 转型
  2. 绑定
  3. 端口/适配器
  4. 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，我必须使用哪些部分来组合它。请把你的经验告诉我。

4

2 回答 2

14

（免责声明-我的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 引擎将是方式向前。

于 2012-03-08T11:28:43.523 回答
2

很棒的帖子和答案。

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

我也可以添加我对斯图尔特提到的缺点的看法吗？我不同意他的评论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

于 2013-05-20T17:20:56.753 回答