将WF 4.0作为服务器端组件运行 [英] Run WF 4.0 as a server-side component
问题描述
Hi all, 一个新项目，我们需要使用WF 4.0来部署和运行工作流.我们决定在服务器端组件中负责运行工作流，而不是在应用程序内部托管工作流. For a new project, we need to use WF 4.0 for deploying and running workflows. Instead of hosting workflows within the application itself, we decided to implement a server-side component that is in charge of running workflows. WF 4.0具有对运行时引擎(WorkflowRuntime)的显式访问，该引擎提供了一些基本的管理功能，例如检索当前正在运行的工作流等.据我所知，WF 4.0缺少此显式访问，因为工作流是通过WorkflowInstance类创建的，WorkflowRuntime ...没有立即可用的引用. Before WF 4.0, one had explicit access to the the runtime engine (WorkflowRuntime), which provided some basic management functionalities, such as retrieving the workflows currently running etc ... As far as I could find out, WF 4.0 lacks this explicit access, as workflows are created via the WorkflowInstance class and no reference is immediately available to the WorkflowRuntime ... 如果我需要在服务器端使用这些管理功能，我正确地需要自己实现这些功能?还是我错过了某件事... If I need these management functionalities on the server side, I'm a correct that I will need to implement these myself? Or did I miss out on something ... 感谢提前为您解答！ 这篇关于将WF 4.0作为服务器端组件运行的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！推荐答案
您希望在服务器上运行哪种工作流程?
可以为工作流使用一些不同的托管"选项:
1)WorkflowInvoker-这将只创建工作流的单个实例并直接调用它，但是它没有不支持持久性或跟踪.
2)WorkflowInstance-这将创建工作流的单个实例，并允许您挂接持久性，恢复书签，启用跟踪等.通常，当您要自己管理所有工作流实例时使用.
3)WorkflowServiceHost-这是开箱即用的主机，可让您创建多个实例.它负责实例管理，连接到配置，启用持久性，跟踪等.它还与WCF基础结构管道挂钩，以允许您使用Receive活动并将来自特定端点的WCF消息接收到您的工作流程中. WorkflowServiceHost还具有可扩展性点，使您可以添加主机扩展来控制实例的某些方面.
使用哪个主机"的决定在很大程度上取决于工作流本身的特征.但我希望至少能帮助您解释一些选择.
-戴夫What kinds of workflows are you looking to run on your server?
There are a few different "hosting" options for workflow that you can use:
1) WorkflowInvoker - this will just create a single instance of the workflow and invoke it directly, but it doesn't support persistence or tracking. This is typically used for small, short-running workflows.
2) WorkflowInstance - this will create a single instance of the workflow and allows you to hook up persistence, resume bookmarks, enable tracking, etc. This is typically used when you want to manage all of the workflow instances yourself.
3) WorkflowServiceHost - this is the out-of-the-box host that allows you to create multiple instances. It is responsible for instance management, hooking up to config, enabling persistence, tracking, etc. It also hooks into the WCF infrastructure pipeline to allow you to use the Receive activity and receive WCF messages from particular endpoints into your workflow. The WorkflowServiceHost also has extensibility points to allow you to add host extensions which control some aspects of the instances.
The decision of which "host" to use depends a lot on the characteristics of the workflows themselves. But I hope that at least helps explain some of your options.
-- Dave
