Windows工作流基础WF4 -工作流托管

Question

对于客户端，我们创建的系统必须支持以下内容：

• 必须能够运行多个工作流，以及具有不同上下文(不同数据/业务对象)的同一工作流的多个实例。
• 某些工作流将长期运行，涉及多个用户/客户端会话并等待外部用户输入。因此，工作流必须能够持久化，并响应来自客户端应用程序的某些信号。这也意味着工作流的执行必须在服务器应用程序上完成(对吗？)。
• 我希望能够在服务器应用程序上运行所有类型的工作流，并且我不希望在工作流发生变化时必须重新部署服务器应用程序。

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

基本上，我希望(从客户端应用程序)启动具有特定上下文(在工作流服务器应用程序中)的工作流。

最好的方法是什么？

任何帮助都是非常感谢的！

Answer 1

至于你的要求：

必须能够运行多个工作流，以及具有不同上下文(不同数据/业务对象)的同一工作流的多个实例。

这对于WF来说没有问题。

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

WF是为能够与外部影响交互的长时间运行的任务而设计的。然而，这并不是说它很容易实现；没有可以挂钩的通用解决方案。您可能必须设计与Workflow Extensions交互的自定义活动，这些活动处理将用户输入移动到工作流中。与向外公开工作流一样，尽管WF4确实附带了一系列可用于实现此目的的WCF活动。

我希望能够在服务器应用程序上运行所有类型的工作流，并且我不希望在工作流发生变化时必须重新部署服务器应用程序。

这就更难实现了。至少，您必须将工作流与服务器代码分开。最简单的方法是以xaml和load it at runtime的形式从数据库中存储工作流。

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

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

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

第一个是使用简单外观的稳定工作流的一个很好的选择。这对您来说似乎不是一个好的选择，因为您必须在工作流更改时动态加载它们；这需要工作流外部的逻辑来处理不仅来自客户端的通信(“这是一个新版本的工作流X!")而且还管理工作流寿命。

似乎你必须找到某种类型的主机应用程序(IIS应用程序，Windows Service，AppFabric，Azure)，定义你的WebService服务并使其在线，处理来自客户端的调用，将这些调用传达给你的工作流运行代码，然后它必须加载和执行这些调用，并返回结果。

我不禁注意到，你似乎对等待你的旅程准备得不够充分。我强烈建议创建一个原型，整齐地切开您需求的最中心部分。一个具有WCF前端的托管应用程序(我建议使用AppFabric)，它加载一个基于XAML的工作流来处理客户端调用。一旦你确定了简单的版本，你就可以扩大范围来涵盖你的所有需求。