GB2460730A - Distributed workflow management system - Google Patents

Abstract

Management of a workflow in a distributed computer environment comprising multiple interconnected sites (1A, 1B, 1C). Business process definitions implemented in the workflow system comprise a number of workflow objects, including activities which are to be processed sequentially or in parallel. Each workflow object (OBJ4) is associated to exactly one site (1A), the so called "owner site" (1A). Each owner site (1A) updates and/or modifies only the workflow objects (OBJ4) it owns. Ownership workflow objects (OBJ4) may be transferred of another site (1B, 1C) on request ("pull") or when said owner site (1A) determines a need for transfer to another site (1B, 1C) ("push"). All sites (1A - 1C) maintain information on which site (1A - 1C) currently owns which workflow object (OBJ1 -OBJ4). Transfers between sites may therefore be updated synchronously, whilst other sites are updated asynchronously. Workloads may be balanced using an algorithm and other sites may have read access.

Description

DESCRIPTION

WORXFLOW MANAGEMENT SYSTEM AND WORX FLOW MANAGEMENT METHOD

FIELD OF THE INVENTION

The invention relates generally to systems for automatic business process execution in a distributed computing environment. Specifically, the invention relates to methods and systems for managing workf lows with automatic or human activities (human tasks) in a computer environment comprising multiple interconnected sites on an enterprise-wide scale.

BACKGROUND OF THE INVENTION

Workf low Management Systems support the definition and execution of business processes. A business processes definition usually consists of a set of activities that can be processed either automatically or by a human being. Depending on the business process definition, these activities can be performed sequentially or in parallel. Both automated and human activities may be added to an existing workf low definition to address ad-hoc requirements after deployment.

Workf low management systems have to satisfy requirements of scalability, high availability and disaster recovery. Most of these requirements can be addressed using established techniques, such as clustering and data replication.

Previously known workf low management systems have been successful in automating business process management for enterprises located at a single geographic site or area.

However, these workf low systems are usually not scalable from a system that serves a single site to a system that serves an enterprise spanning multiple geographically separate sites, for example in America, Europe, Asia and Australia. Effective distribution of activities in a workf low management system spanning multiple sites requires employees in all sites to be able to access data in the workf low management system in the same way and operate on any data. This implies that the system is set up in such a way that requests (for business processes and human tasks) can be served by multiple data centers located at different sites. This is called an 1active/active" configuration (in contrast to an!Jactjv/afljyPI configuration in which the corresponding counterpart in another data center is down during normal operations and only receives requests in case of a failover).

With an active/active configuration, clients connecting to both data centers must be able to access the same data. This is typically achieved by a synchronous data replication between both sites. i asynchronous approach typically introduces latency that can cause inconsistencies in the Workf low Management System due to replication conflicts. This limits an active/active configuration to systems where different data centers are geographically close enough to run synchronous data replication, typically closer than some 10 km/miles. If sites within the workf low system are far apart, however, the large distance between the sites does not allow for an active/active configuration.

US 6,338,074 describes a workf low management system for managing document processing in a distributed computing environment with multiple geographically distributed sites. This workf low system is designed in such a way that it may be partitioned into multiple self-contained work flows. Each work flow may advertise certain services for export to other work flows. The workf low system provides partitioned work queues for distributing data objects and work items to workf lows located on networks at remote sites. However, due to the work queue concept, US 6,338,074 does not address the problem of globally available data. All data related to human tasks and activities reside within one work queue at a particular site. As a Consequence, if that particular site shuts down or experiences a failure, the human tasks arid activities presently being processed at this site are not available any more, and data residing at this site may be irretrievably lost.

In view of the foregoing, it is desirable to provide a workf low management system that may be scaled up from a single site to a multi-site system, distributing work across sites arid which minimizes the danger of data loss in the case of a defect or a disconnection of a remote site.

STJMARY OF THE INVENTION

It is an objective of the invention to provide a system and an architecture f or a geographically distributed workf low system where distant sites can access and operate on a shared set of data in a controlled and efficient way.

These objectives are achieved by the features of the independent claims. The other claims and the specification disclose advantageous embodiments of the invention.

According to a first aspect of the invention, a method f or managing a workf low system with multiple interconnected sites is provided. Each workf low object to be processed within the workf low system is associated to a specific owner site in such a way that (1) said workflow object is assigned to exactly one owner site, (2) each owner site updates and/or modifies only the workf low objects it owns, (3) ownership of the workf low object can be transferred of another site on request ("pull") or when the owner site determines a need for transfer to another site ("push"), and (4) all sites maintain information on which site currently owns which workf low object.

According to a second aspect of the invention, a site in a distributed computer environment with multiple interconnected sites is provided. The site comprises (1) a workflow data store for storing data pertaining to workf low objects of a workf low system, (2) a workf low directory table containing information on which site currently owns which.workf low object, (3) means for modifying the workf low objects currently owned by the site, (4) means for transferring ownership of a workf low object to another site, and (5) means for requesting workf low objects currently owned by another site.

BRIEF DESCRIPTION OF THE DRAWINGS

The present invention together with the above-mentioned and other objects and advantages may best be understood from the following detailed description of the embodiments, but not restricted to the embodiments, wherein is shown ifl: FIG. 1 an exemplary local area network (LAN) suitable for use as a component of a workf low system constructed in accordance with the invention; FIG. 2 an example of a business process definition of an insurance claim process containing a number of human and automated activities; FIG. 3 a schematic of a distributed workf low system with three sites, each of the sites being equipped with a local area network of the type depicted in FIG. 1; FIG. 4 a computer system implementation of the invention.

In the drawings, like elements are referred to with equal reference numerals. The drawings are merely schematic representations, not intended to portray specific parameters of the invention. Moreover, the drawings are intended to depict only typical embodiments of the invention and therefore should not be considered as limiting the scope of the invention.

DETAILED DESCRIPTION OF EXAMPLE EMBODIMENTS

A workflow system of a site 1 (such as an office, building, etc.) typically comprises a LAN, such as the LAN 10 schematically shown in FIG. 1, and software that controls the flow of information through the LAN. LAN 10 comprises workstations 12 and a server 14. Cable 16, which may be coaxial cable, connects workstations 12 and server 14 to each other and provides a means for workstation 12 and server 14 to communicate with each other.

As used herein, the term "workf low system" denotes a combination of hardware and software that makes up a system to automate business processes. Each instantiation of the business process is processed by the system according to instruction sheets that specify the sequence of steps in the process. The term "workf low" refers to the run-time software components and data that control the flow of information through the underlying distributed processing system.

A business process comprises a number of activities which are processed in a well-defined order. These activities are connected using so-called links which may have conditions attached to them. As an example, FIG. 2 shows a flow diagram of a business process definition of an automobile collision insurance claim process 100. whenever an insurance claim (comprising a claim form, an adjuster report as well as supplementary material such as police reports etc.) is submitted by an insurant, an instantiation of process 100 is started (step 101) . After retrieving the insurant's policy (step 102), information pertaining to the collision/damage is collected, validated and adjusted (step 103); the material thus assembled will contain the claim form, an adjuster report and potentially additional information such as police reports, bills, records, photographs, etc. Once all information has been collected, edited and validated, processing of the claim is started (step 104). If the amount of the claim is below a threshold value (step 105), the claim is reviewed directly in step 106.

Otherwise, a verification step 107 is carried out in order to exclude fraud. This fraud history check 107 is typically implemented by calling upon an external service which will access data bases in order to furnish information on whether the claimant or other persons involved are known as fraudulent.

Subsequently, the claim is reviewed in step 108. Depending on whether the claim is approved (step 109), the claimant will be notified of the acceptance of the claim and reimbursed (step 110) or notified of the rejection (step 111).

Some of the steps of process 100 contain activities requiring human intervention, so-called human tasks. An example of such a human task is the validation and adjustment of claim forms (step 103) which is to be administered by the employees within an AdjustersGroup. Another example of a human task is the claim review (steps 106, 108) which is to be performed by employees within an UnderwritersGroup. Process 100 also contains automatic activities such as the Fraud Check 107 in which a (potentially external) service is accessed; this activity does not require human intervention by the enterprise's employees. In the framework of this description, the term "human task" denotes special activities in a business process which are processed by human beings. The term "workf low object" denotes an entity that a workf low engine uses to execute a business process (such as a process instance object, an activity object, a variable object etc.) The workf low system includes run-time information about all process instantiations which are currently active; the system also records the progress of each instantiation as it is processed by the various human tasks and activities. This information is stored in configuration data structures which are updated whenever new instantiations are created or when old ones are destroyed. Moreover, the workf low system comprises a run-time engine responsible f or creating process instantiations, monitoring and updating their status as they are serviced, executing process models and dispatching instantiations accordingly. The run-time engine also monitors completion of the steps of the business procedures and destroys an instantiation when it is no longer needed.

A process instantiation typically includes a nuxniDer of data fields that hold various information about the specific instantiation and the data associated with it. For example, an instantiation of a claim application in the insurance business process 100 may include data fields representing the insurant's name, details of the accident, police reports including photographs, damage estimates as well as information on whether the claim has been approved. Typically, the values of the data fields are provided by the originator of the specific process instantiation and may be supplemented as the claim application is being processed. All data and information pertaining to workf low objects which are currently active in the workf low system are stored in a workflow data store 18; this is schematically illustrated in FIG. 1 by bullets indicating active workf low objects OBJ1 and OBJ2. The workf low objects OBJ1, 03J2 may belong to the same instantiation or to different instantiatjons of process 100; thus, OBJ1 may represent a validation activity 103 in the process instantiation (claim application) "Car accident on May 3rd, 2008, damaging vehicle owned by Mr. Miller of Milwaukee", whereas 03J2 may represent a claim review 108 in the process instantiation "Hail damage inflicted on automobile owned by Mr. Smith of New York on February 23, 2008". Note that while FIG. 1 depicts the workflow data store 18 as represented by a separate entity, workf low data store 18 will typically reside in server 14 of site 1. For each instantiation of process 100, a set of workflow objects OBJ1, OBJ2 are generated (successively or in parallel), following the business process definition. For those workf low objects OBJ1, OBJ2 representing human tasks, lists of workf low waiting to be processed are generated and presented to users accessing the system through workstations 12. As a user selects a specific workf low object OBJ1 for processing, this workf low object OBJ1 will be marked as "claimed" and will not be available to other users any more. In order for the user to conduct activity OBJ1, all data related to this activity OBJ1 are copied to the user's workstation 12 where the operation is to take place; the revised data pertaining to the workf low objects OBJ1 will then be copied back to the data store 18 upon completion of the processing step. Alternatively, only selected variables needed to process a workf low object OBJ1 may be extracted from the data associated with the specific instantiation and provided to the workstation 12, with updated variables and the results of the processing human task being copied back to the data store 18 upon completion.

A workf low system such as the one described becomes unmanageable once is exceeds a certain size or if it has to span several sites of an enterprise. In this case, it is desirable to divide the enterprise workf low system into multiple cooperative workf low systems, so that separate workf low systems are implemented for different departments or sites of the enterprise. Such a division of a large workf low system into several cooperating workf low systems has to address conflicting interests: On the one hand, in order to ensure logical integrity, each individual workf low system should be self-contained in order to assure logical integrity. On the other hand, an exchange between the individual workf low systems should permit accessing workf low objects currently active in another In order to solve this conflict, a workf low system comprising multiple sites is proposed which makes use of conceptual locking as well as logical ownership of workf low objects by a given site. These concepts are explained in conjunction with FIG. 3 which depicts an enterprise's workf low system comprising three sites 1A, lB and 1C. Each site 1A, 1B, 1C contains a LAN 1OA, lOB, 1OC of the kind depicted in FIG. 1, the LAN connecting a server 14 and several workstations 12. Sites 1A, 1B, 1C can be located in geographically distributed regions, such as, for example, in North America, Europe and India. Sites 1A, lB and 1C are connected to each other via a network connection 17 such as Intranet or Internet. Each site 1A, 13, 1C of the geographically distributed workf low management system maintains its own data store 18A, 183, 18C capable of storing data related to all active instantiations of business process 100. Moreover, each site 1A, 13, lC runs a local version of the workf low management system containing the business process definition 100 with its various activities (workf low objects). The workf low management system is configured in such a way that each site 1A, 13, 1C has information about the other geographically distributed components of the system.

The workflow system of FIG. 3 contains four workf low objects OBJ1 -OBJ4 which are active, i.e. which are presently in the course of being processed. According to the invention, each workflow object is owned by exactly one site. In this context, a site "owning" a workf low object means -that the owner site is responsible for keeping the most current version of the data related to the workflow object in its data store; -10 - -that only the owner site is permitted to make modifications to the data related to the workf low object, and -that only the owner is allowed to update data related to the workf low object in the course of a workf low transaction.

Since only the owner site may make changes to the data related to the workf low object, the object is "locked" with respect to all other sites. Thus, the owner site is in fact a "lock owner site". Advantageously, the owner site provides a copy of all data pertaining to its activity for read access for other sites.

Thus, employees at other sites can observe the progress of workf low objects being processed at the owner site.

The workf low system shown in FIG. 3 is thus an extension of the single-site approach workf low system of FIG. 1 where one site 1 has ownership of all workf low objects OBJ1, OBJ2 in the workf low management system.

Ownership of a workf low object may be transferred from the owner site to a new site; in that case, as the workf low object is being transferred to a new (target) site, the previous owner site maintains information on the target owner site. A so-called directory 20 keeps track of all currently active workf low objects currently as well as the site 1A, lB. lC that currently owns that object. The term "active workf low object" refers to all workf low objects belonging to any process that is not yet in an end state and therefore is subject to modification. In the workf low system of FIG. 3, workf low objects OBJl and OBJ3 are owned by site lB whereas workf low object OBJ2 is owned by site ic and OBJ4 is owned by site 1A. Workf low object ownership of a site 1A, 1B, 1C is indicated in FIG. 3 by a solid bullet in the corresponding site's data store l8A, 18B and l8C, whereas active workf low objects owned by other sites are indicated by a dashed bullet. Referring to the specific example of the insurance claim process 100 depicted in FIG. 2, workf low objects OBJ1 and 03J3 may denote data validation activities 103; since these -11 -activities 103 are typically costly in terms of labor, these activities 103 may be presently performed by an AdjustersGroup located at a site 13 in India. Workf low object 03J2 may denote a claim reviewing process 108 which is carried out by specialists of an UnderwritersGroup situated at a site 1C in Europe.

Workf low object OBJ4 may denote a Fraud Check human task 107 which accesses a service located in the US, so that OBJ4 may be presently assigned to site lA situated in North America.

Replicas 20A, 203 and 20C of the directory are stored in the data stores 18A, l8B, l8C of each site 1A, 13, 1C. Contents of the data stores iSA, 183, lSC are asynchronously replicated between the sites 1A, 13, iC using established techniques and protocols. Note that most database vendors offer such replication, e.g. Q-replication which can be used in conjunction with IBM DB2 UDB. Asynchronous replication of data stores 18A, 183, 18C typically happens based on time stamps. The latest update will overwrite any previous versions of the workf low object. Due to network latency, some sites might still have older versions of workf low objects in their local data store.

Asynchronous replication of data objects owned by other sites is indicated in FIG. 3 by dashed bullets, and by a prime () attached to the names of workf low objects that are not owned by the respective site. As an example, workf low objects OBJ1, OBJ3 in data store 183 of site lB are displayed by solid bullets, indicating that these workf low objects OBJ1, OBJ3 are owned by site 13 and thus all data pertaining to OBJ1, 03J3 are up-to-date; workf low objects OBJ2', OBJ4' in data store 183 of site lB are displayed by dashed bullets, indicating that these workf low objects are owned by other sites and thus the data of 03J2', 03J4' stored at site 13 may presently be outdated.

As a new workf low object is created, it is immediately assigned to a site which will act as the workf low object's owner site. A variety of strategies for initial ownership assignment may be chosen: -For example, initial ownership may be based on staff assignment: if, in a business process, a human task to be executed on a workf low object is assigned to someone located at a specific site, ownership of the workf low object requiring this human task may be initially assigned to this site. Thus, workf low objects OBJ1, OBJ3 representing instantiations of validation human task 103 are initially assigned to site lB in India since the AdjustersGroup specialized in claim validation is situated at site lB.

-Alternatively, initial ownership may be based on locality of services or backend systems: if a service is to be invoked in the context of a business process, and if this service or backend system is located at a specific site, the workflos object may be assigned to this site for execution.

Accordingly, workf low object OBJ4 representing an instantiation of Fraud Check human task 107 is initially assigned to site 1A in North America, thus enabling fast access to a US fraud history data base.

-An additional aspect is workload balancing: In a globally distributed team, workf low objects requiring certain human tasks and processes may be pushed to sites according to a -Moreover, time zone optimization may play a role: in a globally distributed service organization, workf low objects may be automatically pushed to sites that are currently working and thus capable providing the human tasks and processes required.

-Finally, business data I language may play a role, so that workf low objects may be pushed to a certain site e.g. based on the languages that a customer requesting a given service understands.

-13 -Original assignment of workf low object to a given site anticipates locking the object to this site. Locking and ownership transfer can be triggered either by "push" or by "pull" semantics and can take place at any time.

Assume now that a new incoming service request arrives at site 1A in North America; this could be a request submitted by an internal or an external user or by another system accessing the workf low management system. Assume furthermore that in the course of processing this request, an existing and active workf low object OBJ1 needs to be updated by the workf low engine.

According to the site 1A directory 20A, workf low object OBJ1 is currently owned by site lB. Thus, site lA sends a synchronous request to site lB, informing site lB that site 1A plans to update workf low object OBJ1. This is called a "pull" request. As a result, ownership and data of OBJ1 will be transferred from site lB to site lA, and directories 20A, 20B, 20C will be updated accordingly. Note that while directories 20A, 20B of sites 1A and lB have to be updated synchronously, directory 20C of site lC may be updated asynchronously. Once workf low object OBJ1 has been transferred from site lB to site lA, OBJJ. is owned by site lA, thus assuring that site 1A will work on the most recent data in the course of the local workf low management transaction. These synchronous requests may be implemented using protocols such as two-phase commit (2PC) or Web Services Business Activity (WS-BA) coordination, and may include more complex interaction patterns, even provide a "pseudo synchronous" communication via an underlying asynchronous communication. In any case, the request placed at site 1A is blocked until object OBJ1 has been transferred from site lB to site 1A.

Assume now that during processing of workf low object OBJ1 at site lA, a new workf low object OBJ5 is generated at this site; assume moreover that the people resolution for workf low object -14 -OBJ5 results in a group or a set of users that are located at site ic. Implementing one of the strategies of how to assign ownership outlined above, the workf low management system may decide that site lC should initially get ownership of workf low object OBJ5. All data and information concerning workf low object OBJ5 is asynchronously replicated to sites lB and 1C, and there is an asynchronous directory "push" for ownership of workf low object OBJ5 to site 1C. After the replication has been completed, users at site 1C may access the workf low management system and work on workf low object 0BJ5 without any further cross-site communication.

A workf low management system with distributed sites lA, 1B, 1C implementing the ownership concept outlined above allows for an active/active configuration using asynchronous replication techniques. Enterprise workf low management systems using this concept will be able to -logically connect workf low applications running on. multiple sites lA, lB, ic, -allow transparent access to workf low objects OBJ1 -OBJ4, regardless from which site 1A, lB, lC users access the system and -avoid replication conflicts caused by concurrent updates to shared workf low objects.

Note that -in contrast to the workf low management outlined in US 6,338,074 -the present invention proposes a distributed workflow system in which multiple sites lA, 1B, 1C are able to communicate with each other without the need of a "master" server or a "master" copy; this is a self-organizing network of workf low object processing sites. Since copies of the workf low object data are stored at each site, these data are globally available, so that a user at site 1A can access workf low objects (activities) presently being performed at site lB at any time.

Moreover, a monitoring/reporting/administration procedure is -15 -location independent, and no complex visiting pattern needs to be introduced to manage remote queues.

The invention is particularly useful for environments with a high affinity of workflow objects to sites, i.e. for environments in which certain activities in a process can be allocated to a certain site based on workf low definitions and characteristics, since read-write operations with an affinity to the owner site take place at a low cost. Note that the locking of workf low objects does not require a predefined "master" site for managing these locks. Rather, requesting a lock is negotiated only between the site requesting the lock and the site owning that lock; all other sites are informed later (asynchronously) about the current lock ownership. Note that each site forms a full subset of the entire system (with respect to quality of service and speed); therefore, each site is capable of subsisting independently of the other sites since; thus, no partitioning and no special considerations in workf low and workf low object modeling are required.

The invention minimizes communication overhead between sites in regular operation and still permits cross-site work on a common data set at a reasonable cost. Thus, the invention provides a good tradeoff between globally available data on the one hand and the good performance of a local workflow system on the other hand. In the case of workf low objects being "pushed" from one site to another site, data is replicated asynchronously; in this case, the overhead at the source site includes change data capturing and adding change records to a messaging system (such as IBM WebSphere MQSeries). Replication and message handling itself is an established state-of-the-art technique and applicable to messaging between distant sites. Servers and clients used for replication may reside on additional physical systems and thus will not impact the performance of the workf low system. Synchronous data replication occurs whenever data is -16 - "pulled", e.g. in the case that a workf low object is owned by site 1A and updates are now required at site 13; in this situation, wait times occur.

In a distributed workf low system comprising multiple sites, transactional integrity has to be assured. Specifically, if a network 17 fails during workf low object transmission and/or a site fails or shuts down (corresponding to a situation in which the site is temporarily or finally unavailable), the workf low system has to be able to recover without losing or corrupting workf low objects. -In order to minimize data loss in a case of a site outage, updates of workf low objects are immediately submitted to the replication queue, and thus data is continuously replicated to remote sites. As long as each site operates locally, service requests will not be affected. Even a temporary network outage between two sites does not impose an issue in the first instance. Asynchronous replication will continue once network connection has been re-established and due to the locking and ownership concept, it is guaranteed that there are no conflicting updates to workf low objects that have to be resolved. Thus, in case one site 1A encounters a physical damage and the local data are not accessible any more, users may log into a remote site 1B, ic and continue working. Each single site is capable of operating disconnected for a certain time as long as all workf low object participants are local.

If a workf low transaction requires transferring ownership from an of f line or permanently defective site 1A to an active site (lB or 1C), a request to "pull" ownership from sites lB or lC to 1A remains unanswered (e.g. a time-out signal is sent for a predefined number of times). In this case, an administrator can manually transfer ownership, this being particularly reasonable in the case in which the defective site lA is expected to remain shut down permanently. Alternatively, a user located at site lA may connect to site lB (or 1C), and ownership of the given -17 -workf low object may be transferred to site 13. Assuming that under normal conditions, users located at site 1A typically connect to the workf low system at their local site 1A, incidents of site 1A users connecting to distant locations (site lB or 1C) indicate the occurrence of an outage at site 1A.

As outlined above, data is replicated either synchronously (in the case of "pull" operations) or asynchronously (in the case of "push" operations) between the sites.. Due to the asynchronous nature of propagating changes, it may happen that information relating to ownership of a given workf low object (lock information) is being changed as it is being sent to another site. For example, assume that site 1A owns workf low object OBJ4 (see FIG. 3), but ownership of 03J4 is to be transferred to site 13. In the case of a transferal via a "push" operation, this change will be propagated asynchronously. Between sending and receiving the change on the queue channel between sites lA and 13, site 1C might request ownership of workf low object 03J4 and send a synchronous request to site 1A. Site 1A "knows" that ownership has been transferred to site lB and responds back to site lc with this information (in fact, with a copy of the change lock request that has been sent to site lB asynchronously). In a subsequent call, site lC will send a request to site lB asking for ownership. If the asynchronous data transfer has not yet arrived at site 13 (and if ownership has not been transferred to yet another site), then site 13 will use the transmitted copy of the lock change request to establish ownership and will disregard the asynchronous request arriving later. -If any part of this communication fails or if inconsistencies between the sites' directories 20A, 20B, 20C are detected, a reset operation for a particular workflow object can be submitted either automatically or manually (by an administrator). This reset operation is sent synchronously to all sites; it causes locks for the workf low object in question -18 -to be reset and asynchronous lock change requests not yet implemented to be discarded.

Replication using a messaging system as outlined above guarantees transactional integrity of the distributed workf low system and also makes sure that change records are applied it the correct order.

Deadlocks may occur if two concurrent threads of execution acquire transactional locks for two respective workf low objects, each thread of execution relying on additional locks of the respective other thread of execution to complete its own transaction. Since locking processes (on the workf low object scope) are more granular than locks on the database level for process navigation, deadlocks are unlikely to occur at this level. However, deadlocks may occur for dependent workf low objects, for example in the case of two interdependent workf low objects being owned by different sites, processing of both workf low objects being triggered concurrently at both sites. In that case, both sites need access to both workf low objects and will -unsuccessfully -request ownership transfer from the other site. In order to solve this impasse, deadlock detection similar to its implementation in modern database systems is required so that one of the sites is forced to roll back its current transaction.

Referring now to FIG. 8, a computer system 200 implementation of the preferred embodiment of the present invention is shown.

Specifically, the computer system 200 may be a server in a workf low system comprising several sites 1A, lE, 1C (e.g. the server l4A of LAN iDA of site 1A of FIG. 3). The present invention can be implemented as a computer system 200 and/or program product 226 for managing workf low objects OBJ1 -OBJ4 in a distributed workf low system comprising multiple sites. This allows user 240 to generate process instaritiations containing -19 -multiple workf low objects OBJ1 -OBJ4 to be processed by the workf low system sites 1A -1C.. As depicted, computer system 200 generally comprises memory 212, input/output (I/O) interfaces 214, a central processing unit (CPU) 216, external devices/resources 218, bus 220 and data base 238. Memory 212 may comprise any known type of data storage and/or transmission media, including magnetic media, optical media, random access memory (RAN), read-only memory (ROM), a data cache, a data object etc. Moreover, memory 212 may reside at a single physical location, comprising one or more types of data storage, or can be distributed across a plurality of physical systems in various forms. CPU 216 may likewise comprise a single processing unit, or be distributed across one or more processing units in one or more locations, e.g. on a client and server.

I/O interfaces 214 may comprise any system for exchanging information from an external source. External devices 218 may comprise any known type of external device, including keyboard, mouse, voice recognition system, printer, monitor, facsimile etc. Bus 220 provides a communication link between each of the components in the computer system 200 and likewise may comprise any known type of transmission link, including electrical, optical, wireless etc. In addition, although not shown, additional components such as cache memory, communication systems, system software etc. may be incorporated into computer system 200.

Database 238 provides storage for information necessary to carry out the present invention. Such information could include, inter alia: (1) business process definitions such as the one depicted in FIG. 2; (2) workf low object ownership information such as directory 20A shown in FIG. 3; (3) information on initial ownership assignment of workf low objects etc. Database 238 may include one or more storage devices, such as a magnetic disk drive or an optical disk drive. In another embodiment, database -20 - 238 includes data distributed across, for example, a local area network (LAN 1OA), wide are network (WAN) or a storage area network (SAN) (not shown in Fig. 4). Database 238 may also be configured in such a way that one of ordinary skill in the art may interpret it to include one or more storage devices.

Moreover, it should be understood that database 238 could alternatively exist within computer system 200.

Stored in memory 212 is logic system 226. As depicted, logic system 226 generally includes Initial Assignment System 228, Updating/Modifying System 230 and Transferring System 232. The systems shown herein carry out the functions described above.

Initial Assignment System 228 will use one (or a mix) of the strategies outlined above to assign a workf low object OBJ4 to a site 1A which will act as the owner site for this workf low object OJB. Updating/Modifying System 230 will update and/or modify workf low objects 03J4 as they are processed at owner site 1A. Transferring System 232 will transfer ownership of workf low object QBJ4 from its owner site 1A to another site lB. 1C upon request ("pull") or when the owner site 1A determines a need to transfer workf low object OBJ4 to another site 1B, 1C ("push") Database 238 will store and update ownership information on all workf low object OBJ1 -OBJ4 currently active at any site lA -1C within the system.

The invention can take the form of an entirely hardware embodiment, an entirely software embodiment or an embodiment containing both hardware and software elements. In a preferred embodiment, the invention is implemented in software, which includes but is not limited to firmware, resident software, microcode, etc. Furthermore, the invention can take the form of a computer program product accessible from a computer-usable or computer -21 -readable medium providing program code for use by or in connection with a computer or any instruction execution system.

For the purposes of this description, a computer-usable or computer readable medium can be any apparatus that can contain, store, communicate, propagate, or transport the program for use by on in connection with the instruction execution system, apparatus, or device.

The medium can be an electronic, magnetic, optical, electromagnetic, infrared, or semiconductor system (or apparatus or device) or a propagation medium. Examples of a computer-readable medium include a semiconductor or solid state memory, magnetic tape, a removable computer diskette, a random access memory (RAM), a read-only memory (ROM), a rigid magnetic disk and an optical disk. Current examples of optical disks include compact disk-read-only memory (CD-ROM), compact disk-read/write (CD-R/W) and DVD.

While the foregoing has been with reference to particular embodiments of the invention, it will be appreciated by those skilled in the art that changes in these embodiments may be made without departing from the principles and spirit of the invention, the scope of which is defined by the appended claims.