We are here today with Matt Winkler from the Workflow Foundation Team, tell us about yourself.

I'm Matt Winkler, I'm the technical evangelist for the Windows Workflow Foundation team, historically I got out of college and started with a small consulting firm, and there I was doing at the time ASP development, but that time was the first public data of .NET so I jumped right into that. Coming out of school I focused on all the things one does in computer science programs, C++, smattering of everything else, and moved right into the Microsoft platform at that point in time, got onto the .NET wagon pretty early on, and haven't looked back since. I was a consultant for about 4 years then I moved to a small ISV that focused on enterprise content management where I was the technical product manager for their workflow product, and about that time Microsoft was starting some buzz around Windows Workflow Foundation, there was a job posting for an evangelist for that, I applied and here I am.

The Workflow Foundation Team: why was the product created, was it broken out of Biztalk?

There's 2 parts of your question: one is why did we create it? And the reason we did that is we looked around and even within our own products there were a lot of places where we were doing workflow, Biztalk as you mention has some workflow components in it, Exchange has workflow components, we were getting ready to do the next version of Office, Office 2007, we wanted to put workflow into that, and up until now the efforts really spanned, each team would build up the pieces that they needed to support their scenario, and we started looking at that as a problem, and how could we fix that problem? And pretty early on we realized that there were also pretty powerful tool to put in the platforms, to take workflow programming and move it into the mainstream development experience. That was the starting point and later on got associated also with Windows Communication Foundation, and Windows Presentation Foundation and what's known now as the .NET 3.0.

Can you give me an overview of WF?

A little bit of hand waving here on my part but, fundamentally a workflow is an arrangement of work. And the way we express that is through activities, which are really fundamentally units of work, that's the building block for workflows. The first thing that Windows Workflow Foundation provides is a framework for building those activities. Out of the box a number shipped with Windows Workflow Foundation but a very important part is building activities. There is an activity model, there is a lifecycle model, of those activities and there are various extensibility points as well, you can influence the design behavior, the runtime behavior, it's really the whole gamut of designing and creating activities.

We take those activities and we arrange them into workflows, and there's a couple of different models that you can use for that, one is the sequential workflow, which is really the typical flow chart: "I'm going to do A then B, make some decision on C or D, and then execute E, and that's going to be my workflow". That's one model. There is also the model of state machines, which is where we define any number of states, that are processed, then we define the events that we're listening for, to why we are in one of those states, if there's any action that we want to perform when that event is received, and then what state should transition to. The canonical example that's available is really a shopping cart, an e-commerce application. Those are the 2 fundamental ways you can create workflows that are supported out of the box.

One of the mentors of Windows Workflow Foundation as extensibility, so all those models are composite activities that are designed to contained trial activities and control their execution. If you have a completely different way that you would like to execute workflows, you can create your own composite activity that's going to be responsible for executing those. Now if we just had that it would be pretty boring, but what we want to do is also have a runtime, that handles workflows too in order to execute. That runtime lives inside any .NET process. Because of that it has to be flexible about how it goes about doing that, because this is the same thing we are going to do in a console app that we are going to do in SharePoint, so we have to make it extensible. The way to do that is through a series of runtime services which provide things like persistence for long running processes or tracking, so that we can extract relevant information from our process.

That's the way workflows work, we have got activities in the workflows that execute at runtime that use a series of runtime services in order to provide extensibility. Final component to that is a Visual Designer, which allows for the graphical composition of those workflows, this is what your designer works with inside Visual Studio; additionally the designer is re-hostable inside any Windows form application, so if you want to have workflow design capabilities in Windows forms applications, outside Visual Studio, you can do that.

What do you see as trends in workflow today?

First I think it is important to point out that workflow is an overloaded term it means a lot of different things to a lot of different people. Even within a development community it means a number of different things, anywhere from the rudimentary logic that you put into your program, all the way up to a full featured business process management or a BPM solution, everything in the middle. The problem that we are trying to solve with Windows Workflow Foundation is to provide an engine upon which to build workflow enabled applications. That are not a lot of trends around that level, we are targeting down at the framework level, targeting developers to bring to the development tool kit a workflow engine. Up in the BPM space there's all sorts of trends, in the EAI space, ESB, all these are different technologies, buzz words, that involve workflow. We are sitting below that and looking up to all those scenarios.

What's the sweet spot for Windows Workflow?

The sweet spot is anywhere you want to embed process into your application. The way its been designed is that it relies on a runtime that is very lightweight. It's a flexible runtime, it can do a lot of different things, but the core runtime itself is very lightweight.

When you are talking about lightweight, give me an idea about what you are talking about.

In terms of performance overhead, by lightweight we mean as follows: Windows Workflow Foundation, the runtime itself does not require its own server, it's not a server product or a service that runs inside your system, and it will live inside any .NET application domain. The default experience is that the workflow runtime spins out inside of a consol application, and that is the starting point where you can start using Windows Workflow Foundation, you can use it in a console application. Because the runtime has such low overhead we can host it inside Microsoft Office SharePoint Server 2007, it's the same runtime that provides the workflow engine capabilities, the workflow capabilities for SharePoint.

Can you provide some examples of embedding Workflow Foundation?

One pretty common scenario is people want to use Windows Workflow Foundation to compose services. They have a number of web services that they want to call, and they want to arrange those, they want to execute 2 or 3 in parallel and wait for those to finish executing before they have to move on in the process, make some decision about the result and then call some more. Windows Workflow Foundation provides a really nice way to declaratively decide what that process looks like. Your application that can be a Windows form application gets removed from that process logic, it knows it needs to start a workflow, it knows it needs to start a process but whether I call service A first or B that's pretty irrelevant to the Windows forms application. That's a scenario where you can use Windows Workflow Foundation, on the client side inside of an application.

Another sweet spot?

Yes, and one of the real benefits of Windows Workflow Foundation is that it enables long running processes, but that doesn't mean that you have to use it for long running processes, you can use it without any persistent service, it will be the lifetime of one simple process.

What would be a typical scenario for using Windows Workflow Foundation?

On the server side again you split things up in 2 categories: one would be short lived processes, and a common scenario there would be to drive some process that sits behind ASP.NET application that we can host inside the runtime and if you think about the canonical example of a state machine workflow for instance, it's a shopping cart. The user is shopping and then they are in the first stage of check-out, they move to the second phase of check out, then they go back to shopping, they want to go back to the check out process, so the managing state there is an example of what would be fairly short lived. You can also use it for long running processes, such as expense reporting so if you want to manage what happened, you are going to gather an expense report from somewhere, a website for example, ASP.NET web application, it's going to package that up, call a web service, that starts up your workflow and that's going to manage everything that has to do with that expense reports.

Maybe it does some initial rules validation on how much it is spent on an individual category, and does that meet the guidelines for his pay grade for instance, and then based on that result you may choose to route the expense approval accordingly. When my manager gets it he may say "I'm out of town all week. I want this delegated to my manager". And all that process can be described by a fundamental set of activities, and the process is in how those activities are arranged, that's what fundamentally a workflow is, an arrangement of work.

What questions should an Architect ask themselves when deciding to use Workflow Foundation?

Anywhere that you have process you can use Workflow Foundation and anywhere you have some business logic where you are composing that logic out of smaller more discreet chunks of functionality. You don't want to go overboard with that down to the level of: "I want to do all my string manipulation with workflow", I wouldn't suggest anyone go down that path. The fundamental building block of a workflow is an activity, which is just a unit of work, and as long as you can divide things up into those units of work, and then you need to arrange that workflow provides the perfect means to do that.

Why should non .NET developers care about Workflow Foundation?

Going back to what I said about the fundamental building blocks of these activities that allows us the capability to define our process agnostic the implementation of those activities. Let's go back to the expense reporting scenario: we have our big enterprise system that actually is what processes the payments out to me, when my expense report finally gets approved. Maybe that has a legacy interfaced maybe it has a really nice web service interface. As long as I can attach to that interface somehow and wrap that up into an activity, now all I have to do is hand my developers that activity and what happens there is completely transparent to the developer. They just drop the activity into their workflow and the workflow is going to execute in a .NET process, but the functionality that those activities encapsulate can be anything and as long as you get to it from .NET code somehow, then it provides a really nice way to orchestrate across multiple platforms. Windows Communication Foundation provides a nice mechanism for that, especially if you are listening on WF Star protocol.

Please provide an overview of tools available for Developers around Workflow Foundation.

There are 2 components to developing with Windows Workflow Foundation. The first is having the runtime for the .NET 3.0 available on the machine, that's going to be available on the machine with Vista and then down level for XP Server 2003, you'll be able to go to MSDN and download that. That will give you the runtime, just by getting the .NET framework. That means that applications that depend on it can leverage it. If you want to develop with that there's also the Visual Studio extensions for Windows Workflow Foundation which is a set of project templates and things that plug in Windows Workflow Foundation and Visual Studio so when you start up Visual Studio you can say "create new workflow project". With those 2 things you are off to the races.

How does one provide feedback to Microsoft on Workflow Foundation?

For feedback we have a connect site, http://connect.microsoft.com, which is where users can go and they can say "I'm seeing this behavior, I don't think this is right", they can also say "I would really like to see feature X". Those come into Microsoft and get reviewed by the product team. The other part of the question is where can people go if they have questions? The MSDN forms are very active, there's a lot of activity on those and questions are getting answered pretty quickly by both folks from the product team as well as members of the community.

As an architect, how would I define work units for a Workflow Foundation developer?

You've got flexibility to handle either one of those scenarios. There's not any hard restriction that only one developer can work on the workflow aspect of a project. Usually what we've seen with workflow projects is there is at least 2 different sections inside them: one is building out as activities, and then there is arranging those activities into the workflows, and then what is the execution pattern that we want for those activities. There is a very natural process even within activity development it's very conceivable you can hand off specs, "I'd like an activity that talks to our expense reporting system. I'd like an activity that talks to our financial reporting system, go take care of that". And developers can go and develop the 2 activities separately and then you can use those inside of a workflow. There's another component that people can use as well. There's a rules engine inside of that, a third task to creating activities, creating workflows would be creating the rules. If you think of processes such as insurance risk scoring, usually there are some very complicated rules around that. So you can also have a developer focused on building out the rules component to the workflow as well, because usually the rules factor pretty heavily into a workflow as well.

What's the future for the next version of Workflow Foundation?

I think first and foremost one of the things we will be doing is making a tight integration between WF and WCF, right now they are very complementary technologies. We can take functionality, expose it to services, we can consume services, transport agnostic inside WCF and right now in WF there's not a set of activities designed around WCF services. Making that integration happen would be one thing that we are going to be doing. The other thing we are doing is really listening to what customers are saying. And looking at that customer feedback to drive what's going to happen in the next version.

There's a new process at Microsoft called the Community Technology Preview Process. How has that shaped Workflow Foundation?

We used it a lot, we started with our first public release at PDC 0.5 that was when Workflow Foundation came out to the world and everybody found out about it, that was version 1.2 at that point. We've moved well beyond that, there have been a number of CTPs and public data that we've done throughout the last year and a half. Since that first initial launch, what it has been great for is getting those terms releases out to customers. Lot of the things that drive those changes is customer feedback: "I'm doing this, I don't like it, it should be a lot clearer to do this instead of this". The CTP process really allows us to relatively quickly turn around and say "try this". As we get later into the process the size and scope of the changes that can be made obviously get smaller and smaller especially because there's another product at Microsoft that has a dependency on us called Office, that's a pretty strong dependency. It's been great to get the bits out this early to this broad of an audience because we've seen adoption in scenarios that I haven't anticipated, so it's exciting to get it out and see what people are doing with it.

Is anyone using Workflow Foundation today and can you talk about that?

Yes, and when we talk about people using it today there are 2 different categories there: one are people inside Microsoft, and the big one there is Office, Windows Workflow Foundation is going to be the workflow engine inside Share Point, there are a number of other Microsoft technologies and products that are building on top of Windows Workflow Foundation. External to Microsoft, there are a number of case studies that are available at microsoft.com, of customers who are using it, the Italian Railway police are using it to as a document management system for all the various forms that go along with policing a railroad, and Dollar Rent-a-Car is using it as well along with WCF and WPF to form the next generation of some of their line of business applications. Part of my job focuses on early adoption within an ISV community so I can say there are a lot of organizations who are doing this and we will be talking about more of them soon.

Matt Winkler, now that you've shipped WF where are you going on vacation?

I'm going to spend a weekend in Cabo.

Is there anything else you want to share on WF?

First and foremost, get the bits, try it out, also go to http://wf.netfx3.com it's our community site where we're aggregating all the workflow blogs if you are a workflow blogger, and you like to include it in that let me know, if you contact us, I'm us, you can also submit activities there. We've got a number of activities that have been submitted by the community. If you have done something cool and what to let other people use it you can submit the activities there. We are also keeping track of any news and announcements, we can make those there.