Managing business
`processes as an
`information resource
`
`by F. Leymann
`W. Altenhuber
`
`The relevance of business processes as a major
`asset of an enterprise is more and more
`accepted: Business processes prescribe the way
`in which the resources of an enterprise are used,
`Le., they describe how an enterprise will achieve
`its business goals. Organizations typically
`prescribe how business processes have to be
`performed, and they seek information technology
`that supports these processes. We describe a
`system that supports the two fundamental
`aspects of business process management,
`namely the modeling of processes and their
`execution. The meta-model of our system deals
`with models of business processes as weighted,
`colored, directed graphs of activities; execution
`is performed by navigation through the graphs
`according to a well-defined set of rules. The
`architecture consists of a distributed system with
`a clientherver structure, and stores its data in an
`object-oriented database system.
`
`0 rganizations typically prescribe how busi-
`
`ness processes have to be performed, espe-
`cially those processes that represent complex
`routine work, that
`involve many persons (both
`concurrently and sequentially), and that are
`in
`general frequently performed. Examples of such
`processes are manifold: program development in
`the software business, credit
`allocation in the
`banking business, customer
`enrollment in the
`health insurance business, or expense allowance
`processing in the administration business.
`
`The relevance of business processes as a major
`asset of an enterprise is being accepted more and
`more. Business processes prescribe the way in
`which the resources
`(e.g., data, capital, human
`
`beings) of an enterprise are used, i.e., they de-
`scribe how an enterprise will achieve its business
`goals. The quality of the business processes will
`influence the quality of the performance of an en-
`terprise. Thus, business processes themselves
`represent important information resources of an
`enterprise, and techniques or systems to manage
`and support business processes are always in de-
`mand.
`
`The IBM program product called FlowMark* sup-
`ports the management of business processes.
`Both fundamental aspects of process manage-
`ment, namely the modeling of processes (build
`time) and the execution of processes according to
`a process model (run time), are facilitated. Flow-
`Mark may be perceived especially as a repository
`for business processes. Within the IBM Informa-
`tion Warehouse* framework (of which some as-
`pects are discussed elsewhere
`in this issue),
`FlowMark is positioned as the work flow man-
`agement component.
`
`Current approaches. Today, there is no generally
`accepted methodology for modeling business pro-
`cesses. Petri nets are
`traditionally used to de-
`scribe and analyze concurrent systems. ' Never-
`theless, it has been recognized that Petri nets are
`
`Wopyright 1994 by International Business Machines Corpo-
`ration. Copying in printed form for private use is permitted
`without payment of royalty provided that (1) each reproduc-
`tion is done without alteration and (2) the Journal reference
`and IBM copyright notice are included on the first page. The
`title and abstract, but no other portions, of this paper may be
`copied or distributed royalty free without further permission
`by computer-based and other information-service systems.
`Permission to republish any other portion of this paper must
`be obtained from the Editor.
`
`326 LEYMANN AND ALTENHUBER
`
`IBM SYSTEMS JOURNAL, VOL 33, NO 2, 1994
`
`Apple Inc. Exhibit 1037
`
`

`
`not currently succinct and manageable enough to
`become useful in modeling business processes.
`For this reason high-level Petri nets have been
`intensively studied during the last
`couple of
`years. In particular, predicatehransition
`nets3
`and colored Petri nets4 have been applied in var-
`ious application areas. But other methodologies
`have also been proposed and applied. It depends
`on the emphasis one puts on the usage of pro-
`cesses as to whether they are described as Petri
`nets, trigger systems, forms, case plans, or even
`collections of formulas of temporal logic, for ex-
`ample.
`
`ing their recovery, is presented in Davis.13 Tar-
`geting in the modeling of long transactions, Kotz9
`proposes the use of eventhrigger systems.
`
`With the support of office work in mind the fol-
`lowing has been suggested: To model office pro-
`cedures, Behrmann-Poitiers and Edelmann14 are
`proposing “case plans.” In cases where the office
`system reveals specific object-oriented character-
`ties are pursued. ’’ If a process can be described
`istics, life-cycle diagrams and composed activi-
`as the processing of a form, a corresponding pro-
`posal is given by Tsichritzis. l6
`
`If one focuses on the pure data manipulation as-
`pects of a process, process models are viewed as
`vehicles for ensuring database integrity. Guyot’
`shows that Petri nets are allowing database ad-
`ministrators to control and constrain the execu-
`tion of activities that manipulate a database.
`Temporal logic has proved to be remarkably suc-
`cessful in describing parallel programs and in
`studying their properties;6 the management of
`parallel components of a program has some sim-
`ilarities to managing transactions concurrently
`accessing databases. Thus, Lipeck and Saake7,’
`discuss how temporal logic is applied to describe
`valid sequences of database states and consisten-
`cy-preserving transactions, which is in certain sit-
`uations the major intent of a process model. Par-
`tial orders on event spaces are also considered to
`model consistency-preserving sequences of data-
`base actions.
`
`Process models may also be perceived as a means
`to extend and complement facilities known from
`conventional transaction processing monitors. A
`process model is viewed as the specification of
`the flow of control and the flow of data separate
`from the collection of routines performing the
`proper computations of an individual application.
`Applications are represented in Garcia-Molina
`and Salem” simply as sequences of related trans-
`actions ensuring either the successful execution
`of all transactions in the chain or its compensa-
`tion. Predicatehransition nets are pursued
`in
`Wachter and Reuter” to model networks of
`“steps” (and “compensation steps”) that repre-
`sent the “scripts” of an application. A network of
`“activities,” which are triggered by “events,”
`which are sent along “arcs” connecting activities,
`is exploited in Hsu et al. l2 for that purpose. A
`very generic and abstract approach (“spheres of
`control”) especially for managing flows, includ-
`
`The commonality among processes in the areas of
`software development,’7”9 office work, and ad-
`ministration has been worked out by Chroust and
`Leymann.20 A methodology applicable in these
`areas is described by Leymann. It strives espe-
`cially for a formalization of processes and their
`models in these problem areas that is even more
`succinct and “user-friendly” than
`in Genrich3
`It encompasses, for example, the
`and J e n ~ e n . ~
`case plans of Behrmann-Poitiers and Edelmann14
`and in addition allows the definition of parameter-
`controlled work flows in their problem domain. In
`this paper the
`methodology of Leymann21 is
`enhanced by introducing PM-gruph (Process
`Model graphs) in order to fulfill additional require-
`ments posed by FlowMark.
`
`Our presentation. First, we show that today pro-
`cess models are treated as information resources
`in a rudimentary manner; also, we sketch the po-
`tential embedding of process models into
`an
`IRDS (information resource dictionary system22).
`Next, we discuss the meta-model of FlowMark
`for processes. We provide and motivate a collec-
`tion of constructs that have to be used in order to
`define the model of a process to FlowMark. Then,
`the architecture of FlowMark is sketched. It is a
`distributed system with a clientherver system
`structure. All relevant data are stored in an ob-
`ject-oriented database system. The graphical end-
`user interfaces for defining and executing pro-
`cesses are sketched. Activities represented by
`executables complying to a certain
`invocation
`paradigm are invoked by FlowMark. In the final
`section, we give a mathematical formulation of
`the syntax and the semantics of the meta-model.
`Mathematically, a process model is represented
`as a special weighted, colored, directed graph of
`activities (called a PM-graph); the semantics of
`the meta-model are defined operationally, exe-
`
`IBM SYSTEMS JOURNAL, VOL 33, NO 2, 1994
`
`LEYMANN AND ALTENHUBER 327
`
`Apple Inc. Exhibit 1037
`
`

`
`cuting a process as an instance of a process model
`by navigating through the PM-graph according to
`a well-defined set of rules.
`
`Process models as information resources
`Along with the classical production factors of
`land, labor, and capital, enterprises are consid-
`ering information more and more as an important
`resource, i.e., as one of their assets. ‘This infor-
`mation includes data about all resources needed
`to reach the goal of the enterprise. It is generally
`accepted that this
`information should be repre-
`sented in a formal manner as much as possible.
`‘The collection of actions needed to achieve this
`goal is referred to as “enterprise modeling.’’
`
`Enterprise models. The conceptual base for en-
`terprise modeling is sometimes called a hyper-
`semantic data model. 23 Producing the model of a
`concrete enterprise
`by using a hypersemantic
`data model results in an enterprise model. Such
`an enterprise model consists of two components:
`the data model and the knowledge model.23
`
`The data model describes the structure of all re-
`sources of the enterprise and is thus somewhat
`like the syntactical component of the enterprise
`model; in this sense, the data model describes
`what can be used by the enterprise to reach its
`goal. Today, enterprises are building data models
`based on semantic data models (for example, the
`entityhelationship model; for an overview of dif-
`ferent semantic data models see Peckham and
`MaryanskiZ4).
`
`The knowledge model describes the use of re-
`
`sources and their connections; it is the semantical
`component of the enterprise model. In this sense,
`the knowledge model describes how the enter-
`prise uses its resources in order to reach its goal.
`The knowledge model encompasses constraints,
`heuristics, and procedures. Constraints define the
`local and global consistency of the resources; if
`the resources are stored in a database, constraints
`fix the valid database states. Heuristics describe
`how to derive data. Procedures define events and
`correlated actions, set sequences of actions, and
`describe business processes. The model of a bus-
`iness process can be used to define, for example,
`valid sequences of state transitions in a database
`(intertransaction integrity7,8J1) as well as se-
`quences of work steps, whereas executing a bus-
`
`328 LEYMANN AND ALTENHUBER
`
`as context-
`
`could be described
`
`iness process
`dependent. ’’,’’
`Documents as process models. Process models
`represent knowledge about an enterprise. Usu-
`ally, this knowledge is found today in the format
`
`The knowledge model describes
`the use of resources and their
`connections.
`
`of textual processing instructions. The handling
`of each single business process according to these
`processing instructions then corresponds to a
`process, i.e., an instance of the process model as
`defined via the instructions.
`
`Process models in the format of textual process-
`ing instructions are very inflexible. Enterprises
`cannot react with sufficient speed to changes in
`their environment. Changes in the processing in-
`structions are communicated by distributing doc-
`uments, thus, the time to activate these changes
`is dependent on when the corresponding docu-
`ments arrive; in distributed organizations these
`documents will arrive at different points in time,
`resulting, in turn, in consistency problems. Sup-
`port for handling individual processes is only en-
`abled in a limited way via the textual processing
`instructions. Precise compliance with the instruc-
`tions cannot be enforced directly.
`
`Control programs as process models. Today, com-
`puter assistance for handling processes is achieved,
`for example, by programming the corresponding
`procedural instructions. Each single work step can
`be supportedvia ”generic programs” (i.e., via tools
`or service routines), via special applications (i.e.,
`via programs considering the individual needs of an
`enterprise), or simply via help texts (Le., via elec-
`tronically documented work instructions). A spe-
`cial control program determines the individual se-
`quence of work steps dependent on the concrete
`context of the individual business process. In this
`sense, the control program represents the formal-
`
`IBM SYSTEMS JOURNAL, VOL 33, NO 2, 1994
`
`Apple Inc. Exhibit 1037
`
`

`
`ized process model, and an instance of the control
`program corresponds to a concrete, individual pro-
`cess. But such control programs also do not allow
`
`A process model may be seen
`as a template for a class of
`similar business processes performed
`within an enterprise.
`
`for highly dynamic reactions. Changing the knowl-
`edge embedded in the control program involves a
`great deal of effort (redesign, coding, compiling,
`etc.).
`
`Separate representations for process models. For
`this reason, extracting the knowledge represent-
`ing the process from the control program and
`forming a separate representation of this knowl-
`edge as its own syntactical unit is extremely de-
`sirable. As a consequence, these syntactical
`units-which now represent the process model-
`have the flexibility and comprehensibility to in-
`stitute the required dynamics. A process inter-
`preter receiving such a process model as input
`(along with other information) can instantiate the
`process model and determine the individual se-
`quence of work steps, depending on the context
`of the instantiation of the process model.20
`
`Computer assistance for defining process models
`should be enabled via a
`language that provides
`constructs that can be embedded canonically in a
`dictionary A dictionary concept that strives for
`integrating data models and process models is
`pursued and thus contains all information re-
`sources. It follows the International organization
`for Standardization (KO) conceptualization prin-
`~ i p l e , ' ~ according to which as much knowledge
`about an application area as possible is moved
`from the programs to the dictionary of an enter-
`prise. Such a language then encompasses a model
`for process models, i.e., a metu-model for pro-
`cesses; instances of the meta model are process
`models. In turn, the instances of the process mod-
`els are the proper representations of process ex-
`ecutions. Meta-model and process model, and
`process model and process, respectively, are
`building intension-, extension-pairsZ6 that thus
`comply conce tually to the ISO Dictionary Archi-
`tecture IRDS. "The integration of process models
`into the IRDS together with the already available
`data modeling capabilities then allows very flex-
`ible enterprise modeling based on a dictionary.
`For that purpose one has to describe our meta-
`model in terms of the fundamental modeling lan-
`guage of the IRDS.
`
`FlowMark allows process models to be defined
`according to our meta-model described below.
`Each process model is an instance of the meta
`model. Process models are instantiated and exe-
`cuted by interpreting the instances of the types of
`the meta-model. The interpretation is performed
`by navigating through each individual instance
`(process) in accordance with the underlying pro-
`cess model.
`
`IRDS and process models. Process models de-
`scribe (apparently) different functions such as the
`production of a part in a production line, the set-
`tlement of a damage case within an insurance
`company, the treatment of a form for making al-
`lowances for expenses, the procedure
`in devel-
`oping a program, or valid sequences of transac-
`tions. In these situations, each
`individually
`executing process can be perceived as a separate
`
`
`
`instance of the process The process
`model is the processing instruction for a concrete
`process to be executed (and is thus a processing
`model). Computer assistance thus means both the
`support for defining the process model (modeling)
`and the support
`for performing each individuaI
`process (execution).
`
`The meta-model
`A process model may be seen as a template for a
`class of similar business processes performed
`within an enterprise. It is a schema describing all
`possible variants of the (dynamic!) execution of a
`particular kind of business process. Each individ-
`ual process is an instance of a process model, and
`it represents a concrete, specific execution of a
`variant prescribed by the process model.
`
`The fundamental building block of the meta-
`model is the activity. An activity represents a bus-
`iness action that is a semantical unit at a certain
`phase of modeling effort. It might have a fine-
`structure, which is then represented in turn via a
`
`IBM SYSTEMS JOURNAL, VOL 33, NO 2, 1994
`
`LEYMANN AND ALTENHUBER 329
`
`Apple Inc. Exhibit 1037
`
`

`
`process model, or the details of it might not be of
`interest at all from a modeling perspective. It is
`important to note that these fine-structures allow
`both a bottom-up
`and a top-down approach
`to
`process modeling.
`
`model for
`As an example, suppose a process
`credit allocation contains an activity called Sol-
`vency. For the modeler of credit allocation it is
`not of interest how Solvency is checked, but
`rather to make sure that this check will take place.
`The refinement of the activity Solvency as a pro-
`cess model again (if required) can be done (or may
`have already been done) by a different modeler.
`
`from sources different from its input container
`(e.g., database reads).
`
`As a result, it is pragmatic to recommend captur-
`ing an activity as a relation between its input con-
`tainer and its output container (for example, be-
`cause additional input as mentioned before might
`result in nondeterministic behavior of the activity
`with respect to its input container). In fact, choos-
`ing whether activities are “maps” instead of “re-
`lations” is not crucial to our meta-model, and the
`model could be easily made to accommodate a
`choice. Nevertheless, for simplicity we treat ac-
`tivities as maps because we consider this treat-
`ment to be more suited to the perception of pro-
`cess modelers.
`
`In general, the work represented by an activity
`produces results. Within the meta-model the
`types of results of this work are associated with
`the activity as parameter types. Now, activities
`generally access types of results of other activi-
`ties, or require information about the context of
`the current activity; such parameter types can
`also be associated with an activity. In general, an
`activity is associated with both input parameter
`types and output parameter types (in cases in
`which no misunderstanding will occur, the suffix
`“type” is omitted).
`
`The collection of all input parameters of an ac-
`tivity is referred to as the input container of that
`activity, and the collection of all of its output pa-
`rameters is referred to as the output container.
`Since process models may serve as fine-struc-
`tures of activities, each process model itself is
`associated with both an
`input container and an
`output container; note that the
`input or output
`container of a process provides some sort
`of
`“global context” for all activities contained
`within this process. A concrete execution of an
`activity (also called an activity instance) is thus
`accessing the instances of the input parameter
`types from its input container and will produce
`instances of the output parameter types from its
`output container. Because of this, activities are
`considered to be mathematical maps.
`
`In general, the activities of a process may not be
`executed in an arbitrary manner. Some activities
`are necessary for a process to start, some activ-
`ities might only be run when others are finished,
`and so on. In other words, the activities of a pro-
`cess form a network with arcs that point from a
`given activity to its successor activities. Since a
`process model has to reflect all possible valid ex-
`ecutions of a specific business procedure, each
`activity within a process model must be con-
`nected to all of its potential follow-on activities.
`A process model may be perceived as a directed
`graph having nodes that are the activities of the
`process and having edges that connect an activity
`with its potential successors. Since an edge rep-
`resents the potential control flow from one activ-
`ity to another, it is also referred to as a control
`connector.
`
`As an example, suppose the credit allocation pro-
`cess model contains the activities Solvency,
`Reject, Accept, BranchManagerApproval, and
`Notify. The potential follow-on activities of Sol-
`vency are Reject, Accept, and BranchManager-
`Approval. BranchManagerApproval has the po-
`tential successors Reject and Accept. The activ-
`ity Notify is the successor of both Reject and
`Accept.
`
`In practice, only the “process-relevant” param-
`eters of an activity are explicitly defined (i.e., ex-
`When a process model is executed (or instanti-
`ternalized) rather than all parameters affected by
`ated) it depends on the concrete situation
`in
`an execution of the activity. For example, an ac-
`which the process is run as to what subset of the
`tivity generally modifies data that are not defined
`set of all potential follow-on activities of a par-
`in its associated containers because these data are
`ticular activity is really executed once this par-
`not of interest to other activities within the pro-
`ticular activity is terminated successfully. A
`cess; or an activity might obtain (additional) input
`“concrete situation” is captured by the collection
`
`330 LEYMANN AND ALTENHUBER
`
`IBM SYSTEMS JOURNAL, VOL 33, NO 2, 1994
`
`Apple Inc. Exhibit 1037
`
`

`
`of all values actually associated with the param-
`eter types of the various containers of the model.
`
`The dynamics of subsetting potential follow-on
`activities are added to our meta-model by allow-
`ing Boolean functions to be associated with each
`edge that connects two activities; these Boolean
`functions are called flow conditions or transition
`conditions. Each of the Boolean functions has an
`input container associated with it, its parameter
`types stemming from the output containers of the
`predecessor activities or from the input container
`of the process model itself. Potential follow-on
`activities of a successfully terminated activity are
`considered for execution in the concrete situation
`
`only when they are reachable from the terminated
`activity via an edge having a flow condition that
`returns “true” based on the actual parameter val-
`ues in its container. By adding Boolean functions
`to the edges of the directed graph the perception
`of a process model within our meta-model is that
`of a weighted, directed graph.
`
`Activities are in general long running, and it must
`be permissible to interrupt them. Thus, when an
`activity terminates,
`it has not necessarily per-
`formed its task successfully. But only success-
`fully terminated activities are relevant when de-
`termining follow-on activities. To capture this
`situation, our meta-model permits assigning a
`Boolean function to each node in the graph which
`represents the exit condition or end condition of
`the activity. The Boolean function representing
`the exit condition of an activity again has an input
`container associated with
`it that has parameter
`types stemming from the containers of the activ-
`ities or from the container of the process model
`itself. An activity terminates “successfully” if its
`associated exit condition returns “true” based on
`the actual parameter values in its container. By
`adding Boolean functions to the nodes
`of the
`weighted, directed graph, the perception of a pro-
`cess model within our meta-model is that of a
`weighted, colored, directed graph.
`
`In general, activities within a process will be ex-
`ecuted in parallel. (This occurs when processing
`allowances for expenses, for example. After the
`activity CheckBill, both the payroll department
`as well as the bookkeeping department can work
`on the bill for expenses in parallel.)
`
`Parallel execution is enabled by a process model
`via an activity having outgoing edges weighted by
`
`Boolean functions that can be “true” concur-
`rently. After having terminated successfully,
`such an activity will function as a “fork.” The
`activities along the different branches can, in gen-
`eral, be worked on in parallel.
`
`An activity having more than one incoming edge
`can function as a “join.” For that purpose our
`meta-model associates a Boolean expression with
`each activity in the Boolean functions that weight
`the incoming edges of the respective activity; this
`expression is called a synchronization apres-
`sion. If the synchronization expression is the con-
`junction of all the Boolean functions weighting
`the incoming edges, the corresponding activity
`can only be executed
`if the Boolean functions
`have been evaluated and the Boolean expression
`in the returned values is “true.” An activity of the
`latter kind thus works as a “join.”
`
`If the Boolean function of an edge is evaluated as
`“false,” the endpoint of that edge might never
`become executable. The Boolean functions of the
`edges leaving a node that can never be executed
`functions. In the
`will never become evaluated
`case where the endpoint of an edge having a Bool-
`ean function that will never be evaluated is a “join
`node,” the corresponding process will never ter-
`minate.
`
`In order to avoid this situation, the “forward tran-
`sitive closure until joins” of the endpoint of an
`edge with a “false” Boolean function is com-
`puted. This means that
`all directed paths origi-
`nating at the subject node are traversed
`until a
`join node is reached. All Boolean functions of
`edges in this closure are considered as “evaluat-
`ed” with a return value
`of “false” (dead path
`elimination). In case all of the incoming edges of
`a join node reached during dead path elimination
`are already evaluated, its synchronization expres-
`sion is computed, and if it results in “false,” dead
`path elimination is performed for that join node.
`This is because the join node is never executed,
`thus leaving the process in doubt unless dead path
`elimination is not performed.
`
`When allowing parallel execution of activities, we
`must be sure that an executing activity does not
`generate results that will be produced by another
`executing activity or that were required as input
`by another executing activity (the Bemstein Cri-
`
`t e r i ~ n ~ ~ ) . Although there are different well-known
`
`techniques (e.g., “10cking”~~) to ensure the ful-
`
`IBM SYSTEMS JOURNAL, VOL 33, NO 2, 1994
`
`LEYMANN AND ALTENHUBER 331
`
`Apple Inc. Exhibit 1037
`
`

`
`fillment of this criterion on a per parameter value
`base, we pursue a more restrictive approach: The
`instances of the parameter types of an activity’s
`input and output container are treated as the local
`context of each particular activity.
`
`As a consequence, shared instances have to be
`defined explicitly. It is done when providing the
`process model by connecting a particular param-
`eter type of the output container of an activity
`with a particular parameter type of the input con-
`tainer of another activityvia a directed edge (datu
`connector). Data connectors are only allowed be-
`tween containers having activities that can be
`reached along a directed path; this ensures that an
`
`activity does not expect data as
`input when the
`data could not be produced by a preceding activ-
`ity.
`
`It is also allowed to define a data connector point-
`ing from the input container of the process to the
`input container of an activity as well as to define
`a data connector pointing from the output con-
`tainer of an activity to the output container of the
`process. Thus input can be passed to an instance
`of a process model once it is started and output
`can be passed from the process instance once it
`terminates.
`
`The implementation
`Currently, the FlowMark product is available to
`implement most of the meta-model described
`above; we will point out the few constructs that
`are not implemented in their generality. Built for
`the Operating System/2* (OW*) 2.1 environment,
`FlowMark is-with
`the exception of the anima-
`tion part written in Prolog-completely written in
`C+ + using object-oriented components and tech-
`nologies (like its underlying object-oriented data-
`base system) that only recently have become
`available.
`
`Definition. The build-time
`and Data Structure
`part allows a process modeler to define and main-
`tain all the information necessary for a FlowMark
`process to be executable. As the process is being
`defined, the animation facility lets the modeler
`examine the behavior of the model. After a pro-
`cess model is completed by its definer, it is trans-
`
`lated into a startable process also called a process
`template.
`
`Build time exploits the clienthewer structure
`of the underlying database for seamless access
`to the definitional objects of FlowMark. The com-
`munication layer is used by the definition com-
`ponents to exchange notification messages for up-
`dating their views on data in case of modifications.
`
`The run-time functions seen by the end user are
`Process Execution, Process List, Work List Han-
`dling, Local/Remote Program Execution, and
`Process API (application programming interface).
`
`The client parts (build time and run time) provide
`the graphical end-user interface to all of the Flow-
`Mark functions. The server parts of FlowMark
`control and synchronize access to the FlowMark
`data and moreover synchronize all work main-
`tained by FlowMark. Users can concurrently de-
`fine processes (to be more precise: “describe pro-
`cess models”) and store them in the database and
`at the same time execute an arbitrary number of
`ready-to-run processes. The number of processes
`and users is only constrained by the system re-
`sources available. The run-time server compo-
`nent of FlowMark is implemented as a hot pool.
`A hot pool in this context is a set of operating
`system processes each of which has the structure
`depicted in Figure 2. Each client request is dis-
`patched to an
`idle server process;
`if all server
`processes are busy, the request waits
`to be
`served. The number of server processes can be
`configured by the user.
`
`System structure. At the highest level, FlowMark
`essentially consists of two parts: build time and
`run time. The syntactical aspects
`of the meta-
`model are implemented in the build-time part, and
`its operational semantics are covered by the run-
`time part. Each of these parts is itself split into a
`client component and a server component.
`
`The functionality provided by build time (Figure
`1) comprises the blocks Animation, Process Def-
`initio