Frank's Blog

State of Workflow Part II: The Shifting Environment 

Still out there? Are you ready to continue the theoretical discussions? This time I want to talk about the State of Workflow Part II: The Shifting Environment.

While in the good old days the environment in which a workflow was enacted was quite static and manageable (e.g. a department, a single company) one can easily recognize a shift this time. All major players praying the support for change today. Some even sell you change! (If you don't believe take a closer look at SAP. They sell you a product called SAP NetWeaver that is "Providing the Foundation to Enable and Manage Change". An ever closer look reveals: "Can your company adapt quickly enough to respond to new challenges or seize new opportunities? With SAP NetWeaver, it can.". Wow!)

But where does the need for change arise from (besides making money)? One major point is a shift from closed to open environments. This requires the fast adaption of workflows, or nowadays called "service orchestrations". In a service orchestration, tasks are executed by services and the routing between the services is then called orchestration. In my observation there are four major shifts in the environment that lead to this situation:

  1. The environment is shifting from an accessible to an inaccessible one. In an inaccessible environment, there is no complete, accurate and up-to-date information available. If we expand the environment to the whole internet, there is much to be left in the dark which could be useful for our business, however we are simply unable to find and incorporate it.
  2. Executing a task in an open environment is more uncertain then in a closed one. There are way more possibilities to foresee and handle. However, if the environment is complex enough you can't enforce everything.
  3. Open environment tend to be constantly changing, in large parts regardless of our actions. However, our actions depend on some states of the environment.
  4. Furthermore, the number of services which can be invoked to perform a certain task is rising fast as the environment opens to the world. Even the decisions on which we base the selection of a certain service have way more input data to compute.

Think a bit about closed environments - your department, a workflow inside a company - and then about open environments. Interactions between several companies in the real world. Interactions between companies in the virtual world of the internet. Interactions between virtual companies in a virtual world?
[ view entry ] ( 1976 views ) permalink $star_image$star_image$star_image$star_image$star_image ( 3 / 2409 )
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...
[ view entry ] ( 1948 views ) permalink $star_image$star_image$star_image$star_image$star_image ( 3 / 2365 )
SOC & Pi 

Just another crazy task is done. Last Tuesday I was looking around for call for papers just to give me some deadline to work to. After searching through some 2,500 dbworld mails, I found a call for papers for the 3rd International Conference on Service Oriented Computing (ICSOC 2005). Fortunately, the deadline has been extended one week - to exactly July 6th. My colleague, Hagen, and I decided to prepare a paper about our approach on mapping a graphical notation for business processes (the BPMN) to a nice formal algebra, the pi-calculus. We went straight to our professor and told him our idea. His first response was: that's just seven days! Indeed, we responded, not seven - just five. Both of us will be going on vacation the weekend between - without any computer.

Writing the paper was actually quite funny as the content focused more and more at the conference than on our initial idea. Finally we created a paper about using the pi-calculus in the area of service oriented computing. We will see if the "be the first" approach will work this time also. Currently, there is just one "hard" scientific paper about using the pi-calculus for workflow on the market - whereas there is a strong demand.

However, we managed to finish our beautiful paper just in time and now wait for notification - that's not before September, 15th.
[ view entry ] ( 33 views ) permalink $star_image$star_image$star_image$star_image$star_image ( 3 / 2387 )

<<First <Back | 1 | 2 | 3 | 4 | 5 | 6 | 7 |