"Grizzly" is exactly why we need YAWF
Jeff Brand posts a groan about the possibility of Yet Another Workflow Framework (YAWF). And he wonders if anybody remembers “Grizzly,” the code name for a workflow system that used SQL Server 7.0 as the back end.
Yeah, I remember trying to use it... once. And that's exactly why we need something better. Sure, you can develop workflow applications based purely on Exchange. You could also assemble your own car from parts. Two words: Rubber Cement. I really don't see BizTalk as being a good fit here either -- its much more of a process integration controller than a workflow framework.
Of course, you could design and build a workflow system based on SQL Server 2005 Service Broker. That'd be complex but not hard depending a couple of factors: if you need dynamic routing and how many variable paths there are in the processing flow. A “starter kit” would help make this more accessible.
A good workflow system really needs five things that are difficult to achieve with what we have today.
- It must be easy to design, test, deploy and maintain -- preferably with a GUI.
- Delivery must be guaranteed and tracked.
- Must support phased attachments -- ones that can be added at any point and can be versioned.
- End-to-end Status Reporting has to be there.
- It must feature dynamic routing based on simple rule processing (of course, scripting or calling an assembly would be nice)
Most of these things exist someplace in the Microsoft portfolio: use Whitehorse for design, test and deploy; Service Broker for the transport; SharePoint for attachments and Reporting Services for the reporting. Dynamic Service Applications for Service Broker would certainly be interesting to see.