Whatcha gonna do when the WWF runs wild on you, brother!?

The Windows Workflow Foundation is a key component of WinFX, essentially the new API for Microsoft's Operating Systems of the future. The beauty of WinFX is that you can run it on Windows Server 2003 and Windows XP Professional Service Pack 2, so we get access to the sweet, chewy goodness that is WPF (Windows Presentation Foundation, formerly "Avalon") and WCF (Windows Communication Foundation, formerly "Indigo").

Workflow is a lot like coffee. If you've never had it before, you've probably heard people laud its eye-opening abilities and smooth, creamy rich taste ( ... must...resist...Starbucks...), but you really don't know what its like for yourself - and you really have no idea why people drink it. Workflow is in the same boat - unless you've actually worked on an application that had a discernable workflow in it, or you've encountered situations where a Workflow was necessary - you might not actually see the need for Workflow, and might dismiss the WWF as ancillary technology. I'm guilty of the same thing - I dove right into WPF and WCF, especially WPF because you can immediately see the benefits of being able to integrate 3D and high-end 2D graphics directly into an application in a declarative manner.

Workflow is really just a defined set of business rules and logic. While some Workflow has traditionally been coded in specific programming languages, the idea behind WWF is that you can visually design a workflow that accurately represents the Workflow of your application (or suite of applications) and have that workflow be usable from within ASP.NET, from within Windows Forms, from within a WPF application, from a Windows Service, or even from a Web Service.

As with all new technologies, I start off with a simple question: Why in the heck would I want to use this new technology?? I need justification. So, with WWF, I set out looking for a concrete reason why I needed it. I got lots of pointers in the direction of Document Management and Document Workflow, but SharePoint 2007 has WWF embedded within it, and if you're looking for a document workflow solution, the buck stops with SP 2007 - no need for me to re-invent the wheel there.

I stumbled on something interesting. If I start out modelling a human-interaction workflow as a state machine, I ended up with a list of processes that could really benefit from automation, tracking, and control. So, for the next several posts, my sample is going to be that of a Restaurant. In a restaurant, a party arrives and asks to be seated. They either have a reservation or they don't. If they have a reservation they are seated immediately. If they don't have a reservation, they go into a 'wait' state and have a seat at the bar and get good and sauced waiting for the next available table. Once seated, the party can then transition through multiple additional states, such as eating appetizers, eating their main meal, eating dessert, paying the bill, and of course, leaving the restaurant.

This particular workflow is an ideal candidate for a State Machine Workflow. State Machines are essentially a list of states accompanied by rules that dictate how a workflow can get from one state to any of the other potential states. For example, while seated, the customer can transition from 'seated', to 'eating appetizers', 'eating meal', and 'eating dessert' directly depending on what their preference is. Some people might show up and just want coffee and cheesecake. (Ok, all this blogging about food is making me hungry... I'll save this as a draft, grab a bite, and come back in a few minutes...)

The following is a screenshot of this workflow from within the Visual Studio 2005 designer:

As a testament to the fact that Workflows really do model real-life situations and you don't need to be a programmer to model a human Workflow - the above Workflow was originally drawn on a piece of paper by my wife. All I had to do was drag and drop states onto the designer to match her drawing. While this might seem insignificant, the fact that someone with no programming ability whatsoever can supply me with a workflow that I can then turn into a functioning application is huge, and should not be underestimated.

I'll get to the code that drives this sample in the next post. For now, I want to focus on the business needs that WWF satisfies, and why this is definitely one of those technologies that qualifies as 'better than sliced bread' :)

Workflows are often long-running processes that often react to human stimulus. Someone pushes a button, someone records an important event, a timeout expires, input comes in from a remote location, etc. In order for Workflows to be maintained without requiring the host process to maintain all of those workflows in memory for an inordinate amount of time, there is a persistence service. You can store the state of active workflows in a persistence medium such as XML files or SQL Server using the SqlWorkflowPersistenceService. Using this persistence service, your application can retrieve persisted, active workflows from a database when it starts up, allowing both the client process and server process to shut down and start up independently without burdening either machine.

In the restaurant workflow specifically, there is information that would be of particular use to the restaurant owner and/or manager. For example, you might want to know the average wait time between when a party arrives and when they're seated, or how long it took a single party to receive their meal, etc. That kind of data is known as Tracking data, and important events within the lifetime of a workflow can be stored and persisted in a medium such as SQL Server using the SqlTrackingService. This service records the date and time of significant events as well as detailed information about the event itself. Using this service, the restaurant owner could retrieve timestamp information on when a party was seated, when the workflow transitioned to the 'Paying Bill' state, and much more. You can even log custom events such as when a party received refreshed drinks. Think about it: if your waiters are enabled with PocketPC devices and wi-fi : all of this information could 'magically' show up as part of the workflow without anyone having to go out of their way to record these events.

THIS is why WWF is so important. Out of the box, you get some ridiculously powerful functionality that would otherwise take a team of developers months to create, and WWF is part of WinFX, and can be utilized by ASP.NET, WinForms, WPF, Web Services, Console Applications, Windows Services, or anything else you can think of - even code on PocketPCs consuming a Web Service over a WiFi connection.

Think of the possibilities. Someone is using a SmartPhone (a cell phone running the Compact Framework) and they do whatever it is they want to do, and that action triggers an event that moves a centrally hosted workflow along. Someone else using SharePoint can then move that workflow even further. Someone using a Windows Forms application can then move that workflow even further. All of these events could take place days apart, and the system just handles it, and at any time you can inspect the state of the workflow, as well as query when every single event of importance took place on that workflow, whether it was yesterday or 3 months ago. All that for free.

The next post will show you the code that makes the Workflow I've demonstrated here run and persist using persistence and tracking.

tags: vista  dotnet  winfx  programming  workflow  csharp  wwf  

links: digg this    del.icio.us    technorati    reddit