WorkflowServiceHost, multiple services and the WorkflowRuntime RRS feed

  • Question





    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.






    Wednesday, February 20, 2008 1:52 PM

All replies

  • 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.

    Friday, February 22, 2008 7:10 AM

    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 ?




    Friday, February 22, 2008 9:19 AM
  • bump

    Wednesday, March 5, 2008 10:23 AM
  • We are at this point also, cannot seem to add another Workflow to the same runtime.  Did you make any progress on this?

    Thursday, April 3, 2008 1:59 AM
  • 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.






    Friday, April 4, 2008 8:41 AM
  • 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.



    Friday, November 21, 2008 6:30 AM
  • 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?






    Friday, November 21, 2008 10:40 AM
  •  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?

    Tuesday, January 6, 2009 5:50 PM
  • Now that wf 4.0 has been released. What's the solution?

    I'm lost in the workflow of workflowservicehost, workflowapplications, etc.

    Please advise.

    Monday, February 22, 2010 10:48 AM
  • ^ Bump

    I found this: http://kraman-wa.spaces.live.com/blog/cns!50BB0FE5BBCCAF4B!119.entry?sa=628052730 which suggests that Dinesh is right. I guess the question is (and I have come at this from the same angle I think, which is why it feels a little dirty): is there actually anything wrong with hosting a single WorkflowRuntime with each WorkflowServiceHost?
    • Edited by Tr1stan Monday, October 11, 2010 9:01 AM more details
    Monday, October 11, 2010 8:51 AM
  • Sot the link is no longer active from the above post.

    I've been trying to figure out how to accomplish this same in WF4, hopefully with AppFabric to have a hosted runtime that can dynamically have xslt definitions loaded on demand. Some will have interfaces to WCF end points, others may not. Basically i want a runtime engine as in 3.0/3.5 but have AppFabric be the "service" instead of me writing it. However as far as I can tell it's sole purpose in life is to run static workflows tied to specific WCF endpoints and nothing more.


    Monday, April 11, 2011 8:54 PM