WorkflowServiceHost, multiple services and the WorkflowRuntime

Question

 

 

Hi,

 

I am hosting the workflow runtime in a windows form application to run a number of "standard" WF workflows. I now want to add a number of WorkflowServices. I intend to create a WorkflowServiceHost to host my services.

 

I noticed a post from Tom Lake that each WorkflowServiceHost can only host a single workflow service (http://forums.microsoft.com/MSDN/ShowPost.aspx?PostID=2233752&SiteID=1).

 

Also, I observe that it is posible to get a reference to the runtime being used by the service host by writing code like:

 

WorkflowRuntimeBehavior workflowRuntimeBehaviour = host.Description.Behaviors.Find<WorkflowRuntimeBehavior>();

WorkflowRuntime rt = workflowRuntimeBehaviour.WorkflowRuntime;

 

My question is - how many runtimes must I have? Can my standard workflows and each hosted service all share the same undelying runtime or do I need to spin up and configure a seperate runtime in each case?

 

Also, could anyone point me at a good code sample for programatically hosting multiple services.

 

Thanks

 

Adrian

 

Answer 1

Multiple services cannot share a runtime. Each service has its own workflow runtime.

 

You could create a service for a workflow by creating and opening a workflowservicehost for the workflow type. The workflowservicehost takes care of creating the workflowruntime internally.

Answer 2

 

At first glance this seems a bit of an odd design?

 

We don’t have a one workflow - one workflow runtime design paradigm in .NET 3.0. In a real world scenario where we plan to deploy many service workflows we would surely have an unmanageable number of runtimes.

 

Also, how would we make use of things like custom runtime services and host to workflow communication mechanisms like external data exchange services in such a scenario? Could we share runtime service instances, custom tracking channels etc between the multiple runtime instances?

 

Presumably the only viable inter workflow communication option in this architecture is via send and receive activities to other service enabled endpoints?

 

Or alternatively, is the workflow runtime sufficiently lightweight that in the brave new "service orientated" - one workflow service - one runtime is exactly the way to go - does anyone else have any views ?

 

Adrian

 

Answer 3

bump

Answer 4

We are at this point also, cannot seem to add another Workflow to the same runtime.  Did you make any progress on this?

Answer 5

None

 

It seems a fairly fundamental (and limiting) design decision if Dinesh is correct (I'd have to assume he is given his closeness to the team). I went back to using WCF/WF 3.0 allowing me to manage the runtime myself (but then requiring me to do more work!). I tried bumping the thread to see if I could get some more insight and comments but no one else responded.

 

Cheers

 

Adrian

 

Answer 6

Anything happen on this in the last 6 months? I'm playing around with custom Factories to see if there are some possibilities there but this is disturbing.

 

I had a few thoughts on how Microsoft intended for people to deal with this problem without having to manually write all the bridge code. It appears that the solution is to write a custom WorkflowServiceHost and WorkflowServiceHostFactory. By doing so you can control when/if a new WorkflowRuntime is created so you could have a single common runtime regardless of the # of workflows hosted.

 

Secondarily, to deal with the terrible annoyance of having a single method per .SVC you can put numerous "receive" activities into a single workflow to provide all the methods needed for a service and have that act like a router (Facade pattern). I haven't played around with that idea too much but anything seems better than this one-to-one business.

 

 

Answer 7

Matthew

 

I gave up and hosted it myself. The lack of replies on the thread suggests to me that not many people actually use this functionality in anger.

 

One observation from comments made at the PDC is that WF 4.0 is a rewrite from the ground up so perhaps we might hope that this will change next year?

 

Cheers

 

Adrian

 

Answer 8

 Can you provide some insight into how you solved this problem? I'm facing the same issue. I've tried the "router" concept but unless I'm doing something wrong, it messes up persistence (the workflow never gets closed). I fear that this plumbing code will involve rudimentary work with queues and context management. By hosting it yourself, did you simply bypass anything related to 3.5?

Thanks.
Dave