Comments on: Thoughts about workflow foundation http://www.udidahan.com/2007/01/05/thoughts-about-workflow-foundation/ Enterprise Development Expert & SOA Specialist Wed, 08 Sep 2010 18:14:32 -0500 http://wordpress.org/?v=2.8.4 hourly 1 By: WillSmith http://www.udidahan.com/2007/01/05/thoughts-about-workflow-foundation/comment-page-1/#comment-357 WillSmith Mon, 08 Jan 2007 18:23:05 +0000 http://udidahan.weblogs.us/archives/362#comment-357 The posts I have put to the WF team have to do with State Machine work flows. State Machines are a great tool for doing business rules and user interface states. However WF support is too weak in this area so we won't be able to use it unfortunately. The posts I have put to the WF team have to do with State Machine work flows. State Machines are a great tool for doing business rules and user interface states. However WF support is too weak in this area so we won’t be able to use it unfortunately.

]]> By: Mark Johnson http://www.udidahan.com/2007/01/05/thoughts-about-workflow-foundation/comment-page-1/#comment-356 Mark Johnson Sun, 07 Jan 2007 23:52:37 +0000 http://udidahan.weblogs.us/archives/362#comment-356 I am currently evaluating WF for a revision to our existing product. The current system has various "work flows" that are implemented in business objects and uses a DB for persistence. The work flows are defined using XML definition files. The problems with the current work flows is that they are complicated and difficult to modify without having side effects. After researching WF for 2 weeks now, I was feeling like WF would give us flexibility, agility, confidence to change, loose coupling and better process visibility. But I must admit that your less than positive opinion of WF is making me rethink my position. There are definitely skeptics about WF in our team. I too agree that the communications supported by WF (local services and web services) is rather limiting. It would've been nice to also include WCF and MSMQ as communication options (especially for proper loosely coupled eventing). So your major problems are that WF is too general, implements its own threading and own activation model. Why is a general (as opposed to a product i.e. BizTalk) work flow foundation bad? Why is it a problem that WF handles its own threading? What is your concern with WF's activation model (it is fairly easily overridable)? I am currently evaluating WF for a revision to our existing product. The current system has various “work flows” that are implemented in business objects and uses a DB for persistence. The work flows are defined using XML definition files. The problems with the current work flows is that they are complicated and difficult to modify without having side effects.

After researching WF for 2 weeks now, I was feeling like WF would give us flexibility, agility, confidence to change, loose coupling and better process visibility. But I must admit that your less than positive opinion of WF is making me rethink my position. There are definitely skeptics about WF in our team.

I too agree that the communications supported by WF (local services and web services) is rather limiting. It would’ve been nice to also include WCF and MSMQ as communication options (especially for proper loosely coupled eventing).

So your major problems are that WF is too general, implements its own threading and own activation model. Why is a general (as opposed to a product i.e. BizTalk) work flow foundation bad? Why is it a problem that WF handles its own threading? What is your concern with WF’s activation model (it is fairly easily overridable)?

]]>