0
votes

I am working on a project in which I want to use a Windows Workflow 4 State Machine. The Visual Studio solution templates and most guidance seem to steer everything towards hosting as a service in IIS that is created dynamically from send and receive activities within the workflow.

However, I would prefer to not use the send and receive activities and then host in my own WCF service which would allow me to use a Windows Service instead of IIS and use other bindings like TCP instead of HTTP and create my own interface instead of exposing MEX. In addition, it would be portable to any other hosting arrangement like in a WPF app or a console or whatever.

This feels a lot more flexible to me. Somehow, having service operations as part of the workflow seems like pretty tight coupling of two things that aren't that related. Is there any downside to my approach? I'm new to WF so I might be missing something.

1
I don't think so there are drawbacks, you would just have to implement on your own some of the thinks workflow services provide out of the box.Enes

1 Answers

0
votes

Depending on the kind of workflows you are running you might need to write quite a bit of pluming code that workflow services provide for you.

Things to consider:

  • Are your workflows long lived?
  • Are you sending multiple messages to the same workflow?
  • Do your workflows need to survive a host restart?
  • Are you using Delay activities to respond to timeouts?
  • Do you need to be a able to retry action after error situations?

Lots of these things are automatically taken care of with a WF service and need your attention otherwise. It is certainly doable, I have done it in the past, but be aware of of what you are losing.