Windows Workflow Foundation WF4 - 工作流托管
对于客户，我们创建的系统必须支持以下功能：
- 必须能够运行多个工作流程，以及具有不同上下文（不同数据/业务对象）的相同工作流程的多个实例。
- 某些工作流程将长时间运行，涉及多个用户/客户端会话并等待外部用户输入。因此，工作流程必须能够持久并响应来自客户端应用程序的某些信号。这也意味着工作流程的执行必须在服务器应用程序上完成（对吗？）。
- 我希望能够在服务器应用程序上运行各种工作流程，并且我不想在工作流程发生更改时重新部署服务器应用程序。
我的第一个想法是工作流服务。经过大量研究后，我得出的结论是，这不是正确的路径，因为工作流服务基本上提供了从客户端应用程序中启动的工作流在远程位置执行活动的可能性。这是正确的吗？或者我可以将工作流程服务用于上述场景吗？大多数示例和/或教程基本上都是接收信号/发送的组合，其中包含一些逻辑。
基本上我想（从客户端应用程序）启动具有特定上下文（在工作流服务器应用程序中）的工作流。
最好的方法是什么？
非常感谢任何帮助！
For a client the system we're creating must support the following:
- It must be possible to run multiple workflows, and multiple instances of the same workflows with a different context (different data/business objects).
- Some workflows will be long-running, involve multiple users/client session and waiting for external user input. So the workflows must be able to be persisted and respond to some signal from a client app. And it also means that the execution of workflows must be done on a server app (right?).
- I want to be able to run all kinds of workflows on the server app, and I do not want to have to re-deploy the server app when a workflow changes.
My first thought was Workflow Services. After a lot of research I concluded that this is not the right path since Workflow Services basically gives the possibility to execute activities at a remote location from a workflow started in a client app. Is this correct? Or can I use Workflow Services for the scenario above? Most examples and/or tutorials are basically a ReceiveSignal/Send combination with some logic in between.
Basically I want to initiate (from a client app) the start of a workflow with a specific context (in the workflow server app).
What is the best approach?
Any help is very much appreciated!
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
至于你的要求：
这对于WF来说是没有问题的。
WF 专为可以与外部影响交互的长时间运行的任务而设计。然而，这并不意味着它很容易实现。没有可以使用的通用解决方案。您可能需要设计与工作流程扩展交互的自定义活动，其中处理将用户输入移动到工作流程中。与将工作流暴露给外部相同，尽管 WF4 确实附带了许多可用于完成此任务的 WCF 活动。
这是比较难实现的。您必须至少将工作流与服务器代码分开。最简单的途径是将工作流程存储为 xaml 并加载它在运行时来自数据库。
其他选项是使用某种依赖注入框架（例如 Structure Map 或 Unity），它在运行时加载工作流程序集。如果工作流程发生变化，您可以将新程序集放到服务器上，更改配置并重新启动。或者，您可以将工作流程序集隔离在其自己的 AppDomain 中，在运行时加载它们，并在必须重新加载新版本时丢弃该域。选择哪一种取决于您的要求；我实际上正在执行第三个选项，因为我必须在运行时加载许多不同版本的工作流程序集，同时运行它们，并且它们通常具有嵌入的资源，从而阻止我走 XAML 路线。
我在标准 Windows 服务应用程序中托管我的工作流程。我必须管理和维护客户端用来与我的工作流程交互的 WCF 前端。据我所知，如果我理解正确的话，工作流服务似乎是稳定工作流的一个可行选择。在 AppFabric 中托管应用程序也是一个不错的选择，而且我认为比使用 Windows 服务更简单。但无论主机是什么，您都有两个选择 - 您的工作流定义您的服务合同，或者您必须定义服务合同并处理与您正在管理的工作流的所有执行和通信。
第一个是具有简单外观的稳定工作流程的不错选择。这对您来说似乎不是一个好的选择，因为您必须在工作流程发生变化时动态加载它们；这需要工作流外部的逻辑不仅要处理来自客户端的通信（“这是工作流 X 的新版本！”），还要管理工作流的生命周期。
似乎您必须找到某种主机应用程序（IIS WebService 应用程序、Windows 服务、AppFabric、Azure），定义您的 WCF 服务并将其联机，处理来自客户端的调用，将这些调用传达给您的工作流运行代码，这然后必须加载并执行这些调用并将结果返回到链上。
我不禁注意到你似乎对等待你的旅程准备不足。我强烈建议创建一个原型，可以整齐地切分您的需求的最核心部分。具有 WCF 前端的托管应用程序（我建议使用 AppFabric），加载基于 XAML 的工作流来处理客户端调用。一旦确定了简单版本，您就可以扩大范围以涵盖您的所有需求。
As for your requirements:
This is no problem with WF.
WF is designed for long running tasks that can interact with outside influences. However, that doesn't say its easy to accomplish; there is no universal solution which you can hook into. You will probably have to design custom Activities that interact with Workflow Extensions which handle moving user input into the workflow. Same with exposing the workflow to the outside, although WF4 does come with a host of WCF activities which could be used to accomplish this.
This is harder to accomplish. You must, at a minimum, separate the workflows from the server code. The simplest route is to store your workflow as xaml and load it at runtime from, say, a database.
Other options are to use some kind of dependency injection framework (such as Structure Map or Unity) which loads the workflow assembly at runtime. If the workflows change, you can drop the new assembly on the server, change your config and restart. Alternatively, you can isolate your workflow assemblies within their own AppDomain, load them at runtime and throw away the domain when you must reload a new version. Which one you do depends on your requirements; I'm actually doing the third option as I have to load many different versions of workflow assemblies at runtime, run them concurrently, and they often have embedded resources thus preventing me from going the XAML route.
I'm hosting my workflows within a standard Windows service application. I have to manage and maintain the WCF frontend which the client uses to interact with my workflows. As far as I can tell, Workflow Services seems like a viable option for stable workflows, if I understand it correctly. Hosting an application in AppFabric is also a good option, and I believe simpler than using a Windows Service. But no matter what the host is, you have two options--your workflows define your service contract, or you must define the service contract and handle all execution and communication with workflows you are managing.
The first is a good option for stable workflows with a simple facade. It doesn't seem like a good option for you, as you must load workflows dynamically as they change; that requires logic outside of the workflow to handle not only communications from the client ("here's a new version of workflow X!") but also managing the workflow lifespan.
It seems like you will have to find some kind of host application (IIS WebService application, Windows Service, AppFabric, Azure), define your WCF service and bring it online, handle calls from clients, communicate these calls to your workflow running code, which then must load and execute these calls and return the result up the chain.
I can't help but notice that you seem slightly ill-prepared for the journey that awaits you. I would strongly suggest creating a prototype that slices neatly through the centermost meat of your requirements. A hosted application (I'd suggest AppFabric) with a WCF frontend that loads a XAML-based workflow that processes client calls. Once you have the simple version nailed down, you can widen the scope to encompass all your requirements.