Modeling Agents with Gamma

---

Modeling Interagent Communications and Agent Migration

As a high-level language, Gamma can succinctly model computations. Local computations within agents can be described by using methods used in previous research. However, to model agent systems, we need to find a mechanism for describing interagent communications and agent migration. In the framework of the higher-order Gamma, interagent communications and agent migration can be merged by viewing interagent messages as an inert program. For example, the following rule describes a message transmission if M is a message, and an agent migration if M is a program:

M: E1, M’ : E2 [M, M’ ]: E2, L(E1, E2) Λ C(M, M2 ),

where E1, E2 denotes two running environments, L(E1, E2) is a communication link between E1 and E2 , and C(M, M’ ) is the condition causing the message transmission or agent migration.

As stated before, agent systems do not have a single type or definition. The following is a collection of subclassifications for agent systems with examples of the use of the Gamma language to describe each type of agent.

Collaborative Agents

Collaborative agents solve problems by working together. The information is assimilated in a process involving collaboration among the agents. A collaborative agent system is usually designed to provide solutions to inherently distributed problems, e.g., distributed network management, meteorological forecasting systems, and virtual classrooms.

Consider a project-evaluation system in an online course; the system is composed of a project-collection module, a project-evaluation module, a student-record module, and a project database, which stores the projects submitted for the course. The following rules govern the process of a project evaluation:

• The project-collection module collects the students’ submissions.

• If the submission is significantly similar to a previously stored submission, the former is considered to have been plagiarized, and an F is recorded in the student’s record.

• Otherwise, the project is forwarded to the evaluation module and evaluated, a grade is given and recorded in the student’s record, and the project is stored in the project’s database.

• All the modules work concurrently.

This system has four modules: the project collection module (Col), the project evaluation module (Eva), the project database-management module (Dbm), and the student record- maintenance module (Srm). The data types involved in the process are as follows:

• Prj: Student projects before submission, in the form of (id, p) where id is the student’s ID, and p is the project

• Sub: Submitted projects, in the form of (id, n, p), where n is a natural number indicating the next project for comparison

• Db: Saved projects in the database

• Rec: Student records, in the form of (id, g), where id is the student ID, and g is the grade

To model communications among modules, the following data types are introduced:

• Qcd: Queued messages from Col to Db—A message is sent from Col to Db when a new submission is received; and the received project and the saved projects should be compared.

• Qdc: Queued messages from Db to Col, which contain a saved project for comparison.

• Qcs: Queued messages from Col to Srm—When plagiarism is found, an F is sent to the student’s record.

• Qce: Queued messages from Col to Eva—After comparison is done, the project is sent to Eva to be evaluated.

• Qes: Queued messages from Eva to Srm—After the evaluation is done, a grade is sent to Srm.

• Qed: Queued messages from Eva to Db—After the evaluation is done, the project is sent to Db for bookkeeping.

The system can be described by the program in Figure 1.

Figure 1: The program for student project evaluation

The main complexity of the program lies in Col and Dbm. For each received project, Col assigns an initial value 1 to the project by dropping (id, 1, p) in the Sub pool. Here, value 1 indicates that the next comparison is going to be made to the first saved project from the database. Whenever a comparison is made, (id, n, p) is changed to (id, n + 1, p) if the database has not been exhausted; otherwise, (id, p) is sent to the evaluation module. The presence of a special value (n, id) in Qdc indicates that n is over the number of projects saved in the database. Dbm uses a similar method to send copies of the projects from the database to Col. When all projects are sent, the special value (n, id) is sent to Col, implementing a sequential algorithm for project comparison.

One may consider letting Col send the project to Dbm and letting Dbm do the comparison, so that Dbm does not need to send copies of projects to Col. However, because of the possible large volume of the database, moving the comparison function to Dbm significantly increases its burden in managing the database. As well, this function transfer violates the modularity of the design.

Using a mobile agent can solve this problem. When Col receives a project, a mobile agent is transferred from Col to Dbm and does the comparison locally. This approach differs from that of letting Dbm do the comparison in that it does not violate the modularity of design while reducing the traffic in the communication link.

The program using this approach is written in Figure 2.

Figure 2: The program for student project evaluation with mobile agents

In this system, Col, Dbm, Eva, and Srm become four agents acting concur- rently. The collaboration among these agents is defined by transition rules in the higher level: Mob, SR, SE, and Con. Mob represents the migration of a mobile agent from Col to Dbm. The environment variable Sub in Col and Dbm is no longer a collection of passive data, but a collection of mobile agents. Note that Q5 is necessary in Dbm to activate any inert mobile agent so that it will perform the comparison function. SR sends the result of the project comparison, which is done by the mobile agent, from Dbm to Rec. SE sends the checked project from Dbm to Eva for evaluation. Finally, Con transfers the project’s grade and the project to Rec and Dbm, respectively, for bookkeeping. Because the communication among agents is defined by higher-order transition rules, message queues are no longer needed in this system.

Interface Agents

Interface agents provide user support by interacting with the user. They work with the user in completing some task in an application. Interface agents carry out the user’s instructions. In situations with no exact instructions to follow, interface agents act according to the knowledge established through feedback from the user. Interface agents can also request help from other agents. Interface agents provide useful assistance to human beings. For example, e- mail filters learn to pick out junk e-mails by hints from the user and past experience.

Here, we consider an e-mail filter implemented by collaborating agents: an e- mail agent, a reference agent, and a counterreference agent. The e-mail agent works as a POP server: it receives e-mails and contacts the reference agent to evaluate the possibility that the incoming e-mail is junk mail/spam. If the possibility (represented by a percentage) is high, then the reference agent consults with the counterreference agent to evaluate the possibility that the e- mail contains important information. The reference agent may use various heuristic rules to examine an e-mail. For example, it may examine the subject to see if it is similar to the subject of a previous junk e-mail, or it may check the e-mail address to see whether the e-mail is from a stranger or a marketing unit of a commercial company. The counterreference is designed to prevent important information, e.g., a receipt from the seller or another important notification, from being regarded as a junk e-mail.

The program in Figure 3 defines the interaction among the above three agents.

Figure 3: An e-mail filtering program

Pop, Ref, and Cnt represent the three agents acting as the e-mail server, the reference, and the counterreference, respectively. Sr, Sc, Rr, and Rc define the communications among the agents. The Pop server determines whether the incoming e-mail should be kept based on the reference and counterreference. The reference is a percentage returned by the Junk function, which calculates the possibility that the e-mail is junk mail. The counterreference, which is computed by function Important, represents the possibility for the e-mail to contain important information.

Mobile Agents

Mobile agents are probably the most interesting agents and have been the subject of many studies. Mobile agents are programs that can be transferred from one computer to another, executing in a platform-independent execution environment. The advent of mobile agents is the result of “demand pulling” and “technology pushing.” On the one hand, applications created a demand for a mobile software unit. For example, distributed information retrieval may require the client to send an agent to distributed sites to collect information from them. On the other hand, advanced technologies make the implementation of mobile agents possible. For example, the Java virtual machine enables the development of an execution environment for a mobile program. An active network allows for the transaction of data, while they are traveling around the network.

The higher-order Gamma language is suitable for describing mobile agents, because programs are treated in the same way as other data entities. An example of a system involving mobile agents is given later in this chapter. Here, we describe another mobile system that is very useful in an e-education environment: the video data transportation system.

Video data transportation is needed in a virtual classroom. Because of the high volume of data, research has been conducted to learn how to expedite the speed of data transportation and enhance the quality of the simulated reality. The mobile agent approach can help minimize the volume of data to be transferred and, therefore, improve the overall performance of the system. For example, consider transferring an image frame. A server transmits the image to the client, which displays the image on the screen according to the settings of the display facility. They may require local processing so that the picture can fit into the frame. For example, a 1024 1024 pixel image has to be reduced in order to fit into an 800 600 pixel screen. The client may send parameters for image processing to the server, which processes the image before transmission. This process, however, complicates the functionality of the server and degrades its performance. As a matter of fact, only the client knows exactly how to process the images. Accordingly, a mobile agent can be employed for this purpose. The mobile agent transfers from the client to the server, processes the image, and sends it to the client.

Figure 4 shows the specification of the image-transportation system involving mobile agents.

Figure 4: An image-transportation program

This program has five clients, each with an ID number of 1 through 5. Q1 transfers an agent from the client side to the server side, while Q2 transfers the processed images to requesting clients. The Resize function resizes the images according to the settings of the clients.

Information Agents

Information agents were developed because of the demand for the management of expansive information growth. The increasing use of the Internet created the need to manipulate and collate information from many distributed sources, while providing easy access to the information. Collecting information is no longer a trivial task. Instead, it becomes tedious and even demanding work, because the user has to check the integrity and correctness of the information. Checking for privacy and copyright has also placed a burden on the users. Therefore, collecting information in most of the situations cannot be done without assistance from information agents.

Information agents can be mobile or static, depending on the nature of the information sources. An example of a static information agent is a bargain finder, which retrieves information from Internet stores, makes comparisons, and then recommends the best price for some specific goods. An example of a mobile information agent is network management software, which travels around Internet routers, collecting information about the availability of Internet facilities and information about network traffic that can be used in routing and identifying a dynamic route so that high-level communication requests can be responded to effectively.

Consider the maintainer of an evolving Web page, which adjusts its content to keep it current with the changing environment. If the page maintains a collection of links to other related pages, and with each link, an excerpt of the content of the pointed-to page, the maintainer works in a driven-by-demand mode. That is, whenever a link is clicked on, an agent is invoked and visits the page pointed to by the link. The agent returns with three pieces of information: (a) whether the page is still available; (b) whether the address is changed, and if so, the new address; and (c) whether the page content is changed, and if so, the excerpt of the new content. The maintainer uses the returned information to delete the link and report to the user the unavailability of the page or to modify the link and the content excerpt.

Figure 5: The program maintaining the Web pages

Figure 5 is the specification of the maintainer.

Program P describes the data flow between the Maintainer and the Updater. M is the set of links to be maintained. The Click Function returns “true” when a link is clicked, and “false” otherwise. The Avail, New, and Excerpt functions test the availability of the Web page, return the new address, and return an updated excerpt from the Web page, respectively. The latter two functions will be called only when Avail returns “true,” so, here, we assume that short-circuit evaluation is used to evaluate a Boolean expression.

Other Agents

There are other agents, such as heterogeneous agents, reaction agents, and economic agents (Weiss, 2003). In the context of e-education, different taxonomies may be used according to the metrics developed by the designers of the systems. For example, CASA (Flores et al., 2001; Lin et al., 2000) classify the agents into five categories:

1. User agents with control interface

2. Task (application) agents

3. Collaboration agents

4. Knowledge-management agents

5. Resource agents

In light of the expressiveness of the Gamma language in describing coordinating software objects, Gamma can easily serve as the specification language of the agent systems. Moreover, the above case studies demonstrate that Gamma can succinctly capture the architectural features. The case study in the following section shows how the Gamma language can be used to describe multiagentbased e-learning environments.

---