对于客户，我们正在创建的系统必须支持以下内容：
- 必须能够运行多个工作流，以及具有不同上下文（不同数据/业务对象）的相同工作流的多个实例。
- 某些工作流程将长时间运行，涉及多个用户/客户端会话并等待外部用户输入。因此，工作流必须能够持久化并响应来自客户端应用程序的某些信号。这也意味着必须在服务器应用程序上执行工作流程（对吗？）
- 我希望能够在服务器应用程序上运行各种工作流程，并且我不希望在工作流程更改时重新部署服务器应用程序。
我的第一个想法是Workflow Services。经过大量研究后，我得出结论认为这不是正确的道路，因为Workflow Services基本上可以在客户端应用程序中启动的工作流程中执行远程位置的活动。它是否正确？或者我可以在上面的场景中使用Workflow Services吗？大多数示例和/或教程基本上是一个ReceiveSignal / Send组合，其间有一些逻辑。
基本上我想（从客户端应用程序）启动具有特定上下文的工作流的开始（在工作流服务器应用程序中）。
最好的方法是什么？
非常感谢任何帮助！
答案 0 :(得分：15)
至于你的要求：
必须能够运行多个工作流，以及具有不同上下文（不同数据/业务对象）的相同工作流的多个实例。
WF没问题。
有些工作流程会长时间运行， 涉及多个用户/客户端会话 并等待外部用户输入。 所以工作流程必须能够 坚持并回应一些信号 来自客户端应用程序。它也意味着 工作流程的执行必须 在服务器应用程序上完成（对吧？）。
WF专为长时间运行的任务而设计，可以与外部影响进行交互。然而，这并不是说它很容易实现;没有通用的解决方案，你可以挂钩。您可能必须设计与Workflow Extensions交互的自定义活动，以处理将用户输入移动到工作流中的问题。与将工作流暴露给外部相同，尽管WF4确实附带了许多可用于实现此目的的WCF活动。
我希望能够运行各种各样的 服务器应用程序上的工作流程，我做 不想重新部署 工作流程更改时的服务器应用程序。
这很难完成。您必须至少将工作流与服务器代码分开。最简单的方法是将工作流存储为xaml，并将load it at runtime存储在数据库中。
其他选项是使用某种依赖注入框架（例如Structure Map或Unity），它在运行时加载工作流程程序集。如果工作流程发生更改，您可以在服务器上删除新程序集，更改配置并重新启动。或者，您可以在自己的AppDomain中隔离工作流程序集，在运行时加载它们，并在必须重新加载新版本时丢弃域。你做哪一个取决于你的要求;我实际上正在做第三个选项，因为我必须在运行时加载许多不同版本的工作流程序集，同时运行它们，并且它们通常具有嵌入式资源，从而阻止我进入XAML路径。
我的第一个想法是Workflow 服务。经过大量的研究我 得出的结论是，这不是正确的 自从Workflow Services以来的路径 给出了执行的可能性 在远程位置的活动 工作流程在客户端应用程序中启是 这是正确的吗？
我在标准的Windows服务应用程序中托管我的工作流程。我必须管理和维护客户端用来与我的工作流交互的WCF前端。据我所知，如果我理解正确，Workflow Services似乎是稳定工作流的可行选择。在AppFabric中托管应用程序也是一个不错的选择，我认为比使用Windows服务更简单。但无论主机是什么，您都有两个选择 - 您的工作流程定义您的服务合同，或者您必须定义服务合同并处理与您管理的工作流程的所有执行和通信。
对于具有简单外观的稳定工作流程，第一个是一个很好的选择。对您来说这似乎不是一个好选择，因为您必须在更改时动态加载工作流程;这需要工作流程之外的逻辑不仅要处理来自客户端的通信（“这是工作流程X的新版本！”），还要管理工作流程的生命周期。
您似乎必须找到某种主机应用程序（IIS WebService应用程序，Windows服务，AppFabric，Azure），定义您的WCF服务并使其联机，处理来自客户端的呼叫，将这些调用传达给您正在运行的工作流程代码，然后必须加载并执行这些调用并将结果返回到链。
我不禁注意到你似乎对等待着你的旅程做了一些准备不足。我强烈建议创建一个原型，整齐地切入您要求的最中心的肉。托管应用程序（我建议使用AppFabric），它带有一个WCF前端，用于加载处理客户端调用的基于XAML的工作流。一旦您确定了简单版本，就可以扩大范围以涵盖您的所有要求。