A strong case for WF

I have struggled for so long to find a开发者_运维技巧 compelling use case for workflow (ie: WF) as against regular imperative programming. Each time I fall back to the conclusion that I should just leave WF out or defer getting into it until later. But I keep having this nagging feeling that there's something am missing.

Does anyone know any book that truly makes a strong case for the Workflow way? The book has to (i) teach WF well, and (ii) show using appropriate use cases that WF made an implementation easy to do than if we just did our regular straight coding.

I will appreciate it.

---

From the perspective of a non-expert, there are two things that to me make the case for WF -- one unique to workflow platforms, the other perhaps more of a convenience thing.

The convenience feature is the ability to create new ways of composing activities. Imperative programming provides only a limited repertoire of composition primitives: basically sequencing, if-else and loops. WF allows you to build your own composition operators such as interleaved execution, parallel execution, first past the post, etc. And of course it has the sophisticated composition mechanism of state machines built in.

I say this is a convenience feature because you can build all of these operators in an imperative language like C#: in fact that's how you build the WF operators. But WF makes it easy to use and to read custom compositions, whereas in C# you'd rapidly go down in a hail of lambda expressions. So if you have complex orchestration requirements -- that is, if the way your activities fit together is more complicated than sequences, if-else and loops -- then WF may make your program easier to express and to understand.

The unique feature is durability. This is where the Shukla and Schmidt book starts from, and where it keeps coming back to. An imperative program written in C# or VB can run for hours, days, weeks if it's lucky, maybe even months... but eventually IIS is going to cycle the app pool, or the admins are going to want to install the latest security updates, or somebody is going to trip over the power cord. How then does your program remember, "okay, I've got the purchase order from Unimaginative Company Names R Us, and I'm waiting on a credit approval from Bank of Breadheads Inc., and when I get that I can send the confirmation email"?

In a conventional imperative program, when the process dies, the execution state dies with it. You can start a new process, but it will start at the beginning of the program. Sure, you can create a database and use that to store flags like "got purchase order" and "got credit approval." But now you have to write application-specific code to save and query state, and to jump back to the right point in the program depending on that state. And you have to design a new database and new save/restore/jump logic for every single long-running application.

Durable workflow is about tackling this problem. If you write your program as a workflow of activities, then WF will take care of persisting its state including where it is in its execution flow. The machine running the program may catch fire and burn down your data centre, but when the response from the bank comes in, WF will wake up your program in your other data centre, and it will start running at the right place and with the right data.

That to me is the "strong case" for WF. In many cases, you don't need it: applications are sufficiently short-lived that failure isn't a significant concern, and restarting from scratch is a viable recovery strategy. But for long-lived applications, such as where you may be orchestrating external systems that may take hours to respond, or business processes that involve humans who may take days to respons, durability may be the killer feature for WF.

Disclaimer: I am not a WF programmer and have never built a real-world WF system. I'm coming at this from a BizTalk background, and from what I've read about WF, so this assessment is kinda theoretical. Hope it helps all the same!

---

Not sure if there is a good answer to your question. The problem isn't that the question isn't valid or anything like it because you are are asking for two very different things.

First of all you ask for compelling reasons to use workflow. This is a very subjective question and not technology related at all. You can find white papers on the web pointing to all sorts of successful, and unsuccessful for that matter, workflow implementations. This is regardless of technology, an solution that was done using some product X could just as well have been done using product Y. The chapter from Shukla and Schmidt certainly explains the fundamentals but I am not sure it is a good book showing you where and how to apply workflow.

Secondly you are looking for a book to teach you Windows Workflow Foundation. First question is WF3 or WF4 as they are very different beasts. I will assume WF4 because that will replace WF3 when .NET 4 is released (real soon now) and starting with WF3 doesn't make a lot of sense in most cases. But as WF3 never was very populair and the book market not very profitable for most writers there are no WF4 books out yet. I believe Bruce Bukovics is working on a new version of his Pro WF: Windows Workflow in .NET 3.5 book which I found one of the more usable WF3 books. So far there is nothing though and you are stuck with the, extremely limited, docs on the msdn site and blog like mine here. And of course there are course out there like this from DevelopMentor (note: shameless plug as I am the lead course author)

I did provide a number of reasons in this answer here, these might help you some.

Not quite an answer to you question but I hope all this will still be useful to you.

---

This is again not a direct answer, but this might be helpful if searching for other resources. To me it looks like WF is pretty closely modelled around the concepts introduced in Business Process Execution Language (BPEL). This std. has been around for a lot longer than WF, and any uses of BPEL should give you an idea of what to use WF for.

I've not used WF, but when I toyed around with BPEL a bit, and I found it hard to use. This was mainly due to the tool support (I found the eclipse plugin for visual modelling was lacking). When you combine this with the fact, that it is difficult to read code in XML compared to "normal programming language syntax", then BPEL was not a viable solution. If WF has a good visual tool, then this problem has at least been solved.

---

Good reasons are: Visual overwiew of your business processes. You can even have your client - the domain expert - edit the workflow with the designer ; restart the application and have it running without recompiling

Good Book: Bruce Bukowics AND my allways favorite: PRO C#2010 and the .NET 4 framework has an excellent chapter

---

I don't know of a book specifically about this topic. However, I believe that part of the appeal of WF (or other workflow products) is that it reintroduces the possibility of the loosely-coupled, message-based paradigm that the original OO guys (such as Alan Kay) were interested in.

The concept of a "message" being passed is not immediately obvious in WF. However, the notion of objects acting as discrete machines is.

For an awesome (but somewhat crazy) book about the state of OO, see Object Thinking by David West. And see here for Alan Kay's discussion of what OO means for him.