locked
WCF Workflow Service Design Considerations RRS feed

  • Question

  • Hello All,

    I am in the process of finalizing the design of my long running workflow service. Hope you guys can provide me inputs.

    The workflow service needs to be consumed by various clients. Consider the Risk Management process, it goes through various states with different transitions like ApplicationReceived, ModifyApplication, RejectApplication, ApproveApplication, CancelApplication, Complete and so on………

    The client will have various screens like a wizard. And few states will change based on the data client supplies, for instance it is important to do counterparty credit check before giving them a loan.

    Once successful then credit check state will be changed. Important point to note is there is a human interaction with few of the states.

    How should I expose this WCF Workflow Service, having a single endpoint (initial endpoint say SubmitApplication) – If so, how will I manage other human interactive states???

    Or should I have multiple operationcontract like traditional WCF service, say SubmitApplication, CancelApplication, ApproveApplication……which does not makes sense at this point.

    Let me know your thoughts.

    Regards,

    x

    Wednesday, June 13, 2012 9:45 AM

Answers

  • That's what I do.  I usually have a "front end" web service, plain old WCF, that takes in messages and logs them, then manipulates them and sends them to a backend workflow for some operations.  Other operations may just query status or do non-WF operations.

    I usually use MSMQ to talk from front end to back end, so my front end WCF service just "fires and forgets" to the MSMQ queue of the WF service and returns to the caller.

    • Marked as answer by RahulSisodia Friday, June 15, 2012 8:10 AM
    Thursday, June 14, 2012 6:27 PM

All replies

  • If you can target .NET 4.5 I'd recommend contract-first.  Think more about your business process as a service and how other services or the UI will need to interact with it.

    Then you can implement that interface as a WF service (plain old WCF if needed later).

    For WF service, you'll have one endpoint, that endpoint will expose multiple service operations.

    Beyond the initiating "Submit" operation, how you structure your other calls is up to you.  You could have separate methods like Approve/Cancel/.. or you could have one method called ApplicationEvent which has an enum or other structure to handle all the possible events you'll want.  If all your various types of operations take a similar type of data, a single ApplicationEvent might be nice, whereas if they are all complex/different then you'll probably want separate service operations.

    Wednesday, June 13, 2012 5:33 PM
  • Hi jvrobert, thanks for your reply.

    I am thinking of following design.

     

    Have a old-code based service which will expose multiple operations contract like SubmitApplicaion, Modify, CreditCheck, CancelApplication and all....

     

    Then consume a WCF WF service which will handle almost same data and manage diff states..this way I am protecting my WF from consumers and I have separation in business services to do other tasks such as validation and all...Have a single operation contract in WF service say SubmitData and based on the data change the state, if not return message...

     

    How does this sound to you?

    Thursday, June 14, 2012 2:38 PM
  • That's what I do.  I usually have a "front end" web service, plain old WCF, that takes in messages and logs them, then manipulates them and sends them to a backend workflow for some operations.  Other operations may just query status or do non-WF operations.

    I usually use MSMQ to talk from front end to back end, so my front end WCF service just "fires and forgets" to the MSMQ queue of the WF service and returns to the caller.

    • Marked as answer by RahulSisodia Friday, June 15, 2012 8:10 AM
    Thursday, June 14, 2012 6:27 PM