|
(continued from the previous post)
A Quick Tour gives a good example on how to establish working environment and build one simple "Hello world" project. Inside you'll see what to expect from WF and how to manage to live with it. Nevertheless, Foundation Overview chapter is very good explained. It's good structured, in terms of that you don't have to install and use all of the features of WF at once. The phenomenon of "services" is heavily used through the book, as it's hype theseadays to use it. Well, I also have an opinion about'em, but curretly, I'm keeping it to myself...
What makes the story about workflows very intriguant is that they are "persistent" and "compensatable". It thrilled me from the beginning, because I have couple of "close encounters" with this "persistance" and "compensation" before in my short life. Nevertheless, later about that...
Activities
Why WF constantly reminds me to SQL DTS packages? Huh, maybe it's derived from it, but it's evolutionary better. As you probably know, DTS is history now, it has been replaced with SSIS (SQL Server Intergration Services) and BIDS (Business Intelligence Development Studio) - a wicked brother of VS.
As in DTS package, you have very neat collection of components you can work with, and only one "real" component you can "massage" the code. It's code activity and it's intended to mess the workflow with non-eligible code-behind. Well, you can't avoid after all.
Another good point is that you can take a base activity class (workflow itself is treated also as one big activity) and extend it as you wish (as much as you dare...). That means, you can have your own desired activities you can later reuse and test separately (hey, how do I unit test this stuff, anyway?). For example, consider creating ReservationBooking, CreatingRequest, OrderProcessing, CalculateTax as some of your custom activities.
As a big surprise, WF is not a system, it's part of a system. And this is good.
Why? You can host it wherever you like: desktop app, web service, web app, you name it.. For that, you'll typically create some management or handling classes. I had once one example of this: one monitoring app which displayed semaphore lights indicating statii about executing some of the background tasks, with some config features. Well, parameterization and configuration is also managed here. It means, you wouldn't normally need to "reset" the app to change the settings (as you'd need with NT services). So, you benefited.
Flow of Workflow
The flow is the same as you look the SSIS today. It allows also to debug the workflow on-the-fly. Also on live system, but it's not recommended (of course, who would recommend this?).
First thing which buggers me is that I think it's primarly intended to be used for "middle-earth" applications, i.e. building business models for specific business problems. I cannot imagine it to drive GUI's flow of instructions, or data-driven apps. Just can't. But, you can nicely see how it mingles inside some robust large-scale business app.
Persistence
Imagine you have some application you want to run for one year, or couple of months. I have survived this scenario before, but with performance monitor on the screen, tuning the memory usage and a headache. Now it won't be like that - it's promised by WF. The thing is that i'ts guarrantied by persistence service not by workflow itself. Workflow just "conforms" with this service, and therefore, it lives in some special store that is managed by persistance service, and it's not dependent on a particular instance of an app. When there is no work to be done, it just stays idle and wait for its master to be obedient.
For this purpose, state machine workflows are particulary useful. Of course, you can do it also without it, as you can go from Europe to Afrika by feet. Very practical. They function by raising and handling events. That reminds me on one debate in which there are no "services" at all, but rather only resident apps (as viruses) which stay in memory and keep in mind that CPU cycles should be low...
Compensation
The term "compensation" is misused here. Actually, we're not compensating something, as you'd thing of it as "else block", but rather try to "undo" the stuff you mistakenly done before. How you'd get this thing work? Through the usage of transactions. You create a transaction and stuff it with some code (i.e. activity work) and commit it. If it succeeds it can be "compensated". Ugly terms. Traditionally, that work must involve a resource manager such as a relational database or other store. By implementing the IPendingWork interface, you can undo things in a way you desire.
Rules of Engagement
One of my favourite themas - business rules management. As I've already tackled with this topic in one of my book reviews, it can be done in myriads of ways. And programmers are just one creative kind of people. So, they are never satisfied with this, and neither am I. Really, every time I think it's not good enough. The nearest solution to the perfection, I have to confess, is Validation Application Block. It rocks... But, for the sake of this tech, we'll stick to the Workflow Rules whose are not so neat, but they work. You have Rule class, RuleSet class, dependency properties (check out the WPF), you can manage it through the code or externally (declarative rulez).
Other warez
Dynamic Workflow Updates provide you to make dynamic changes to the structure of a workflow instance (I just pasted it from the book ;)). Tracking is a built-in mechanism that automatically instruments your workflows. (also pasted).
Hosting Workflow Designer
And, finally, workflow designer itselft can be hosted by your app.
What I actually meant that it is WF in the first place, but now it seems to be a feature! Nevertheless, it is awesome. I just can't help myself on stopping ideas to come into my head - how much applications I could build that looks awesome with it !! Imagine you have a PBX system you can visually configure (on how a call is forwarded, a girl on answering machine spells you soft words, ...), a hardware network of your company (or home in my case), a delivery system (hey Amazon, I have a solution for you!)....
The bad is that you have to use lots of low-level classes such as DesignSurface, WorkflowLoader, and so. But when you once establish the style, you'll fly with it.
I've seen that some guy did it as an AJAX application and it's somewhere available on web. Wonders you can do with it.
So, what to say about the book and about it's topic?
"We'll meet again, but not yet.. not yet.." (Gladiator)
|
