Workflow Patterns Revisted

I was looking at one of my favorite sites today, the workflow patterns site by Wil Van Der Aalst, and it occured to me that if you are writing in a procedural language such as C you are effectively doing the same thing as writing out control patterns.  So then it occured to me that there might be some constructs in languages such as C or VB that are not covered by the existing list of workflow patterns (as I understand them).

 Here are some VB,C language contructs that dont really have the same kind of thing in the workflow patterns.

1) Goto:

Yes an outdated language construct and with good reason.  The goto is used to exit out of a context and goto another one and it pretty much forgets where it came from.  With the workflow control patterns they are alot more controlled.  They don’t skip all over the place as is the case with goto.

2)  Kill Process / Exit Application

If I am in a proces within a process within a process there does not appear to be a way to exit the high level process without creating a whole bunch of control logic with the currently defined control flow patterns.

3)  Wait

I am not really sure if this qualifies as a control flow pattern but it kinda is.  When getting to this stage just don’t do anything for a period of time (irregardless of what else is going on in the system).

4)  Queue and Stack

You could argue that both of these structures are not control patterns but for the sake of arugement I am going to argue that they are.  Lets say we have 3 tasks running in parallel 1.1, 2.1, 3.1

after one point 1.1 comes 1.2 after

after one point 2.1 comes 2.2 after

 after one point 3.1 comes 3.2 after

here is the catch however for queue:  1.2 can only be complete if and only if 1.1 was complete before 2.1 or 3.1 or x.2 is completed i.e. First In First Out

here is another possible scenario 1.2 can only be completed if it has not been completed and it is x.1 has not been completed later than it or x.2 has been completed. i.e. Last In First Out.  The interleaved parallel routing construct doesn’t exactly cater for this behavior.  You may argue that it is more of a resourcing pattern but I would need to be convinced.   You could also argue that this is more of a multiple choice, which in many ways it is.  However the logic at the point of choice could become very difficult to express at the point of choosing which x.2 item is next.

One thought on “Workflow Patterns Revisted

  1. Blog Ideas

    1) GoTo
    I won’t miss it. However, any transition from one activity to the next can be considered a “go to” statement.

    2) Kill Process / Exit Application
    The cancellation patterns seem to cover this requirement. The Cancel Activity will kill a specific task, while the Cancel Case will remove an entire workflow instance. (Please correct me if I am misunderstanding the patterns!)

    3) Wait
    I don’t see a direct notation for this feature, however, many BPM system include a method for implementing this need. (Including mine – pardon the shameless plug.)

    4) Queue & Stack
    I have never seen a customer specifically this feature. However, I think most systems show the available tasks sorted according by received date. Such a system could be considered a stack; assuming the user processes each work item from top to bottom.

Leave a Reply

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

You are commenting using your 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