Runtime Behavior

The process definitions of a workflow model specified with the process modeling environment may be executed in the Stardust runtime environment.

a Stardust runtime environment consists of

Details concerning the deployment of a model to a Stardust runtime environment can be found in the chapter Deploying a Workflow Model of the Deployment Guide.

Process Start and Continuation

To start a process, an instance based on the process definition has to be created. Process instances can be created by using

Once a process is started, its instance is executed on one or more EJB servers with respect to the clustering facilities of your runtime environment. During execution, all non-interactive activities (e.g. Session Beans) are performed independently from user operations. The corresponding applications are invoked by the Stardust Process Engine.

If the execution of the process instance arrives at an interactive activity, which is assigned to a performer - a role, an organization, a user or a user group - a work item representing an instance of this activity is put in the worklist of this performer. The execution of the process instance is then interrupted until this work item is activated from the worklist and completed. After completion of the activity, execution of the process instance is continued.

Asynchronous and Synchronous Execution

Whenever a process is started or continued in a Stardust Process Engine, the starter (e.g. a program using the programming interfaces of Stardust ) may want to wait until

Synchronous Execution

Such a solution is called synchronous execution. The synchronous execution is suitable for a scenario, where it is expected that

In interactive scenarios where a process is started by a manual trigger the advantage of synchronous execution is that the first interactive activity may be synchronously presented to the user after starting the process.

Asynchronous Execution

Alternatively to synchronous execution it might be desired only to guarantee to the invoking client that the process is started or continued. This scenario is referred to as asynchronous execution. The asynchronous execution is achieved by the same mechanism as multi-threaded execution, which is described below.

Visualizing the Engine Behavior during Transition Conditions

You can set the View Fork on Traversal flag on the Drawing Preferences page to visualize how Stardust Engine traverses during transition conditions.

Multi-Threading, Concurrency and Messaging

Normally, a process definition consists of a non-linear sequence of activities connected by transitions, thus forming a network containing split and joins of activity sequences.

The general topology of a process definition network is a directed graph of activities connected by transitions.

Activity Thread

A linear chain of activities in such a graph is called an activity thread.

a Stardust Process Engine performs activity threads concurrently. Activities in different activity threads are instantiated and executed in parallel. While one activity thread is waiting for an interactive activity pending in a worklist of a user to be continued, other activity threads of this process instance may be executed.

If arbitrary data (business and/or workflow data) are accessed in the activities of two concurrently executed activity threads, all policies of concurrent access apply (isolation, locking etc.).

Because the functionality of the Stardust Process Engine is provided as a set of EJBs and it is not allowed to use Java multi-threading in EJBs, the required functionality is achieved by using the Java Messaging Service (JMS). Whenever the control flow in a process definition arrives at an AND-split, JMS messages are sent for each outgoing transition and additional activity threads are executed parallel to the existing activity threads.

The detailed threading behavior can be controlled by the Fork on Traversal flag of the transitions involved.

Assume the following process definition:


Figure: Sample Process Definition with Multiple Activity Threads

If the default forking behavior for the outgoing transitions of Activity2 is specified the execution control flow for an instance of this process will be as follows:

 


Figure: Default Control Flow

If both outgoing transitions of Activity2 are specified to fork on traversal the control flow will change:

 


Figure: Changed Control Flow if Forking on Traversal is specified

Transactions

A transaction is a set of modifications, which is applied against a data source or a set of data sources and appears to be atomic - the modifications apply as a whole or not at all. If multiple data sources are involved, applying changes against one data source may succeed while modifications against another data source may fail. To guarantee atomicity in these cases the so-called two-phase commit protocol is used. Two-phase commit is provided by all application servers compliant to the supported J2EE or Java EE specification.

The execution of a process in Stardust may likely involve modifications on multiple data sources, because it causes Stardust 's audit trail database to be changed as well as sources of business data (e.g. a customer database). Hence, it is required to perform a two-phase commit protocol, which is performed transparently by Stardust and the EJB server/container hosting the Stardust EJBs.

It is relevant for the execution of a process to specify where a transaction starts and where it is committed. Specification of where a transaction begins and where it is committed is referred to as transaction demarcation.

Transaction demarcation in Stardust is done implicitly and compliant with the mechanisms of the EJB standard:

Normally, each call to start or continue a process demarcates the boundaries of a transaction. A two-phase commit is performed against all involved data sources after this call returns. If the client submitting this call has already demarcated a transaction, the commit may even be postponed until that point.

For a process definition containing multiple activity threads to be executed concurrently, the situation is more complicated:

If JMS messages are sent to spawn the control flow of a process instance, these messages are finally submitted as part of the two-phase commit protocol - the JMS message queue is considered as a transactional resource. Submitting the JMS messages earlier would prohibit to provide transparent and implicit transaction demarcation.

As a consequence, if forking on traversal for the transitions involved in the multi-threading is specified improperly, execution of concurrent activity threads may be delayed for a long time. Hence, a consequent review of the forking behavior is a vital part of process definitions. In the figure below the JMS message which starts ActivityThread2 is finally sent after Activity9 and the subsequent (implicit) commits have been performed.

 


Figure: Transaction Demarcation with Multi-Threaded Process Execution

If performing Activity3 to Activity9 takes a long time, unnecessary serialization of potentially concurrent control flow is forced and it is recommended to specify the transition between Activity2 and Activity3 to be forked on traversal.