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年工作，但我还需要了解如果我通过BizTalk利用WF，我将不得不使用哪些组件。请向我提供您的经验。

Answer 1

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

BizTalk最适合于系统间，部门间和公司间的集成+业务流程工作流程（BPEL） - 即企业问题。 迄今为止，IMO WF已经定位了更多的内部系统或应用问题。 但无疑，越来越多的灰色地带正在向Azure + Appfabric方向发展。

看来你在寻找WF进行整合？

转换 - 无疑在BizTalk一件好事 - 因为你可以在XSLT映射无论是视觉上或直接，你可以快速变换的端口或业务流程的信息格式，并留下作为一种事后的物理技术 - 即你可以在逻辑层面上实现您的设计，并且不会陷入任何特定技术（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引擎将是前进的方向。

Answer 2

好帖子和答案。

现在WF Manager是否可用，人们是否开始看到客户将WF用于集成项目？以前的ID从来没有真正看到任何人认为WF + WCF除了小规模或小生境之外的任何东西，因为缺乏成熟的托管环境。人们开始看到现实世界的变化吗？

我还可以在stuart提及的缺点上添加我的观点。我不同意100％的评论。

• 成本

成本不是一样大问题，因为它曾经是。 Azure上的BizTalk可以为您改变这种情况，因此您可以在模型中使用付费设置。虽然当您考虑解决方案类型的范围时仍然存在许可证费用（每月），那么您可以构建其不错的性价比。我认为人们经常难以量化定制构建解决方案的成本，并且只是假设，因为biztalk获得了许可证，它必须更昂贵。当人们争论BizTalk的成本时，我经常问他们为什么会使用Sharepoint进行协作，只要他们可以使用共享文件夹和电子邮件。我认为成本是相对的，对于一些公司来说，如果你只有几个整合流程，它可能比你会得到的价值更多，但对于其他公司而言，它可能是一笔很好的投资。

• 缓升/开发

我同意的BizTalk是一家专门技能，但它不是真的那么不同，以在任何其他平台的开发人员。有时候一家公司希望把一个没有经验的.net开发人员加入到分享点或动态CRM中，然后想知道他们为什么会犯错误，你不需要成为一名真正的genuis。有一些很好的资源可以帮助你成为一名biztalk开发者，尤其是与某些竞争对手的产品相比，id认为这是一种超越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