Command Chain

Scope

This API provides means to define and control the workflow of a request. With workflow we mean both the flow of execution in a single request and the flow of different requests. There are other API's, for instance Struts from the Apache Jakarta Project, which has similar ambitions. This is by no means the ultimate solution and you may replace it with your own choice of workflow controller.

Functional Requirements

The need for a workflow controller arised while reviewing the first release of SCAM. The tight coupling between the different parts made it nearly impossible to change order of execution and, thus, difficult to adapt to other applications.

The review identified following requirements:

  • Easy to adapt the workflow controller to different applications.

  • Many applications has parts of their workflow in common, these parts should be made reusable.

  • Avoid the need for re-compiling when changing the workflow. This to make it easier for non-programmers to make changes in the application.

Architecture

The workflow controller consists of three parts:

  • the workflow interfaces.

  • a configuration utility.

  • a library of reusable parts.

The workflow framework provides two interfaces:

se.kmr.scam.client.chain.CommandChain

object with this interface represents an executor of requested workflows.

se.kmr.scam.client.http.Command

object with this interface represents a command performed during a request.

We now define a command-chain to represent a given workflow, it is identified by a name and is associated to a ordered set of commands. By executing a named command-chain the associated commands are executed, in the predefined order.

The configuration utility uses a configuration file, command-chain.xml, to define the commands associated with the different command-chains.

Design Descussion

The Command interface does not define any arguments for the execution of the command, this because each command should be self supported regarding dynamic data. This does not imply that a command is prohibited to leave fingerprints. A command will be initiated with parameters from the configuration utility, read the current state from Java Beans and request attributes. Upon execution the command updates the state by updating appropiate Java Beans.

Using a configuration file for describing the workflow of a request gives an abstraction between the command implementations and the workflow. Although that the development of commands requires some programming skills, the configuration process is a non-programming task. This simplifies the task of adopting the workflow to different applications.

We choose the XML-format because it is adequate to our needs, is widly known and many other formats can be transformed into it.