Our Background System

In a mobile agent system, the agents can not only collaborate and communicate with each other, but also migrate to another place to accelerate the problem-solving process. The Object Management Group (OMG) had proposed a standard specification, Mobile Agent System Interoperability Facility (MASIF)[7]. This specification defines a set of interfaces and data types for the interoperability between those heterogeneous mobile agent platforms of different organizations. Organizations following these specifications can migrate their agents to another heterogeneous agent platform for work.

Our agents are based on an extended agent architecture from JAM[2]. We extended the JAM system by implementing several primitive functions. For an agent’s mobility and negotiation, our system follows the MASIF specifications to implement the agent-move and communicate functions.

Figure 2.1 illustrates our system. All the workflow, artifact, and role definitions, named static definitions, are stored in the script repository and database. The Agent Manager is responsible to instantiate, manage and destroy all kinds of agents. The other components are based on the services supported by the Agent Manager. The Workflow Manager manages authority settings and monitors workflow instances. The

agents can request the Workflow Manager for various services, such as instantiating a agent, inquiry for system status, starting a workflow process, etc. The administrators can maintain the static process, role and artifact definitions by administration tools, and control the running workflow instances through the Workflow Manager. The client tools provide GUIs for users and can interact with his/her person agent.

Script Repository

Login / Logout Login / Logout

Refer

Supervisor Agent Refer / Update

Create / Delete Process / Artifact / Person Agents Handle

Figure 2.1: System internal view.

There are four kinds of agents which cooperate to accomplish a workflow (instance) in our system. When a workflow is initiated, a process agent will be instantiated with corresponding process definitions. The process agent then requests to create the artifact agents for required artifacts in the workflow. A process agent keeps a “flow graph” for each artifact agent, takes charge of task dispatching, and makes the routing decision for each artifact agent. An artifact agent carries the workflow relevant data (an e-form), keeps the state of these definitions, and communicates with the proper person agents assigned by the process agent. A person agent has the personal and role information of

the corresponding user, and it would present appropriate contents of the artifact to the user when he/she interacts with an artifact agent. The supervisor agent is a special person agent used by the administrator to interact with other agents.

Here is a possible scenario of the running system. Suppose that a user enters the workflow system with his/her client tool, and the client tool sends an instantiation request to the Workflow Manager. The Workflow Manager in turn requests the Agent Manager to instantiate a person agent, which carries the user’s personal and role information. When user enacts a workflow with the client tool, his/her person agent is asked to send a request to the Workflow Manager. The Workflow Manager firstly checks if the user is authorized for the process. If the authentication is not passed, the request is rejected directly. Otherwise, the Workflow Manager asks the Agent Manager to instantiate a process agent which is in charge of the enactment of the workflow. This process agent then requests the Workflow Manager to instantiate one or more proper artifact agents, and makes the routing decisions for each artifact agent. Each artifact agent will communicate with the engaged person agents to perform (pre-defined) actions with the participants respectively. After completing one delegated work, the artifact agent reports the computation results to the process agent. Meanwhile, these reports and carried process definition are calculated by the process agent to make the next routing decision, and notifies the artifact agents of the decision. When the workflow process completes, the process agent will request to destroy all artifact agents and then itself be destroyed by the flow manager.

In the following sections we will distinguish the types of changes that may occur on the agents and the data carried by the agents, and discuss their solutions.

Chapter 3

Changes on Process Definitions

The processes, roles, and artifacts definitions, which are defined by the process designer in the design phase and stored in the repository, are the static definitions.

When a workflow is enacted, a process agent is instantiated with the corresponding workflow definition. When an artifact is requested by a process agent, an artifact agent is instantiated with the artifact definition. When a user enters the system, a person agent is instantiated with his/her role definition. The definitions carried by these agents are called dynamic definitions.

The changes occurring at run time might work either on the static definitions or dynamic definitions. The changes on the static definitions might occur at the modification by the process designer, participants, or the other workflow instances.

The modification on the static definitions can also change the dynamic definitions of the agents, if the administrator enforces to apply the modification immediately. The dynamic definitions can also be changed when some participants request to modify the workflow instances.

Basically, our system adapts to the changes in three steps:(1) Recognize: Firstly the process agent identifies whether there is a change and the type of the change. (2) Modify: After figuring out the change, the process agent will decide when to halt the workflow instance, how to modify the carried dynamic definition, and then apply the modification. (3) Resume: Finally the system records the system status and the process agent resumes the halted workflow instance. The third activity keeps the history of the changes and depends on the system implementation. So we will skip the discussion of the resuming action.

To identify whether there is a change, it is appropriate to periodically check the difference between the static definitions in the repository and the dynamic definitions carried by the process agent. If the process designer makes an urgent change on the static definitions, the workflow manager can actively notify the related agents of the changes. Besides, the process agent can be aware of the inherent exceptions, such as the inconsistent definitions caused by the process designer, during the enactment of the definitions. With the pre-defined rules, it can actively modify its carried definitions to continue the enactment, or even ask the workflow manager to update the static definitions and notify the other running instances. If the exceptions cannot be solved, the process agent might halt the workflow instance to wait for the administrator’s manipulation.

When the process agent notices the differences between the static and dynamic definitions or the alert of changes from the workflow manager, it could adopt the proper actions according to the changes types and the status of the workflow instance.

The rest of this chapter distinguishes the changes on the process sub-models.

3.1 Characteristics of the process definitions

The changes on the static process definitions could be resulted from the modification by the process designer, the system administrator, or the participants, as described above. To change the dynamic process definition, a user must have the authority to make the local change, like the insertion of a sub-flow. As the process agent detects an inherent exception, it can halt the workflow instance and notify the administrator to check out the static definition.

The following describes the typical definitions which can be carried by a process agent and the potential changes on these definitions. The further solutions are presented in the next section.

1. Workflow requester’s information: If the system administrator modifies the authority setting of a workflow process, it may cause some contradiction. For example, a user may not be permitted to initiate the workflow instance that he/she has initiated.

2. Workflow identifier (unique name, or serial number, etc): The information is used to recognize the type of workflow instance. When the static definition of a workflow is changed, we can exactly recognize those workflow instances whose corresponding static definitions are just modified by compare their workflow identifiers.

3. Artifact identifier: The process agent can identify if a new artifact is inserted in the static process definition, or if an obsolete artifact is deleted from the static process definition, by the number of artifact identifiers. The change of an artifact’s content cause no addition or deletion of artifact identifier in the process definition. This case will be discussed in next chapter.

4. Flow graph of an artifact: When the system administrator modifies the flow graph of an artifact, he/she changes the static artifact definitions. The process agent can distinguish the difference between the modified flow graph and the carried flow graph. Then, with the status of the workflow instance, the process agent can make a correct routing decision for the artifact agents.

5. Authority setting of local change: A local change on the dynamic process definition means that the change is only applied to the process definition carried by the process agent. A local change on a workflow instance can be the insertion of a new sub-flow or the deletion of an original sub-flow. If a person agent wants to make a local change to a workflow instance, it must be authorized to change the dynamic definition of the workflow instance.

3.2 Possible phenomena and corresponding decision policies

The way to adapt to the changes is case by case. Now we state the phenomena and the corresponding decision policies in our system, and illustrate the examples of the change types described above.

3.2.1 Changes on static definitions

1 Changes on authority settings: Only the process designer and the system administrator can modify one process’s authority settings. If the process designer or the administrator takes off a user’s authority to initiate a workflow process, the following requests of instantiation of this workflow process from the user will be rejected by the workflow manager. When a process agent notices the authority change of the user who is interacting with the artifact agent of the workflow instance, the process agent has to decide to continue or stop according to business policy. If the process agent decides to stop, it would cause the destruction of its artifact agents after their current tasks and notify the process requester of the situation. Then it would request to be deleted. If the process agent decides to continue, it would finish the rest of the process as the change on authority setting does not happen.

For example, every employee can initiate a workflow for applying money.

Now, the system administrator modifies the authority setting to allow that in a department, the manager is the only person who can initiate the workflow for employee. In other words, the authority to initiate the workflow is changed.

During the time of authority change, all the unfinished applying processes with the illegal process requesters will be stopped by their process agents. After notifying their requesters, these process agent and related artifact agents will be

destroyed by the workflow manager.

2 Changes on artifact settings: The process designer and the system administrator can add or delete an artifact to or from a workflow process. So do a participant with the authority of local change and we’ll describe it in next section. After the modification on the static artifact settings, the process agent would request the workflow manager to create or destroy the corresponding artifact agents, and lead the rest artifact agents to complete the process. Although destroying an artifact agent will not affect the other artifact agents of the same workflow process, the process agent has to modify its process definition to make the correct routing decision for the rest artifact agents. For example, the process agent can directly lead the other artifact agents to the next site without waiting for the task report of the destroyed artifact agent. When the process designer or the administrator modify the artifact setting to add a new artifact into the workflow at run time, the process agent request the workflow manager to create an artifact agent with the corresponding artifact definition, and directs the artifact agent according to its flow graph. The process agent would make the routing decisions for the original artifact agents simultaneously. For consistency, an artifact agent should not be aware that itself is inserted for a dynamic change. For example, suppose that there is a new artifact agent added in a workflow instance, which had only one artifact agent before, and these two artifact agents shares the same one flow graph. In other words, the process agent has to route the two artifact agents at the same time. When one artifact agent is ready to enter a site, the process agent has to check if another artifact agent had arrived already. If not, the process agent further checks if another artifact agent had passed the site or not. Then the new artifact agent can finish the early task and catch up another artifact agent.

For example, the system administrator modifies the artifact settings of the

subvention recreation application process, and the workflow requesters are now asked to provide an additional manifest, like a voucher. All the unfinished workflow instances would be halted by their process agents. The process agent requests the workflow manager for a new artifact agent for the manifest. The new artifact agent will interact with the person agent of the process requester for the manifest’s content, and follow the process agent’s routing decision to the site the halted artifact agent stays. Eventually all artifact agents would get together and the process agent would make the routing decision for them.

3 Changes on flow graphs: The process designer and the system administrator can modify the flow graphs in the static definitions. A normal participant cannot change the flow graph of an artifact in the static definition, but a participant with authority of local change can modify the flow graph in the dynamic definition.

The change on the dynamic definition will be described in the next section. After noticing the modification on the static flow graph, the process agent must modify the dynamic definition (the flow graph). Then according to the modified flow graph and the process status, the process agent will make the decision of how to adapt to the change. There are three cases. In the first case, the artifact agent has not moved in the modified region of the flow graph yet. The process agent just need to update the carried definition and will make the routing decision by the updated definition in the future. The “modified region” of the flow graph is a continuous segment within a flow graph, which includes all the nodes affected by a dynamic change. During execution time, it can also be deemed as an area of the flow graph starting from the first affected node to the last affected node. There will be a possible algorithm to find out the modified region in the later section. In the second case, the artifact agent has already gone through the modified region.

There are two ways for the process agent to handle this kind of case. One is to

ignore the modification and continue to finish the remains of the workflow.

Another is to route the artifact agent backward to the starting node of the modified region and start over again. In the third case, the artifact agent is inside the modified region. In this case, the process agent must make the artifact agent restart from the starting node of the modified region. Figure 3.1 illustrates these three kinds of cases.

Figure 3.1: Three kinds of changes on flow graph

For example, in Figure 3.2, the original flow graph of an artifact was AÆBÆCÆDÆE. After the modification, the flow graph is changed to AÆXÆYÆE. After the identifying and updating its definition, if the artifact agent is now at the node A, the process agent will make the routing decision by the updated flow graph from now on. If the artifact agent is at the node E, the process agent may continue making the routing decision by the original flow graph or route the artifact agent backward to the node X, depending on the

company’s policy. If the artifact agent is now at the node C, B, or D, the process agent has to ask the artifact agent backward to the node X.

Figure 3.2: Examples of changes on flow graph.

For another example, originally, the flow graph of an artifact was like AÆBÆC, and now it is changed to AÆXÆC. The process agent has to ask the artifact agent backward to the node X. Although this case is a kind of the transference of the employee or the role, it also can be classified as a case of changing the flow direction. We will present an algorithm to infer whether the

artifact agent is in the modified region of the flow graph in the later section.

3.2.2 Changes on dynamic definitions

In previous section, we have described the phenomena about the changes on the static definition. Although the changes on the static definition can cause the corresponding change on the dynamic definition carried by the agents, the changes on the dynamic definition might not have to be applied to the static definition. This kind of change is called local change. The person agent with the authority of the local change can modify the dynamic definition carried by the process agent at run time. In most companies’ business processes, only the managers have this authority. The process designer and the system administrator can also apply a local change to one of the running processes.

Although the process agent keeps up its workflow identifier and process requester’s information, it is nonsense for a participant to modify the identifier or to disable the requester’s authority. If the administrator want to modify the workflow process’s identifier or take off one role’s authority to initiate the process, it would be more convenient for him/her to directly modify the static definition as described in previous section.

When one of the participants requests a local change on the flow graph of an artifact agent, there are two kinds of the cases. In the first case, a new flow will be inserted after the node the artifact agent stays in the flow graph. The dynamic process definition would be modified by the person agent, so that afterward the process agent can correctly make the routing decision for the artifact agents to pass the inserted sub-flow. In the second case, a segment of the original flow graph after the node the artifact agent stays will be deleted. The process designer has to pay more attention on the authority settings and the structure of the workflow process when designing the

process and making the local change. Consider the authority settings, an employee can hardly make an artifact agent skip a sub-flow of the artifact’s flow graph, if the

process and making the local change. Consider the authority settings, an employee can hardly make an artifact agent skip a sub-flow of the artifact’s flow graph, if the