Frank's Blog

State of Workflow Part I 

I've came across a nice article about the state of workflow (although not the newest one). The article reminds me of putting together the things I currently research. In the section "The Workflow Landscape", three main differences between traditional workflow management systems and executional processes are characterized:

State vs. Message oriented.
Process instance id vs. Message correlations.
Central engine vs. Abstract service endpoints.
Today I want to consider the first point, state vs. message oriented processes. Traditional (academic) workflow research focuses on state-based descriptions of workflow (e.g. Workflow nets). However, as the term workflow broadens to inter-organizational workflow between companies, and especially by the use of service-oriented approaches, distributed, state-based processes are hard to manage. In contrast, message-based systems that rely on events promise a much broader usability (e.g. BPEL).

Let me give you an example in the Workflow net notation:

The simple process above consists of a task that sends a request and afterward waits for either the response or a timeout if no response has been received within a given timeframe. The process already contains the nice pattern Deferred Choice. In traditional workflow systems, this process lived alone. Each task appears at the work list of some employee who finally has to execute it. The first task was maybe a letter to be sent. Afterward, two exclusive tasks appeared at the work list. If an answer was received by mail within a given timeframe, the answer was processed, whereas otherwise the timeout task was selected (which contains maybe some callback actions).

However, as time moves on and the future of workflow arrives at the service-oriented architecture level, all tasks of our example are executed by computers. So, what is required first? Of course, a corresponding process. Lets assume this to be an abstract process, meaning that we only know the parts which we can use for interaction:

I used some fancy notations to denote the hidden parts of the corresponding process. We can actually call this process service. All we know is the interface description (receive request, send response). We additionally can derive the order of the tasks (first receive a request, then send a response). This is by far more as static web-service descriptions (WSDL) contains, as we have a static as well as a behavioral description of the service.

When we use a state-based description of how our example process interacts with the service, we need to introduce some additional states that describe the incoming requests and outgoing responses. The result contains two workflow nets which interact by using shared places (marked in sweet orchid):

I want to state again, that this system consists of two different workflows, executed by two (different) engines, which use shared places for synchronization. There exists a lot of formal research on this topic, for example how to extend the service without violating the "interface" behavior (by van der Aalst).

A message, or event-based system has no explicit state description. Each task has so called preconditions which have to yield true to enable the task, and postconditions, which hold after the task has been executed. All tasks are "swimming" inside a service-oriented environment as the for example the web. For several good reasons, the tasks of our example are belonging inside our companies space, whereas the services belong to other companies which offer them. However, in theory all task can be easily distributed across the environment. Let me also give you a picture here:

All tasks are represented as circles which a short name inside (not to confuse with the states, or places of workflow nets). The tasks are split across two spaces, our and the other space. The pre- and postconditions of the tasks are not contained within the picture, however the dependencies between are shown by lines. Each line connects a postcondition of one task with the precondition of another one (where the precondition-end is marked with a filled circle). So we see dependencies between P1, S1, P2, P3 as well as S2 and P2. Actually S1, P2, and P3 can only be activated after P1 has been executed, those meaning the preconditions of S1, P2, and P3 depend on the postcondition of P1. The same holds for S2 and P2. I leave it as an exercise for the reader to give the corresponding conditions. What I would like to highlight is the high distribution of all possible tasks. P2 for example could also be inside another space, and each task can be controlled by a different execution environment, those making a message-based workflow system highly distributed.

What this is all good for? We will see...


Add Comment

Comments are not available for this entry.