mata99

7/27/2019 mata99

1/15

Optimizing the Migration of Mobile Agents

Guilherme Soares Lus Moura Silva

Departamento Engenharia Informtica

Universidade de Coimbra - POLO II

Vila Franca - 3030 Coimbra

PORTUGAL

Email: {fsoares,luis}@dei.uc.pt

Abstract

The paradigm of Mobile Agents is emerging in the field of distributed computing. Several Java-based

platforms have been already implemented and people is now starting to implement some agent-based

applications. In most of the cases, the performance of the applications is an issue of paramount importance.In this paper, we present a set of optimization techniques that have been implemented in the JAMES

platform, a Java-based mobile agent system that has been developed by the University of Coimbra and

Siemens, and is mainly oriented for telecommunications and network management. The techniques include

some caching schemes, code prefetching, thread and socket pooling and some protocol optimizations. These

techniques are general-purpose enough that can be ported to any other Java-based mobile agent platform. In

the second part of the paper, we present some performance results that show the effectiveness of the proposed

techniques.

Keywords: Mobile Agents, High-Performance, Distributed Computing and Java.

1. IntroductionMost of the existing applications used in the management of telecommunication networksare based on client/server solutions. This static and centralized approach, where everyelement of the network sends the data to a central location has some relevant drawbacks: it

is not flexible, it has problems of scalability and it produces too much traffic in thenetwork.

The use of Mobile Agents in this kind of applications represents a novel approach and

potentially solves most of the problems that exist in centralized client/server solutions. The

applications can be more scalable, more robust, can be easily upgraded or customized andthey reduce the traffic in the network.

In the last few years the use of mobile agent technology has received an extraordinary

attention from several universities and research institutes. Various efforts are alreadyunderway to standardize mobile agent technology, as MASIF [MASIF] and FIPA [FIPA].

The use of mobile agents has been proposed for many application areas, like ElectronicCommerce, Internet applications, information retrieval, cooperative work, network

management and telecommunications. Several commercial mobile agent systems have

already been presented in the market, including Aglets from IBM [Aglets], Concordia fromMitsubishi [Concordia], Odyssey from General Magic [Odyssey], Voyager from

ObjectSpace [Voyager], Jumping Beans from AdAstra [JumpingBeans] and Grasshopper

from IKV [Grasshopper].

7/27/2019 mata99

2/15

Optimizing the Migration of Mobile Agents 2

______________________________________________________________________________________Submitted for ublication at the MATA99 First International Worksho on Mobile A ents for Telecommunication A lications

In order to fulfill one of the main requirements of the mobile agent applications - the need

for high performance some optimization mechanisms should be used. In this paper wepropose a set of techniques to improve the performance of mobile agent systems, including

a flexible distribution of the agents code, a code prefetching scheme, a pool of threads and

migration channels and some protocol enhancements.

These optimization mechanisms have been implemented in the JAMES platform, a Java-

based mobile agent infrastructure that has been developed on behalf of Eureka Project

(!1921). This project includes three partners: University of Coimbra (Portugal), Siemens

SA (Portugal) and Siemens AG (Germany). The JAMES platform is mainly oriented for

applications in the area of Telecommunications and Network Management, where

performance is an issue of paramount importance.

The rest of the paper is organized as follows: section 2 presents some related work. Section

3 describes briefly the James platform. Section 4 describes the techniques and mechanisms

that we have implemented to optimize the migration of mobile agents. Section 5 presentssome performance results and section 6 finishes the paper with some conclusions and

future work.

2. Related WorkMost of the existing mobile agent platforms do not implement any special techniques toachieve high-performance in the migration of agents.

The main exception is the Mole system [Mole] from the University of Stuttgart. Themembers of this project have already published some very interesting work in this topic.

In [Hohl97] is described how to design an efficient code migration component, called code

server. Some mechanisms to transport code are analyzed: one that is able to get classes in

an efficient manner and one that is able to get any valid class by its reference. It is also

presented some code replacement policies, showing that a random or a LRU algorithm is agood starting point for the code replacement scheme.

[Strasser97] presents a performance model for the interaction of agents in mobile agentsystems. It introduces a model where agents can alternatively use remote procedure calls or

agent migrations for the interaction with partners on different locations. The conclusion is

that an alternating sequence of remote procedure calls and agent migrations performs betterthan a pure sequence of remote procedure calls or a sequence of agent migrations.

[Iqbal98] presents some efficient algorithms to find optimal agent migration strategies. It is

indicated that the optimal performance of an agent is achieved by a critical sequence of

mixed remote procedure calls and agent migrations.

[Knabe97] presents several strategies to improve performance that are used by a mobileagent language, called Extended Facile. There are several techniques reviewed that includeallowing agents to use different transmissible representations and performing agent

compilation in a lazy way. Some quantitative measurements have been presented, showing

the effectiveness of these techniques.

3. Overview of the JAMES PlatformThe main goal of the JAMES project is to develop an infrastructure of Mobile Agents with

enhanced support for network management. We also try to exploit the use of this new

technology in some telecommunication software products.

7/27/2019 mata99

3/15



The main goals of the JAMES platform are the following: high-performance, security,

fault-tolerance and robustness, support for network management, easy upgrading,disconnected operation, a 100% pure Java implementation and the integration with

CORBA.

The JAMES Platform provides the running environment for mobile agents. There is a

distinction between the software environment that runs in the manager host and the

software that executes in the network elements: the central host executes the JAMES

Manager while the nodes in the network run a JAMES Agency. The JAMES system willprovide a programming interface that allows the full manipulation of mobile agents. Figure

1 shows a global snapshot of the system, with a special description of a possible scenario

where the mobile agents will be used.

Central Host

NetworkElement

Network

Element

Network

Element

Network

Element

Mobile Agent

Mobile Agent

JAMES

Agency

JAMES

Manager

User

Operator

JAMES

GUI

JAMES

agent

JAMES

Code Server

Code Server

Application Developer

Figure 1: An Overview of the JAMES Platform

The host machine that runs the JAMES manager is responsible for the whole management

of the mobile agent system. It provides the interface to the end-user, together with a

Graphical User Interface for the remote control and monitoring of agents, Agencies andapplications. A snapshot of this interface is presented in Figure 2. The James GUI is the

main tool for the management and administration of the platform.

7/27/2019 mata99

4/15



Figure 2: The Graphical User Interface.

Every Network Element runs a Java Virtual Machine and executes a JAMES Agency that

enables the execution of the mobile agents. The JAMES agents will migrate through these

machines of the network to access some data, execute some tasks and to produce reportsthat will be sent back to the JAMES Manager. There is a mechanism of authentication in

the JAMES Agencies to control the execution of agents and to avoid the intrusion of non-

official agents. A special protocol was developed to transfer the agents across the machines

in a robust way and atomic to the occurrence of failures.

The programmer writes the applications that are based on a set of mobile agents. These

applications are written in Java and should use the JAMES API for the control of mobility.The use of Java was motivated for reasons of portability and robustness of the applications.

After writing an application the programmer should create a JAR with all the classes that

make part of the mobile agent. This JAR file is placed in a JAMES Code Server. Thisserver can be a different machine or in the same machine where the JAMES Manager is

executing. In both cases, it maintains a code directory with all the JAR files available and

the mapping to the corresponding mobile agents.

The JAMES platform was designed with high performance in mind to provide the mostefficient support for telecommunication applications. In order to achieve this goal, we have

integrated several optimization techniques in the platform. These techniques are presentedin the next section.

4. Optimization Techniques

4.1 Flexible Code DistributionOne of the main characteristics of the mobile agent systems is the ability to transport not

only the data but also the code to the different places of the agents itinerary. Thereby, the

system should be able to fetch the agent code in a flexible and efficient way.

7/27/2019 mata99

5/15



The majority of the existing platforms provide a central code server, where all the code isstored. Although the code server ensures a solid structure it does not permit an efficient

migration of the agents through the platform. A single centralized point of request can

easily become a point of bottleneck in the system. Fetching the classes from a single nodecan be a very inefficient approach and does not fulfil the needs for high-performance

computing.

The JAMES platform overcomes this problem, by providing a flexible and decentralizeddistribution of the code across the entire platform. The code classes of the JAMES agents

are grouped in JAR files, which enables a good naming and versioning policy, while

ensuring that all the components of an agent are viewed as a unique block by the system.The migration of the code is always based on these archive files and not on single classes.

The agent/JAR names are unique within the entire platform.

The agents must be registered in the platform before they can be used. During theregistration process the agents JAR file is stored in the main code repository. This central

server has the JAR files corresponding to all the registered agents. The JAR files are

fetched from this server only if they could not be grabbed from a better alternative place, as

will be described next. This code server can be replicated to increase the availability andimprove scalability, namely through a Primary/Backup approach.

Apart from the central repository of code we have implemented a hierarchical repositorymechanism. There are some different code storage levels that can be used to decentralize

the fetching of the code in order to avoid the congestion in the main repository.

The Agencies have their own disk-based repository of JAR files. This local storage reduces

the time and the network traffic that is needed to transfer the JAR files from another point

of the system. The code can be sent only once to the Agency and it stays there waiting for

future requests. The platform administrator can configure the maximum disk space that canbe used in each Agency.

In every Agency, there is also a main memory cache of agent bytecodes. One agent caninstantiate its objects using the data left by another agent of the same type. The information

is available in bytecodes instead of class objects due to classloader and security restrictions.

This caching level reduces the execution time needed to access the classes in the JAR files.The amount of space available for the memory cache is also configurable in each Agency.

Each agent running on an Agency has its own private memory cache. All the agents

specific code stays in this repository and can be reused during the agents lifetime. The datais composed by class objects instead of bytecodes because it is only accessed by one agent

and, consequently, by one classloader. These objects are transparently garbaged by theAgency when the agent finishes its execution.

When the available memory or disk space is running below some limit and there is a need

to load new code, some data must be removed from the cache. We used the Least RecentlyUsed (LRU) replacement algorithm.

Every time an agent arrives at one Agency there is a multi-phase protocol to fetch the

classes of the agent: first, the agent classes are searched in the main memory cache; thenthe platform searches in the memory table that contains the available JARs. If the JAR file

is not in the local cache, the Agency tries to get it from the previous Agency of the

7/27/2019 mata99

6/15



Itinerary. If the classes could not be fetched from this machine then the Agency contacts

the central code store.

This hierarchical searching process provides a higher flexibility in the code distribution.

There is always a central point where all the code is stored but there are multiple choicesthat can be used to improve the performance of the application.

Figure 3 shows the different cache levels that are used in the JAMES Platform.

Figure 3: Cache Levels in the JAMES Platform.

4.2 Prefetching Mechanism

The caching of JAR files tries to exploit the locality of code of the mobile agents. For thosecases where the cache is still empty we have implemented a code prefetching technique toaccelerate the distribution of JAR files.

When an agent is created and launched to the James platform it has its own Itinerary of

Agencies. The code of the agent must exist in every Agency of the Itinerary. There isalways an overhead when the classes of the agent are not in the local cache of the Agency.

This overhead can be reduced by informing all the Agencies that some particular agent is

going to execute there. With this information, the Agency can perform some code loadingin advance while the agent is still executing in a previous place of the Itinerary.

The prefetching options are defined in the Manager and are the same for all the Agencies.The prefetching process can be done by the James Manager or it can be distributed among

the Agencies.

AgentCache

AgentCache

AgentCache

Agency Memory Cache

Agency Disk Cache

Main

Code

Server

Agency

Replicated

Code

Server

Previous

Agency

7/27/2019 mata99

7/15



In the first case, the James Manager sends the prefetching information to all the Agencies

of the Itinerary (except the first one). The type of data that is sent depends on theinformation that is maintained by the Manager about the caching status of the Agencies. If

the Manager does not have such information it sends a simple prefetching information

packet to all the other Agencies of the Itinerary. If there is a global information about thecaches of the Agencies, the prefetching mechanism can make use of that information. If the

Manager detects that there is no JAR for this agent in a destination Agency, the file can be

sent in advance, so that it can be there when the agent arrives. If the JAR file is in the

Agencys local disk but the agent classes are not in memory and/or the migration channelto the next destination is not established, the simple prefetching information packet is sent

to this Agency. Figure 4 represents a sample execution of the prefetching mechanism based

on a Manager with a global information about the caches of the Agencies.

Figure 4: Prefetching mechanism centralized in the Manager.

In the second case, the James Manager only sends a prefetching information to the second

Agency of the Itinerary. When the Agency receives the message it forwards it to the nextAgency and so on until the information reaches the last Agency of the Itinerary. Since the

Agencies do not have a global view of the cache they only send a generic prefetching

information packet. Figure 5 shows an example of this prefetching model.

Figure 5: Prefetching mechanism distributed among the Agencies.

The Agency that receives a prefetching information message can act differently according

to the level of prefetching that is selected by the platform.

Agency 1

Manager

AgentData

JAR file

PrefetchMessage

Agency 3

Agency 2

Agency 1

Manager

Agent

Data

PrefetchMessage

Agency 3

Agency 2

7/27/2019 mata99

8/15



There are three different options that can be selected: disk, memory and migration channel.

If the first option is selected the Agency must get the JAR File to its local disk repository.The second option enforces the Agency to fetch the agent classes to the Agency memory

cache. If the third option (migration channel) is selected, the Agency tries to establish a

socket to the next Agency in the Itinerary, in order to speedup the migration phase.The Manager uses the prefetching options when its prefetching mode is based on the global

view of the cache of the Agencies. If this is the case, the Manager will send different

prefetching data depending on the selected options.

Figure 6 represents the different options of prefetching available in the James Platform.

Code Server

Disk Cache

Memory Cache

2

Agency 2

1

Agency 3

3 Prefetching

Options

1 - JAR

2 - Memory

3 - Migration

Channel

Figure 6: Different options of Prefetching.

4.3 Pool of Threads and Pool of Migration Channels

We are concerned not only about the migration aspects of the mobile agents but also withthe efficient usage of system resources. A good control of the platform resources can be

combined with the previous scheme to achieve a better performance.

One of the main aspects that must be taken in account in order to ensure a correct behavior

of a system is the number of executing threads. The platform should have some kind of

mechanisms to control the number of threads since it is not possible to predict how manyagents will execute at a specific moment of time. A mechanism to control the number of

threads can protect the system resources but can also improve the overall performance of a

platform.

We have conducted a comparison study of performance between different platformspresented in [Silva99]. The study has shown that some of the platforms crashed just in

some stress situations. A close look at the causes of such disasters showed that, sometimes,they were due to the lack of system resources, including threads. Even when the platforms

did not crash, their performance was largely affected by the absence of a good mechanism

to control the execution of the threads.

The JAMES platform implements a very effective mechanism to overcome this problem.

All the threads that run inside the platform are encapsulated in a class named

JamesThread, that extends the Thread class of the Java API. A complementary

structure has been defined to allow the re-use of the threads, called

7/27/2019 mata99

9/15



JamesPoolOfThreads. This pool is available in every Agency and is composed by

JamesThread objects waiting to be used. Every time a new Thread is needed, the pool is

checked to see if there is some existing Thread to be recycled or if it is necessary to create anew one. There is a maximum limit after which no more threads can be created. After

being used the threads should return to the pool. This implementation scheme leads to a

great performance improve since we can avoid the overhead time of creating threads every

time they are necessary.

Another system resources that are largely used by mobile agent systems are the migrationchannels, established between two Agencies of the Agents Itinerary. The absence of any

kind of control over the number of this type of connections can be fatal to the entire

platform. In the same study referred above [Silva99] we have noted that some platformshave problems when the number of agents is very high because they open a new channel

for every migration. Some time after the beginning of their execution they run out-of

migration channels (sockets), leading to a very low level of performance and, in some

cases, to an undesirable crash.

In the JAMES platform we have implemented a mechanism to prevent this kind ofproblems. The migration channels established between two Agencies are not closed afterbeing created. Instead, they are stored in a pool of migration channels to enable a future

reuse. There is a pool of migration channels in each Agency. Every time an agent wants to

migrate to a new Agency it asks for the opening of a migration connection to that place.The Agency checks the pool to see if there is any available connection or if it is necessary

to establish a new one. The limit of migration channels that can stay in the pool is also

configurable and there is a closing mechanism every time this limit is reached.

These implementations, based on an effective control and re-use of the system resources,

contribute to a more robust, secure and scalable platform. The performance of the

applications also benefits largely from these techniques.

4.4 Protocol Optimizations

The overall performance is also related with the internal implementation of the migrationprotocol. We tried to optimize the inner parts of this protocol, exploiting all the available

techniques of the Java language. We have developed a simple but efficient protocol to

allow the migration of the agents between the nodes of the Itinerary.

The use of buffer streams allows a better control of the flow of the data between the two

parts of the communicating process. The JAMES platform use different buffer sizes,

depending on the agents size. This dynamic process can be important for the migration ofthe mobile agents.

The reception of different agents is accomplished in parallel; there is no input queueresponsible for all agents. Each agent is received by a separated thread that starts its

execution in a new thread. This new thread will be also responsible for sending the agent to

the next destination. By starting a new thread we can finish all the protocol transactionswhile the agent is already executing.

7/27/2019 mata99

10/15



5. Performance ResultsIn this section we present some experimental results that show the effectiveness of the

optimization techniques that have been described before.

We used a simple mobile agent that roams a network of computers to get a report about thefree memory of each machine. These machines were running Windows NT and JDK 1.2

and were connected through a dedicated 10 Mbit/sec Ethernet network. Each machine wasexecuting a JAMES Agency, while the JAMES Manager was installed in a separatedcomputer. The version of the JAMES platform was the 2.0.

We have measured three different results for every different test. The final result is theaverage of all these ones, with a standard deviation below 5%.

5.1 Caching Mechanisms

In Figure 7 we present the execution time of the application when we applied the cachingmechanisms of the JAMES platform. We have tested agents with different code sizes. We

used five Agencies to perform this test. The size of the agent data was around 1 KB.

Although the agent only performs a free memory data collection (using 4KB of code), italso carries and instantiates extra classes to simulate the growth of the agents code.

Figure 7 Comparing the performance of the caching levels when increasing the Agents code size.

The results show that when using the memory caching mechanisms the performance wasimproved up to 380% against the version without cache. The execution time with a disk-

based cache can be 160% faster than without cache. The use of the memory cache canimprove even 80% further the performance when compared to a disk cache

implementation.

This set of results shows that the caching mechanism can reduce significantly the execution

time of a migratory agent. These techniques should be taken in account if we want to

achieve a good performance in a mobile agent system.

0.00

2.00

4.00

6.00

8.00

10.00

12.00

14.00

16.00

4 KB 100 KB 1 MB

Agent Code Size

Execu

tionTime(sec)

No Cache

Disk Cache

Memory Cache

7/27/2019 mata99

11/15



5.2 Open in advance the Migration Channels

In the following experiment we will try to show the advantages of opening in advance themigration channels between two Agencies of the Itinerary. This technique is implemented

has an option of the prefetching mechanism of the JAMES platform.

In Figure 8 we present the execution times with and without pre-established migration

channels. In both cases we have applied the caching mechanisms. We used five agencies to

perform this test; the size of the agents code was around 4 KB and the agents data size

was near 1KB.

Figure 8 The results of open in-advance the migration channels.

The use of pre-established migration channels can also contribute to a better performance

in the execution of the mobile agents. In this test case the improvement factor was up to60 %.

5.2 Code Prefetching

In the next experiments we will show the importance of the code prefetching mechanism.

The mobile agent was executed for the first time in the network, to ensure that the

application did not make use of the caching scheme. The migration channels were also not

established between the Agencies.

In Figure 9 we compare the execution times of the migratory agent for different agent code

sizes, when we applied the different prefetching modes. All the possible options have beenselected: disk, memory and migration channels. We used five agencies to perform this test

and the data size of the agent was near 1 KB.

0.000

0.500

1.000

1.500

2.000

2.500

None Disk Memory

Caching Level

Execu

tionTime(sec)

Migration Channel

Closed

Migration Channel

Opened

7/27/2019 mata99

12/15



0.00

2.00

4.00

6.008.00

10.00

12.00

14.00

16.00

4 KB 100 KB 1 MB

Agent Code Size

Execution

Time(sec)

No Prefetching

Manager

Manager Global View

Agency

Figure 9 Comparing the performance of the prefetching modes.

As we can see in Figure 9, the prefetching mechanism can speed up the migration of the

agents up to 87 %. The best results were achieved when the Manager has a global viewabout the caching of the Agencies. Since the Manager has information about the resources

that each Agency has, it can prefetch the JAR file in advance. The other two

implementations have similar execution times. The Agency-based mechanism can be a

good solution in order to decentralize the processing among the Agencies of the network.

The number of Agencies in the Itinerary can be an important factor to measure the

relevance of the prefetching scheme. Figure 10 shows the execution times of the migratoryagent for one, three and five Agencies. We have measured the times without any

prefetching mechanism and with the different modes implemented in the JAMES platform.All the possible options were used: disk, memory and migration channels. The size of theagents code was near 4 KB and the data size of the agent was near 1 KB.

0.00

0.50

1.00

1.50

2.00

2.50

1 3 5

Number of Agencies

ExecutionTime(sec)

No Prefetching

Manager

Manager Global View

Agency

Figure 10 Prefetching Mechanism with different number of Agencies.

7/27/2019 mata99

13/15



We can conclude that the effectiveness of the prefetching mechanism is related with the

number of Agencies of the Itinerary. The migration with prefetching is up to 33% and 87%times faster than the non-prefetching migration, for three and five Agencies, respectively.

The prefetching with a global view about the caches is the fastest and the two other

implementations have similar results.

Figure 11 shows the execution times of the migratory agent in different mobile agent

platforms. We have implemented the same benchmark application on the Aglets

Workbench [Aglets], Voyager [Voyager], Grashopper [Grashopper], Concordia[Concordia], Odyssey [Odyssey], Swarm [Kovacs98] and James [James].

We have measured the times with and without the prefetching mechanism. The size of theagents code was near 4 KB and the data size of the agent was near 1 KB. We used five

Agencies to perform this test and all of the machines were rebooted before performing this

test.

0.00

1.00

2.00

3.00

4.00

5.00

6.00

7.00

8.00

ExecutionTime(sec) James (Pref.)

James

Swarm

Odyssey

Concordia

Grashopper

Voyager

Aglets

Figure 11 Comparison between the performance of different Mobile Agent Platforms.

The results show that the JAMES platform has the better performance of all the mobile

agent platforms that have been tested. Both the JAMES prefetching and non-prefetching

versions are faster than any of the other platforms. The JAMES prefetching implementationis 100% faster than the non-prefetching one, 120% faster than the second placed platform

(Swarm) and 352% faster than the last platform (Aglets). The JAMES non-prefetching

implementation is 9% faster than the Swarm platform and 123% faster than the Agletsplatform.

We have made a very large set of tests comparing the JAMES platform with eight othermobile agent platforms [Silva99]. The conclusions show that JAMES has the best overall

performance of execution and produces a very small amount of network traffic. The

robustness is another strong aspect of this platform when compared with the majority of

platforms tested.

7/27/2019 mata99

14/15



The performance results of the caching and prefetching mechanisms seem to be quite

promising and the JAMES platform seems to be very competitive for the applications wehave in mind: telecommunications and network management.

6. Conclusions and future work

James is a mobile agent platform designed to be used with telecommunication and networkmanagement applications. One of the main requirements of these applications is a goodperformance of execution. Some techniques have been implemented in the JAMES

platform to provide the most performance for the agent-based applications, namely:

caching and prefetching mechanisms, reusable pools of threads and migration channels andan optimized agent migration protocol.

The preliminary results show that these techniques are really effective and can improve the

execution of mobile agents. The results also show that JAMES seems to be verycompetitive in performance when compared with other existing platforms.

We are now making some tests using compressed JARs for the migration of the mobileagent. In a near future we hope to know in which cases it will pay off to compress or not

the agents code. There are several factors that must be taken in account in order to turn the

conclusions as reliable as possible.

Another topic that we plan to explore in a near future is the concept of elastic agents. These

special type of agents can drop some code when they dont need it or include new code.These characteristics can optimize the migration performance of the agents, since there is a

significant reduction in the code size that travels with agent through the network.

7. AcknowledgmentsThis project is partially supported byAgncia de Inovao and was accepted in the EurekaProgram (!1921). Special thanks to the rest of the team that is implementing the JAMES

platform, namely: Victor Batista, Paulo Martins, Paulo Simes, Luis Santos , Rodrigo Reis

and Antnio Bernardino

8. References[Aglets] IBM Aglets Workbench, http://www.trl.ibm.co.jp/aglets/

[Concordia] Concordia, http://www.meitca.com/HLS/Projects/Concordia/

[FIPA] Foundation for Intelligent Physical Agents, http://www.fipa.org/

[James] Project James, http://dsg.dei.uc.pt/James[JumpingBeans] Jumpinh Beans, http://www.JumpingBeans.com

[Knabe97] Frederick Knabe, Performance-Oriented Implementation Strategies for a Mobile Agent

Language, in Mobile Object Systems, Christian Tschudin and Jan Vitek, editors, number 1222 in

Lecture Notes in Computer Science series, pages 229-243, 1997. Springer-Verlag.

[Kovacs98] E.Kovacs, K.Rohrle, M.Reich, "Integrating Mobile Agents into the Mobile Middleware", Proc.

2nd Int. Workshop on Mobile Agents, MA98, pp. 124-135, Stuttgart, Germany, September 1998.

[Ghezzi97] C. Ghezzi, C. Vigna, Mobile Code Paradigms and Technologies: A Case Study, Proceedings of

the first International Workshop on Mobile Agents, MA97, Springer 1997

[Grasshopper] Grasshopper platform, http://www.ikv.de

[Hohl97] F. Hohl, P. Klar, J. Baumann, Efficient Code Migration for Modular Mobile Agents, 3rd ECOOP

Workshop on Mobile Object Systems: Operating System support for Mobile Object Systems

(MOS'97).

7/27/2019 mata99

15/15


[Iqbal98] A. Iqbal, J. Baumann, M. Straer, Efficient Algorithms to Find Optimal Agent Migration

Strategies, Universitt Stuttgart, Fakultt Informatik, Bericht Nr. 1998/05.

[MASIF] Mobile Agent System Interoperability Facility, http://www.fokus.gmd.de/research/cc/ima/masif/

[Mole] Project Mole, http://www.informatik.uni-stuttgart.de/ipvr/vs/projekte/mole.html

[Odyssey] General Magic Odyssey, http://www.genmagic.com/agents/

[Silva99] L.M.Silva, G.Soares, P.Martins, V.Batista, L.Santos, The Performance of Mobile Agent

Platforms, Technical Report, University of Coimbra, submitted for publication.

[Strasser97] M. Straer, M. Schwehm, A Performance Model for Mobile Agent Systems, In: H. Arabnia

(ed.), Proc. Int. Conf. on Parallel and Distributed Processing Techniques and Applications(PDPTA'97).Vol II, CSREA, pp. 1132-1140.

[Voyager] Voyager, http://www.objectspace.com/voyager/

mata99

Documents