locked
Workflow Services & multiple workflow per service RRS feed

  • Question

  • Hi,

    In .Net 3.5 only one workflow per service is allowed which is just not manageable for large applications.
    I was wondering if it was still the case in .Net 40.

    Thanks.
    philippe
    • Moved by Amadeo Casas - MSFT Monday, November 30, 2009 4:52 PM More appropriate forum (From:.NET Framework 4: Windows Communication Foundation - Beta 2)
    Monday, September 28, 2009 10:58 AM

Answers

  • Hi Phillipe,

    I thinkwe're confusing terminology here.  In WCF, a single service definition can implement multiple service contracts, and each of those service contracts can have multiple operations.  Each WCF ServiceHost (e.g. a single .svc file) is restricted to one service definition. 

    Similarly, in WF 4.0, a workflow service can implement multiple service contracts, and each of those service contracts can have multiple operations.  This is accomplished by using multiple Receive and SendReply activities with different values specified for the ServiceContractName and OperationName properties.  Each WorkflowServiceHost is restricted to a single workflow definition (as Darren mentioned above).

    So if you had 25 services before, there's no reason why you couldn't have 25 workflow services.  With that said, it may not make sense to migrate some of those services to be workflows; it really depends on the type of services you've written.  If they are static, stateless web services that have no complex business logic (e.g. a web service fronting a database that just returns the results of a query), then it's probably ok to just leave it as is.  It also depends on the interaction between each of your operations on your web service, e.g. if you have one operation that creates an order, and one that updates an order, then it makes more sense to use a workflow to enforce that Update can't be called before Create.

    Hope that helps,

    -- Dave
    Tuesday, December 1, 2009 7:02 PM

All replies

  • Hi
    Workflow Services in .net 4.0 has overcome this limitation

    Regards
    Suds
    Monday, September 28, 2009 5:06 PM
  • Actually, even in 4.0 you can only host one workflow service per service host. You can create child workflows, which you can move your work off to, but only one of your workflows per host will be able to accept messages.

    What scenarios do you see as being more manageable if we did support having multiple workflows hosted in a single service host?

    Tuesday, November 24, 2009 11:03 PM
  • Hello,

    Thanks for the answer.
    Here is my scenario :
    My server app contains 300 operations spreaded between 25 services.
    If I had to migrate all 300 operations to workflow service I would endup with 300 .svc files.
    And also I would have an average of 12 xamlx files per project and not speaking about the client who will need to create 300 proxy files.
    Personnaly I think it is lot of files.
    That's my first impression but tell me if I'm wrong.
    philippe
    Wednesday, November 25, 2009 6:31 AM
  • Hi Phillipe,

    I thinkwe're confusing terminology here.  In WCF, a single service definition can implement multiple service contracts, and each of those service contracts can have multiple operations.  Each WCF ServiceHost (e.g. a single .svc file) is restricted to one service definition. 

    Similarly, in WF 4.0, a workflow service can implement multiple service contracts, and each of those service contracts can have multiple operations.  This is accomplished by using multiple Receive and SendReply activities with different values specified for the ServiceContractName and OperationName properties.  Each WorkflowServiceHost is restricted to a single workflow definition (as Darren mentioned above).

    So if you had 25 services before, there's no reason why you couldn't have 25 workflow services.  With that said, it may not make sense to migrate some of those services to be workflows; it really depends on the type of services you've written.  If they are static, stateless web services that have no complex business logic (e.g. a web service fronting a database that just returns the results of a query), then it's probably ok to just leave it as is.  It also depends on the interaction between each of your operations on your web service, e.g. if you have one operation that creates an order, and one that updates an order, then it makes more sense to use a workflow to enforce that Update can't be called before Create.

    Hope that helps,

    -- Dave
    Tuesday, December 1, 2009 7:02 PM