3.4 Wfms Architecture

Using components and composite applications, a distributed architecture for supporting workflows can be developed. The functional aspect of an workflow with its hierarchy subworkflows can be represented by an hierarchy of composite applications. The control aspect of an workflow can be realized by the event processing capabilities of composite applications. The event mechanism also provides basic support for the data aspect of workflows, however more sophisticated mechanisms may become necessary if complex data structures have to be exchanged. Single beans realize the operational aspect. The organizational aspect is the only imperative aspect which cannot be realized directly with composite applications, however, serices such as the Java Naming and Directory could provide the glue to the organizational representation of the enterprise.

In this architecture the processing of workflows is done by composite applications linked over connectors and communicating via events (see also figure 4). These events also contain data or references to them, necessary for processing of the workflow. The composite applications may represent subworkflows or atomic workflows. The starting point of the processing are incoming events from other composite applications. They may have been directly propagated or may have passed a condition. They may even have caused an action as part of an E/C/A rule. The processing of conditions and actions is done by adaptors, as described above. Because the adaptors for the incoming events are outside of the composite application, they can be used by several applications, therefore reducing the overhead processing. By changing the adaptors behavior, changes to the workflow can be easily represented.

 

Figure 4: Workflow-processing through composite applications

However, there may be temporal conditions, which define dependencies between the occurrence of different events. They have to be tested before the processing of the workflow can be continued, but they can only be tested inside the composite application. Therefore a checking mechanism for temporal conditions has to be included in the composite application. After passing this test, a subworkflow or a workflow operation inside of the composite application can be processed. After this is done, the fulfillment of a condition at the end of the workflow processing is checked and events are propagated to subsequent composite applications to continue the processing of the workflow.

The architecture presented here is of a physically and logically distributed character. Because composite applications can be distributed transparently, the processing of the workflow can be physically distributed quite simply. More important, this architecture is logically distributed as well, because there are no centralized mechanisms controlling the execution of the workflow. In order to represent business processes with this architecture, it is necessary to transform business process models such as the SOM-approach [FS94] into workflow representations which are executable by the architeture described here. In order to create such a transformation, the fact that composite applications and workflows can be modelled using state-and-activity-charts will be of importance.