Workflow Foundation - useless?

N

nightwatch77

Hello, I'd like to discuss with you my concern regarding Windows
Workflow Foundation. I hoped to use it for implementing business
processes in applications and, optionally, to provide graphical
business process designer to application users. But I was greatly
disappointed at what the creators of WWF did

1) It looks as if they provided a graphical designer for writing
normal code - there are primitives for loops, if statements, function
calls and not much more. You can create a normal program with that,
but

2) there are no business process-related primitives I expected to find
in a workflow designer. I mean tasks, actors (people that are involved
in the process), flow split and join for handling concurrent sub-
processes. Such designer is practically useless for business people -
they are unable to understand or use the process description language
provided by Microsoft because it is too low-level

3) What you are able to implement in a single sequential process is
rather limited. I doubt if it can be used for handling complex
business processes. Implementing even a simple process takes a lot of
work and results in a very complex code graph. I think it could be
used for implementing some fragments of application logic, but
definitely not business processes

4) You have to use a lot of custom code to make your process work.
Actually, you need to use custom code for everything, as the WWF
language provides only basic control structures.

5) You need to compile your workflows. That is, if you modify a
process, you need to recompile your application. Why is this a
problem? Because very often business applications need to run 24x7,
especially applications supporting key business processes. So you just
can't modify a process and keep the system running, you have to wait
until next 'system release' which takes weeks in big companies. Also,
you can't just experiment with an ad-hoc workflow and modify it live.
Business users should not modify and compile the application
themselves.

6) There is no utility for managing process definitions (modifying/
versioning/creating new/switching etc)

7) Generally, the WWF language is too low-level. You have no common
primitives to build from, so you end up implementing some custom logic
every time you need to extend a process. So, there's no possibility of
unified analysis of process definitions (validity checks), reporting &
statistics.

8) As the graphical designer is useless for business people, it's also
useless for programmers. Almost every programmer gets rid of graphical
designer as soon as he is proficient enough with the language or when
the logic grows more complex. For developers it's much easier to work
on text files - they are smaller, easier to edit and view.

Thats it for now, what do you guys think?
RG
 
M

Marc Gravell

1-4, 6
Hence the "F"; it isn't a product, it is a foundation. By the way, it
is WF, not WWF, to save upsetting the pandas and the wrestlers.
Actually I think you can probably do a bit more than you think; have
you read any of the books etc? This is a complex area. Actually for
most business processes I suspect state machine is the better model,
but this gets less focus.

5 You need to compile your workflows.
No you don't; WF can work from the xml stream (xoml), as long as you
don't use custom code steps (the name escapes me); just

7 (extension) Build a custom step; that is the whole idea
7 (reporting) Report off the persistance layer (i.e. database), not
the WF server

8 (text) Great - then use the xml editor to work with the xoml; job
done.

Marc
 
M

Marc Gravell

I wrote:> custom code steps (the name escapes me)

CodeActivity; you should instead be creating custom activities
(preferably with parameters to allow for re-use) that you can move
between flows etc.

Marc
 
N

nightwatch77

Yes, you're right - this is foundation. But my main concern is that
is not flexible enough. I think it should be more script-like and with
ability to provide high level abstractions in graphical process
representation and allow developers to descend to the lowest level of
details. So the business users could work on the high level, and
developers could write scripts at lower level but the framework would
enforce common rules. Currently developers can do what they want by
adding custom activities, and probably every dev will have his own
idea on how workflow definition should look like.
Custom activities are a good thing, provided that they are used for
extending the workflow language or providing reuseable components, not
for implementing custom business logic. A good example could be a
'Task' component responsible for assigning a task to someone and
monitoring the execution of the task. Bad example - a custom activity
containing some process-specific business rules that change very
often. In such case, it would be better to add a script that could be
modified without rebuilding the application, and it would also be
clear that this is a custom script and not a general-use component.
Why script - because it would allow for higher abstraction level than
C# or VB.
I like very much the idea of BPML language, or the academic YAWL -
both are Petri-net based and both provide high level process building
blocks - such as tasks, notifications, actors, subprocesses, parallel
flows and several variants of flow synchronization. So basic process
definition is understood by business users and at the same time it's
possible to run it, although it doesn't do anything useful - just a
model. Then the developers add code at lower level so the process will
actually perform some work. Developers don't bother to draw their code
- they just insert the scripts.
With such approach it's possible to automatically analyze the validity
of process definition, for example detect deadlocks or unreachable
paths. Also, reporting is easier - for example, if you have the same
'task' abstraction in every process, you can easily measure the
performance of any process just by looking at task execution times and
distribution of tasks to people.

Please remember this is my first impression so I probably don't know
WF well enough, but I see it's not very helpful as business proces
modelling tool. Its very similar to Biztalk orchestrations, but in
Biztalk its used for processing the messages and application
integration and not as a BPM tool.
Best regards
RG
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Top