Windows Workflow Foundation本地托管和Web Api

Question

I want to use Windows Workflow Foundation 4.5 and trigger the workflows via web api. What are my hosting options now that MS is ending AppFabric support? Should I even use Windows Workflow Foundation or should I look into a 3rd party solution?

This is on-premise and I don't have the ability to use azure. I've done a few workflows and seems like WWF isn't hard to use but it's not clear how to host it. Can I host inside a web api project without AppFabric?

My main concern is being able to resume workflows if IIS app pools recycle using WorkflowApplication or the server crashes. I'm not using WCF I plan to use WorkflowApplication inside the web api.

Can anyone point me in the right direction on implementing the custom features that AppFabric was responsible for? Resuming, Logging, etc..

From MS: Using IIS with AppFabric is the preferred host for workflows. The host application for workflows using AppFabric is Windows Activation Service, which removes the dependency on HTTP over IIS alone

IIS 7.0 recycles application pools periodically for various reasons. When an application pool is recycled, IIS stops accepting messages to the old pool, and instantiates a new application pool to accept new requests. If a workflow continues working after sending a response, IIS 7.0 will not be aware of the work being done, and may recycle the hosting application pool. If this happens, the workflow will abort, and tracking services will record a 1004 - WorkflowInstanceAborted message with an empty Reason field.

If persistence is used, the host must explicitly restart aborted instances from the last persistence point.

If AppFabric is used, the workflow management service will eventually resume the workflow from the last successful persistence point if persistence is used. If no persistence is used, and the workflow performs operations outside a Request/Response pattern, data will be lost when the workflow aborts.

Answer 1

One hosting strategy is to have your Web API methods simply put messages into a queue (like MSMQ or Rabbit MQ), and have a back-end Windows Service for actually hosting the workflow instances. The back-end service would continuously read the queue(s) and spin up the correct workflow you need.

This way you don't run into IIS application pool recycling events that could terminate a workflow.

If you need to have a Web API method wait for the workflow to finish, you could have it wait for a "correlation message" to arrive on the queue to signal that the operation finished. Or you could store the WF instance result in a DB table.

I actually recommend not using App Fabric and simply rolling your own hosting service for better flexibility. Plus its relatively simple to implement one with your desired behaviors.

Here's a diagram I hope that will help out in your design or give ideas: