tags:

views:

84

answers:

4

I read a bit about the overall idea of this technology but it reminds me of a few decades ago when we were told "in the future you won't write code, you'll connect boxes in some graphical tool".

Is it a technology which has become central in .NET development (like WCF and WPF have) or has it failed to catch on?

A: 

If you use some of the Microsoft product lines it becomes quite useful (Dynamics CRM allows you to write custom workflow actions that business users can then use via the web interface, for example).

Beyond that my (limited) anecdotal evidence says it's not used much.

mavnn
A: 

It may be worth noting that the TFS2010 build process is based around Workflow (including the box-dragging UI if you prefer to use that).

It's not as central as WPF or WCF, but it definitely has its uses. One issue I've seen is that worfklow is more fundamental to an application than the others: replacing a UI with WPF doesn't require a ground-up rearchitecture to work. Likewise, creating a WCF web-service layer doesn't require ground-up rearchitecture. Integrating workflow usefully often requires much bigger and deeper changes to be effective, making the barrier to entry that significant bit higher for most systems I've looked at.

Dan Puzey
+1  A: 

WF is a workflow engine, not a fully fleshed workflow application or component. You can use it to add workflow capabilities to your own application but you have to provide a user-friendly designer otherwise it is more trouble than benefit.

WF hasn't caught on until now because it was too slow, making it suitable only for heavy-duty workflows. Pageflows for example (specifying a sequence of web pages) were out of the question. Developers also had to create a lot of plumbing in order to host WF in their application. Finally, you had to create the end-user WF designer from scratch, or use Visual Studio's designer which was totally unsuitable for end users.

WF v4 is a lot faster and easier to host but you still have to build your own designer.

Panagiotis Kanavos
+2  A: 

I don't believe WF is that widely used; we're probably one of the few places currently using it (WF3) and we're ditching it for a simpler bespoke solution instead of migrating to WF4.

A problem is that one of the main audiences WF is aimed at is those building 'enterprise' type systems (i.e. solutions with complex long-running stateful processes) but Microsoft don't provide any 'enterprise class' hosting solution for it, and writing your own is a painful experience (been there, done that). The AppFabric stuff for WF4 looked like it could answer this issue, but ended up being nothing more than a bit of logging and persistence framework, leaving the actual hard problem of hosting completely out of the picture.

It's a shame, because WF4 looks like a great framework for building this type of application. With the right hosting it could be 'BizTalk done right' (speaking as a seasoned BizTalk developer here too). But until there's a good hosting solution out of the box, I'd expect its use to be fairly limited.

Greg Beech