我有一个问题 - BizTalk或WF？让我澄清一下，我意识到前三个工件背后的类似技术，并意识到我可以构建它们，但我没有发现它们是内置于WF，所以我试图理解为什么我会使用一个技术优于另一方。
转换
BizTalk本身支持增强的设计人员启动，生成模式和地图的能力，这是非常好的。此外，我喜欢所有内容都已转换的事实，因为我不必担心我的工作流程中的集成点，因为它始终采用一致的格式，这可以降低我的风险，因为我的集成变异 - 我只需要重构模式和映射
相比之下，对于WF，我没有内置的奢侈品，所以我错过了什么或BizTalk在这里有+1？
绑定
绑定是BizTalk中另一个完全封装的功能。我可以将我的工作流设置为具有我想要的任何绑定，因为上述工件意味着在测试期间我可以绑定到文件系统，在生产期间我可以绑定到服务。
相比之下，对于WF，我没有内置的奢侈品，所以我错过了什么或BizTalk在这里有+2？
端口/适配器
这很可能是BizTalk中存在的最大工件 - 恕我直言。将物理连接抽象为众多具体实现所需的工作量，特别是在一个非常大的组织中，其中一些具体的组件通过基本文件系统而不是SOAP / REST，以及像IBM Mainframe和MSMQ这样的东西。 BizTalk的物理端口适配器在向工作流发送消息之前通过转换自动运行原始数据，非常简单，优雅。
相比之下，对于WF，我没有内置的奢侈品，所以我错过了什么或BizTalk在这里有+3？
BizTalk Future
最后，我想提一下，在我的研究中，构建BizTalk的同一团队正在构建WF - 这太棒了！此外，微软的长期愿景是这个新的流行词“集成服务器”，实际上是一大堆松散耦合的框架，提供了BizTalk今天的功能。由于Azure的努力，这项工作对我来说很有意义 - 我肯定会为此做出贡献。但是，我需要实现一个解决方案今天，这个解决方案将在15年后开始工作，但是如果我利用WF而不是BizTalk，我还需要了解我必须使用哪些部分来组合它们。请告诉我你的经历。
答案 0 :(得分：14)
（免责声明 - 我的WF经验仅限于WF3.0，因此我可能会支持最近的WF发展）
BizTalk最适合于系统间，部门间和公司间集成+业务流程工作流程（BPEL） - 即企业关注点。 到目前为止，IMO WF已经更多地关注内部系统或应用程序问题。 但毫无疑问，灰色区域越来越多，因为它们似乎正在向Azure + Appfabric汇聚。
您似乎正在考虑使用WF进行集成？
转换 - 在BizTalk中无疑是一件好事 - 鉴于您可以在XSLT中直观地或直接地映射，您可以快速转换Ports或Orchestration上的消息格式，并将物理技术保留为事后的想法 - 即您可以在逻辑层面实现您的设计，并且不会在任何特定技术（MQ，WCF，SQL，FTP等）中陷入困境。
一个警告 - 模式管理可能会变得非常痛苦 - 每条消息都有一个模式，需要在BizTalk上的所有应用程序中使用唯一的XMLNS＃Root。您可以“不可知”并使用规范模式进行内部流程 - 因此需要良好的命名，配置和管理规则。 如果将BizTalk与大量WCF / WebService服务耦合，则模式管理变得尤为繁重 - 每个服务都会有一个请求和响应模式（如果使用MessageContract，则可以共享公共模式）。
绑定 - 你已经得到了它。此外，如果使用直接（消息框）绑定，则可以选择具有多个传入接收位置，或通过简单地添加具有适当过滤器的新端口来发送目标。这个pub-sub功能构成了Bizalk的ESB工具包的基础。不同环境的绑定（Dev，UAT，Prod等）也可以很好地管理。
适配器 - 同意 - 从文件切换到MQ Series就像更改端口配置一样简单。 BizTalk与MSMQ和IBM MQ非常合作。
此外，不要低估管理和维护EAI / BP解决方案的工作量 - 集成通常对企业至关重要，跟踪错误和避免停机至关重要。 BizTalk具有以下运营优势：
IMO对BizTalk的重大'缺点'是：
结论：如果您正在使用少量非关键消息进行2或3个应用程序之间的集成，那么请使用专有或WF路由，但如果您正在寻找企业级解决方案，那么像BizTalk这样的EAI / BPEL引擎会是前进的方向。
答案 1 :(得分：2)
很棒的帖子和答案。
当WF Manager可用时，人们是否开始看到客户考虑使用WF进行集成项目？以前从来没有真正看到任何人因为缺乏成熟的托管环境而考虑WF + WCF以外的任何小规模或小众区域。人们是否开始在现实世界中看到这种变化？
我是否还可以在stuart提及的缺点中添加我的观点。我不同意100％的评论。
成本不像以前那么重要。 Azure上的BizTalk可以为您改变这种情况，因此您可以使用付费模式进行设置。虽然在考虑解决方案类型的范围时仍然存在许可证成本（仅每月一次），但您可以建立其不差的物有所值。我认为人们通常很难量化自定义构建解决方案的成本，并且只是假设因为biztalk获得了许可证，它必须更加昂贵。当人们讨论BizTalk的成本时，我经常会问为什么当他们可以使用共享文件夹和电子邮件时，他们会使用Sharepoint进行协作。我认为成本是相对的，对于一些公司来说，如果你只有几个集成流程，它可能比你获得的价值更高，但对于其他公司来说，它可能是一个很好的投资。
我同意biztalk是一种专业技能，但它与任何其他平台上的开发人员并没有什么不同。有时一家公司想把一个没有经验的.net开发人员放到sharepoint或动态CRM上，然后想知道他们为什么会犯错误，你不需要成为一个工作的人。有一些很好的资源可以帮助你成为一个biztalk开发者，特别是与一些竞争对手的产品相比，id认为这是我对WF的一种优势。 BizTalk开发的主要风险在于，如果你不知道自己在做什么，你可以很容易地做到这一点。这是业界常见的错误，但我已经看到其他平台实施已经很多次了
（注意“作为竞争对手的WF”我认为WF是BizTalk所做的一个子集的竞争对手，但从长期来看，我认为它们在某些情况下也会相互补充）
这与您要介绍的任何新产品没有任何不同，您的公司需要与您的IT专业人员合作，以使他们能够支持和维护您使用过的任何产品。获得一个好的BizTalk管理员并不是最简单的事情，但是有很多资源可以培训人员，如果你想外包它，可以在这个领域找到合作伙伴。
虽然WF是一个更简单的产品我不太确定从管理角度来看这个实现方面会简单得多。你仍然需要一个能够很好地运行的SQL Server。管理员的WF工具不太成熟，我不认为WF管理的支持空间是成熟的。
你可能想查看下面的书，其中有一章（我认为），他们认为BizTalk或WF + AppFabric，一些有趣的讨论点
http://www.packtpub.com/applied-architecture-patterns-microsoft-platform/book#chapter_7