Mechanism for heterogeneous, peer-to-peer, and disconnected workflow operation

Claims

Having thus described the invention, what is claimed as new and desired to be secured by Letters Patent is:

1. A computer system for workflow operation with heterogeneous components, comprising:

a. sources, representing heterogeneous service requesters, capable of generating service requests;

b. activities, representing units of work generated within said sources;

c. performers, representing heterogeneous service providers, capable of performing said service requests and generating service responses;

d. tasks, representing units of work executing within said performers in response to incoming service requests, such that each task is uniquely associated with an activity within a source;

e. source agents that act as proxies of said sources;

f. performer agents that act as proxies of said performers;

g. task request and task response messages, used to transmit service requests and service responses between said source agents and performer agents;

h. a continuously available network to which said source agents and said performer agents are always connected.

2. The system of claim 1, wherein each source comprises:

a. means for generating and issuing said service requests for said activities;

b. means for receiving said service responses;

c. a connection to its own unique source agent.

3. The system of claim 1, wherein each performer comprises:

a. means for receiving said service requests;

b. means for performing service requests as said tasks;

c. means for generating service responses;

d. a connection to its own unique performer agent.

4. The system of claim 2, wherein sources can comprise one or more of the group consisting of:

a. a workflow script specified as a control and data-flow graph, a set of rules, or means executing on a centralized workflow server;

b. a custom workflow program written in a standard programming language that implements a specific process by generating service requests in a sequence;

c. a workflow-aware human agent implementing a specific process by generating service requests in a sequence;

d. a long-running collaborative application that generates service requests.

5. The system of claim 3, wherein performers can comprise one or more of the group consisting of:

a. a human participant;

b. an automated application, including a database, a gateway, or a program or electronic device for receiving inputs and generating outputs;

c. a workflow server;

d. an organization, business unit;

e. an intermediary application that receives activities from said source agents and dispatches the activities to performer agents.

6. The system of claim 1, wherein said task request represents a service request to a performer agent, comprising:

a. activity ID, a unique, unchangeable identifier assigned by an originator source agent that identifies a specific activity in said source that caused the service request;

b. source agent reference, a unique reference to the originator source agent of the activity, which can be used by a performer agent to identify the originator source agent;

c. task details, which contain information about the exact type of task to be created on the performer and the input parameters required to create and start the task.

7. The system of claim 6, wherein said task request further can comprise one or more of the group consisting of:

a. status information of said task request;

b. annotations that provide an informal description of said task request;

c. information about priority of said task request;

d. information about deadlines on said task request;

e. a detailed history or log of the routing of said task request.

8. The system of claim 1, wherein said task response represents a service response to a source agent, comprising:

a. activity ID, which uniquely identifies an activity in said source to which the response corresponds;

b. source agent reference, a unique reference to said source agent that generated the task request;

c. performer agent reference, a unique reference to said performer agent which handled the task request;

d. task ID, a unique identifier of the task executed on said performer;

e. task result details, which contain information about the exact type of task executed on the performer and the outputs generated for the task.

9. The system of claim 8, wherein said task response further can compromise one or more of the group consisting of:

a. annotations that provide an informal description of said task response;

b. status information which describes if the task was completed correctly, failed, or was forwarded;

c. a detailed history or log of the routing of said task response.

10. The system of claim 1, wherein each source agent comprises:

a. a continuous connection to said network;

b. a task response handler component, for receiving and handling said task responses over said network on behalf of its source;

c. a task request dispatcher component, which generates said task requests from said service requests and dispatches them to said performer agents via said network.

11. The system of claim 1, wherein each performer agent comprises:

a. a continuous connection to said network;

b. a task request handler component, for receiving and handling task requests over said network for its performer;

c. a task response dispatcher component, which constructs said task responses from said service responses and returns them to said source agents via said network.

12. The system of claim 11, wherein said performer agent is a client to its performer, which is an automated application or server.

13. The system of claim 11, wherein said performer agent is a worklist which is a persistent store of arriving task requests, and its performer is a human or application accessing it via a pull client application resident on a connected computing device.

14. The system of claim 13, wherein said pull client application comprises a user interface, comprising:

a. means for being notified by the performer agent about the arrival of new task requests on the worklist;

b. means for explicitly refreshing the content of the worklist;

c. means for downloading specific task requests from the performer agent.

15. The system of claim 11, wherein said performer agent is a push server that pushes arriving task requests to its performer via a push client application residing on a connected computing device.

16. The system of claim 11, wherein a performer agent further can comprise one or more of the group consisting of:

a. means for enabling said source agents on said network to request a listing of the capabilities and services available on a performer;

b. means for enabling authorized source agents on said network to request that a task currently in progress be aborted;

c. means for enabling authorized source agents on said network to request that a task currently in progress be suspended;

d. means for enabling authorized source agents on said network to request that a task currently in suspension be resumed;

e. means for enabling authorized source agents on said network to request the status of a task request;

f. means for enabling authorized source agents on said network to request the current workload on the performer agent.

17. The system of claim 1, further comprising a directory means comprising:

a. means for registering location information of said performer agents;

b. means for registering service capabilities of said performer agents;

c. means for mediating between service requirements of said source agents and the service capabilities of said performer agents;

d. means for enabling said source agents to retrieve location information of matching performer agents subsequent to mediation;

e. means for unregistering location information of said performer agents.

18. The system of claim 13, further comprising worklist servers on which said worklists are created and managed on said network.

19. The system of claim 1, wherein said network comprises:

a. a network means, comprising one or more of the group consisting of a LAN, WAN, Internet, Intranet, Extranet and wireless network;

b. a communication means, comprising one or more of the group consisting of electronic mail, TCP/IP sockets, RPC, HTTP, and IIOP.

20. The system of claim 11, wherein a performer agent further comprises means for acting as an intermediary, role, or group, by receiving said task requests from said source agents and dispatching said task requests to said performer agents.

21. The system of claim 13, further comprising means for enabling multiple performers to share a single performer agent which is a worklist, thus providing the functionality of a shared worklist.

22. The system of claim 10, further comprising means for enabling multiple sources to re-use a single source agent, comprising:

a. source identifiers that can be used by said source agent to resolve each source;

b. a mapping of each task response to its corresponding activity and said source by the source agent.

23. The system of claim 1, further comprising a workflow specification environment, comprising:

a. means for enabling a human workflow designer to create a workflow script by graphical specification as a template and store it in a workflow template repository;

b. means for enabling a human workflow designer/administrator to create an instance of a source and its source agent by instantiating a template from the workflow template repository;

c. means for enabling a human workflow designer/administrator to monitor the execution of said source, and modify the specification graphically.

24. A computer system for peer-to-peer workflow operation between workflow systems, comprising:

a. sources, representing instances of executing workflows that represent processes such as data and control flow graphs, sets of rules, or other custom programs;

b. activities, representing units of work generated within said sources;

c. performers, representing instances of workflow systems;

d. tasks, representing units of work executing within said performers in response to service requests, such that each task is uniquely associated with an activity within a source;

e. source agents that act as proxies of said sources;

f. performer agents that act as proxies of said performers;

g. task request and task response messages, used to transmit service requests and service responses between said source agents and performer agents;

h. a continuously available network to which said source agents and said performer agents are always connected.

25. The system of claim 24, wherein each performer comprises:

a. a connection to its own unique performer agent;

b. a local repository of workflow script templates;

c. means for receiving execution requests for workflow script execution via its performer agent;

d. means for creating said workflow scripts from said local repository in response to said execution requests;

e. means for execution of said workflow scripts on a local workflow execution environment;

f. means for returning the results of said workflow script execution to said sources.

26. The system of claim 24, wherein each source comprises:

a. a connection to its own unique source agent;

b. means for generating requests for workflow script executions on remote performers;

c. means for receiving the results of workflow script executions on said remote performers, via its source agent.

27. The system of claim 24, wherein said task request represents a service request to a performer agent, comprising:

a. activity ID, a unique, unchangeable identifier assigned by an originator source agent that identifies a specific activity in said source that caused the service request;

b. source agent reference, a unique reference to said originator source agent of the activity, which can be used by a performer agent to identify the originator source agent;

c. task details, which contain a request for a workflow script template available in the local repository of said performer to be instantiated and executed on said performer, and input data required for the creation and execution of said workflow script.

28. The system of claim 27, wherein said task request further can comprise one or more of the group consisting of:

a. status information of said task request;

b. annotations that provide an informal description of said task request;

c. information about priority of said task request;

d. information about deadlines on said task request;

e. a detailed history or log of the routing of said task request.

29. The system of claim 28, wherein task details further comprise the workflow script template that is to be instantiated and executed on said performer.

30. The system of claim 29, wherein task details further comprise a portable workflow execution environment that is required to execute said workflow script downloaded on said performer.

31. The system of claim 24, wherein said task response represents a service response to a source agent, comprising:

a. activity ID, which uniquely identifies an activity in said source to which the response corresponds;

b. source agent reference, a unique reference to said source agent that generated the task request;

c. performer agent reference, a unique reference to said performer agent which handled the task request;

d. task ID, a unique identifier of the task executed on said performer;

e. task result details, which contain information about the exact type of task executed on the performer and the outputs generated.

32. The system of claim 31, wherein said task response further can comprise one or more of the group consisting of:

a. annotations that provide an informal description of said task response;

b. status information which describes if the task was completed correctly, failed, or was forwarded;

c. a detailed history or log of the routing of said task response.

33. The system of claim 24, wherein each source agent comprises:

a. a continuous connection to said network;

b. a task response handler component, for receiving and handling said task responses over said network on behalf of its source;

c. a task request dispatcher component, which generates said task requests from said service requests and dispatches them to said performer agents via said network.

34. The system of claim 24, wherein each performer agent comprises:

a. a continuous connection to said network

b. a task request handler component, for receiving and handling task requests for its performer;

c. a task response dispatcher component, which constructs said task responses from said service responses and returns the task responses to the source agents via said network.

35. The system of claim 33, wherein a single source agent can be utilized by multiple sources, and comprising:

a. means for said task request dispatcher to receive service requests from multiple sources and post them as task requests to appropriate performer agents;

b. means for said task response handler to return service responses to appropriate sources based on the origin of the service request.

36. The system of claim 24, wherein said network comprises:

a. a network means, comprising one or more of the group consisting of a LAN, WAN, Internet, Intranet, Extranet and wireless network;

b. a communication means, comprising one or more of the group consisting of electronic mail, TCP/IP sockets, RPC, HTTP and IIOP.

37. A computer system for workflow operation with disconnected or occasionally connected components, comprising:

a. sources, representing heterogeneous service requestors, capable of generating service requests;

b. activities, representing units of work generated within said sources;

c. performers, representing heterogeneous service providers, capable of performing said service requests and generating service responses;

d. tasks, representing units of work executing within said performers in response to service requests, such that each task is uniquely associated with an activity within a source;

e. source agents that act as proxies of said sources;

f. performer agents that act as proxies of said performers;

g. task request and task response messages, used to transmit service requests and service responses between said source agents and performer agents;

h. a continuously available network to which said source agents and said performer agents are always connected;

i. an occasionally available source-side network between said source and said source agent;

j. an occasionally available performer-side network between said performer and said performer agent.

38. The system of claim 37, wherein each source comprises:

a. means for generating and issuing said service requests for said activities;

b. means for receiving said service responses;

c. a connection to its own unique source agent;

d. a mechanism for connecting with and disconnecting from its own source agent over said source-side network.

39. The system of claim 37, wherein each performer comprises:

a. means for receiving said service requests;

b. means for performing service requests as said tasks;

c. means for generating service responses;

d. a connection to its own unique performer agent;

e. a mechanism for connecting with and disconnecting from its own performer agent over said performer-side network.

40. The system of claim 37, wherein said task request represents a service request to a performer agent, comprising:

a. activity ID, a unique, unchangeable identifier assigned by an originator source agent that identifies a specific activity in said source that caused the service request;

b. source agent reference, a unique reference to the originator source agent of the activity, which can be used by a performer agent to identify the originator source agent;

c. task details, which contain information about the exact type of task to be created on the performer and the input parameters required to create and start the task.

41. The system of claim 40, wherein said task request further can comprise one or more of the group consisting of:

a. status information of said task request;

b. annotations that provide an informal description of said task request;

c. information about priority of said task request;

d. information about deadlines on said task request;

e. a detailed history or log of the routing of said task request.

42. The system of claim 37, wherein said task response represents a service response to a source agent, comprising:

a. activity ID, which uniquely identifies an activity in said source to which the response corresponds;

b. source agent reference, a unique reference to said source agent that generated the task request;

c. performer agent reference, a unique reference to said performer agent which handled the task request;

d. task ID, a unique identifier of the task executed on said performer;

e. task result details, which contain information about the exact type of task executed on the performer and the outputs generated on the task.

43. The system of claim 42, wherein said task response further can comprise one or more of the group consisting of:

a. annotations that provide an informal description of said task response;

b. status information which describes if the task was completed correctly, failed, or was forwarded;

c. a detailed history or log of the routing of said task response.

44. The system of claim 37, wherein each source agent comprises:

a. a continuous connection to said network;

b. means for potential disconnected operation from its source, comprising,

i. means for accepting connection requests from said associated source via said source-side network,

ii. means for accepting disconnect requests from its source,

iii. a task response queue component, for receiving and temporarily storing said task responses over said network,

iv. a task response handler component, for receiving and handling said task responses over said network on behalf of its source, and returning them to said source when it is connected,

v. a task request dispatcher component, which generates said task requests from said service requests and dispatches them to said performer agents via said network.

45. The system of claim 37, wherein each performer agent comprises:

a. a continuous connection to said network;

b. means for potential disconnected operation from its performer, comprising,

i. means for accepting connection requests from said performer via said performer-side network,

ii. means for accepting disconnect requests from said performer,

iii. a task request queue component, for an authorized source agent to send a task request over said network and for temporarily storing the incoming task requests,

iv. a task request handler component, for receiving and handling task requests for its said performer,

v. a task response dispatcher component, which constructs said task responses from said service responses and returns them to the originating source agent via said network.

46. The system of claim 37, wherein said network comprises:

a. a network means, comprising one or more of the group consisting of a LAN, WAN, Internet, Intranet, Extranet and wireless network;

b. a communication means, comprising one or more of the group consisting of electronic mail, TCP/IP sockets, RPC, HTTP and IIOP.

47. The system of claim 37, wherein said source-side network comprises:

a. a network means, comprising one or more of the group consisting of a LAN, WAN, Internet, Intranet, Extranet and wireless network;

b. a communication means such as electronic mail, TCP/IP sockets, RPC, HTTP and IIOP.

48. The system of claim 37, wherein said performer-side network comprises:

a. a network means, comprising one or more of the group consisting of a LAN, WAN, Internet, Intranet, Extranet and wireless network;

b. a communication means, comprising one or more of the group consisting of electronic mail, TCP/IP sockets, RPC, HTTP and IIOP.

BACKGROUND OF THE INVENTION

The present invention is related to workflow management systems, and in particular to a distributed computer system for workflow execution across a network infrastructure.

Workflow systems are essential to organizations that need to automate their business processes. Workflow systems allow organizations to specify, execute, and monitor their business processes in an efficient manner over enterprise-level networks. This has the net effect of improved throughput of processes, better utilization of organizational resources, and improved tracking of processes.

Many workflow systems are commercially available. Even though many workflow systems exist, interoperability across these systems is a technical problem. The systems are monolithic and proprietary, and workflows cannot extend beyond a single workflow system. To solve this problem, the Workflow Management coalition (WfMC), an industry-wide consortium of major workflow system vendors, has defined a standard workflow architecture, described in the document "The Workflow Reference Model" �WFMC-TC-1003!. The model defines the major components of a workflow system and a set of interfaces between workflow system components. The major components it describes are a Process Definition or Builder Tool to capture business process logic in a high-level notation; a Workflow Server that acts as the nerve center of the workflow system; Workflow Clients that are used by users to view and interact with the contents of their worklists; Workflow Applications that are invoked by the workflow server to perform automated activities; and finally, Administration & Monitoring Tools used to administer the execution and monitor the status of work flowing through the workflow system using Audit Data.

The WfMC Reference Model also defines interfaces between these components. Interface 1 (builder-server interface) defines a common process definition format for the interchange of static process specifications between a Process Definition Tool and a Workflow Server �WFMC-WG01-1000!. Interface 2 (client-server interface) defines an API that provides a complete range of interactions between a Workflow Client and a Workflow Server �WFMC-TC-1009!. These include worklist interaction, query and control of workflow processes and their activities, and administrative functions. Interface 3 (application invocation interface) is not currently available, but is intended to describe how applications are invoked. Interface 4 (server-server interface) defines an API that describes the interactions between two Workflow Servers �WFMC-TC-1012!. Interactions include initiation, query and control of workflow processes and their activities, and administrative functions. Finally, Interface 5 (monitor-server interface) defines audit data for administrating and monitoring a Workflow Server �WFMC-TC-1015!.

The WfMC standard has significant weaknesses that make it unsuitable for a heterogeneous, distributed computing environment. Specifically, the design of current workflow systems based on the WfMC standard makes them inappropriate for workflow execution across wide area networks such as the Internet, where scalability, flexibility, and interoperability across heterogeneous systems and networks is the needed. The weaknesses of the WfMC architecture stem from the monolithic nature of the workflow server, which is responsible for process execution, management of the Staff Directory, binding of activities to participants and distribution of work items to appropriate workflow participants (performing role and group resolution as necessary), worklist management for all workflow participants who receive work items from the server, and application invocation. This leads to the following problems:

1. Participants cannot be shared by multiple workflow systems: Since participant worklists are hidden within the workflow server and are not externally addressable, processes are only able to send work items to worklists that reside in the same workflow server. Thus, in order for a participant to participate in multiple workflows running on heterogeneous servers, an identity and a worklist must be maintained separately inside each workflow server the client wishes to receive work from. In addition, the workflow client must now manage multiple client connections to each of these workflow servers in order to receive work. This overloads the client application with unnecessary functionality; whenever a participant wishes to participate in a large number of workflow applications from different servers, the participant has to connect to each server and explicitly `pull` work from it. Because of the complexity in the client, this architecture is not suitable for workflow participation using thin clients and lightweight, portable computing devices such as personal digital assistants. From a distributed design perspective, this is an unscalable solution.

2. Participants cannot work in disconnected mode: Even though work items are logically owned by the workflow participants, the WfMC architecture assigns the task of managing work items to the workflow server. Consequently, the participant interacts with a remotely located work item, and each interaction between the participant and an associated work item results in a remote access (usually a Remote Procedure Call (RPC)). While this design has potential benefits when work items must implement some server-side functionality, it imposes severe constraints on disconnected workflow participation, since the network must be constantly available for the participant to do any work. The WfMC standard also involves workflow servers in client-side application invocation, via the proposed Interface 3. For example, if a participant needs to invoke a local application such as a word processor as part of a work item, the workflow server that owns the work item must invoke the word processor on the participant's behalf on the participant's machine via the proposed Interface 3. The consequence of this intrusive approach is that participants can work only when directly connected to the workflow server-they cannot operate in a disconnected mode.

3. The execution of work is not transparent: The WfMC architecture makes clear distinctions between how the server assigns work items to human participants, how it invokes workflow scripts on other servers, and how it manages application invocation. For the first, it assigns work items to its internal worklist and expects the participant to explicitly `pull` the contents of the worklist using Interface 2. For the second, it explicitly `pushes` a request to another server using Interface 4. For the third, it performs a synchronous procedure call using Interface 3.

Treating work in three different ways leads the server to early judgments about the actual implementation of an activity. This leads to a loss of transparency, and makes it difficult for a work item at the level of the requesting server to be dynamically bound and implemented as a workflow by a participant domain at execution time.

U.S. Pat. No. 5,530,861 describes a task management method that allows humans to receive and manage tasks from different sources such as other individuals, process engines, and application agents. The task management scheme assumes that tasks are always performed by humans, and provides a standard way in which a human user can interact with tasks assigned to the user. The method does not deal with interoperability of workflow systems. It also does not deal with distributed workflow execution with respect to how tasks can be treated uniformly across application invocations, workflow script executions on heterogeneous systems, and human participants across a network. It does not deal with issues of disconnected operation, and recursive, dynamic workflow execution.

SUMMARY OF THE INVENTION

The present invention deals with the use of a distributed computer system that spans local-area networks (LANs), wide-area networks (WANs), and global networks and provides a homogeneous view of heterogeneous workflow systems and components. The system is called a distributed workflow system. As a result of the present invention, workflow scripts or applications can be executed in a scalable manner using components scattered across the distributed workflow system. The present invention facilitates peer-to-peer interactions between multiple autonomous and proprietary workflow systems. The present invention also facilitates disconnected or occasionally connected operation of workflow components.

The present invention achieves the following desirable features:

1. Workflows executing on different workflow servers can reuse the same service providers, components, or applications on the network. Workflow participants can receive work from and interoperate with heterogeneous, proprietary workflow servers without using proprietary or dedicated workflow clients.

2. Human workflow participants need to interact with a single Worklist, which is addressable by different workflow servers, and receives all work on behalf of the participant.

3. Workflow-enabled applications and components can be developed and installed by third-parties on the network, and these applications and components can be utilized by and interoperate with multiple workflow servers.

4. Workflow servers can use a wide range of internal workflow execution mechanisms, ranging from rule-based workflow interpretation to control-flow based graph interpretation to hardwired workflow applications or scripts, and operate seamlessly within the distributed workflow system.

5. Heterogeneous and proprietary workflow servers installed in different organizations can interoperate by triggering pre-installed workflow applications on each other, or by downloading workflow applications to each other on demand.

6. Workflow participants, designers, and administrators can participate in workflows even when they are disconnected or occasionally connected to the network.

7. Workflow servers are treated like any other workflow participant; hence, work assigned to a participant may be dynamically refined and implemented as an independent workflow. This allows dynamic workflow decomposition, or late-binding of work to workflows.

These improvements are accomplished by providing:

1. A workflow abstraction called Source that represents a workflow or service requestor that generates a sequence of service requests as part of a process execution.

2. A workflow abstraction called Performer that represents a service provider (human, application, or workflow server) that provides services in response to service requests generated by Sources.

3. A workflow component called Source Agent that acts as a proxy to a Source. The Source Agent is always connected to the network and represents the Source in its interactions with Performers. The Source may be occasionally connected to its Source Agent.

4. A workflow component called Performer Agent that acts as a proxy to a Performer. The Performer Agent is always connected to the network and represents the Performer in its interactions with Sources. The Performer may be occasionally connected to its Performer Agent.

5. A workflow message called Task Request that represents a service request sent to a Performer; and a workflow message called Task Response returned to a Source as a service response.

6. A continuously available Network that allows Source Agents and Performer Agents to communicate with each other.

In addition, the present invention provides a mechanism for disconnected workflow participation. An occasionally available Source-side network allows a Source to connect and disconnect from its Source Agent. Similarly, a Performer-side network allows a Performer to connect and disconnect from its Performer Agent.

The present invention provides a mechanism for heterogeneous, autonomous, workflow systems or servers to execute on the same distributed workflow system. Sources may be workflow scripts executing on a wide variety of workflow systems, or they may be hardwired process-based programs.

The subject invention provides a mechanism for heterogeneous service providers or Performers to present a common interface to the Sources in the distributed workflow system. Performers may be humans participants, or heterogeneous programs and applications, or workflow servers that can execute other workflows.

The present invention provides mechanisms for Performer Agents and Performers to interact in different ways. The most common interaction occurs when a Performer Agent acts as a Worklist (or inbox) for its Performer, which acts as a Pull client. Since the Performer Agent is addressable on the network, various Sources can send work to the Performer via its Performer Agent, without the Performer having to pull work from each of them. Another interaction mechanism is when a Performer Agent acts as a client to its Performer, which is a program or application. Another interaction mechanism allows the Performer Agent to act as Push Server for the Performer.

The present invention provides a mechanism for heterogeneous workflow servers to implement Source and Performer interfaces appropriately and thus engage in peer-to-peer workflow operation. The peer-to-peer operation allows workflow servers to both receive work from and assign work to other workflow servers.

The present invention provides mec