Watch Scott's interview on Windows Workflow Foundation (23:32)
On the topic of emerging architectural patterns for using Windows Workflow, Scott predicts:
I think Windows Workflow is going to be the execution engine. There's certainly the ability to write a lot of code inside of a Workflow, to actually put implementation code inside of a Workflow. I don't think that is going to be the most flexible approach, it's not going to be the best architecture. Workflow has the ability to communicate back to the host process and receive events from the host process during the lifetime of a Workflow through well defined interfaces. You literally define an interface that has public methods and the public events and you tell the Workflow "this is what you're going to be working with". Let's say I'm building a Workflow to download the log files from a web server. I can certainly create activities that do the ftp transfer, the parsing of the log files that do the insertion into the database. But ultimately I think you want to keep those jobs into separate components. The Workflow is really just the shell that says "here's the process we follow, here are the rules". It calls back to the host process which does a lot of the work.Have any InfoQ readers had a chance to use Windows Workflow yet, if so, what were your experiences?