Yesterday, I completed my training on Windows Workflow foundation.
In my opinion, it yet a new tech and provides you with a set of good features.
However, a question that was racing my mind all the time was, why the hell do you need workflows, I mean almost all programs that we write have activities and business logic within them, so what the big use of using a framework to model workflows.
These were some of the pointers the trainer think of if you need to go for workflows.
1) Activities can be clearly identified with boundaries
2) Whether to use state machine workflows can be determined if the logic is push based and not pull based
3) When rules need to be customized externally without rebuilding the system.
4) You have huge number of human interaction (to determine if you need to use state machines)
5) Long running process that can be done asynchronously without user intervention
On the other hand, MS Workflow foundation has its own advantages.
1) A cool designer support.
2) Custom activities can be created that is compiled but you can have your work flow in an external XML file, so it s configurable. The workflows loaded into the runtime by de-serelizing the XML and passing the XML reader into the CreateWorkFlow method of the runtime.
3) Workflows can be started and stopped at will, and the program state can be persisted (the property values and all), there is a default persistence service you can use with SQL server.
4) Transaction handling is cool, putting up a transaction scope would revert back the whole set of state of the workflows (even reseting member variables that we changed in the process).
5) For the stuff that the workflow cannot revert back in a transaction rollback, you can write your compensation transaction.
6) Fault handling can be done for each activity of the work flow.
7) You can host the runtime in a asmx webservice or a wcf sebservice, how you do this is also becomes simple.
We'll these are some of this stuff I remember and by the way state machine gets deprecated in .net 4.0
In my opinion, it yet a new tech and provides you with a set of good features.
However, a question that was racing my mind all the time was, why the hell do you need workflows, I mean almost all programs that we write have activities and business logic within them, so what the big use of using a framework to model workflows.
These were some of the pointers the trainer think of if you need to go for workflows.
1) Activities can be clearly identified with boundaries
2) Whether to use state machine workflows can be determined if the logic is push based and not pull based
3) When rules need to be customized externally without rebuilding the system.
4) You have huge number of human interaction (to determine if you need to use state machines)
5) Long running process that can be done asynchronously without user intervention
On the other hand, MS Workflow foundation has its own advantages.
1) A cool designer support.
2) Custom activities can be created that is compiled but you can have your work flow in an external XML file, so it s configurable. The workflows loaded into the runtime by de-serelizing the XML and passing the XML reader into the CreateWorkFlow method of the runtime.
3) Workflows can be started and stopped at will, and the program state can be persisted (the property values and all), there is a default persistence service you can use with SQL server.
4) Transaction handling is cool, putting up a transaction scope would revert back the whole set of state of the workflows (even reseting member variables that we changed in the process).
5) For the stuff that the workflow cannot revert back in a transaction rollback, you can write your compensation transaction.
6) Fault handling can be done for each activity of the work flow.
7) You can host the runtime in a asmx webservice or a wcf sebservice, how you do this is also becomes simple.
We'll these are some of this stuff I remember and by the way state machine gets deprecated in .net 4.0
Comments
Post a Comment