什么时候使用WF4内部的BizTalk Mapper Activity而不是BizTalk引擎?
本文关键字：BizTalk 引擎 Activity Mapper WF4 内部 什么时候 | 更新日期: 2023-09-27 18:13:34
我已经看到BizTalk 2010支持新的Mapper Activity for Workflow Foundation(从这里:在WF Designer for AppFabric Applications中轻松使用Mapper和LOB适配器)。这个依赖关系似乎与AppFabric绑定在一起(因此是IIS?)。问题是在什么情况下您会使用来自BizTalk引擎外部的映射器活动?在WF Runtime/AppFabric中托管映射器提供了哪些优势，而在BizTalk引擎中托管则没有?为什么不直接调用BizTalk编排Web服务呢?
BizTalk是一个健壮可靠的平台，可以托管您的业务流程并执行转换。为此，它包括一个SQL Server数据库，在其他方面，提供持久性，以确保面对硬件故障或软件崩溃时的弹性。
正因为如此，BizTalk进程被认为是重量级的，通常很难用BizTalk实现非常低的延迟。
相反，托管在IIS中的WF工作流通常比同等的BizTalk提供更低的延迟。但是，WF并没有提供一个开箱即用的流XSLT转换引擎，适合在不耗尽所有可用服务器资源的情况下处理大型消息。
这就是为什么在轻量级WF工作流中使用高效的流式BizTalk映射器在某些情况下是有意义的，因为它不会产生持久化到数据库的性能开销。
如果您已经运行了BizTalk，那么使用WF、AppFabric和BizTalk Mapper就没有多大意义了。这个功能似乎主要是为那些没有运行(也许不想运行)BizTalk的人准备的，尤其是那些已经在IIS中拥有所有东西的人。
IIS中的WF当然要轻量级得多。下面是一个演练，介绍了使用工作流和映射器的基本好处:http://seroter.wordpress.com/2011/04/03/using-the-biztalk-adapter-pack-and-appfabric-connect-in-a-workflow-service/
然而，这种安排中令人讨厌的部分是，您必须安装(授权的)BizTalk运行时。您可能知道，BizTalk许可证并不便宜。
[推测]展望未来，我预计我们将看到越来越多的BizTalk功能移植到IIS/AppFabric世界，因此最终(比如在10年内)BizTalk可以消失(假设我们不是都被迫离开自己的服务器而转向云，这也可能发生)。[/speculation]