Windows Workflow Foundation WF4 - 工作流托管

Question

Windows Workflow Foundation WF4 - 工作流托管

6

对于客户，我们正在创建的系统必须支持以下内容：
- 必须能够运行多个工作流，并且可以使用不同的上下文（不同的数据/业务对象）运行相同工作流的多个实例。
- 一些工作流是长时间运行的，涉及多个用户/客户端会话并等待外部用户输入。因此，工作流必须能够被持久化并响应来自客户端应用程序的某些信号。这也意味着工作流的执行必须在服务器应用程序上完成（对吧？）。
- 我想在服务器应用程序上运行各种类型的工作流，并且不希望在工作流更改时重新部署服务器应用程序。

我的第一个想法是Workflow Services。经过大量的研究，我得出结论，这不是正确的路径，因为Workflow Services基本上提供了在远程位置执行活动的可能性，而这些活动是从客户端应用程序启动的工作流。这是正确的吗？或者我可以在上述情况下使用Workflow Services吗？大多数示例和/或教程基本上是使用ReceiveSignal/Send组合以及其中的一些逻辑。

基本上，我想要从客户端应用程序开始启动具有特定上下文的工作流（在工作流服务器应用程序中）。

最佳方法是什么？

非常感谢任何帮助！

- Maarten

1个回答

网页内容由stack overflow 提供, 点击上面的

可以查看英文原文，
原文链接

- user1228 · Accepted Answer

关于您的要求：

必须能够运行多个工作流，并且使用不同的上下文（不同的数据/业务对象）运行相同工作流的多个实例是可行的。

对于WF来说，这是没有问题的。

一些工作流将是长时间运行的，涉及多个用户/客户会话，并等待外部用户输入。因此，工作流必须能够持久化并响应客户端应用程序的某些信号。这也意味着工作流的执行必须在服务器应用程序上进行（对吗？）。

WF专为可以与外部影响交互的长时间运行任务而设计。然而，这并不意味着很容易实现；没有通用的解决方案可以挂钩。您可能需要设计自定义活动，与工作流扩展交互，处理将用户输入移入工作流中。同样，将工作流暴露给外部也是如此，尽管WF4带有大量WCF活动，可用于完成此操作。

我想在服务器应用程序上运行各种工作流，而不希望在工作流更改时重新部署服务器应用程序。

这更难实现。您必须至少将工作流与服务器代码分开。最简单的方法是将工作流存储为xaml，并从数据库等位置在运行时加载。

其他选项是使用某种依赖注入框架（例如Structure Map或Unity），在运行时加载工作流程程序集。如果工作流程发生变化，您可以在服务器上放置新的程序集，更改配置并重新启动。或者，您可以将工作流程程序集隔离在其自己的AppDomain中，在运行时加载它们，并在必须重新加载新版本时放弃该域。你要做哪一个取决于你的要求；实际上我正在执行第三个选项，因为我必须在运行时加载许多不同版本的工作流程程序集，同时运行它们，并且它们经常具有嵌入式资源，从而防止我走XAML路线。

我的第一个想法是Workflow Services。经过大量研究，我得出结论，这不是正确的路径，因为Workflow Services基本上提供了在客户端应用程序中启动的工作流程在远程位置执行活动的可能性。这是正确的吗？

我将我的工作流程托管在标准的Windows服务应用程序中。我必须管理和维护客户端用于与我的工作流程交互的WCF前端。据我所知，如果我理解正确的话，Workflow Services似乎是一个可行的稳定工作流程的选择。在AppFabric中托管应用程序也是一个很好的选择，我认为比使用Windows服务更简单。但是无论主机是什么，您都有两个选项-您的工作流程定义了您的服务契约，或者您必须定义服务契约并处理您正在管理的工作流程的所有执行和通信。

第一种方法适用于具有简单外观的稳定工作流程。但是，由于您必须在工作流程发生更改时动态加载工作流程，因此它似乎不适合您。这需要在工作流之外处理逻辑，以处理来自客户端的通信（“这是工作流程X的新版本！”），并管理工作流的生命周期。

看起来您将不得不找到某种主机应用程序（IIS WebService应用程序、Windows服务、AppFabric、Azure），定义WCF服务并将其上线，处理来自客户端的调用，将这些调用传达给正在运行的工作流程代码，然后必须加载和执行这些调用，并将结果返回到链上。

我不禁注意到您似乎略微准备不足，面临着等待您的旅程。我强烈建议创建一个原型，从而精确地满足您需求的核心。使用托管应用程序（我建议使用AppFabric）和WCF前端加载基于XAML的工作流程，以处理客户端调用。一旦您掌握了简单版本，就可以扩大范围以涵盖所有要求。