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.

I love articles like this, that introduce small amounts of new detail but really formalise and consolidate what you think you already know. It takes in software factories, industrialisation of the software development process, buy vs. build etc.  Most importantly it establishes some criteria for architectural decomposition along component boundaries.  Effectively, how to use components effectively.  Though it doesn’t say it specifically, this means sensible steps to manage risk for software projects that use components – which these days, even if you’re only using the component set that came with Visual Studio.NET, means all of them.

I don’t use many (actually, I try not to use any) of the built-in styling properties of ASP.NET server controls.  The only property that means a thing to me is CssClass.  However, there are a few properties I find I always have to set to avoid crummy markup.  Chief amongst these is the GridView’s GridLines property – if you don’t set this to ‘None’ and CellSpacing to -1, CSS styling of grid borders isn’t possible as inline styles will override any of your stylings.

I don’t really theme sites either, largely because of the aforementioned bad markup – the presentational properties result in a slew of inline styles applied to many elements which bloats the HTML. Since I’m not using them for anything else, a single ‘Default’ theme’s skin files actually works very well as “policy” style document.  I always set these two properties on any GridView - now I can set them once in a ‘Default’ theme and every GridView I use will inherit the policy. Not precisely what themes were intended for, but pretty useful nonetheless (at least until ASP.NET Control Adapters arrive later this month) :)

Frans Bouma has posted a multifaceted muse about the nature of operating systems as collections of components. In talking about Vista, he touches on something very close to my heart – the allocation of resources to the OS:

How it’s going now is that the OS is starting to become (or already has become) an application on its own. And IMHO that’s a bad thing. If the effectively amount of raw computer power left to my applications under Vista is roughly the same as it was under Windows 2000 on a P3-933, what have we won in all those years? IMHO not much besides pretty pictures and shiny mirrors. But trust me, shiny mirrors and pretty pictures don’t get the job done you have to do.

He also mentions the Amiga (I had a 500 and then a 1200 with a 120MB HD):

My Amiga 500 with 1MB ram and a 7.16MHz processor was perfectly capable of task-switching the cr*p out of different threads/processes, so it’s not the core-OS that needs all that power.

Every now and again, I look at Windows and I baulk at the fact that the heap of components in front of me is doing (year on year) more and more in the name of housekeeping than in dealing with the computing tasks I throw at it. Continue reading »

© 2010 ZephyrBlog Suffusion theme by Sayontan Sinha