The implementation of the WorkflowServiceHost class apparently requires a single instance of the class to be created for each type of workflow being hosted. This also means that a separate workflow runtime will be created for each of these instances. This doesn’t seem to be very efficient since a single workflow runtime can handle multiple types of workflows. Multiple workflow runtimes seem like a waste of resources.
So I asked around about this.
Kenn Scribner, author of Microsoft Windows Workflow Foundation Step by Step, answers:
The short answer is you are correct, and a lot of people aren’t happy about this limitation. I’ve heard rumors this might be corrected in .NET 4.0, but just rumors.
An alternative is to write your own host class, if you’re of a mind to do so…
Paul Mehner adds his thoughts:
I was not aware that send/receive activities require a new runtime and I am thinking that this is likely just a configuration issue. I assure you that you do not want multiple hosts no matter what. That would be a ridiculous constraint if it proved to be true, and I plan to investigate this later tonight if my time permits (it likely won’t but I will try). In general, you should have only one workflow runtime for a single AppDomain, and that runtime can easily service many types of workflows.
BTW: I completely avoid using the send/receive activities. In point of fact, I have _never_ used them in a production application (only for training and demo purposes). These activities couple a workflow with a need to be used in a service host, thus preventing a workflow from being used independent of its hosting environment. I like a better separation of concerns than this model allows. I also like business developers to stay focused on their own business implementations without worrying about the network plumbing that services developers are concerned with (who likewise don’t want to be burdened with having to understand business rules and processes). I _always_ create my own service host, which itself hosts a singleton of the WF runtime. I can then run an infinite number of differing workflow types based on the service operations that are called. I can provide additional sample code if you would like… just ask. Here’s a starter though…
[ServiceBehavior(InstanceContextMode = InstanceContextMode.Single)]
[ErrorHandlingServiceBehavior(typeof(EpukServiceErrorHandler))]
public class EpukServiceBus : ServiceBase, IEpukServiceBus
{
public EpukServiceBus() : base()
{
Factory factory = new Factory();
....
}
And later adds:
The workflow runtime is designed to support multiple workflow types running simultaneously. That’s a fact you can bank on. If the ReceiveActivity violates that principle by introducing a need for multiple workflow runtimes for each workflow type, then that product manager REALLY screwed things up. I still haven’t had time to prove or disprove that assertion, and I will be traveling from the holidays back home today (and with pass conditions in the PNW — likely tomorrow as well), so it’s not likely this week.
Is the workflow we are talking about a sequential workflow or a state machine? It sounds to me like this is a state machine workflow, so I think I would probably just drive it off of the events that cause the state changes. I would expose the state change events through the abstraction of different operations on my operation contract, and I would pass the data into the workflow through the corresponding custom EventArgs. An external caller would call an operation on the service that would raise the appropriate state transition event on the workflow, and pass in the relevant data. I have used this pattern on several production systems with great success. Of course a single operation on the service contract could examine the data and then raise the appropriate event (if that makes the interface simpler for the caller, like the facade pattern described below).
I dislike the entire concept of the Receive/Send activities. I find that they too often violate my sense of separation of concerns. If they are really wired with the limitations that people are blogging about, then I find them to be much worse than that.
This forum post also confirms the limitation.
I agree that there should be a good separation of concerns in a production implementation (as Paul discusses above). For a project that I am working on, I ended up defining workflow events but created a service layer that fires the events. This separates communications issues from the actual hosting of the workflow.
Another idea, suggested in the forums post above, was to create a single workflow with a number of receive activities that route incoming requests to other workflows (using the Facade pattern). This is an interesting idea as well, but I have not tried it.
Second Stanza 