Designing Distributed Learning Environments with Intelligent Software Agents

The above section demonstrates that Gamma language can be used as a specification language of agent systems. In this section, we discuss implementation issues. Because the Gamma language is a high-level language designed for program specification, especially for specifying distributed systems, and because this language does not have any sequential bias, it has no straightforward implementation that addresses the efficiency of the target program. Structured Gamma (Fradet & Le Metayer, 1998) language has been proposed to address the implementation issue by introducing an “address” component into the multiset, thereby furnishing a mechanism for representing data structures. Also, Lin et al. (1997) proposed a transformational method for implementing a Gamma program, but in spite of these attempts, it has never been efficiently implemented with enough automation. Therefore, the Gamma language is applied as a specification language mainly to areas of coordination computing. In terms of software engineering, it is irrelevant to consider direct implementation of the Gamma language in distributed running environments, because an individual software unit may be written in a different language on a proprietary computing facility. In this section, we examine how the Gamma specification can be used as a guideline for the architectural design of agent systems.

Operations on Active Configurations

We address some design issues relating to higher-order transition rules, i.e., transition rules specifying operations on active configurations. In the Gamma language, active configurations are representations of a program unit, such as a process or an agent, while passive configurations are representations of data structures. The design issue of first-order active configurations has been studied as described above. In this section, we discuss the architectural design of agent systems specified by higher-order transition rules. Four possible operations on active configurations can be performed by executing a transition rule: (a) process creation, (b) process deletion, (c) process transition, and (d) data transfer. In the following discussion, we will use the terms “process” and “agent” interchangeably. Therefore, “process transition” is another term for the transfer of mobile agents.

Process Creation

In the project-evaluation program ProjEvaMob, a transition rule produces a mobile agent when a student’s project is submitted to the system:

(id, p): Prj [S, Prg = {(id, 1, p)}, Db = F, Rec = F ]: Sub Ready(p)

By executing this transition rule, an active configuration [S, Prg = {(id, 1, p)}, Db = F, Rec = F] is created in the Sub environment when the project p is ready to be submitted. Here, we avoid the issue of the status of a process: whether it is suspended, ready, or running. We do not have a problem in this case, because the environment Db is empty in the created configuration, and no reaction can take place. The created configuration, which represents a mobile agent, will be transferred to another configuration, a database will be inserted into its environment, and the agent will do its work thereafter. Moreover, whenever necessary, the status of the processes can be expressed by using different environment variables in the Gamma language.

Process Deletion

When a process finishes its work, it will automatically disappear from the running environment. In Gamma language, this process is represented as an active configuration, becoming a passive configuration when no more reactions can take place:

[Prog, (Var1 = Multexp1, …, Varn = Multexpn)] [F, (Var1 = Multexp1, …, Varn = Multexpn)]

A process is deleted as a result of executing a higher-order transition rule, probably triggered by some condition regarding the environment variable. Although the deletion of processes may not frequently occur in a well-defined system, this kind of deletion happens in a system that accommodates error conditions caused by unexpected events. For example, we may consider adding rules to handle the “database overflowing” error indicated by the presence of element (-1, p) in the Db environment variable. In this circumstance, any selected mobile agent is deleted from the Dbm configuration:

s: Sub, (-1, p): Db (-1, p): Db

A problem in synchronization occurs when deleting an active process, however. In the Gamma computing model, testing the reaction condition and completing the reaction action should be considered as an atomic operation. Otherwise, a flaw will occur in defining the semantics of the higher-order transition rule: if the condition for deleting the process is triggered by the status of the environment variable of the active configuration, what if the environment variable is changed during the execution of the process, and the condition for deleting the process is no longer satisfied? This process, however, usually does not cause major problems in practice, because when a process is selected for deletion, usually no further result is expected from its continuing execution. For example, when the database overflows, no further result is expected from the mobile agents, because the system needs to be overhauled at that point.

Process Transition

A process can transfer from one running environment to another. Process transition represents the transfer of mobile agents in agent systems. For example, in the ProjEvaMob program, the following rule transfers mobile agents from the project collection module (Col) to the database module (Dbm):

[P1, Prj = N, Sub = N’ ]: Col, [P2, Db = D, Sub = L]: Dbm

[P1, Prj = N, Sub = F]: Col, [P2, Db = D, Sub = L N’ ]: Dbm N’ F

A platform-independent runtime environment for mobile agents is in order when we consider implementing this feature of the higher-order Gamma. The most difficult issue is probably how to test the condition of the higher-order transition rules in a distributed running environment, because this involves synchronization among processes.

Data Transfer

Processes can exchange data between each other. For example, the following rule in the ProjEvaMob program defines the data flow from the database module (Dbm) to the student record maintenance module (Srm):

[P2, Db = D, Sub = N’ , Rec = R’ , Prj = N]: Dbm, [Rec = R]: Srm

[P2, Db = D, Sub = N’ , Rec =F , Prj = N]: Dbm, [Rec = R R’ ]: Srm R2 F

Hierarchical Execution Environments

The distributed running environment allows the coordinating program units to form a logical topology of communication that may not reflect the pattern of physical connection of the underlying computing resources. Individual program units can be developed on proprietary platforms and communicate between each other by using the Internet. To support collaborative multiagent systems, however, a virtual execution environment must be built upon the underlying networked participating sites. As we discussed in previous sections, the virtual execution environment requires each site to have the facility for the creating, deleting, and transferring processes as well as static data. Based on the modern technology of network computing, this capability does not impose any excessive demands on the networking operating systems. In the e-learning context, in building the environment, we would need to provide a set of function calls for process creation, deletion, and migration that could be invoked from a remote controlling site. Process migration may require a runtime environment such as the Java virtual machine (JVM).

In this section, we focus on how Gamma configurations can be coded in such an execution environment. Hereinafter, we denote a program unit (a process or an agent) as a node, which can run on any physical site of the execution environment. Each node has an interface for communicating with other nodes, and multiple nodes can run on the same physical site. We classify nodes into two types: first-class nodes and controlling nodes. A first-class node performs operations on data and sends data to and receives data from other nodes. A first-class node cannot control the execution of other nodes. First-class nodes represent a first-order Gamma program. A controlling node monitors the execution of other nodes on lower levels. It examines the reaction conditions of transition rules and performs higher-order operations on configurations (represented by the nodes on the lower levels) accordingly. Higher-order operations include creating, deleting, and transferring the nodes on the lower levels. Controlling nodes represent higher-order Gamma configurations.

Figure 8 shows the architecture of the project evaluation program ProjEvaMob. In this system, ProjEvaMob, Col, and Dbm are controlling nodes. Note that the mobile agents (S1, S2, S3, …) are subnodes of Col and Dbm. They are created by Col and then migrate to Dbm, under the control of ProjEvaMob.

Figure 8: Architecture of ProjEvaMob program

Separating controlling nodes from first-class nodes has a direct benefit for implementing transition rules involving multiple configurations. Interprocess synchronization has to be done when testing the condition of such transition rules. If the condition involves data from only one of the configurations, the action must be posted to other configurations, even though the test can be done locally. However, if the condition involves data from more than one configuration, all involved configurations have to communicate with each other and freeze the local processing. With the presence of controlling nodes, the condition test can be done on the upper level, eliminating the demand for interprocess communication at the same level for condition-test purposes. Whenever an event that can probably result in a positive condition test happens, the requested data item is sent to the ordering controlling node to do the test, and the controlling node performs the action according to the test result.

This discussion demonstrates that our method for modeling agent systems is not only of theoretical interest, but also can be used for direct implementation. Of course, our discussion has not covered all the practical issues relating to implementation. For example, we may have security concerns when we allow for the external control of process creation, deletion, and migration.