A LOGIC-BASED MOBILE AGENT FRAMEWORK FOR WEB

APPLICATIONS

Shinichi Motomura, Takao Kawamura, Kazunori Sugahara

Tottori University

4–101, Koyama-Minami, Tottori 680–8552, JAPAN

Keywords:

Logic programming, mobile agent, ﬁeld, XML-RPC.

Abstract:

A new logic-based mobile agent framework named Maglog is proposed in this paper. In Maglog, a concept

called “ﬁeld” is introduced. By using this concept, the following functions are realized: 1) the agent migra-

tion which is the function that enables agents to migrate between computers, 2) the inter-agent communication

which is the indirect communication with other agents through the ﬁeld, 3) the adaptation which is the function

that enables agents to execute programs stored in the ﬁeld. We have implemented Maglog on Java environ-

ment. The program of an agent which is a set of Prolog clauses is translated into Java source code with our

Maglog translator, and then it is compiled into Java classes with a Java compiler. In addition, through XML-

RPC interface for Maglog which we have also implemented, other systems can easily utilize Maglog. The

effectiveness of Maglog is conﬁrmed through the demonstration of an application: the distributed e-Lerning

system.

1 INTRODUCTION

Techniques for developing Web applications show an

advance recently and dynamic contents provided by

programs can be inserted in them. These programs

have an inclination to become complicated and some

of them are having communication facility with an-

other computers. Service-oriented architecture (SOA)

attracts attention as a key technology for this require-

ment. SOA is an architectural style whose goal is

to achieve loose coupling among interacting software

agents.

On the other hand, mobile agent systems are dis-

cussed for developing distributed applications. It is

meaningful to develop Web applications based on mo-

bile agent systems. For realization of the mobile agent

systems, the following functions are required to be

implemented.

1. Agents should be able to migrate from one com-

puter to another with data and programs.

2. Agents should be able to communicate with other

agents.

3. Agents should be able to adapt themselves to en-

vironments such as computers they belong to. The

adaptation is accomplished by taking data and pro-

grams of the environments into themselves.

Considering the above points, a concept of the

“ﬁeld” is proposed to realize the required functions

simply.

Agents communicate with other agents indirectly

through the ﬁeld and adapt themselves to the environ-

ment by importing data and programs stored in the

ﬁeld. The functions realized by the ﬁeld are summa-

rized as follows.

1. Migration: Function that enables agents to migrate

between computers.

2. Inter-agent communication: Indirect communica-

tion with other agents through the ﬁeld. That is, an

agent is able to import data or programs that other

agents store in the ﬁeld.

3. Adaptation: Function that enables agents to exe-

cute programs stored in the ﬁeld.

For the implementation of the mobile agent system

with the concept of the ﬁeld, programs that describe

behavior of the agent are written in Prolog language in

our system. Since Prolog is logic programming lan-

guage and has powerful pattern matching mechanism,

agents are able to search data and programs stored in

ﬁelds easily. This powerful pattern matching mech-

anism of Prolog is called “uniﬁcation”. Uniﬁcations

between computers are realized to construct mobile

121

Motomura S., Kawamura T. and Sugahara K. (2006).

A LOGIC-BASED MOBILE AGENT FRAMEWORK FOR WEB APPLICATIONS.

In Proceedings of WEBIST 2006 - Second International Conference on Web Information Systems and Technologies - Internet Technology / Web

Interface and Applications, pages 121-126

DOI: 10.5220/0001251101210126

 SciTePress

Agent

Field

Agent Server

Host

Network

Migration

Figure 1: Overview of a mobile agent system on Maglog.

agent system.

In this paper, the mobile agent framework named

Maglog on Java environment is proposed to imple-

ment the above-mentioned functions. Java is adapted

because of its huge class libraries to build network

applications. It also should be noted that Java’s goal

of “write once, run anywhere” is desirable for mobile

agent systems.

There are several mobile agent frameworks

realized as a set of class libraries for Java

such as Aglets(Lange and Oshima, 1998), Mo-

bileSpaces(Satoh, 2000), and Bee-gent(Kawamura

et al., 2000). The combinations of one of them and

a Prolog interpreter written in Java such as NetPro-

log(de Carvalho et al., 1999) and Jinni(Tarau, 1999)

have some similarity to Maglog. The main difference

between the combinations and Maglog is the class

of mobility. Their mobilities are weak mobility, in

which only their clause databases are migrated. On

Maglog, all of the execution state including execution

stack can be migrated. That is to say, the mobility of

Maglog is strong mobility so that agents on Maglog

can backtrack and unify variables across the network.

That makes programs on Maglog simple and under-

standable.

2 OVERVIEW OF MAGLOG

Figure 1 shows an overview of a mobile agent system

on Maglog executing an example. In the ﬁgure, two

computers (hereafter referred as hosts) are connected

to a network and agent servers are running on each of

them to activate agents and to provide ﬁelds for them.

The rest of this section describes three basic com-

ponents of Maglog, that is, agent, agent server and

ﬁeld.

2.1 Agent

An agent has the following functions.

1. Execution of a program that describes behavior of

the agent,

2. Execution of procedures stored in a ﬁeld where the

agent currently locates,

3. Communication with other agents through a ﬁeld,

4. Creation of agents and ﬁelds,

5. Migration to another host in a network,

6. Cloning of itself.

An agent of Maglog executes its program sequen-

tially. The class of agent migration is strong migration

which involves the transparent migration of agent’s

execution state as well as its program and data. In

order to realize uniﬁcations between computers, Ma-

glog supports strong mobility.

For creation of a child agent, a parent agent exe-

cutes the following built-in predicate.

create(AgentID,File,Goal)

In this predicate, File corresponds to the ﬁlename

in which the behavior of the agent is described. If the

execution of the predicate is successful, an agent is

created and its globally unique identiﬁer AgentID is

returned. The created agent immediately executes the

goal speciﬁed by the argument Goal and disappears

when the execution is accomplished.

An agent can obtain its identiﬁer by executing the

following built-in predicate.

get

id(Agent)

An agent can create its clone agent by executing

the following built-in predicate. If CloneAgentID

is the empty set, it is original agent. In the case of the

cloned agent, CloneAgentID is the cloned agent

identiﬁer.

fork(CloneAgentID)

Each agent contains Prolog program and its inter-

preter. Initial behavior of the agent is described in the

Prolog program given by File in the predicate of its

creation. Since Prolog language treats programs and

data identically, the agent behavior might be modiﬁed

during execution.

Figure 2 shows an example of an agent be-

havior. agentA is assumed to have a clause

in((clause(p(x),Y),assert(p(X):-Y)),

fieldA) in its program. Behavior of agentA is

described as follows,

1. agentA enters ﬁeldA.

2. agentA executes a predicate clause(p(X),Y)

and retrieves a clause whose head matches p(X)

from ﬁeldA as a result. Here Y is bounded to

q(X),r(X) which is the body of the clause.

3. agentA executes a predicate

assert(p(X):-Y), and then a clause

p(X):-q(X),r(X) is added to its own

program.

WEBIST 2006 - INTERNET TECHNOLOGY

122

That is to say, an agent is able to import clauses from

ﬁelds so that it can change its behavior dynamically.

The built-in predicate in/2 will be described in

Section 3.1. Here the notation Name/Arity is the

predicate indicator (hereafter referred as PredSpec)

which refers one or several predicates. Name and

Arity correspond to the name of predicate and its

number of argument respectively.

agentA

fieldA

p(X) :- q(X), r(X).

in((clause(p(X), Y), assert(p(X):-Y)), fieldA).

in((clause(p(X),Y),

assert(p(X):-Y)),fieldA).

in((clause(p(X),Y),

assert(p(X):-Y)),fieldA).

p(X):-q(X),r(Y).

Figure 2: Dynamic change of program that describes be-

havior of the agent by asserting a new clause.

2.2 AgentServer

An agent server is a runtime environment for agents

and it provides required functions for agents. The

above-mentioned predicates, such as create/3 and

get

id/1, are the examples of the functions.

An agent server creates and deletes agents. An

agent server assigns AgentID to the created agent.

AgentID consists of host’s IP address and the time

the agent created, so that it becomes globally unique.

In addition, an agent server also provides an agent mi-

gration function. When an agent migrates from hostA

to hostB, the agent server on hostA suspends the

agent’s execution and transports the agent to hostB.

And after that the agent server on hostB resumes the

execution of the agent.

An agent server also manages ﬁelds and provides

functions for an agent to utilize them.

2.3 Field

A ﬁeld is an object managed by an agent server to

hold Prolog clauses, and it is created when an agent

executes the following built-in predicate.

fcreate(Field)

If Field is an unbound variable, a ﬁeld which has a

unique identiﬁer is created, and its identiﬁer is bound

to the argument Field.IfField is a symbol, the

action of this predicate depends on whether the ﬁeld

whose identiﬁer is the symbol exists or not. If it does

not exist, a ﬁeld whose identiﬁer is the symbol is cre-

ated, otherwise nothing is done.

Important features of Maglog realized with the con-

cept of the ﬁeld will be described in the following sec-

tion.

3 FEATURES REALIZED WITH

FIELD

3.1 Predicate Library

An agent enters a ﬁeld and executes a goal by the fol-

lowing built-in predicate.

in(Goal, Field)

The agent exits from Field automatically whether

the execution succeeds or not. This built-in predicate

is re-executable, i.e. each time it is executed, it at-

tempts to enter the ﬁeld and executes the next clause

that matches with Goal. When there is no more

clause to execute, this predicate fails.

When an agent enters into a ﬁeld, it imports proce-

dures of the ﬁeld and combines them with procedures

of itself. Therefore, an agent needs not hold all of the

program by itself to solve a problem, but rather enters

the appropriate ﬁelds which provide necessary proce-

dures. An agent can change its behavior dynamically

according to the ﬁeld which it entered. In this way, an

agent can adapt its behavior to the environments.

3.2 Inter-agent Communication

Agents entering the same ﬁeld can be considered of

forming a group. The procedures within the ﬁeld are

shared by the agents. Moreover, by adding/removing

procedures within the ﬁeld, agents can inﬂuence the

behavior of other agents.

Updating procedures in a ﬁeld can be done by the

following built-in predicates.

fasserta(Clause, Field)

fassertz(Clause, Field)

fretract(Clause, Field)

The ﬁrst argument Clause of these predicates is a

clause to be added or removed from the ﬁeld speci-

ﬁed by the second argument Field. fasserta/2

inserts the clause in front of all the other clauses with

the same functor and arity. Functor and arity mean

the name of predicate and its number of the argument

respectively. On the other hand, fassertz/2 adds

the clause after all the other clauses with the same

functor and arity. fretract/2 removes the next

A LOGIC-BASED MOBILE AGENT FRAMEWORK FOR WEB APPLICATIONS

123

uniﬁable clause that matches with the argument from

the ﬁeld. This built-in predicate is re-executable, i.e.

each time it is executed it attempts to remove the next

clause that matches with its argument. If there is no

more clause to remove, then this predicate fails.

By using these predicates, an agent can communi-

cate with other agents not only asynchronously but

also synchronously. An agent has two modes for exe-

cution of procedures stored in a ﬁeld. In the fail mode,

the execution fails when an agent attempts to execute

or to retract a non-existent clause in a ﬁeld. In the

block mode, an agent that attempts to execute or to

retract a non-existent clause in a ﬁeld is blocked until

another agent adds the target clause to the ﬁeld. For

agents in the block mode, a ﬁeld can be used as a syn-

chronous communication mechanism such as a tuple

space in Linda model(Carriero and Gelernter, 1989)

Figure 3 shows an example of the synchronous

inter-agent communication.

1. PARENT creates fieldA.

2. PARENT creates CHILD and makes it execute

main(’fieldA’). PARENT attempts to re-

move the clause that matches ans(ID,X) from

fieldA and it is blocked until a uniﬁable clause

is added by CHILD.

3. CHILD executes calculate(X) and the re-

sult is bound to X. The identiﬁer of CHILD is

bound to ID by the execution of the built-in pred-

icate get

id(ID). CHILD adds ans(ID,X) to

fieldA.

4. PARENT wakes up and removes ans(ID,X)

from fieldA.

2.create

1.create

3.write

4.read

fieldA

main(Field) :-

calculate(X),

get_id(ID),

fassert(ans(ID, X), Field).

calculate(X) :- ...

main :-

fcreate(’fieldA’),

create(ID, ’CHILD’,

main(’fieldA’)),

fretract(ans(ID, X), ’fieldA’).

PARENT

CHILD

ans(ID, X).

Figure 3: Agents can communicate synchronously through

a ﬁeld.

3.3 Agent Migration

Each agent server has globally unique identiﬁer that is

composed of the server IP address and deﬁned name.

If the second argument of the predicates in/2,

fasserta/2, fassertz/2, and fretract/2

is speciﬁed in the form of Field@ServerID, the

agent executing this predicate migrates to the host in

which the agent server speciﬁed by ServerID runs,

and enters Field. The agent returns to the host lo-

cated before the migration automatically as it exits the

ﬁeld.

Figure 4 shows that the agent matches f(X) with

clauses in two ﬁelds in hostA and hostB. As shown in

Fig. 4, this attempt proceeds through performing the

following steps and succeeds.

1. An agent enters ﬁeldA in hostA and executes the

goal f(X). Consequently X is bound to 3, because

f(3) is the ﬁrst clause that matches with f(X).

2. The agent migrates to hostB and enters ﬁeldB.

3. The agent executes the goal f(3). This attempt

fails since there is no clause that matches with

f(3).

4. The agent returns to hostA and enters ﬁeldA auto-

matically.

5. The agent attempts to execute the next clause that

matches with f(X). X is therefore bound to 5.

6. The agent migrates to hostB and enters ﬁeldB,

again.

7. The agent executes the goal f(5). This attempt

succeeds this time since there is the clause f(5)

in ﬁeldB.

f(3).

f(5).

fieldA

fieldB

hostB

f(5).

f(6).

X=5?

yes

backtracking

X=3

X=3?

hostA

AS1 AS2

in(f(X), fieldA@AS1),

in(f(X), fieldB@AS2).

X=5

Figure 4: Backtracking and uniﬁcation between two hosts.

WEBIST 2006 - INTERNET TECHNOLOGY

124

4 IMPLEMENTATION

We have implemented Maglog on Java environment

through extending PrologCaf

e(Banbara and Tamura,

1999) which is a Prolog-to-Java source-to-source

translator system.

The program of an agent which is a set of Prolog

clauses is translated into Java source code with our

Maglog translator, and then it is compiled into Java

classes with a Java compiler. As mentioned in Sec-

tion 2.1, an agent can import Prolog clauses from a

ﬁeld at run time. These clauses are interpreted by the

Prolog interpreter included in an agent instead of be-

ing compiled into Java classes. An agent runs as a

thread in a process named agent server.

Agent servers have an XML-RPC(Winer, 1998) in-

terface which is accessible from applications written

in any other language with support for XML-RPC.

The following operations from other systems are

available through XML-RPC.

1. create and kill agents,

2. create and delete ﬁelds,

3. assert clauses into ﬁelds and retract clauses from

ﬁelds,

4. get a list of names of ﬁelds,

5. get a list of IDs of agents currently exist.

Implementation of Maglog features realized with

the concept of the ﬁeld is described in the rest of this

section.

4.1 Predicate Library

As shown in Fig. 5, a ﬁeld is implemented as a

Java Hashtable, i.e. procedures in a ﬁeld are put in

a hashtable; a key is PredSpec of a procedure, and the

value is a set of objects representing the procedure

whose predicate indicator is PredSpec.

Figure 5: Structure of a ﬁeld.

When an agent executes a predicate in in/2,it

searches the predicate by specifying PredSpec from

the hashtables of ﬁelds it currently enters and inter-

prets the found value.

In order to improve execution rate, the concept of a

static ﬁeld is introduced into Maglog. It stores read-

only procedures compiled into Java classes before the

agent server to which the ﬁeld belongs starts.

A static ﬁeld is implemented as a Java Class Loader

which receives PredSpec and loads the bytecodes of

the class for the corresponding procedure.

According to the experiments, an agent can execute

a clause in a static ﬁeld about 250 times faster than in

an ordinary ﬁeld.

4.2 Inter-agent Communication

As mentioned in Section 3.2, an agent which attempts

to execute or to retract a non-existent clause in a

ﬁeld simply fails in the fail mode, while the agent in

the block mode is blocked by calling the Java wait

method.

When another agent adds one clause to a ﬁeld, the

blocked agents in the ﬁeld are waked up by the Java

notifyAll method and try to execute their goal.

The agents whose target clause is added restart while

the rest of the wake-up agents are blocked again.

4.3 Agent Migration

The migration of an agent is realized by using a Re-

mote Procedure Call (RPC) as the following:

1. The source agent server encodes the agent as the

argument of a RPC.

2. The source agent server gets serverID of the

destination agent server from the second argu-

ment of the predicates in/2, fasserta/2,

fassertz/2, and fretract/2.

3. The source agent server sends a RPC re-

quest to the destination agent for invocation of

receiveAgent method.

4. The destination agent server decodes the argument

of the RPC and restarts the decoded agent.

The mechanism for RPC is implemented using XML-

RPC.

5 APPLICATIONS

In this section, one of the applications is demonstrated

to conﬁrm the effectiveness of Maglog.

5.1 Distributed e-Learning System

A distributed e-Learning system for asynchronous

Web-based training has been built using Maglog. This

system allows a student to study by himself in his

A LOGIC-BASED MOBILE AGENT FRAMEWORK FOR WEB APPLICATIONS

125

own time and schedule, without live interaction of a

teacher.

Our distributed e-Learning system consists of ex-

ercise agents and user interface programs. Each

exercise agent includes not only exercise data but

teacher’s functions to mark user’s answers, to tell the

correct answers and to show some extra information.

Every computer of students receives some number of

exercise agents from another computer when it joins

the system and takes the responsibility of sending ap-

propriate exercise agents to requesting computers.

The user interface program is developed as a plug-

in program of Firefox web browser. XML-RPC is

used for communication between the plug-in program

and an agent server.

Figure 6 shows one part of key codes in this appli-

cation. This procedure is a part of an exercise agent.

This is the procedure to provide an exercise for a

remote user. In executing this procedure, following

steps are performed.

1. An agent retrieves a clause request/2 which

other agent added from fieldA . Here, Host and

Field are host name and ﬁeld name of student’s

computer.

2. The agent migrates to Host and enters Field,

and it provides an exercise for student. When the

student ﬁnishes the exercise, the agent returns to

the host it belongs automatically.

3. The agent recursively executes this procedure.

Figure 6: This is the procedure to provide an exercise for a

remote user.

In this procedure, two types of ﬁeld, ﬁeldA and

Field are used. fieldA in line 1 of Fig.6 is used as

a medium of asynchronous communication between

agents, and Field in line 2 is used as an abstraction

of migration.

6 CONCLUSION

The new framework named Maglog for mobile agent

systems was designed and developed on Java environ-

ment. In Maglog, a concept called “ﬁeld” is intro-

duced. By using this concept, migration, inter-agent

communication and adaptation functions are realized.

The effectiveness of the proposed framework Ma-

glog is conﬁrmed through the demonstration of an ap-

plication: the distributed e-Learning system.

Regarding the issue of error handling, Maglog cur-

rently handles only one type of error which occurs

when an agent intends to migrate to a host. Handlings

of errors after or during migration are remained as fu-

ture works. Security issues are indispensable prob-

lems for distributed applications using mobile agents.

In Maglog, programmable security functions are not

provided sufﬁciently because security issues are vast.

Those functions are due to be added in future works.

In addition to make programs more practical, it is nec-

essary to provide a program developing environment,

such as a debugging tools and a testing tools.

REFERENCES

Banbara, M. and Tamura, N. (1999). Translating a linear

logic programming language into Java. In M.Carro,

I.Dutra, et al., editors, Proceedings of the ICLP’99

Workshop on Parallelism and Implementation Tech-

nology for (Constraint) Logic Programming Lan-

guages, pages 19–39.

Carriero, N. and Gelernter, D. (1989). Linda in context.

Communications of the ACM, 32(4):444–458.

de Carvalho, C. L., Pereira, E. C., and da Silva Julia, R. M.

(1999). Netprolog: A logic programming system for

the java virtual machine. In Proceedings of the 1st

International Conference on Enterprise Information

Systems, pages 591–598. Setubal, Portugal.

Kawamura, T., Hasegawa, T., Ohsuga, A., and Honiden,

S. (2000). Bee-gent: Bonding and encapsulation en-

hancement agent framework for development of dis-

tributed systems. Systems and Computers in Japan,

31(13):42–56. John Wiley & Sons, Inc.

Lange, D. B. and Oshima, M. (1998). Programming and

Deploying Java Mobile Agents with Aglets. Addison

Wesley.

Satoh, I. (2000). Mobilespaces: A framework for building

adaptive distributed applications using a hierarchical

mobile agent system. In Proceedings of IEEE Interna-

tional Conference on Distributed Computing Systems,

pages 161–168. IEEE Press.

Tarau, P. (1999). Inference and computation mobility with

jinni. In Apt, K., Marek, V., and Truszczynski, M.,

editors, The Logic Programming Paradigm: a 25 Year

Perspective, pages 33–48. Springer.

Winer, D. (1998). Xml-rpc speciﬁcation.

http://xmlrcp.com/spec.

WEBIST 2006 - INTERNET TECHNOLOGY

126