Workflow History Management in Virtual Enterprises using aLight-Weight Workflow Management System

Peter Muth, Jeanine Weissenfels, Michael Gillmann, Gerhard WeikumUniversity of the Saarland

E-mail: { muth,weissenfels,gillmann,weikum} @cs.uni-sb.de, http://www-dbs.cs.uni-sb.de

AbstractEnterprise-spanning workflows require workflow

management systems that can be tailored to specific ap-plication needs, as well as enhanced support forinteroperability between different workflow managementsystems. In virtual enterprises, the interoperability problemis not limited to workflow execution, but also entails facili-ties like worklist management and history management to beinteroperable.

We present a light-weight system architecture, consist-ing of a small system kernel on top of which extensions likehistory management and worklist management are imple-mented as workflows themselves. The functionality of thekernel such as distributed workflow execution andinteroperability interfaces is available for all extensions. Weshow the feasibility of our approach by presenting the imple-mentation of history management in our workflow specifica-tion language, based on state and activity charts, on top ofour light-weight kernel, coined Mentor-lite.

1 IntroductionToday, interoperability of workflow management sys-

tems is only addressed at the level of actual workflow execu-tions. Interoperability of other system components likeworklist management and history management is widely ig-nored. However, for many workflow applications in virtualenterprises it is mandatory that some or even all system com-ponents are available for enterprise spanning workflows. Animportant example is the management of workflow historydata, as discussed in this paper.

Consider a large mail order company which wants tofocus its activities on the core business of selling products.Activities like marketing and customer support should behandled by other companies. The marketing companyshould be notified about orders that come through the Inter-net in order to develop customer specific advertisementstrategies. When a customer asks for support on purchaseditems, he should be referred to a call center. The actual han-dling of the order in terms of shipping the ordered items andthe final billing should still be handled by the mail ordercompany.

This work was performed within the research project “Architecture,Configuration, and Administration of Large Workflow ManagementSystems” funded by the German Science Foundation (DFG).

In order to develop a customer specific advertisement,the history of a customer’s orders must be available. Basedon this history, the customer can be supplied with advertise-ment material according to his interest. In addition, the cus-tomer can even be notified about available updates or exten-sions of previously purchased items. For example, thismight be the case for a specific software he ordered or a newbook that complements a book he already purchased.

From the above scenario it is clear that history manage-ment plays an important role for the marketing company.The workflow management system in use must providepowerful history management facilities, being able to sup-ply the required history data even for complex advertise-ment strategies.

For the marketing company, it is sufficient to base itsadvertisement strategies on its own history data. Except forthe notification about new incoming orders, there is no needfor interoperability with the workflow management systemof the mail order company. However, this is not true for thecall center that provides customer support for the mail ordercompany. Assume that the charges for customer support de-pend on whether the purchased product is still under warran-ty and on an internal rating of customers according to thevalue of their overall purchases in the past. In order to imple-ment this in a workflow of the call center, the workflow hasto query the history of a customer’s orders in the workflowmanagement system of the mail order company. This re-quires interoperability between both systems at the level ofworkflow histories. Even more demanding, the serviceagents who handle calls in the call center might be selectedbased on customer data, e.g., a customer who has purchaseditems above a given total value should receive service by ex-perienced service agents only. In this case, the worklist man-ager of the workflow management system of the call centermust access data managed by the history manager of theworkflow management system of the mail order company.

In this paper we advocate a light-weight system kernelthat can be customized to the full spectrum of applicationsand interoperability requirements through appropriate ex-tensions. To retain the light-weight nature also for the ex-tended system as much as possible, we pursue an approachthat makes extensive use of the kernel functionality to im-plement the higher-level extensions. In particular, we arguethat workflow administration functionality like historymanagement should itself be implemented as a workflow.This novel technique distinguishes our approach from earli-

148O-7695-0119-2/99 $10.00 0 1999 IEEE

er proposals towards light-weight and adaptable architec-tures.

The history management component of Mentor-lite ba-sically consists of two components: a database system foractually storing the history data and a library of sub-work-flows handling the access to the history database. Mentor-lite uses state and activity charts as its workflow specifica-tion language. Hence, the history management sub-work-flows are specified as state and activity charts as well. Theyimplement means for aggregating history data duringworkflow execution and implement complex queries onthese data. For optimization purposes, however, the expres-sive power of the underlying database system should be ex-ploited as much as possible. History management sub-work-flows can easily be incorporated into existing workflowspecifications by using the state chart features of nestedstates and orthogonal components. Because Mentor-litesupports a distributed execution of workflows, workflowsextended by history management sub-workflows can also beexecuted in a distributed environment. This way, historymanagement is available even for enterprise spanningworkflows without extra effort. If a virtual enterprise usesdifferent workflow management systems including Mentor-lite, the history management of Mentor-lite is accessible byall systems which are able to interoperate with Mentor-lite atthe level of workflow specifications.

The rest of the paper is organized as follows. Section 2discusses related work. Section 3 presents the architecture ofMentor-lite. In Section 4, we give a brief introduction of ourworkflow specification language, state and activity charts.In Section 5, we discuss the design and implementation ofhistory management as an example for extending the Men-tor-lite kernel. Section 6 concludes the paper.

2 Related WorkIn general, the history manager implements a temporal

database. Inserts into this database are performed duringworkflow execution. Temporal queries are used to retrieveinformation from this database, both off-line for administra-tion purposes and on-line during workflow execution forcontrol flow decisions. Apparently, using a temporal data-base system for storing history data seems to be a good idea[36]. The most notable proposal for a temporal data modeland a query language based on the relational model isTSQL2 [30], other approaches as well as implementationtechniques are surveyed in [31] and [1 11. However, none ofthese proposals has been implemented in a practically viablesystem so far. In addition, there are requirements that are notyet provided by database systems at all, e.g., aggregatingdata depending on workflow execution.

The need for data aggregation has been realized espe-cially in the areas of data warehousing and online analyticalprocessing (OLAP) [6,27]. Projects in this area deal with thecollection and integration of information and with view ca-pabilities, especially materialized views, e.g. [15, 26, 411.

Providing temporal views over the history of source data is afairly new issue in this context [40]. All these approaches as-sume that all source data already exists when the collectionand the aggregation of information is initiated. For manag-ing the history of workflows, we rather need the dynamic ag-gregation of data during workflow execution, and we wouldoften store only aggregated data for space reasons and fastdata access. In general, we want to avoid having to deploy alarge-footprint data warehouse in conjunction with the op-erational workflow management system.

History management for workflow management sys-tems has received very little attention in the literature. [ 191describes the structure of a history database and the queryingof the history data. Unlike our approach, neither aggregatingdata during workflow execution nor adapting the historymanagement features to workflow application needs areconsidered.

Customizing workflow management systems to spe-cific workflow application needs has become an importantissue. However, most workflow management systems, bothproducts and research prototypes, are rather monolithic andaim at providing full fledged support for the widest possibleapplication spectrum [ 1, 8, 10, 12, 18, 341. On the otherhand, the idea of extensible and adaptable system architec-tures is not new. Extensible database systems have been in-vestigated in research and development for a decade, withmixed.success but wide agreement that this is the right archi-tectural paradigm [5]. A similar paradigm is being pursuedfor constructing highly adaptable, distributed middleware[2, 31. In the area of workflow management, however, theneed for extensible and adaptable architectures has not re-ceived much attention so far, with the most notable excep-tions being the MOBILE [17, 181, Meteor2 [20, 291, INCA[4], WASA [35] and WIDE [7] projects. Our specific ap-proach towards an extensible, light-weight system, namely,viewing major extension components as workflows them-selves, is, to the best of our knowledge, a novel idea.

3 Mentor-lite ArchitectureIn this section we present our approach to a light-

weight and tailorable workflow management system. It isbased on the Mentor workflow management system [22,23,38, 391, but aims at a simpler architecture. The main goal isto provide only kernel functionality inside the workflow en-gine, and consider system components like history manage-ment and worklist management as extensions on top of thekernel. The key point to retain the light-weight nature is thatthese extensions are implemented as workflows themselves.We have coined this approach Mentor-lite [2 1, 371.

As shown in Fig.1, the basic building block of Mentor-lite is an interpreter for workflow specifications. Two addi-tional components, the communication manager (ComMgr)and the log manager (Logkfgr), are closely integrated withthe workflow interpreter. All three components togetherform the workflow engine.

149

\ . , <Worklist Mgmt)

‘\\\H1stov Mgmt!, 0 ’

,

Workflow Engine 1, ’ ’ History Database

Workflow Interpreter

Workflow Logs

Figure 7: The Mentor-lite architecture

In Mentor-lite, workflow specifications are given interms of state and activity charts, the specification languagealready used in Mentor. The interpreter performs a stepwiseexecution of the workflow specification according to its for-mal semantics. For each step, the activities to be performedby the step are determined and started. In contrast to Mentor,which initially included a code-generation phase, specifica-tions in Mentor-lite are interpreted at runtime and can there-fore be dynamically modified.

The execution of a workflow instance can be distrib-uted over several workflow engines at different sites. Thecommunication manager is responsible for sending and re-ceiving synchronization messages between the engines.These messages contain information about locally raisedevents, updates of state chart variables and other state infor-mation of the local engine. When a synchronization messageis received, the corresponding updates at the receiving siteare performed [23]. In order to guarantee a consistent globalstate even in the presence of site or network faults, we cur-rently use the TP-Monitor Tuxedo [25, 321 for delivering thesynchronization messages within queued transactions. Inthe near future, we plan to substitute the Tuxedo facilities byOrbix [24] and the CORBA Object Transaction Services [9].

The log manager provides logging facilities andrecovery mechanisms. A separate workjlow log is used ateach site where a Mentor-lite workflow engine is running.Databases like the workflow specification or the worklist da-tabase can be shared by Mentor-lite workflow engines atdifferent sites. Application programs are connected to theworkflow engine by specific wrappers.

Application dependent facilities like history manage-ment, worklist management and monitoring are implement-ed on top of the engine as state and activity charts. Hence,they are interpreted by the workflow interpreter just like anyother workflow specification. This allows us to use the func-tionality of the Mentor-lite workflow engine through a

single interface, namely the state chart and activity chart in-terpreter. Section 5 presents the history management ofMentor-lite in detail.

4 Brief Review of State and Activity ChartsIn this section we briefly describe the formalism of

state and activity charts [13, 14, 161. This specification for-malism has been adopted for the behavioral dimension of theUML industry standard [33]. State and activity charts com-prise two dual views of a specification.

Activities reflect the functional decomposition of asystem and denote the “active” components of a specifica-tion; they correspond directly to the activities of a workflow.An activity chart specifies the data flow between activities,in the form of a directed graph with data items as arc annota-tions.

State charts capture the behavior of a system by speci-fying the control flow between activities. A state chart is es-sentially a finite state machine with a distinguished initialstate and transitions driven by Event-Condition-Actionrules (ECA rules). Each transition arc between states is an-notated with an ECA rule. A transition from state X to state I:annotated with an ECA rule of the form E[C]/A, fires ifevent E occurs and condition C holds. The effect is that stateX is left, state Y is entered, and action A is executed. Condi-tions and actions are expressed in terms of variables, for ex-ample, those that are specified for the data flow in the corre-sponding activity chart. In addition, an action A can explicit-ly start an activity, expressed by st!(activity), and can gener-ate an event E or set a condition C (e.g. fs!(C) sets the condi-tion C to false). Each of the three components of an E[C]/Atriple may be empty. Every state change in a state chart exe-cution is viewed as a single step; thus, state changes induce adiscrete time dimension.

Important additional features of state charts are nestedstates and orthogonal components. Nesting of states means

150

that a state can itself contain an entire state chart. The seman-tics is that upon entering the higher-level state, the initialstate of the embedded lower-level state chart is automatical-ly entered, and upon leaving the higher-level state all em-bedded lower-level states are left. The capability for nestingstates is especially useful for the refinement of specifica-tions during the design process and for inserting predefinedsub-workflows. Orthogonal components denote the parallelexecution of two state charts that are embedded in the samehigher-level state (where the entire state chart can be viewedas a single top-level state). Both components enter their ini-tial states simultaneously, and the transitions in the two com-ponents proceed in parallel, subject to the preconditions fora transition to fire. Fig. 2 shows the state chart of a creditprocessing workflow as an simple example.

Note, that,although state charts make use of ECA rules,they provide a substantially higher abstraction level thanstand-alone ECA rules as advocated in active database sys-tems; in particular, they support modular specifications.Therefor, unlike simple ECA rules alone, we consider statecharts as an appropriate means for specifying application-specific workflow-system extensions.

5 Mentor-lite History ManagementIn this section we will show the feasibility of our ap-

proach for implementing extensional functionality of theworkflow management system as workflows themselves.We will discuss history management as a detailed example.

In general, the task of history management is to effi-ciently implement a powerful temporal database. The tem-poral database should be able to answer queries on the histo-ry of workflows as well as on their projected future. Insertsinto this database are performed during workflow execu-tion. Temporal queries are used to retrieve information fromthis database, both off-line for administration purposes andon-line during workflow execution for control flow deci-sions. If multiple departments are involved in a workflow,the history management might even have to be decentral-ized. Instead of reimplementing all the necessary function-ality for distributed execution in the history manager, the

1 CREDIT-SC 1

1 .I. ID=_OKl :f-zz-l

Figure 2: State Chart ‘credit processing’

-

functionality of the Mentor-lite workflow engine can beused for providing access to the history management data-bases. Aggregation of history data at insert time as well as atquery time can be implemented by using state and activitycharts. This makes the history manager much easier to de-sign and to implement. In addition, the history manager, likeall components implemented on top of the engine, immedi-ately benefits from enhancements of the engine and the un-derlying middleware components, e.g., in terms ofscalability, availability and interoperability.

5.1 RequirementsThe workflow history can serve several purposes. It

can be used for simple monitoring of a single workflow, orfor complex decisions on improving business processesbased on histories of several workflows together. The histo-ry can also be used for time-dependent decisions in aworkflow such as sending a reminder when a bill has notbeen paid in time. We can distinguish between two basickinds of histories:

Histories of a single workflow instanceIf the history of a single workflow is considered, we can

further distinguish between information belonging to thepast of the workflow, its current state, and its projected fu-ture. Typical queries against the past are:l When has a given activity been completed, and what was

its outcome?l When has a given event occurred?l Which activities have already been completed?l How often has a given activity been executed inside of

the work$ow?Considering the current state of a workflow, typical queriesare:l Which activities are active and when have they been

started?l Is the workflow still on schedule?The projected future of a workflow is of interest if deadlinesare violated in case the progress of the workflow is too slow,or if resource schedules for system resources or even humanresources must be determined. Typical queries are:l When are the current activities due?l What is the expected due date of given future activities?l Can all deadlines still be met?l By how much will a given deadline be violated?The answers to these queries can either be used for puremonitoring purposes which will not affect the control flowof the current workflow, or for making decisions on futureactivities of the workflow, e.g., if deadlines have been vio-lated and solutions for compensating the resulting problemshave to be found.

Histories of multiple workflow instancesHistories of multiple workflows can be considered for

a single type of workflow or for multiple types. They are

151

W l d 1 AId IAType I lsrartActor I End I Deadline I . . .El7 1

El7 2

El7 3

El7 4

InsertOrder

CallCustomer

SendReminder

CallCustomer

Ed

Rita

Rita

Ricky

Jul-30, 10:00

Aug-2, 15:lO

Aug-2, 16:20

Sep-5, 10:00

Jul-30, lo:15

Aug-2, 16:20

Aug-2, 16122

Sep-5, 12:00

1

---

---

Aug-3 1

---

. . . I I II I I ITable 7: Activity history

used to improve the utilization of resources and even thewhole underlying business processes. Typical queries are:l Why is a given agent overloaded?l What is the average turnaround time of orders?l What is the average cost of an order (in person hours)?l Where are critical paths in workfzow executions?Queries against multiple workflows are usually not used toaffect the control flow of currently executed workflows.Instead, they serve to support medium or long term businessdecisions on assigning types of tasks to workflow actors oron modifying specifications of production workflows.Hence, they are typically much more complex than queriesagainst single workflows.

5.2 History Tracking

With state and activity charts used for workflow speci-fications, keeping the history of the workflow context in adatabase requires storing the following information:(1) States entered by the workflow(2) The contents of state chart variables(3) The occurrence of events(4) Start time and end time for the execution of activities,

including their input and their return parameters(5) Deadlines for activities(6) The actor who performed an activityGiven the above information, the execution of a workflowcan be fully reconstructed, including transitions that fired.

Table 1 shows an example for storing the history data ofactivities in a relational table. The table contains the identifi-er of the workflow which started the activity, an activityidentifier and type, the actor who performed the activity,start time and end time of the activity execution, and the ac-tivity deadline. Further attributes like input and output pa-rameter values are omitted for space reasons.

ActivityHistoryGiven the schema of Table 1, the first query above

“When has a given activity been completed?” can be ex-pressed in SQL as follows:

SELECT End FROM ActicityHistory WHERE WId = . . .AND AId = . . .

If a temporal database system were used, even complex tem-poral queries like “Which actor has pe$ormed more than IOactivities in different workjlows within 3 hours?” could easi-ly be expressed:

SELECTActor FROM Activities WHERE (Start, End)OVERLAPS MOVINGWINDOW (3 hours)

GROUP BYActor HAVING Count (Distinct WId) > 10The history data can be kept in a centralized database, or canbe distributed over the sites where the workflows are execut-ed. Even the replication of history data is possible, to de-crease access costs and to increase availability.

5.3 Integrating History Tracking into State andActivity Charts

In order to implement the approach sketched in Section5.2, we have to identify hooks where history tracking rou-tines are plugged into state and activity charts. Our goal is tospecify these hooks by means of state and activity charts,such that no additional code in the state and activity chart in-terpreter is necessary. A straightforward approach is to issueSQL statements by additional activities. For the most com-prehensive solution, i.e., storing the complete history data ofall workflows, this requires augmenting all transitions byhistory management activities. These activities have to storeinformation about the states entered by the correspondingtransition, events that caused the transition to fire, all statechart variables, etc., and can be automatically generatedwithout the help of the workflow designer.

Using this approach, we can keep track of the starttimes of all workflow activities. However, obtaining the endtime of an activity is a little bit more difficult. After an activi-ty is started, the execution of the state chart continues inde-pendently of the activity. If the state chart fires a transitionimmediately after the activity is finished, we can use thistransition to notify the history management about the end ofthe activity. Otherwise, we have to create such a transition aspart of the interface to the history management. It requiresthe activity to notify the state chart interpreter about its end.If the activity represents an external application program,the application wrapper, i.e., the interface between Mentor-lite and the application program, will have to set a corre-sponding state chart variable.

152

CustomerSupport_S

[Support_WANTED]/st!(CustomerSupport)- - - - - - - - - - - - - - - - - - - -[Deadline-CurrentTime<O

CurrentDate-HireDate<st!(DeadlineViolation)

[in(CustomerSupport_S)]/Deadline:=CurrentTime+l5 min

Figure 3: Keeping track of deadline violations

5.4 Dynamic Aggregation of History Data Dur-ing Workflow Execution

Storing all details of the execution of all workflows inthe history database will result in huge databases and longexecution times for queries against this database. Note thatwe want to avoid bundling the workflow management sys-tem with a full-fledged data warehouse. Instead, we want toretain a small system footprint and thus provide a viablesolution also for small companies that cannot afford an ad-ministrator staff for a complex system. We can solve thisproblem by performing aggregations of history data at exe-cution time of the workflow. If we know that some informa-tion will only be needed in aggregated form, or will not beneeded in the future at all, we can store selected and aggre-gated data. In this case, the size of the history data as well asthe execution times of queries against the history data will besubstantially reduced.

Selection and aggregation of history data at runtimecan be implemented in two ways. First, we can use facilitiesof the underlying database system such as triggers. Howev-er, this approach is limited as some aggregations may not beexpressible in the language of the database system, i.e., typi-cally SQL. Rather we may have to perform them outside ofthe database system, again making use of state and activitycharts.

The basic idea is to extend the given workflow specifi-cations in terms of state and activity charts by orthogonalstate chart components and the corresponding activities.The orthogonal components are executed in parallel to theoriginal workflow specification. In principle, history track-ing can also be implemented by creating new states andmodifying transitions in the original specification. Howev-er, with the implementation as orthogonal components, thehistory tracking is as modular as possible in that it does notaffect the readability and maintainability of the originalspecification. In the following, we discuss two examples forour mail order business scenario.

Example 1: Tracking Deadline ViolationsAssume that in our mail order business scenario, there

is an upper limit say 15 minutes for the time a customer in-quiry is allowed to be under consideration by an agent of thecall center, i.e., there are deadlines for the corresponding ac-tivity in the workflow. Instead of keeping track of all startand end times of all activities, we only want to store informa-tion about violations of deadlines in the history database. Inaddition, we are only interested in violations of deadlines ifthe corresponding activity was performed by a new agentwho was hired no longer than four weeks ago. Fig. 3 shows apart of the original workflow specification, which consistsof states Web-Order-S and CustomerSupport_S. When anorder has been placed by a customer over the Web, theworkflow reaches state WebOrder_S. If the customer asksfor human advice before proceeding, condition S u p -port-WANTED is set to true, activity CustomerSupport isstarted and state CustomerSupport_S is entered. When ac-tivity CustomerSupport is finished as indicated by conditionSupport_FlNISHED, state WebOrder_S is entered again.The state chart of Fig. NO TAG has already been extendedby an orthogonal component that tracks the violation of thedeadline for activity CustomerSupport. The orthogonalcomponent has three states, NotMonitoring_S, Monitor-ing-S, and DeadlineViolation_S. State NotMonitoring_S isentered initially. When the activity CustomerSupport isstarted, the corresponding state CustomerSupport_S is en-tered in the original workflow specification. In theorthogonal component, when condition in(CustomerSup-port-s) becomes true, the deadline is set and state Monitor-ing-S is entered. If, after 15 minutes, condition Deadline -CurrentTime < 0 becomes true and the agent performing theactivity has been hired only recently, indicated by conditionCurrentDate - HireDate < 4 weeks, state DeadlineViola-tion_Sis entered. Firing of the transition into state Deadline-Violation_S also causes activity DeadlineViolation to bestarted. This activity inserts information about the deadlineviolation and the responsible agent into the history database.

153

WO-OK1~-(iiGiZ-)~. . .RegisterOrder_S

_--------------------[in(RegisterOrder_S]/st!(... UPDATE CustomerCategory CC

SET CC.Amount = CC.Amount + OrderAmountWHERE CCCustomerID = CustomerID AND CC.CategoryID = OrderID . ..)

Figure 4: Maintaining advqtisement information

If condition Support_FINISHED becomes true, the stateNotMonitoring_S is entered again.

The variables CurrentTime and CurrentDate must beupdated each time the state chart interpreter is evaluatingwhether the corresponding transition has to fire. This can bedone by calling a function of the operating system or by im-plementing a clock inside the state chart interpreter.

Example 2: Maintaining Advertisement InformationAssume that the marketing company for the mail-order

business wants to maintain customer profiles in order tosend customer specific advertising information. Each cus-tomer should receive advertisements for products in threeproduct categories he is considered to be most interested in.In order to implement this, for each customer and each prod-uct category, the overall value of all purchases the customerhas made in the category is stored in the history database.This creates a ranking of categories for each customer.When advertisements for a new product are to be mailed,only customers having the corresponding product categoryranked in their say top three categories should receive theadvertisement material.

Fig. 4 shows a part of the original mail-order state chart,together with the extended version implementing the historytracking for advertisement purposes as sketched above. If, inthe original state chart, the transition between states We-border-S and RegisterOrder_S fires, i.e., conditionWO_OK becomes true, the history data must also be up-dated. In the orthogonal component, there are two statesHistOrderl_S and H&Order2S. State HistOrderl_S is en-tered initially. If condition in(RegisterOrder_S) becomestrue, state HistOrdeR_S is entered. In addition, the SQLstatement shown in Fig. NO TAG is executed, which adds thevalue of the currently ordered item to the total value of allproducts the customer has purchased from the mail orderbusiness in the category the orderd item belongs to (assum-ing for simplicity only one item per oder). Performing thisaggregation during the execution of the workflow instead ofstoring all values of all purchases of a customer has severalbenefits. It saves database space, it significantly decreasesthe complexity of future queries to determine whether a cus-tomer qualifies for a specific advertisement, and it providesa faster response time of these queries.

5.5 Aggregation by QueriesFinal aggregations of history data will be performed by

queries against the history data. In terms of our advertise-ment example, this requires to determine the three topmostcategories for each customer. The most efficient way is tocompletely code the query in the query language of the data-base system that stores the history data as this allows ex-ploiting query optimizations by the database system. Forcomplex aggregations that exceed the capabilities of stan-dard database systems, final aggregations of the results ofmultiple queries can be computed in programs or can be spe-cified in terms of state and activity charts. This is also re-quired in our example, as a query delivering the three top-most categories of a customer can not be expressed in stan-dard SQL. Unless the database system used for maintainingthe history data already supports special SQL extensions asimplemented in OLAP environments, we can either use em-bedded SQL or a simple state chart. The state chart approachhas to be used anyway if history data is stored across differ-ent databases, or if it is maintained by different workflowmanagement systems. In this case, providinginteroperability at the level of workflow specifications pro-vides interoperability also with regard to history manage-ment, an important advantage of our approach.

6 ConclusionsIn this paper, we have presented an approach for imple-

menting workflow administration functionality on top of alight-weight system kernel. We argue that such extensions tothe kernel should themselves be implemented as workflows.In Mentor-lite, we use state and activity charts as a specifica-tion language that we consider as particularly suitable forspecifying application-specific workflow-system exten-sions. However, the approach can, in principle, be carriedover to workflow management systems using other specifi-cation languages or even to heterogenous collections ofworkflow engines that support some form of interchangeformat for workflow specification and state information.

Our approach is particularly suited for enterprise span-ning workflows. Interoperability of administration compo-nents like history management and worklist managementbecomes a matter of interoperability at the level ofworkflows themselves. In addition, due to the light-weight

154

design of our system kernel, the system footprint can be keptas small as possible. Functionality implemented in the ker-nel is automatically available to all extensions, e.g., distrib-uted execution, reliable and fault tolerant execution, and en-cryption.

7 References[l] G. Alonso, D. Agrawal, A. El Abbadi, C. Mohan, Function-ality and Limitations of Current Workflow Management Systems,IEEE Expert, Vol. 12, No. 5, 1997[2] G. Alonso, C. Hagen, Geo-Opera: Workflow Concepts forSpatial Processes, in: M. Scholl, A. Voisard (ed.): Advances inSpatial Databases, 5th International Symposium, LNCS, Vol.1262, Springer, 1997[3] G. Alonso, C. Hagen, H. J. Schek, M. Tresch, Towards a Plat-form for Distributed Application Development, in [lo][4] D. Barbara, S. Mehrotra, M. Rusinkiewicz, INCAS: Manag-ing Dynamic Workflows in Distributed Environments, Journal ofDatabase Management, Special Issue on Multidatabases, Vol. 7,No. 1,1996[S] M. J. Carey, D. J. Dewitt, Of Objects and Databases: A De-cade of Turmoil, Proc. VLDB Conference, 1996[6] S. Chaudhuri, U. Dayal, An Overview of Data Warehousingand OLAP Technology, ACM SIGMOD Record Vol. 26, No. 1,1997[7] S. Ceri, P. Grefen, G. Sanchez, WIDE - A Distributed Archi-tecture for Workflow Management, Proc. of Int’l Workshop on Re-search Issues in Data Engineering (RIDE), 1997[8] A. Cichocki, A. Helal, M. Rusinkiewicz, D. Woelk, Work-flow and Process Automation - Concepts and Technology, KluwerAcademic Publishers, 1998[9] CORBA Services,http://www.omg.org/corba/csindx.htm[lo] A. Dogac, L. Kalinichenko, M. Tamer Ozsu, A. Sheth (Eds.),Workflow Management Systems and Interoperability, Springer,1998[ll] 0. Etzion, S. Jajodia, S. M. Sripada (Eds.): Temporal Data-bases: Research and Practice, LNCS Vol. 1399, Springer, 1998[12] D. Georgakopoulos, M. Homick, A. Sheth, An Overview ofWorkflow Management: From Process Modeling to WorkflowAutomation Infrastructure, Distributed and Parallel Databases,Vol. 3, No. 2, 1995[13] D. Harel, State Charts: A Visual Formalism for ComplexSystems, Science of Computer Programming Vol.8, 1987[14] D. Hare1 et. al, Statemate: A Working Environment for theDevelopment of Complex Reactive Systems, IEEE Transactionson Software Engineering Vol. 16, No. 4, 1990[15] J. Hammer, H. Garcia-Molina, J. Widom, W. Labio, Y.Zhuge, The Stanford Data Warehousing Project, IEEE Data Engi-neering Bulletin, Vol. 18, No. 2, 1995[16] D. Harel, A. Naamad. The STATEMATE Semantics of StateCharts, Technical Report, i-Logix Inc., 1995[17] S. Jablonski, MOBILE: A Modular Workflow Model andArchitecture, Proc. of Int’l Working Conference on DynamicModelling and Information Systems, Nordwijkerhout, 1994[18] S. Jablonski, C. Bussler, Workflow Management, ModelingConcepts, Architecture, and Implementation, International Thom-son Computer Press, 1996[19] I? Koksal, S.N. Arpinar, A. Dogac, Workflow History Man-agement, SIGMOD Record, Vol. 27, No. 1, 1998

[20] J. A. Miller, D. Palaniswami, A. l? Sheth, K. Kochut, H.Singh: WebWork: METEOR2.s Web-Based Workflow Manage-ment System. Journal of Intelligent Information Systems, Vol. 10,No. 2,1998[21] P. Muth, J. Weissenfels, M. Gillmann, G. Weikum, Integrat-ing Light-Weight Workflow Management Systems within Exist-ing Business Environments, Proc. of Int’l Conf. on Data Engineer-ing (ICDE), Sydney, Australia, 1999[22] l? Muth, D. Wodtke, J. Weissenfels, G. Weikum, A. Kotz Dit-trich, Enterprise-wide Workflow Management based on State andActivity Charts, in [lo][23] P Muth, D. Wodtke, J. Weissenfels, A. Kotz Dittrich, G.Weikum, From Centralized Workflow Specification to DistributedWorkflow Execution, Journal of Intelligent Information Systems -Special Issue on Workflow Managament, Vol. 10, No. 2, 1998[24] Manuals of Orbix 2.2, IONA Technologies PLC, 1997[25] F. Primatesta, TUXEDO, An Open Approach to OLTP Pren-tice Hall, 1994[26] N. Roussopoulos, CM. Chen, S. Kelley, The ADMS Project:Views “R” Us, IEEE Data Engineering Bulletin, Vol. 18, No. 2,1995[27] D. Schneider, The Ins and Outs (and everything in between)of Data Warehousing, Tutorials VLDB Conference, 1997[28] A. Sheth (ed.), Proc. NSF Workshop on Workflow and Pro-cess Automation in Information Systems, Athens, GA., May 1996,http://lsdis.cs.uga.edu/activities/NSF-workflow/proc_cover.html[29] A. Sheth, K. J. Kochut, Workflow Applications to ResearchAgenda: Scalable and Dynamic Work Coordination and Collabo-ration Systems, in [lo][30] R. T. Snodgrass (Ed.): The TSQL2 Temporal Query Lan-guage, Kluwer, 1995[31] Tansel, U. Z., Clifford, J., Gadia, S. K., Jajodia, S., Segev, A.,Snodgrass, R. T. (Eds.): Temporal Databases: Theory, Design, andImplementation, Benjamin/Cummings, 1993[32] Tuxedo System 5, System Documentation, Novell, 1994[33] Unified Modeling Language (UML) Version 1 .I,http://www.rational.com/uml/documentation.html[34] G. Vossen (ed.), J. Becker (ed.), Busines Process Modellingand Workflow Managment, Models, Methods, and Tools (in Ger-man), International Thomson Publishing, 1996[35] G. Vossen, M. Weske, The WASA Approach to WorkflowManagement for Scientific Applications, in [lo][36] G. Weikum, Workflow Monitoring: Queries On Logs orTemporal Databases?, Position Paper, High Performance Transac-tion Systems (HPTS) Workshop, Asilomar, California, 1995[37] J. Weissenfels, P. Muth, G. Weikum, Flexible Worklist Man-agement in a Light-Weight Workflow Management System, Proc.EDBT Workshop on Workflow Management Systems, 1998[38] J. WeiBenfels, D. Wodtke, G. Weikum, A. Kotz Dittrich, TheMENTOR Architecture for Enterprise-wide Workflow Manage-ment. In: [28][39] D. Wodtke, J. WeiBenfels, G. Weikum, A. Kotz Dittrich, TheMENTOR Project: Steps Towards Enterprise-Wide WorkflowManagement, Proc. of ICDE, 1996[40] J.Yang, J. Widom, Maintaining Temporal Views Over Non-temporal Information Sources fot Data Warehousing, Proc. ofEDBT Conference, 1998[41] G. Zhou, R. Hull, R. King, J-C. Franchitti, Supporting DataIntegration and Warehousing Using H20, IEEE Data EngineeringBulletin, Vol. 18, No. 2, 1995

155