3

Before asking a question, and before you all get mad because there are a couple of similar questions, I would like to explain a bit what are project requirements. You will see that question differs from all others.

  • Users will create workflows using ReHosted WPF application and upload xaml files to web application we will provide.
  • Entry points to start workflow execution is in that web application. They can use UI or consume API function from their own application.
  • Workflows will be long-running.

I'm aware of different possibilities for hosting.

Simplest would be to host it within ASP.NET web application, but as we are not aware what kind of workflows users will upload, IIS AppDomain recycling could break workflow thread execution.

WCF Workflow Services look nice, but the fact users will upload their own xaml workflow definitions makes things more complicated. Looks like we would have to create something like core workflow, exposed as WCF service, and that workflow will load and execute inner workflow (xaml customers uploaded). Not sure how in parameters would be passed to inner workflow in that case.

Third option, and the one looking best to me, is hosting workflow execution in Windows Service. Communication between web application and window service can go over MSMQ. Downside of this solutions is maybe boylerplate code to ensure good communication between web app and win service.

Am I missing better solution? In case you need more details, just post a comment.

Misha N.
  • 3,455
  • 1
  • 28
  • 36

1 Answers1

3

I have similar requirement and have dome long discussion With "The problem solver".

which one is better architecture for the WF4.0?

Now my conclusion is to develop Workflow as a workflow services hosted on IIS.

You can follow these two approaches.

  1. Divide workflow requirement into smaller activities they can be an independent XAML activities and to create workflow drag drop those on Workflow Service (xamlx). Relate these on InArgument and outargument and correlation context where ever required.
  2. Create and store workflow in db and load them dynamically. Excellent link-- http://blogs.msdn.com/b/appfabric/archive/2011/06/16/how-to-load-wf4-workflow-services-from-a-database-with-iis-appfabric.aspx
Community
  • 1
  • 1
Vivek
  • 570
  • 8
  • 21
  • Hello Vivek, thanks for your answer. This is indeed interesting solution that I might be able to use. My requirements are that end users will be IT persons, but not programmers. They will just create workflow using some basic and custom activities, upload it and then they should be able to open form that will list all InParameters needed to run workflow. They don't know how to consume WCF service and therefore exposing WCF service is not an option. – Misha N. Jun 21 '12 at 13:21
  • Did you mean I could still present on UI simple form for starting workflow, but behind my own code will consume exposed xamlx service? If yes, my end customers will not define Recieve activies in their workflow definitions, how could I then expose them as wcf services? – Misha N. Jun 21 '12 at 13:21
  • Hi Misha, These are the way you can precede. Create a custom activity with receive activity, configure all endpoint and contract related information so that it can be drag and drop. End user only needs not to do endpoint configuration. This is the first activity of your workflow service. Internal details are hidden from them. Suppose end user need to use an activity that is calculating interest, workflow developer responsibility to develop and test this activity. End user drag drop this activity and Input parameters are need to be filled. – Vivek Jun 22 '12 at 06:02
  • Ok, I see it now. Basically, all end user needs to know is that his workflow needs to start with that custom activity. Sounds ok to me, we'll see what my business owner will say :). Thanks Vivek. – Misha N. Jun 22 '12 at 09:19