Ok, I acknowledge WF is an exciting piece of technology. It must be, I’ve spent days poring over examples. However, despite what is asserted on the videos, it’s not an easy piece of technology to get to grips with. In particular, there aren’t any “full” real-world examples. Pretty much all of the examples don’t actually write anything to a recognisable problem domain-specific database, they just use in-memory structures to hold ad-hoc workflow instances which then persist themselves to a very generalised workflow database.

I’m unsure how this squares with traditional app development. To use their helpdesk example, where does the data actually go? If it’s into this generalised persistence database, that makes it impossible for me to query, for example, the latest top 10 high priority cases, doesn’t it? Does this mean I am supposed to keep a domain-specific database in sync with the workflow using activities?

This seems to be the one area that gets no discussion – everyone’s so wrapped up in discussing the technical details of flying the runtime, persisting their instances, writing custom activities, that no-one has mentioned how the traditional application really fits around this. Oh, sure, there are plenty of examples that show how to handle external host app events or call out to the host app, but they’re all hooked up to Console.WriteLine or similar in the examples!

So, if I wanted to write a real-world ASP.NET version of the helpdesk app, do I need one database or two (one domain DB, one for the WF persistence service)? If two, how do you ensure the two stay in sync? If one, how do I query my cases?

Do I just write my application as normal and then put the hooks into workflow? How can I drive my ASP.NET page flow? Do I have to retrieve work items from a queue and display them somehow for helpdesk agents to pick up? Can I use straight ASP.NET data binding for this and which DB would it come from, domain or WF persistence?

These are a lot of questions (these are just *today’s* questions), and answering them one by one is like carving a Bamiyan Buddha singlehandedly. I’d post this to the WF forums, but such questions seem to go unanswered while the simple tech questions get immediate replies.

The quest continues…

EDIT: It looks like Jon Flanders may already have been through this pain.

Lots of properties required to get this upI’ve been looking at Windows Workflow Foundation (WF, not WWF for the usual World Wildlife Fund / World Wrestling Federation reasons) these past few days. In particular, I’ve been interested in collaborative workflows hosted online in ASP.NET applications. That sounds really dull (and that’s partly because it is ;) ), but it’s also the way forward (this week). The main reason I’ve been looking at it is for the state machine management combined with persistence for workflows which are waiting on user input.

I think the (possibly temporary!) conclusion I’m coming to is that WF is massive overkill for nearly any application. I’m currently looking at the WF Labs Expense Reporting example, and we’re looking at six (count ‘em!) co-operating assemblies, a lot of instance data on your workflow, co-operating applications to get data in or out, a slew of new terminology and a drag-and-drop coding environment that reminds me very much of some Amiga game I can’t remember the name of from around 1993 (which had a hacking sub-game with while/if/else implemented in a drag-and-drop style).

When it takes around five drag and drop operations and a dozen property settings to implement a simple if/else construct in your workflow, you can’t help wondering if any of this is a step forward from a simple method call. Ok, it’s not helped by the quality of the examples, which concentrate far too much on the how and not enough on the why. Even so, you quickly get the feeling there’s little here that could be described as exactly agile.

Of course, the architecture astronauts are never ones to pass up an opportunity to use a dozen new metaphors where three old ones would have done. This probably explains why BizTalk “architects” are commanding such insane salaries for what is essentially a grandiose plumbing job with little or no coding required. And when things go wrong, you’re left twiddling properties instead of sat inside a decent debugger with a decent worldview.

Tune in tomorrow when the penny drops, I get less grumpy about the learning curve, and I retract all this and replace the post with a thorough evangelisation :D

FOOTNOTE TO MS: If you could make your recorded webcasts freely available as straight video without having to jump through registration hoops and requiring the use of IE, that would also help my grumpiness a great deal. Thanks.

© 2014 ZephyrBlog Suffusion theme by Sayontan Sinha