hook & discover

A plug-in should be developed according to the "hook & discover" principle. This means that a plug-in can attach to a WorkItem in every possible situation and integrate itself into the structure of the WorkItem. This requires the plug-in to be developed to allow analyzing and validating of the actual structure of a WorkItem, preparing the WorkItem for its own process handling. A plug-in should not assume the structure of a WorkItem but provide the required attributes itself and initialize them, if required.

This principle ensures that plug-ins can be applied to as many WorkItems as possible. The actual status of a WorkItem should not have any effect on a plug-in.

For implementing this concept, the "init()" and "run()" methods are available.

Transaction

Every plug-in should support the transaction concept. The run method of an individual plug-in is always a single step within a transaction of the WorkflowKernel. The term "transaction" that was originally used in the business environment shows that this operation has a certain meaning for a process (business process).

From a technical perspective, the transaction has so-called ACID properties.

Atomicity: The actions that make up the transaction are performed either completely or not at all.

Consistency: A transaction always transforms own data resources from one consistent state into another consistent state.

Isolation: Two simultaneously running transactions are isolated from each other. This means that a transaction is not disturbed by the changes of another one.

Permanence: The changes of the transaction are permanently stored.

Two-Phase Commit

There is an interesting possibility of using plug-ins within transactions. For instance, this applies if different plug-in resources on different systems are to be synchronized. Typical cases are data resources on different systems that contribute to a transaction (process method). The challenge is to obtain the ACID properties of an individual plug-in.

To achieve this, the plug-in supports the concept of a two-phase commit (2PC). The WorkflowKernel assumes the role of the central coordinator. It executes the two phases that are mapped through CallBack methods "run()" and "close()" in the plug-in.

1. During execution of the "run()" method (matching phase), the WorkflowKernel requests all plug-ins to check and prepare their actions. A plug-in must finish the "run()" method with a PLUG-IN_OK, thus signaling the WorkflowKernel that execution is possible. If the plug-in returns a PLUG-IN_ERROR, the plug-in indicates that the action cannot be executed without errors. In this way, the coordinator (WorkflowKernel) gets all votes from the plug-ins and decides how the transaction should be completed. If there was at least one error, the entire transaction will be undone. Otherwise, the WorkflowKernel decides that the transaction can be executed successfully.
2. During execution of the "close()" method (commit phase), the WorkflowKernel informs the plug-ins about its decision. The plug-ins must then ensure that the action results in a commit and is actually completed, or execute a rollback if a PLUGIN_ERROR occurs.

PluginStack

The WorkflowKernel defines a so-called PluginStack when forwarding a WorkItem to a plug-in. The PluginStack provides information about the current processing state of the WorkItem in relation to the plug-in.

The stack is organized as follows:

 Itemname=$PluginStack
 Itemvalue=Pluginname|ProcessStartTime|ProcessEndTime

Example:

 org.foo.MyPlugin | 1/1/04 03:30 AM:30| 1/1/04 03:30 AM:31;
 org.foo.SimplePlugin | 1/1/04 03:30 AM:31| 1/1/04 03:30 AM:32;