Watch out Java - Windows Workflow is coming!

by Paul Browne

Related link:

Workflow is core to most business as it describes the core of what they do. Workflow can be as simple as 'Search for Flights, Select Flight, Pay, Recieve Email confirmation', to something much more complex (e.g. a Mortgage application). Many systems already have workflow in them, only they don't know it. The problem is then that the Business People (who understand the workflow) can't see how it is implemented in (hidden behind code), while the technical people don't understand the business process. Workflow (closely related to Rule Engines) aim to solve this problem.

I recently attended an Irish .Net Developers presentation by Aiden O'Connor (long story), about the new Windows Workflow, currently in Beta as part of Microsoft .Net. While workflow in Enterprise Java is nothing new (Serverside Article), the implementation of Workflow in Visual Studio will bring it's ideas to a wider audience, and force the Java workflow people to 'raise their game'.

So, why should you be interested in Windows Workflow?

  1. Visual Studio has always had 'Drag and Drop' building of Systems. Now it will also have 'Drag and Drop' flowcharts (it looks a bit like Visio or other drawing tools). When the process hits a stage an Event is triggered and appropriate code called (e.g. similar to a mouse click on a form).

  2. It is likely that Business Analysts will use a Visual design tool to draw up the workflow. Programmers will then handle events at each stage in the workflow - a much easier process as they just have to concentrate on a single step, and not worry (so much) about the bigger picture.

  3. Long lived workflows and processes can be handled easily. For example, if we have issued the ticket and are waiting for the customer to check in (weeks later), state will be persisted automatically.

  4. It brings the workflow ideas from a niche to a wider audience. Even the Java based frameworks will benefit from this.

  5. It is part of the .Net framework - the equivalent in the Java world of coming free with the JVM. It will run anywhere .Net does, and one workflow can span multiple machines (this was buggy in the demo, but it is still Beta software).

Workflow, if and when it goes mainstream, has the potential to change the way we program as radicially as Visual Tools and OOP did.

Is workflow going to change your programming style? Are you going to be using workflow in your next project?


2006-01-21 15:10:31
*shrug* (yawn)
Ever heard of BPEL? Seems like this is just another case of Microsoft inventing a new term for something that many people have already implemented.
2006-01-22 00:33:24
*shrug* (yawn)
Yes, BPEL is a very good implementation of workflow (and is one of the frameworks mentioned in the serverside article).

The main point of this post is

1) Windows Workflow is a very impressive visual tool, and whatever the merits of the 'under the cover' implementation (v BPEL , for example), that alone will get it (and worklfow in general) attention.

2) Microsoft is providing this workflow as Standard with .Net and Windows Vista. I would love for BPEL to get that kind of coverage and push the idea of workflow into the mainstream.

A good analogy is Visual Basic programming - while there is a lot to critise technically (as a former VB programmer), it brought the idea of 'drag-and-drop' programming to a entire group of people that otherwise would not have seen it.

2006-01-24 11:53:06
*shrug* (yawn)
Another important point to make is that there is tight integration between the visualization of the business processes involved and the code which sits behind these business processes.

A good Business Analyst(BA) can sit down at a PC with a developer and sketch out what the BA perceives to be the business processes taking place in his/her organization, all through WF. This means that the BA can get involved at more stages in the development life cycle.

Traditionally, developers get analysis information from the BA; the developers then implement the logic and come back with a final implementation i.e. what generally resides on your application server (what makes a company money).

There won't be any clear mapping between what the BA gave the developers in term of diagrams. What we end up with is a monolithic block of code which will evolve over time and most lightly will become ever harder to understand and end up costing allot of training hours getting junior developer/contractors up to speed with the application domain, not to mind understanding the code.

The way I see it, WF allows us to keep a structure on the business processes involved since we can always get a visual representation of how everything hangs together. This traditionally has always been a hazy area for developers and BA's. I feel WF helps draw Business and Software development closer together, helps new developers understand how the business processes work in a domain (You would hope the BA's already know this) and makes it easy to augment workflows with minimum code changes. There are a number of other advantages; I'll discuss these on a different occasion.

One item which I have an issue with in relation to work flow is the manageability of a workflow diagram if the work flow becomes very large. There is only so much real-estate on a modern flat screen. I sometimes think that people could loose the visualization if the WF diagram becomes over complicated or too large. I know people will say, just add more work flows to the project but I can imagine people trying keep everything on the one diagram.



2006-01-24 12:22:42
*shrug* (yawn)
Thanks Aiden - you've put it better than I could.
2006-05-11 13:40:42
Yes, I am excited about the workflows and definetly my programming style is going to be based on workflows..
Paul Browne
2006-05-12 06:51:52
Since writing this post, I've done a bit of work with JBoss workflow - the blogpost in this is here: