3

在问一个问题之前，在你们因为有几个类似的问题而生气之前，我想解释一下什么是项目要求。你会看到这个问题与所有其他问题不同。

  • 用户将使用 ReHosted WPF 应用程序创建工作流，并将 xaml 文件上传到我们将提供的 Web 应用程序。
  • 启动工作流执行的入口点位于该 Web 应用程序中。他们可以从自己的应用程序中使用 UI 或使用 API 功能。
  • 工作流程将长期运行。

我知道托管的不同可能性。

最简单的方法是将其托管在 ASP.NET Web 应用程序中，但由于我们不知道用户将上传什么样的工作流，IIS AppDomain 回收可能会破坏工作流线程的执行。

WCF 工作流服务看起来不错，但用户将上传自己的 xaml 工作流定义这一事实使事情变得更加复杂。看起来我们必须创建类似核心工作流的东西，公开为 WCF 服务，并且该工作流将加载并执行内部工作流（xaml 客户上传）。不确定在这种情况下如何将 in 参数传递给内部工作流。

第三种选择，也是我认为最好的选择，是在Windows Service中托管工作流执行。Web 应用程序和窗口服务之间的通信可以通过 MSMQ。此解决方案的缺点可能是用于确保 web 应用程序和 win 服务之间的良好通信的 boillerplate 代码。

我错过了更好的解决方案吗？如果您需要更多详细信息，请发表评论。

4

1 回答 1

3

我有类似的要求，并与“问题解决者”进行了长时间的讨论。

WF4.0 哪个架构更好？

现在我的结论是将 Workflow 开发为托管在 IIS 上的工作流服务。

您可以遵循这两种方法。

  1. 将工作流需求划分为更小的活动，它们可以是独立的 XAML 活动，并在工作流服务 (xamlx) 上创建工作流拖放。在需要时将这些与 InArgument 和 outargument 和相关上下文相关联。
  2. 在数据库中创建和存储工作流并动态加载它们。优秀的链接——http ://blogs.msdn.com/b/appfabric/archive/2011/06/16/how-to-load-wf4-workflow-services-from-a-database-with-iis-appfabric。 aspx
于 2012-06-21T11:56:46.493 回答