These characteristics have to be considered in the architecture of a WFMS. It will turn out thatthe main architectural issues of WFMS are
with respect to hard- and softwareheterogeneity, hard- and software distribution, varying size of the system, and different servicessupported. A client/server architecture is very suitable for achieving this goal. In this paper, wedetail the client/server architecture of a WFMS.
2Workflow Modeling in Workflow Management Systems
Although the architecture of WFMSs is the main topic in this paper, we have to introduce aworkflow model first in order to know what workflows look like. The architecture of WFMSsshows
a workflow is executed, while a workflow model shows
has to be performed.A distinguished architecture must use an orthogonal and modular workflow model to be orthogo-nal and modular by itself. The following discussion of the ramifications of our workflow modelABS (
Activity Behavior Specification
) gives an introduction in what has to be enacted by aWFMS. Details about the workflow model of ABS can be found in [BuJa94].
Workflows are described by an object-oriented model. Therefore, workflows are object typesand their fundamental features are represented by data variables and methods. Workflows repre-sent a functional unit (cf. Figure 1). They are either elementary or composite; composite work-flows reference further workflows (called subworkflows) so that nesting of workflows occurs.Elementary workflows invoke applications which are separately modeled as object types. Ap-plications represent an executable image, like a program or a server routine. Workflows arespecified in a modular way such that they can be reused in different contexts i.e. by differentworkflows. A workflow is called by its name along with a predefined set of values for the inter-face variables. Inside of a workflow, only variables local to that workflow can be referenced(scoping rule). Local policy variables may be needed to specify notification and policies (seeSection 2.3). The most important method of a workflow is
. Usually, the interface pa-rameters of a workflow describe the calling parameters for this function.
For composite workflows the execution sequence of their subworkflows is determined by depen-dencies between the subworkflows This defines the control flow among subworkflows. Twomajor types of control flow are distinguished ([Jabl93]).
of control flow are
. They bear the usual semantics. We use the followingnotation, whereby it is assumed that a superworkflow A comprises of two subworkflows B andC. Descriptive control flow among B and C is expressed by the following constructs:–
(B; C) /* serial execution*/ –
(cond(); B; C)/* alternative execution*/