Maa*_*ten 6 .net c# workflow-foundation-4
对于客户端,我们正在创建的系统必须支持以下内容:
- 必须能够运行多个工作流,以及具有不同上下文(不同数据/业务对象)的相同工作流的多个实例.
- 某些工作流程将长时间运行,涉及多个用户/客户端会话并等待外部用户输入.因此,工作流必须能够持久化并响应来自客户端应用程序的某些信号.这也意味着必须在服务器应用程序上执行工作流程(对吗？).
- 我希望能够在服务器应用程序上运行各种工作流程,并且我不希望在工作流程更改时重新部署服务器应用程序.
我的第一个想法是Workflow Services.经过大量研究后,我得出结论认为这不是正确的道路,因为Workflow Services基本上可以在客户端应用程序中启动的工作流程中执行远程位置的活动.它是否正确？或者我可以在上面的场景中使用Workflow Services吗？大多数示例和/或教程基本上是一个ReceiveSignal/Send组合,其间有一些逻辑.
基本上我想(从客户端应用程序)启动具有特定上下文的工作流的开始(在工作流服务器应用程序中).
什么是最好的方法？
很感谢任何形式的帮助!
小智 15
至于你的要求:
必须可以运行多个工作流,以及具有不同上下文(不同数据/业务对象)的相同工作流的多个实例.
这对WF来说没有问题.
某些工作流程将长时间运行,涉及多个用户/客户端会话并等待外部用户输入.因此,工作流必须能够持久化并响应来自客户端应用程序的某些信号.这也意味着必须在服务器应用程序上执行工作流程(对吗？).
WF专为长期运行的任务而设计,可以与外部影响相互作用.然而,这并不是说它很容易实现; 没有通用的解决方案,你可以挂钩.您可能必须设计与Workflow Extensions交互的自定义活动,以处理将用户输入移动到工作流中的问题.与将工作流暴露给外部相同,尽管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的工作流.一旦您确定了简单版本,就可以扩大范围以涵盖您的所有要求.