Datasheet

Chapter 1: Workfl ow Programming Principles
3
So far, I ’ ve discussed the characteristics that WF workflow programming has in common with traditional
programming such as C#. Next, I ’ ll discuss the characteristics that make workflow programming
fundamentally different from a traditional programming such as C#.
When the program control in a single - threaded C# program reaches a program statement, the program
statement executes continuously in synchronous fashion until it completes its execution. This concept is
so obvious and rudimentary in traditional programming models that we never think about it.
When the logical program control in a logical program (business process or workflow) reaches a logical
program statement (activity), the logical program statement may or may not execute continuously in
synchronous fashion. For example, consider the section manager activity in the aforementioned vacation
request workflow. After an employee makes a vacation request — that is, after the employee activity
or logical program statement completes its execution — the execution of the section manager activity or
logical program statement begins. However, the section manager may be stuck in meetings for several
days and may not be able to respond to the vacation request immediately. In the meantime, the section
manager logical program statement cannot continue its execution because it is waiting for the
section manager to approve or deny the vacation request.
This is a common characteristic of business activities or logical program statements. They execute for a
very short while and then suspend their execution, waiting for an indefinite period of time for an
external entity to deposit the required data before they resume their execution.
This introduces a huge challenge. What should a business activity or logical program statement do when
it suspends its execution and waits for an indefinite period of time for an external entity to deposit the
required data? Should it hold on to the thread on which it is running?
Holding on to the thread for an indefinite period of time is not a viable solution for two main reasons:
Threads are expensive resources and should not be wasted.
Threads and the processes owning the threads would not stay around for an indefinite period of
time. For one thing, Windows processes do crash.
Therefore, the activity must let go of the thread when it suspends its execution and waits for an
indefinite period of time for an external entity to deposit the data.
Another resource - related issue is the fact that activities consume memory. It would not make sense to let
an activity remain in memory while waiting indefinitely for external input. This would waste a lot of
server resources, especially when too many inactive activities are sitting in memory waiting for external
inputs. A better solution is to serialize these inactive activities into a durable storage.
When the required data is finally deposited in the appropriate location, the activity or logical program
statement can then be brought back to memory to retrieve the required data and resume its execution
where it left off. However, there is no guarantee that the activity or logical program statement will
resume its execution on the same Windows process, let alone the same thread, because by the time
the external entity deposits the data — which could be days or weeks later — the process on which the
activity or logical program statement was running when it suspended its execution is long gone! There is
no guarantee even that the activity or logical program statement will resume its execution on the same
machine!
❑
❑
c01.indd 3c01.indd 3 8/25/08 4:02:52 PM8/25/08 4:02:52 PM