Initial Impressions of Windows Workflow Foundation

In my last post, I mentioned I was reading Pro WF Windows Workflow in .NET 3.5 by Bruce Bukovics. I also used the words Whoop-Tee-Doo.

Well, I'm now 335 pages into the book, and into the concept of state machines, and this morning I finally had an 'Aha!' moment. See I've been trying to solve a problem at work, and knew that Workflows would probably help me, but the Sequential Workflows weren't blowing my mind. They just seemed like a lot of overhead to implement something that I could do inmany other ways.

However, the State Machine Workflows are definitely something I can see real possibilities for. I'm going to mock up my problem as a state workflow today, and see if I can get it to work.

I have two concerns:
1. Will I be able to call a .NET 3.5 Workflow DLL from a .NET 2.0 Application. I think so, as long as the .NET 3.5 Framework is installed on the clients (which it is)
2. Should I, as the architect, introduce another new technology into an application which is already difficult to support, even if it makes the problem I am trying to solve easier to solve. I am conciously trying to not alter the core of the application because of the size of it and the cost of fixing stuff that isn't broken, but the framework of the application is really limiting what we can do, and I think I can just peel out some pieces and make the application better. I also don't want to be the only one able to support it going forward, and if the rest of the team doesn't take their education in the new technologies as seriously as I do, I could be painting myself into a corner.