AJ's blog

December 14, 2007

Workflow Series Recap

Filed under: .NET, .NET Framework, Software Architecture, Software Development, WCF, WF — ajdotnet @ 6:57 pm

This post concludes my little workflow series…

1. Talking WF (introduction)
2. Workflow Instance State Management
3. Workflow Communication and Workflow Communication Clarification
4. Hosting WF
5. Talking to the Windows Service
6. Robust Operations
7. Error handling is Error Management

Remember where we started? WF. And what did I mostly talk about? Asynchronous data updates. Threading issues. Robust Windows Service implementation. Asynchronous error handling. Patterns. Practices. Guidelines.

And what did I rarely talk about? Shapes. Activities. Workflow specifics.

Remember what I wrote in the intro post: „And also very similar in the demand for knowledge of things that are not WF specific but are far from common knowledge for the average developer…“

Why are these things “far from common knowledge”, especially if they are not WF specific?

In my opinion this is because WF did not only introduce workflows. It also introduced asynchronous behavior and reliability demands far more forcibly than any other technology before.

  • We had threading before – but only the odd developer actually embraced it.
  • We had Windows Services before – but only rarely were they employed.
  • We had human workflow and state before – but it was largely hand grown and synchronous state machines.
  • We had demanding applications that could not live with these simplistic notions – but these called for specialized server software like BizTalk anyway.

With WF any developer might have to face all these new demands at once. It’s not WF in itself that is complex, in fact I can hardly imagine a workflow engine more easy to use than WF. It is the architectural consequences, the need for until then somewhat exotic concepts, the complicated asynchronous processing patterns. And the need to master all these demands at once.

Truth to be told…. ?

I once worked in a project that had quite amazing characteristics: 6 mio frontend transactions, processed to eventually enter the balance sheet, being subject to GAAP and quite a set of other legal compliance demands. Of course the software was built using BizTalk, not WF. We did then much of what I told you here. We had no choice and we had the budget.

Vacations@SDX does not even handle 1 vacation requests per day on the average. Does Vacations@SDX adhere to all the guidelines? Of course it does not. No one would have paid for that amount of fault tolerance just for one single workflow. We had to stay on budget and to meet a deadline; and making it foolproof simply was not feasible. (And the hosting part was a learning experience anyway.)

The reality is: What I presented here is in certain parts the 120% solution. (I am a friend of delivering 80% and waiting which of the missing 20% parts cause the most trouble. And 120% is simply 20% waste in any case.) But since this project was meant to have reference character we designed for the 120%. And with changing demands, new versions, or other applications built on the same principles, we may evolve the framework and the patterns. Gradually and where it hurts most. And in one respect we have accomplished more than with a simple “coding” experience: We have the architectural patterns (even if not fleshed out in toto) and we have the Windows Service Framework implementation.

The pragmatic point of view for you is: Decide for yourself which parts do hurt you. If you leave out certain aspects, do it knowingly. And I hope I could present some patterns that will help you addressing the aspects you can’t leave out.

Anyway, this concludes that little series. It’s been a number of posts, but believe me, this is only where it begins. On the missing list are testing of workflows, workflow design (including choosing between sequence and state driven workflows), and versioning, among others. Anyway, I wanted to talk about those areas that I came to realize caused the most problems for the people involved in the projects. I hope to have provided some useful hints, even if I got carried away sometimes😉 .

PS: I know, I promised another post about the replay pattern. But given my current workload and other topics in my blog queue, I decided I should close this series this year. I haven’t forgotten it and if want to prioritize it, drop a respective comment.

I wish you a peaceful Christmas and a happy new year.

That’s all for now folks,
AJ.NET

2 Comments »

  1. Hi,
    I have gone through your posts. Pretty impressive explanation. Thanks a lot. I have got
    one question regarding WF engine. Does WF engine start in different AppDomain than the host?
    Why i am asking this question is, From host i raise an event to WF and as part of event arguments i send objects such as very big DataTable or DataSet. This event is part of ExternalDataExchange stuff. Can’t i send huge data objects to WF?? Is that the correct to exchange large dataobjects between host and WF.

    Thanks,
    Manohar

    Comment by Manohar — September 17, 2008 @ 10:59 am

  2. @Manohar: To my knowledge WF doesn’t create new app domains. And you certainly _can_ send huge data objects to workflows. Whether this is a good idea or not depends largely on your use case (source of the data, architecture, runtime characteristics…) etc.. I’m afraid I cannot answer this question for your particular application.

    Comment by ajdotnet — September 18, 2008 @ 10:58 am


RSS feed for comments on this post. TrackBack URI

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

Blog at WordPress.com.

%d bloggers like this: