Beruflich Dokumente
Kultur Dokumente
Contains work prepared under the KNIXMAS (Knowledge shared XPS-based Research Network
Using Multi-Agent Systems) EU-Inco N°:977113 Project
MTA SZTAKI Technical Report TR 2000-1
1 INTRODUCTION........................................................................................................3
1.1 TRENDS IN SOFTWARE ENGINEERING ....................................................................3
1.2 TECHNICAL BACKGROUND....................................................................................6
1.3 AGENTS, MULTI-AGENT SYSTEMS ........................................................................8
1.4 MOBILE SOFTWARE SYSTEMS ...............................................................................9
1.5 WHAT TECHNOLOGY TO USE (FOR KNIXMAS)?.................................................11
2 FOUNDATIONS OF MOBILE SOFTWARE SYSTEMS .................................................13
2.1 INTRODUCTION AND HISTORY .............................................................................14
2.2 APPLICATION AREAS IN GENERAL AND FOR KNIXMAS ......................................15
2.3 ARCHITECTURE...................................................................................................18
2.4 CLASSES OF MOBILITY AND MIGRATION ..............................................................18
2.5 DESIGN PARADIGMS FOR MOBILE APPLICATIONS ................................................21
2.6 MOBILITY CLASSES FOR DESIGN PARADIGMS .....................................................22
2.7 THE LIFE CYCLE OF MOBILE AGENTS .................................................................23
2.8 COMMUNICATION IN MOBILE SYSTEMS ..............................................................24
2.9 SECURITY ISSUES AND THEIR SOLUTIONS ...........................................................31
2.10 WHY MOBILITY? ARGUMENTS: PROS AND CONS ................................................38
3 STANDARDIZATION EFFORTS ................................................................................40
3.1 INTER-AGENT COMMUNICATION..........................................................................41
3.2 AGENT SYSTEM INTEROPERABILITY ....................................................................43
4 MOBILE PLATFORMS FOR KNIXMAS ..................................................................44
4.1 ASPECTS OF THE STUDY ......................................................................................45
4.2 THE STUDIED MOBILE SYSTEMS .........................................................................49
4.3 DETAILED RESULTS OF THE STUDY .....................................................................51
5 CONCLUSIONS........................................................................................................67
6 REFERENCES .........................................................................................................69
7 APPENDICES ..........................................................................................................73
7.1 PUBLIC RESOURCES ON AGENTS AND MOBILITY .................................................73
7.2 A LIST OF MAJOR MOBILE SOFTWARE SYSTEMS .................................................74
7.3 ABBREVIATIONS .................................................................................................75
1 Introduction
The Knowledge shared XPS-based Research Network Using Multi-Agent Systems
(KNIXMAS) project aims at the design and development of a framework for the
support of intelligent global research cooperation. This objective is achieved through
interconnected cooperative network environments augmented by decision support
techniques. The framework consists of co-operating expert systems (Intelligent Base
Systems). Intelligent information retrieval and knowledge acquisition is supported by
multi-agent techniques.
As the proposed system is highly distributed and modularized, it requires the use of
latest technological advancements both in terms of conceptual (design) approaches
and that of deployable (preferably standard or near-standard) implementation
techniques. To comply with the statement above, we have dedicated our efforts to
survey the present state of distributed software technology. This included the study of
one of the novel approaches of this domain, namely mobile software systems. More
specifically we have been focussing on mobile agent systems (see Section 2.5 for a
detailed distinction). This enterprise included the overview of current advances and
problems in both the theoretical and practical domain. Furthermore, we have surveyed
several existing mobile software systems, in order to understand the issues the
KNIXMAS system will be faced to and in order to chose the system to be used or to
specify the requirements of the system to be developed.
This paper reports on the effort outlined above. In order to draft the background of the
issues we are going to deal with and in order to define the terminology we are using,
we start out by a very short overview of recent trends in software engineering,
together with the trends’ technical background. After this, in Section 2 we summarize
the foundations of mobile software (mobile code) technology from the perspective of
the KNIXMAS system. This summary introduces the basic concepts, together with
possible application areas and arguments in favor and against the use of mobile
techniques. It also elaborates on more theoretical and security issues. In Section 3 we
examine the standardization efforts connected to the implementation of the
KNIXMAS system. Section 4 reports on our experiments with mobile agent systems
in existence, while Section 5 draws our conclusions.
1.1.1 Distribution
The very presence of network infrastructure stimulated the scope of applications to be
leveraged from the level of single workstations to that of a set of networked
computers. Soon this leverage meant the distribution of the application’s logic among
the participating computers, which development required novel ways of thinking and
application design.
The growth of the publicly available network infrastructure and the increase in its
capacity (communications bandwidth and computing power at the nodes) resulted in
an even more radical shift in the scope of applications and in the way we think of
computers. These developments are summarized by the common slogan: the network
is the computer. This new revolution, however, requires our tools and methodologies
to be scaled up to deal with much larger networks; networks at the multi-national, or
even at the global level.
The KNIXMAS system builds upon these advances and widens the horizon of
research cooperation to the multi-national (even possibly global) level. It first
leverages the research task from individual computers (Work-Research Spaces, WRS)
to local (national) networks (Local Research and Working Networks, LRWNs). It
then continues this approach by connecting these networks and bringing cooperative
research efforts up to the global level, at the façade of the KNIXMAS system. Thus,
the KNIXMAS system paraphrases the slogan cited above, suggesting that the
(research) computer is the whole network itself.
1.1.2 Localization
There are different possible ways to look at the developments of programming
technology. One view that renders the different technological developments into a
single line of coherent evolution, is the level of localization. This approach sorts the
techniques by their increasing level of encapsulation (or localization). According to
this view, facing the more and more complex problems to solve (which was enabled
by the increasing power of the underlying hardware), software engineering practice
“strengthened the grab” on the components the programs were built of.
Monolithic programs got divided into separate compilation units and subroutines as
an effect of structured programming movement. After localizing the code
(localization, in this context, is meant in contrast to external entities, e.g. another
code-block, the user, etc.), the object-oriented approach encapsulated state
information (i.e., data) with the code. The activation, however, as it is shown on Table
1.1, still remained external. This was overcame by the recently appeared agent
paradigm, which allocates autonomy besides encapsulated code and (state) data (e.g.
by specifying the goal or rule of the entity).
Monolithic Structured Object- Agent-
Program Programming Oriented Oriented
Programming Programming
How does a unit External Local Local Local
behave? (code)
What does a unit External External Local Local
do when it runs?
(state)
When does a unit External External External Local (rules,
run? (activation) (called) (message) goals, etc.)
The tendency described in this paragraph complies with that of distribution. The more
localized the control of the software component is, the more straightforward it
becomes to distribute it over the network.
The design and architecture of the KNIXMAS system has profited a lot from the ideas
described in this paragraph. KNIXMAS relies on object-oriented design standards and
common object-oriented implementation techniques (e.g., the Common Object
Request Broker Architecture, CORBA). Furthermore, wherever it was possible, it was
taken a step further by introducing (mobile) agents forming multi-agent systems. This
design allows for the development of an efficient and fully network-aware research
environment.
'regular' computers: PCs and workstations) its highly distributed nature makes
considering related technologies (e.g. mobile computing) worth exploring.
1.2.1.1 (D)COM
"How can a system be designed such that binary executables from different vendors,
written in different parts of the world, and at different times are able to inter-operate?"
This is the problem Microsoft's Component Object Model (COM) tries to provide a
solution for. The main issues in such a solution are basic interoperability; versioning
system to handle the continuous development of the integrated components;
independence of the underlying languages; and transparent cross-process
interoperability.
The solutions what the COM system offers are based on a binary standard for inter-
component function calls. Language independence is achieved through strongly typed
groupings of functions (i.e., interfaces). Versioning issues are handled through
globally unique component identifiers (GUIDs). As this solution means that no
subsequent versions of the same interface can be linked to each other, developers and
users of continuously upgraded components must rely on the dynamic discovery of the
interfaces ('reflection'). This technique makes possible that a component learn its
partner's capabilities (i.e., functions) on the fly.
The Distributed Component Object Model (DCOM), Microsoft's distributed
component solution builds upon the COM architecture. Its network philosophy is to
keep the application as independent as possible from the underlying network
infrastructure. It manages connections to components that are dedicated to a single
client, as well as components that are shared by multiple clients. DCOM's location
independence makes flexible deployment possible.
Moreover, it uses an efficient pinging protocol that forms the base for a distributed
garbage collection algorithm. Communication is symmetric in DCOM; that is, any
component can be both a provider and a consumer of functionality.
Concerning security issues, DCOM supports different industry standards with
different underlying concepts to defend the hosts.
1.2.1.2 CORBA
The Common Object Request Broker Architecture (CORBATM) is a member of the
Object Management Group's (OMG) Object Management Architecture (OMA) which
partitions the object-oriented problem space into different problem-components (see
Figure 1.2.1).
1
Note, that a multi-agent system differs both from parallel (or concurrent) computation and from distributed
sytstems, due to the autonomy of the participating agents.
MTA SZTAKI, Department of Distributed Systems 9
MTA SZTAKI Technical Report TR 2000-1
Distributed System
Hardware
Figure 1.4.1 Traditional distributed systems provide a layer that hides the network
architecture from the programmer [22]
One of the approaches to overcome this problem with a bottom-up approach, by
developing a technology providing support for the development of network-aware
applications and software components. Here what we mean by network awareness is
the capability to reconfigure dynamically, at run-time, and not only the parameters of
the application but also the binding between the application's software components
and their physical location within a computer network. This dynamic binding is
supported by novel mobile software (mobile code) technologies.
Figure 1.4.2 Mobile systems do not hide the network architecture. The programmer
must take it into account [22]
Traditional distributed systems can be conceived within a virtual machine framework
(although, it does not necessarily means that they are interpreted). This is depicted in
Figure 1.4.1. Traditional technology provides a layer (i.e., the 'virtual machine') that
hides the network architecture from the components (and thus from the programmer).
On one hand, this eases the programming burden as provides transparency of
communication among the application's components independently of their actual
location. However, on the other hand, this may result in inefficient implementation.
MTA SZTAKI, Department of Distributed Systems 10
MTA SZTAKI Technical Report TR 2000-1
The code cannot behave differently depending upon the actual location nor it can
adapt to changing patterns in network traffic.
Technologies that support code mobility (mobile software systems) follow a different
approach. While they may also be described within the virtual machine framework
(see Figure 1.4.2), the structure of the network is not hidden from the components.
Thus, the programmer can write real network-aware code. She can handle similar
events differently based on location information or she can adapt the overall structure
of the application to changes in the infrastructure.
members of this subclass are software components that themselves initiate their own
migration, so that from a more technical perspective, they deserve to be called an
agent.
Figure 1.5.1 shows the relation between agent-based software systems and mobile
computation in more detail. It shows that there are two different classes of agent-
based systems: the ones that contain only a single agent (1) and those that have
multiple autonomous components (2). The figure also depicts distributed systems (3)
and one of its special subclasses, mobile computation (4). Mobile computation
contains the class of mobile agents. From the argument presented above, it is clear
that mobile agents can be interpreted, in a very technical sense, as agent-based
systems (6). Sometimes, however, they are also part of a multi-agent system (7).
Number (2) depicts multi-agent systems that run on a single machine, while number
(5) represents distributed systems containing a single agent only. Number (8) stands
for multi-agent systems implemented over several networked machines, but
containing no mobile code.
In the KNIXMAS system we are dealing with a distributed multi-agent system, so we
have number (7) and (8) to choose from. The distributed nature of our enterprise is
inherent in the networked task we set out to solve. The agent metaphor is the most
appropriate tool to cover the wide range of components (expert system modules and
other AI techniques, communications modules, administrative tools, adaptive and
graphical user interfaces, etc.) the KNIXMAS system includes. The high number of
the different agents makes the use of a multi-agent system evident.
From our argument in this paragraph, it must be clear that the decision of whether to
use mobile technology to implement our distributed (multi-agent) system is
independent of both the agent-oriented and distributed nature of the problem. This
question will be discussed and answered in the next paragraph.
etc. This makes room for a wide flexibility of design and thus supports the
development of more robust distributed computational systems.
The question of what components should be allowed to move, or to put it another
way, when it is more advantageous to use dynamic binding and when it is more
appropriate to make them static cannot be answered in general. It should be always
weighted on a case by case basis. (A thorough survey of 'mobile scenarios' will be
provided in Section 2.2 and 2.10.)
As the KNIXMAS system is clearly complex enough to have modules that do profit
and others that don't from mobility, we'll need a middleware infrastructure that
supports both mobility and static binding to implement it. In the next paragraph we
identify our preferences concerning component (object) architectures. This will be
followed by a detailed overview of mobile concepts to provide a thorough
understanding of mobile systems. Based on this knowledge, Section 4 provides a
survey of middleware architectures supporting mobility that takes our preference
concerning component architectures into account.
We start out our introduction with the precursors of the technology to improve
understandability. We soon step forward, however, towards possible application areas
of the technology. After understanding the historical background and motivations, we
set out to provide an architectural overview of mobile systems. (This architecture is
independent of the concrete system in use.) This is followed by the different
taxonomies of both implementation details and conceptual design approaches.
In the second half of this section we discuss the life cycle of mobile components and
the issues of communication in mobile systems. Following this, we survey the
security issues raised by mobility and other special problems of mobile software
environments. Finally, the section ends by a short summary of arguments both in
favor and against of the use of mobile technologies.
While our intention with this introduction was to summarize the important issues of
mobile software technology, our design of the KNIXMAS system has been kept in
our mind throughout the writing of the section. Therefore, issues and problems
relevant from the point of view of the KNIXMAS system are emphasized and
arguments provided to relate the general comments to the actual system in mind.
2
The term is not to be confused with mobile computing which denotes the applications and techniques
developed for portable and handheld devices, such as cellular phones, notebook computers, or personal
digital assistants. (On the other hand, mobile computation is one of the proposed technologies for
implementing mobile computing.)
MTA SZTAKI, Department of Distributed Systems 14
MTA SZTAKI Technical Report TR 2000-1
dynamically allocate (e.g., download) application code to the card, depending on the
actual application context. With these technologies the same card (i.e., a computer
with very limited computational and storage capacity) can be used in very different,
only loosely related applications, since inserting the card into different slots, different
agents (applications) can be executed on the core data stored on the card.
As the KNIXMAS system does not build upon the strengths of smart card technology,
this application scenario is out of its scope.
2.3 Architecture
Execution
Units
Operating
Operating Operating
Operating Operating
Operating
System
System System
System System
System
Software
Sure enough, this is an important decision; conceptually it is even more important that
what is moving. This is the question of the unit of mobility. The answers range from
the whole application, to some special components (objects) or to smaller fragments
(e.g., methods or functions). The exact answer changes from mobile system to mobile
system, but it can be said that perhaps object-level mobility gives to most flexibility
and manageability. (In case of these systems, usually the term mobile object is used.)
The unit of What's moving? The whole program or a part of it (a fragment,
mobility procedure, object, etc.)
The allowed How many moves One-hop or multi-hop mobility. The former
number of are allowed and only allows for the migration of yet
migration when? unexecuted code.
Strength of What is moving Strong or weak mobility and migration The
mobility with the code? latter only transfers global and instance
variables with the code. The former also
carries the execution state (stack, local
variables, thread state, etc.).
Transparency How migration In case of transparent mobility, the
handled is at the programmer only issues a command (or calls a
language level? method) and the code is transferred to the
remote location. Upon arrival it recovers and
continues its execution seamlessly. In case of
non-transparent mobility, the programmer has
other duties besides just signaling its intention
to move the code.
migration is an example of the latter. In this latter case the programmer is facing with
the burden of logically linking the code preceding and succeeding the move.3
Note that in case of one-hop mobility there is no real raison to use strong mobility.
Since the code is only allowed to move before its execution starts, no execution state
exists when the migration takes place. (On the other hand, initial values for data
members do exist, so there may be data to carry with the code.) It is important to
understand, however, that the exact meaning of one-hop mobility very much depends
on the unit of mobility. E.g., if the unit of mobility is the method then one-hop
mobility can mean several migration over the whole execution of the component (as
in some cases of remote evaluation – see Section 2.5 for more details).
Another important remark is that not even strong mobility can move all state
information with the code fragment. In some cases, state information may include
unmovable references (e.g., to low-level communication channels, to file references,
etc.) which would loose their meaning upon migration. These references, however, are
usually so specific and are at such a low-level that their lost is easily overcame at the
more abstract level of programming languages by the programmer.
Finally, it is worth noting that transparency is in a way connected to the strength of
mobility. While it is not impossible to provide high level transparency with weak
migration, the ideal environment for transparent mobility is that in which strong
migration is available. Furthermore, it is clear that transparent migration loses its
meaning when only one-hop mobility is allowed.
Code Synchronous
fragment
Asynchronous Immediate
Deferred
Code Synchronous
fragment
Asynchronous Immediate
Deferred
3
Some sources in the litterature use the term transparent migration differently, to denote the theoretical
maximum of strong mobility when all state information is transferred with the code. These sources use the
term sequentiality of execution logic for the property we call 'transparent migration'.
MTA SZTAKI, Department of Distributed Systems 20
MTA SZTAKI Technical Report TR 2000-1
There are other possible ways and properties to classify mobile code approaches. We
think, however, that the previously introduced classes and properties give a clear and
simple way to characterize mobile software systems (see Table 2.1). However, for the
more interested reader, on Figure 2.4.1 we present the taxonomy of Fuggetta et al. as
an illustration.
assumption of mobile computation (see Section 2.1) it is more efficient to move the
code than the data. Thus, the code and the processor is transferred from A to B, where
it gets executed. The result remains at B with the processor that can remain there,
migrate forward to another site or back to A, depending on the application. (In
practice, the processor rarely migrates, as it is most often available of all sites of the
underlying infrastructure, see Figure 2.3.1)
Note that in case of mobile agents the code and the processor are together during the
whole scenario. This means that, theoretically, the code could be executed at an
arbitrary point in time, both before and after migration. In a sense, this possibility of
execution means autonomy (the code 'decides for itself' which data to act upon)
which, in a way, justifies for the use of the term agent. This does not mean, however,
that mobile agents are autonomous agents (see Section 1.5 for more details).
One-hop Multi-hop
Code on Demand
Mobile Agent
Strong
Figure 2.6.1 The design patterns and the major mobility classes
Remote Evaluation and its counterpart, Code on Demand needs only one-hop
mobility, since in these scenarios only the unexecuted code is transferred to its place
of execution. Since one-hop mobility can be implemented using both weak and strong
mobility, they are equally useful for Remote Evaluation and Code on Demand.
Naturally, as strong mobility is not fully exploited in case of one-hop mobility, the
best match for these two design patterns is one-hop, weak mobility.
Mobile Agents are autonomous concerning their migration and must carry state
information with themselves. Therefore, they need multi-hop mobility. Ideally, they
carry the execution state, too. That is, they are best supported by multi-hop, strong
mobility. On the other hand, as a compromise, it is possible to implement them using
weak migration, but in these cases the programmer must take care of the handling of
the lost information.
Agent
Cloning Agent
Cloning (remote clone)
(local clone) Communication
Communication
Disposal Persistent
Creation (programmed or storage
automatic)
4
We note, however, that the introduction of Java RMI (in JDK 1.1) made the implementation of remote
communication much easier than it was before. This development is clearly visible in the approaches the
'second generation' of mobile systems had taken. Most of them allow both remote and local
communication.
5
Note, however, that this service is not identical to the Yelow Pages service described in Section 12.8.3.3.2.
That service provides symbolic names for agents and stores (symbolic name, agent name) pairs. A query
addressed to this service retrieves an agent name associated with the symbolic name provided. But this
agent name should usually be further processed (e.g., by the registry service) to determine the agent's
actual location.
MTA SZTAKI, Department of Distributed Systems 25
MTA SZTAKI Technical Report TR 2000-1
6
In this document we use the object-oriented terminology. Clearly, there is no conceptual difference
between remote procedure call (RPC) and remote method invocation (RMI) apart from the fact that the
MTA SZTAKI, Department of Distributed Systems 26
MTA SZTAKI Technical Report TR 2000-1
(usually a string or a special object) and send it through the communication media to
its partner. On receiving such a message, a message handling method is invoked (a
message-received event is generated).
On the other hand, method invocation calls the specified method of the called agent
and passes whatever parameters are provided. Clearly, this is a special form of
messaging, with constrained syntax. However, it differs from messaging in at least
two ways. First, it allows for the definition of several 'mailboxes' on the called agent.
Second, it fits more seamlessly into the logic of procedural programming languages,
providing transparency for inter-agent communication.
The messaging concept of direct communication is exemplified in the Knowledge
Query and Manipulation Language (KQML), one of the de facto standards for inter-
agent communication. An example of remote method invocation is the Java RMI
system.
Control-Driven Data-Driven
Common Namespace DIRECT COMMUNICATION BLACKBOARD
Messaging
Method Invocation
latter follows the object concept. Also, when discussing message handling, the word procedure or function
could stand in place of method when using a non-OOP system.
MTA SZTAKI, Department of Distributed Systems 27
MTA SZTAKI Technical Report TR 2000-1
The setup above, however, only works if the communication partners are known at the
time of compilation, since the stubs and skeletons (proxies) should be generated. This
is the case of statically invocing a method. On the other hand, in the case of an open
application on the Internet, it may become necessary to perform method invocation on
a 'foreign' agent or object. In these cases, the signature of the method (number and
types of arguments and the return value) to be called should be discovered and the
stubs must be generated dynamically. This is called dynamic method invocation. Most
of the major middleware architectures (e.g., CORBA or DCOM, see Section 1.2.1)
provide ways to discover the signature of participating agents.
2.8.3.2 Blackboard
The data-driven model of common namespace communication is provided by the
blackboard architecture. In this model, communication is mediated by a shared
dataspace on which addressed data items can be placed. Later on, the partner
(addressee) can search the blackboard for items (messages) addressed to it and
retrieve the information it found. It is important that the access to the items is limited
to the addressee only.
Blackboards often allow for broadcast or multicast communication by providing ways
to formulate addresses denoting several addressees (e.g., through jokers or wildcard
characters). It is important, however, that broadcasting and multicasting is initiated by
the sender. That is, by the initiator of communication. As soon as the address of an
item is specified, no agent of out that set can have access to the information stored in
the item.
The blackboard architecture can be centralized, hierarchical or distributed. In the first
case, communication is mediated through a single, central dataspace, while in the two
latter cases, there are several blackboards organized into some structure. For mobile
systems, usually distributed blackboard architectures are used. E.g. every host can
have a blackboard on it. In this setup, agents usually have access to the local
blackboard, but some systems also allow for remote blackboard access.
Blackboard architectures are usually supported as extensions to mobile software
systems. No mobile system exists to our knowledge that inherently supports this
model of communication. On the other hand, basically any mobile architecture can be
augmented with this construct. This is due to the fact that blackboards easy to build,
they can even be implemented as synchronized user objects. Besides these ad hoc
implementations, several more complete architectures exist. These implementations
are usually by-products of reactive Linda-like architectures (see Section2.8.3.5).
2.8.3.3 Meeting
Anonymous control-driven communication is called a meeting. It has two subclasses:
group meeting and service points. In the former case, usually more than two agents
interact, while the latter generally denotes a client-server like connection between two
agents.
Meetings can be continuously open or constrained in time. The latter means that the
meeting has a controller who initiates and closes the interaction. Continuous meeting
is common in the case of service points (e.g., a stationary agent offers access to local
resources), while group meetings are usually focussed on a given task.
As it is shown above, the security issues of mobile systems are not limited to the
obvious problem of protecting the host against the code (agents) they execute. Nor it
is only extended by the protection of other agents being executed on the same host.
Both of these issues belong to the first category that contains issues with close
resemblance to security issues of multi-tasking operating systems.
Category II contains the problem of ensuring the security of a group of hosts
(executing environments). That is, it is possible that a mobile agent does not harm the
individual hosts, but put a significant load on the whole of the sub-network. (E.g., if
the agent keeps migrating from host to host or it keeps creating clones of itself that
also create further clones, etc.)
Another important problem is protecting the agents themselves against malicious
hosts. This is listed under Category III. These security issues may be caused by errors
in the executing environments or by intentional misbehavior. Both of these cases
should be prevented, or at least, detected. It should be guaranteed that the code of the
agent gets executed according to the specification of the programming language and
that of the middleware architecture. It is also important to ensure that the information
(data) carried by the agent remain sealed.
Category IV contains issues related to communication. Both local (among
components within the same execution environment) and remote (among agents
residing on different hosts) communication should be secure. These problems
coincide with those encountered in the Internet or in distributed applications in
general.
similar to those of more traditional systems (e.g., sandboxing, software fault isolation,
etc.)
Before execution, the host must authenticate the agent and its owner (developer).
Based on this information, different sets of authorizations and resource limits can be
assigned to the agent. In this way access to files, memory or CPU usage can also be
constrained. Some systems use two classes of resource limitations. One class
concerning the amount of a given resource the agent may consume during its whole
execution, while the other class restricting resource usage to a given amount per a
specified unit of time. These issues are usually handled by the underlying network
infrastructure or by the middleware. E.g., as most of mobile systems are built on top
of JavaTM, they usually use a version of Java's Security Manager to deal with these
problems.
Similarily, the issue of secure communication is also a well-studied problem. It can be
solved e.g., by public key infrastructures, using one of the available packages
implementing secure communication channels (or by implementing such a package
using the techniques publicly available). One of the most popular of these packages is
the Secure Socket Layer (SSL).
Note, however, that both of the categories above are subject to a special problem
caused by mobility. The problem is how to make sure that an agent arriving to a host
is carrying the intended code, i.e. it has not been modified during its previous visits to
other hosts. Clearly, such modifications are independent of both the owner or the
developer of the agent. It is also evident that such 'trojan horses' could destroy the
host's security, if they go undetected. The solutions to this special problem belongs to
category III.
2.9.2.1.2 Category II
Implementing the protection of a group of hosts is a relatively easy task. Consider the
case when the affected hosts are under common administration (e.g., belong to the
same subdomain). In this case, it is safe to assume that the agent causing the problem
would be quickly detected and the operator would act against it soon enough in an
appropriate way (e.g. by suspending or terminating it).
The lack of common administration makes the problem harder. However, security
issues belonging to the second category are denial of service (DoS) like attacks. And
intentional DoS attacks against unrelated hosts and domains are very unlikely. That is,
we assume that in the case of distributed administration category II security issues are
either caused by general attacks against every accessible host or by erroneous code. In
both cases, however, the misbehavior of the agent would be widespread enough to
effect a whole (or most of a) local network. (Otherwise, it is not a real problem.) And
if the agent effects most of a local network (or domain), it is safe to assume that the
system administrator of the affected network domain will detect the agent.
Putting it another way, the argument above says that if the group of effected hosts
consists enough members which belong to the same local network to effect the related
domain then the attack will be detected. On the other hand, in the case of generally
destructive or erroneous agents it is very unlikely that they would not effect the
neighbors when they hit a component of a local network. Or at least, as they continue
executing they will eventually hit enough interrelated hosts to be detected.
administrator of the host) have full possibility to interpret it or to use it to extract the
data it uses. 7
As a consequence of the common agreement above, significant efforts has been put
into the development of techniques that help proving and detecting the fraud, as soon
as possible. Having such techniques in place the results of the agent can be omitted.
Moreover, legal and social sanctions can be initiated against the responsible hosts or
its owner. In the absence of a profound and uniform legal background social penalties
are expected to play the more significant role. It is assumed that it is in the interest of
the host's owner to provide its computational service (e.g. she earns money from it).
In this case, proved and advertised frauds can result in agents avoiding the host in the
future, thus harming the owner's interests. This is expected to have a preventing
effect. (While it is clear that this is not a complete solution, similar schemas are
already in used on the Internet. See the problem of mail relaying as an example.)
7
Another argument in favor of clear text execution is that of protecting the server. Or at least, improving the
server owner's trust in the agent it runs. Indeed, agents with code impossible to understand do not really
contribute to enhancing mutual trust.
MTA SZTAKI, Department of Distributed Systems 35
MTA SZTAKI Technical Report TR 2000-1
unique identifier of the instruction executed. The second is the value of input
variables for black statements and empty for white ones.
The algorithm requires the host to store the trace generated and to send a hash of it
along with the agent when it leaves the host. From this information, tampering can be
proved upon suspicion.
The main disadvantage of this approach is that traces are very large, even in
compressed form. Moreover, the hosts must archive them (at least until a pre-
determined period of time), which is really inconvenient for any host. It can indeed
result in that most of the resources of the hosts are occupied by tracing and the
archives of previously traced executions.
Moreover, tracing clearly reduces efficiency and in its current form it cannot handle
multi-threaded agents.
8
Some advocates [49] often claim that the object-oriented approach does not have a killer application either,
still it is well accepted and widely used. Although, only after a couple of ten years of childhood period.
While this statement is questionnable as several textbooks provided clear examples for the advantages of
OOP (e.g., the classical GUI example), it is true that these applications can also be implemented in more
traditional ways.
MTA SZTAKI, Department of Distributed Systems 38
MTA SZTAKI Technical Report TR 2000-1
sum of them, as does the mobile approach. It is a question, however, whether there
exist an application that really needs solutions to all, or even, to a significant subset of
these problems.
Finally, a more abstract, conceptual comment. Mobility, in a sense, helps reducing
design risk. We mean that mobility allows the decisions about the distribution of code
components to be pushed toward the end of the development effort. Clearly, this can
help to achieve better design (and possibly better performance), as decisions are made
when more is known about the individual components’ efficiency.
3 Standardization Efforts
This section gives a very brief summary of the different standardization efforts related
to agent and mobile agent technologies. It is needless to discuss the advantages of
method. The result (if any) travels back to the initiator in a similar way. The travel of
the call and the parameters is mediated by the RMI services running one the hosts.
The initiator talks to the daemon on the local server, while the called object interacts
with the RMI service of the remote host. Inter-host communication is managed by the
daemons. It is, in a sense, similar to the way CORBA and DCOM work.
The main problem with Java RMI technology is that it only provides a low-level
communication infrastructure. The syntax and the content of the messages are not
defined (or only in a very poor form). While it is not impossible to express ontologies
in the form of object and type hierarchies, it is clearly not the ideal toolkit for e.g.,
knowledge exchange. These are provided by the standards discussed below. An
important aspect, however, is that Java RMI can provide a basis for the
implementation of content-level standards.
3.1.2 KQML
The Knowledge Query and Manipulation Language (KQML) is the oldest
standardized agent communication language (ACL) [43]. It was developed by the
DARPA's knowledge sharing effort (KSE) for inter-agent information exchange [44].
Its main goal is to provide ways for agents with limited knowledge about each other to
interact, even if they are not able to understand one other's language. A minimal
requirement for this case is to realize the incompatibility. Moreover, the structure of
KQML makes the content's format and ontology explicit, thus, providing a way to
find an appropriate interpreter.
Even though, KQML was designed for intelligent agents, that is, for AI software
components, it had been the de facto standard for inter-agent communication for
several years. It was true, despite the fact that it never reached recommendation level
(it is still just a draft or beta-specification). Its position was recently shaken by FIPA
ACL (see Section 13.1.3), the another communication standard in the works.
KQML does not define the way the communication channel is established or
implemented. It simply specifies its requirements. These requirements can be fulfilled
by most of the common Internet protocols, therefore implementations over sockets or
Java RMI are possible. KQML does not define a rigorous content format either. It
only provides a framework to describe the basic parameters of communication, such
as the sender, the receiver, the identifier of the conversation, the ontology and the
content format. Most importantly it introduces another property, however. Namely,
the property of the communicational act. This is based on a simplified form of the
speech acts theory that puts the messages exchanged during a conversation into a
larger context and describes them as actions to achieve something. Such acts can be,
for example, inform, reply, tell, ask, achieve, deny, etc.
While the KSE left the actual content format to the application developer, it also
defined a KQML-related standard to express the knowledge. This standard is the
Knowledge Interchange Format (KIF) that will not be discussed here, mainly due to
the fact that it is basically not used in context of mobile computation [41]. Its
function, on the other hand, is similar to that of XML (see Section 13.1.4), but for a
limited application domain.
3.1.4 XML
The Extensible Markup Language (XML) is not an agent communication standard
[80]. It is a general Internet markup language, defined by the World Wide Web
Consortium (W3C). Its goal is to provide a powerful way to structure data on the
Internet. Therefore, it is not exactly a communication standard either, but a format to
describe content. Moreover, in a sense, it is a method to define ontologies and thus to
implement common understanding between agents of different applications or
vendors.
Just like the Hypertext Markup Language (HTML), XML builds on top of the
Standardized General Markup Language (SGML). It follows shares its tree-like
structure composed of tagged elements. XML is an important industry standard for
markup.
It is important from our point of view for two reasons. First, it provides the lacking
content definition element in the row of inter-agent communication standards.
Seconds, it has been already used or supported by several mobile agent platforms (see
Hive in Appendix 17.2 and Section 14.1.6 for more).
As the work was carried out as an OMG effort, the MASIF specification builds on top
of CORBA concepts and defines interoperability between MASIF compliant mobile
platforms and CORBA [15].
Above all of these, the main concerns of MASIF are agent management
(administration) and the way an agent is found on the network. Therefore, MASIF
provides a CORBA interface (AgentSystem) for the administration of an agent server
and the agents running on it. Ideally, this interface allows for the administration of a
given agent system from a remote machine, thus making possible to administer the
execution environments of a whole domain from a single place. MASIF also specifies
an AgentFinder interface. Networks of objects implementing this interface make the
location of local and remote agents possible. Due to the fact that MASIF deals with
finding agents on the network, it is also concerned with naming issues. It proposes
standard formats for globally unique agent system and agent names.
The MASIF specification makes a step toward implementation level agent
standardization, too. While it is explicitly stated that MASIF does not want to specify
a code level standard, canonical codes are introduced for agent systems, agent
programming languages and for transportation mechanisms. These codes could server
as stubs for later efforts to implement bridges or cross-compilers.
several demo and test applications in them and collected our findings. During our
investigation, our main concern was the KNIXMAS system, that is, the given system's
applicability to our goals. As a consequence, some systems that are really important
from a theoretical or from general programming perspective, and others which are
considered to be 'one of the bests' or 'one of the most popular' according to common
evaluation, may have received a relative low score as they did not fit into our
envisioned framework.
The results of our experiments are reported in the following paragraphs. First we
present a summary of the main aspects of our study. This will be followed by a brief
description of each system we had selected for further investigation. After this we
provide the detailed results of our investigation, listing all the surveyed aspects and
the systems' performance or support concerning the aspect. Then we summarize our
impressions about every system. Finally, we conclude by selecting a surveyed system
to implement mobile agents in the KNIXMAS system.
releases. Therefore, systems supporting the most up-to-date versions were ranked the
highest.
Another important concern was the ease of installation. The KNIXMAS system must
rely on an underlying infrastructure that is relatively easy to deploy. Otherwise this
supporting layer could become a major obstacle in front of research organizations
tending to join the cooperative environment.
4.1.3 Documentation
The next aspect to study was the amount and quality of the supported documentation.
This aspect is not really important concerning the final performance of the
KNIXMAS system, but it has a significant effect on the development process and thus
on the final outcome of the project. Clearly, an undocumented or poorly documented
system may prove to be nearly unusable, even though, its promises receive the highest
ranking on practically all aspects. Therefore, we have preferred well-documented
systems, possibly with an extensive set of example code. We must note, however, that
our experiments have been carried out on the free versions of the selected systems. As
a consequence, our results may not be appropriate for commercial releases.
the long term acceptance or rejection of the mobile technology. It is also important,
however, from the point of view of the KNIXMAS system.
The KNIXMAS system is implemented over public networks (i.e., over the Internet);
therefore the involved hosts should be protected against malicious (e.g., faked) agents.
The information and the agents communicated between KNIXMAS hosts running
mobile systems must also be secured. Therefore, security issues of category I and IV
have to be solved by the selected platform. Category II issues (the protection of a
group of hosts) is not vital, but preferable. The protection of agents against hosts
(category III issues), however, is not required, as KNIXMAS agents visit only
KNIXMAS hosts and trust between partners of the same cooperative research network
is assumed. Naturally, platforms implementing agent protection too, received higher
scores.
As it was already stated in Section 12.9.2.2, we were aware of the fact that usually
actual implementations of mobile technology are not at their strength when
considering security issues. Nonetheless, we wanted to have a clear picture on what is
provided by what system.
4.2.2 Aglets
The Aglets Software Development Kit (Aglets SDK) is the experimental product of
IBM's Research Institute in Japan. It is also one of the pioneer mobile platforms that
gained such popularity that when IBM once decided to withdraw it, a world-wide
customer campaign had started and the company renewed its support. It is available
again for download from http://www.trl.ibm.co.jp/aglets/. No support is available to
our knowledge.
Aglets is another general-purpose platform, without clear focus on any application
areas. We tested Aglets SDK V1.0.3.
4.2.3 Ara
The Agents for Remote Access (Ara) system have been developed at the University of
Kaiserslautern, Germany. It is an experimental system available from http://www.uni-
kl.de/AG-Nehmer/Projekte/Ara/index_e.html. No support is available.
Ara is primarily concerned with system support for general mobile agents regarding
secure and portable execution. The application focus of Ara is on weak-
connection/high-volume systems such as wirelessly or intermittently connected
computers, or globally distributed large databases.
We tested Ara v1.0a.
4.2.4 Concordia
The Concordia platform is a commercial system, developed at the Horizon Systems
Laboratory of Mitsubishi Electric Information Technology Center, America. It is
4.2.5 Grasshopper
The Grasshopper system is another commercial product. It was developed by
Forschungsinstitut für offene Kommunikationsysteme (IKV++), Germany. A light
edition (max. 5 agents and 2 agencies) is available for evaluation at
http://www.ikv.de/products/grasshopper/. The evaluation version includes no support.
Grasshopper is a relatively new system and one of the first platforms implementing
MASIF support. Its application focus is on telecommunication applications.
We tested Grasshopper 1.2.2.
4.2.7 Mole
The Mole platform is another experimental system. It was developed at the University
of Stuttgart, Germany and available at http://www.informatik.uni-
stuttgart.de/ipvr/vs/projekte/mole.html. No support is available.
The Mole platform is relatively old. That is, it was not member of the first branch, but
it has a relatively long history. It is also a general-purpose mobile agent platform,
without expressed focus on any application area.
We tested Mole 3.0.
4.2.8 Odyssey
The Odyssey system was a commercial product of General Magic Inc, USA. It used to
be available free of charge for non-commercial use from
http://www.genmagic.com/technology/odyssey.html. General Magic had decided to
discontinue it, however. Therefore, the previous URL is no longer valid. Also, as the
platform has been dropped, no support is available for it.
General Magic Inc. was the developer of first mobile agent platform ever. This
platform was the so-called Telescript platform, whose intended use was for electronic
commerce applications. It was developed before the Internet era, therefore it mainly
operated on propriety networks and it was not publicly available. Nor the language
specification was. This closed nature caused that Telescript never got widespread.
Still, its fame was big. As Java became dominant in network applications, General
Magic decided to re-implement its 'telescript ideas' in Java. The result of this effort
was Odyssey. This was a bit delayed, however, and Odyssey never reached the level
of reputation Telescript had. Probably this contributed to its withdrawal.
We tested Odyssey v1.0Beta2.
4.2.9 Plangent
The Plangent system is a free product of the Computer & Network Systems
Laboratory, Corporate R&D Center, Toshiba Corporation, Japan. It is available from
http://www2.toshiba.co.jp/plangent/index.htm. E-mail support is available.
Plangent is an intelligent agent system that performs tasks for human users. An agent
in the Plangent system (Plangent agent) has movement and planning capabilities; it
can move around the network, determine the best course of action in various
situations, and act by itself.
It is designed to realize autonomous and flexible mobile agent architecture for wide,
open, and dynamic networks. The agents can produce their own plans (mobile codes)
by themselves using their planning functionality. The planning can be done anytime in
agents' life cycle automatically, so agents can change their own code dynamically. It
is effective for the agents to adopt their execution failures dynamically and
autonomously.
We tested Plangent v1.0b8.
4.2.10 Voyager
Voyager is a commercial product of the ObjectSpace Inc, USA. Despite its
commercial nature, Voyager is available free of charge from
http://www.objectspace.com/. The cost of this availability is that ObjectSpace does
not provide any support for the free version. That is retained for commercial users.
However, there is a public mailing list for discussion of Voyager-related issues that is
read by Voyager developers. Nonetheless, this list is not an official support forum;
answers from developers are considered unofficial.
Voyager is one of the first mobile agent platforms and surely it is the most compact
one. It is a general purpose distributed middleware that is claimed to be used at more
than 10.000 companies word-wide.
ObjectSpace Inc. does not advertise its system as a mobile system (that supports
CORBA), but as an ORB that has mobility support. They seem to be serious on this
distinction and this shows their focus.
Voyager is a modular system, including security solutions, administration tools,
transaction services, etc. Most of these modules, however, are only available in the
commercial package.
We tested the free package of Voyager 3.1.
4.3.3 Documentation
If the easy of installation signals the quality of the whole system, the amount and
quality of documentation may actually determine one's perception of the given
system. This issue, however, is a bit more complex in our case, as several
organizations consider documentation (or full documentation) to be only included in
to supported software package (e.g., in the commercial version).
MTA SZTAKI, Department of Distributed Systems 53
MTA SZTAKI Technical Report TR 2000-1
We have summarized our findings in Table 4.3, using a staring system. An ideal set of
documentation would received five stars (*****) and no documentation at all would
qualified for zero stars (nothing). To our understanding, the ideal documentation
includes a 'Getting started' manual, a documentation of the Application Programming
Interface (API) and a step-by-step tutorial of the given platform with a reasonable set
of examples.
D'Agents has a good set of well-written documentation, but parts of it are outdated
(describe the previous version, i.e., AgentTcl 1.1, instead of D'Agents 2.0). Aglets
provides good-enough API documentation, but has no tutorial. That is, the developers
have written a book on Aglets, which is, in fact, a very popular, 'must read' book, but
not included in the package. We considered this book as an option only.
The Ara platform, on the other hand, provides only a minimalist API documentation,
but has a very good tutorial. We ranked this higher than the default set of Aglets, but
the same as Concordia's documentation, which has a reasonable API description with
a moderate tutorial.
Grasshopper only provided an API documentation that we ranked as Aglets', but we
assume that the commercial package includes more. MAP and Mole have only a very
limited set of papers that we honored by a single star (*) in both cases. Odyssey
provides an API documentation similar to that of Grasshopper.
Plangent and Voyager both received four stars (****), the highest ranking among the
surveyed systems. Voyager's documentation missed the last star due to the brochure-
like nature of the set, while in the case of Plangent; we did not find the number of
examples enough.
Quality of Comment
Documentation
AgentTcl *** Well-written, but partly outdated.
(D'Agents)
Aglets ** API Doc.
A ***** book is available, however.
Ara *** Minimalist API, good tutorial.
Concordia *** APIDoc, moderate tutorial.
Grasshopper ** API Doc.
MAP * Minimalist documentation.
Mole * Minimalist documentation.
Odyssey ** API Doc.
Plangent **** Well-documented, but too few examples.
Voyager **** A bit brochure-like.
Table 4.3 Quality and amount of documentation
Strong mobility is only supported by D'Agents, Ara and Plangent. (D'Agents does not
support strong mobility for the Scheme language.) It is not surprising, however, as the
current architecture of the Java system does not make the implementation of strong
mobility possible.
It is not a contradiction that both Ara and D'Agents are supposed to be programmable
in Java, see Section 4.3.9; and that Plangent is implemented in Java. The impossibility
of strong migration is true for Java objects running in standard JVMs only. Both Ara
and D'Agents implement their core system in other language than Java and only
provide an API for Java programmers. On the other hand, Plangent is implemented in
Java, but does run agents written in a special script language (that has connections to
Java objects.) Clearly, propriety core systems can avoid the blocks in the Java VM,
preventing strong mobility.
Transparent migration is supported by the platforms providing strong mobility. It was
expected as mentioned in Section 2.4. Concordia, Grasshopper and Voyager,
however, provide a tool to overcome the burdens of non-transparent mobility. They
allow the programmer to (optionally or mandatory) specify the method on which the
execution must continue. This small facility saves a bunch of conditional branches
and preserves the clarity of the code.
One-hop vs. Strong or Weak Transparent?
Multi-hop
AgentTcl (D'Agents) Multi-hop Strong9 YES
Aglets Multi-hop Weak NO
Ara Multi-hop Strong YES
Concordia Multi-hop Weak NO, BUT…
Grasshopper Multi-hop Weak NO, BUT…
MAP Multi-hop Weak NO
Mole Multi-hop Weak NO
Odyssey Multi-hop Weak NO
Plangent Multi-hop Strong YES
Voyager Multi-hop Weak NO, BUT…
Table 4.4 Mobility classes supported by the selected mobile platforms
As we discussed in Sections 2.4 and 4.1.4, the KNIXMAS system does not need
strong mobility. Still, we ranked the platforms supporting that the highest. This
coincides with the general opinion in the mobility community. Moreover, as migration
transparency preserves the logical structure of the code (something that is needed in
KNIXMAS), we ranked platforms that has at least some steps toward it higher than
those with completely non-transparent mobility.
9
Strong in Java and Tcl, weak in Scheme.
MTA SZTAKI, Department of Distributed Systems 55
MTA SZTAKI Technical Report TR 2000-1
we have also surveyed DCOM support (besides the sake of completeness). The
importance of Java RMI support was discussed in Sections 3.1.1 and 4.1.5.
Our results are summarized in Table 4.5. We think it talks for itself. We must note,
however, that we only showed explicit support. That is, standards that may be
accessible or that are not impossible to implement bridges for are not listed. We have
only included support that is either explicitly stated by developers or that has an
explicit language construct, tool, etc. in the mobile platform.
We included, however, planned support for CORBA, in case of the D'Agents
platform, and planned support for CORBA and RMI in the case of Odyssey.
Naturally, the plans for Odyssey are no longer valid, as the whole system has been
discontinued.
CORBA DCOM Java RMI
AgentTcl (D'Agents) - - -
Aglets planned - √
Ara - - -
Concordia - - √
Grasshopper √ - √
MAP √ - -
(default)
Mole - - √
(default)
Odyssey planned - planned
Plangent - - -
Voyager √ √ √
Table 4.5 The mobile platforms' support for industry standards
10
The commercial package has more.
11
In the commercial package only.
MTA SZTAKI, Department of Distributed Systems 57
MTA SZTAKI Technical Report TR 2000-1
What is clear at the first sight is that there is no platform protecting agents from the
hosts they are being executed on. That is, support for this is described in a recent
paper (to appear in 2000) for the Mole mobile platform [38], but this feature was not
included in the version we tested. Nor it is available in the package downloadable
from the platform's home page at the time of writing. The Ara system also announced
works in this domain, but their results are not available either. It is interesting,
however, how Ara developers plan to protect their agents' code (they do not attempt to
provide data privacy). The agent's code is divided into unmutable and mutable parts
(e.g., data, etc.) and unmutable parts are digitally signed.
Concerning secure communications, some systems provide nothing. These platforms
are Concordia, Mole, Odyssey, Plangent and Voyager. This last, however, offers
protection for commercial users, in the form of pluggable industry standard packages,
such as SSL, etc. Other platforms do not currently have protection for inter-agent
communication, but work on it. These are Ara and MAP. About the first, it is to be
known that an SSL-based solution is planned.
Host Protection Agent Secure
Protection Communication
AgentTcl (D'Agents) Propriety PGP-based Nothing. Agent protection
authorization. Resource limits while in transit.
and access control.
Aglets Based on Java Sec. Manager Nothing. Integrity Checked
User & domain authentication between Servers
Fine-grained, like the JDK1.2 within a Domain
security model.
Ara Propriety model: allowances In the works. In the works. (SSL)
Limited CPU&memory usage (Non-mutable
for the agent's lifetime and per parts signed.)
place.
Agent carries a host trace.
Concordia Agent identification. Nothing. Nothing.
Resource permission.
Grasshopper Based on the Nothing. SSL
Java Security Manager.
MAP In the works. Nothing. In the works.
12
Mole Hard to know. Nothing. Nothing.
Odyssey Based on the Nothing. Nothing.
Java Security Manager.
Plangent Limited. Nothing. Nothing.
Voyager Pluggable security manager. Nothing. Nothing.13
Favors Java Security Manager.
(Access control lists.)
Table 4.8 Security solutions offered by the tested platforms
Among the ones providing some kind of secure communication, Grasshopper seems
to be the best. It provides full SSL protection for inter-agent communication and for
the channels the agents are travelling on during migration. Aglets and D'Agents only
provide means for the solution of this latter issue.
12
Promised in recent publications, but nothing in the tested version.
13
Supported in the commercial version (pluggable packages).
MTA SZTAKI, Department of Distributed Systems 58
MTA SZTAKI Technical Report TR 2000-1
Most of the platforms provide some kind of protection for the executing host. Among
the few who do not, is the MAP system. Allegedly, the complete lack of security
mechanisms is due to the infancy of the system and its developers' hands are dirty
with implementing the solutions. The other platform that provides no identifiable
security mechanism for host protection is Mole. It is strange, however, that its
developers are already busy with agent protection, but they have no solution to ensure
to hosts security. We think that the developers simply forgot to document (and
demonstrate by examples) the fact that their system makes use of Java's built-in
security mechanisms. (This forgetfulness would not be surprising, considering the
quality of documentation.)
Another class of platforms do provide host security, but only at a limited level.
Platforms belonging to this class are Plangent and Concordia. Aglets, Grasshopper,
Odyssey all provide host security based on Java's standard Security Manager.
Voyager's solution is a bit more general (it provides a pluggable security manager),
but it also favors the standard Java solution. D'Agents and Ara have propriety
solutions, based on authorization and different implementations of resource and
access control mechanisms.
From the findings described above, it is visible that the Grasshopper platform and the
Voyager system are the winners of this turn. They are, in fact, providing the services
the KNIXMAS system needs. While Voyager only includes secure communication in
its commercial version, it is nothing less than Grasshopper's evaluation licensee to the
full set of its security solutions.
itinerary à startTrip()
Ara ara_agent ara_go
ara_fork
Concordia class Agent class Itinerary
addDestination()
launchAgent()
Grasshopper abstract class Service cloneMe(), copy(), move() à
class StationaryAgent live() or specified method
class MobileAgent
MAP class Agent go() à exec()
Mole abstract class Agent migrateTo() à start()
class SystemAgent
class UserAgent
interface MobileAgent
Odyssey class Agent, class Place class Ticket, class Means
class Worker, class Task go() à live()
Plangent Actions, goto()
Preconditions, Postconditions,
A command to execute the action
Voyager Dynamic aggregation: facets moveTo() à
Mobility.of() the specified 'callback' method
Agent.of(), setAutonomous()
Table 4.10 Base constructs and migration tools in the tested systems
Table 1.1 summarizes the main language structures and primitives the mobile
programming layer of the platforms is built upon, together with the actual tools
supporting mobility. In case of multi-lingual systems, the use of the 'home platform' is
demonstrated.
Aglets, Concordia and MAP all have a single object class forming at the base of
mobile functionality. In case of Aglets, this class is called Aglets itself, while in
case of the two other platforms the name is simply Agent.
The Mole platform defines an abstract class called Agent that has two descendants
SystemAgent and UserAgent. Objects belonging to the SystemAgent class
represent agents with system level functionality (e.g. the default service agents
implemented by the platform, but application agents wanting to have a GUI
component must also be implemented this way). UserAgents are pure application
components. Moreover, the Mole system defines the MobileAgent interface.
Agents implementing this are capable of moving.
Grasshopper follows a similar logic. It defines the abstract class named Service
with two descendants, StationaryAgent and MobileAgent. Objects
belonging to the StationaryAgent class represent services in the executing
environment and are, as suggested by the naming, unmovable.
The Odyssey platform defines a wider range of classes. It first has places (Place)
and agents (Agent) representing the execution environment and the agents,
respectively. There is, however, a Worker class, too. Workers can have tasks (Task)
assigned to them, which they carry out. Tasks form an itinerary to define worker's
migrating behavior.
Voyager is object-oriented, too. In fact, it is in a way more object aware than other
systems. Its developers claim that Voyager is not a mobile platform with CORBA
support, but a CORBA ORB that supports object mobility. Indeed, Voyager can move
whatever object implementing the interface named IMobile. This is implemented
through the concept of dynamic aggregationTM. This mechanism assigns facets
(special objects) to an object during execution. Using this method an object can have
the Mobility facet assigned to it that makes it movable. Also, objects can receive
the Agent facet that makes them capable of self-initiated migration (and allows for
autonomous life-cycle management).
The basic structures of D'Agent, Ara and Plangent are somewhat different from
object-orientation. In D'Agent the agent's code is written between a block opened by
the agent_begin and closed by agent_end statements (they perform the
agent's registration and de-registration to/from the agent system, respectively). Ara
has a single statement ara_agent for the same reason that embraces the agent's
code by its parentheses. Plangent, on the other hand, is programmed through plans
that are a series of actions. The programmer can define actions comprising pre- and
postconditions and a command to execute an action. There are three levels of plan
creation. At the highest level are action definitions. Below them are script definitions
that are built on top of Java class definitions.
The platforms are also different concerning the language constructs they provide for
migration. We investigated two main questions concerning the language layer of
mobility. First, the command(s) or function call(s) to initiate migration. And second,
the way this is handled. That is, how execution resumes, how the control is returned to
the agent.
In D'Agent an agent can submit a code fragment for remote evaluation by the
agent_submit command. It can move itself, too, by agent_jump. Finally, it
can clone itself by agent_fork. As D'Agents provides transparent mobility, the
execution of the agent simply continues in case of agent_jump, while naturally, the
transferred code is just started in case of the other two options.
Ara has similar solutions. It offers the ara_go function, which transfers the issuing
agent and the ara_fork function that clones it. Having support for transparent
migration, the Ara agent behaves after moving just like a D'Agents agent does.
Communication Other
AgentTcl agent_send, agent_receive -
(D'Agents) agent_event, agent_getevent
agent_meet, get/reject/accept_meeting
tcpip_read, tcpip_write
message/meeting/event masks
Aglets class Message Synchronization, monitors.
sendMessage(), sendAsyncMessage(),
sendOnewayMessage()
– handleMessage()
Ara ara_announce, ara_meet ara_checkpoint
Concordia Java RMI Support for collaboration.
AgentGroup
Grasshopper Java RMI MASIF's full agent
class FutureResult, class MulticastResult management functionality.
listServices(),
listMobileAgents(), listStationaryAgents()
MAP sendSyncMessage(), receiveSyncMessage() MASIF's agent
getAgentList() management functionality.
Mole Java RMI -
registerMeForService(), serviceProvidersOf()
Odyssey class Petition class OdysseyApplet
meet()
Plangent - -
Voyager Java RMI + CORBA Naming Service ORB's object management
Sync/OneWay/Future.invoke(), functionality (e.g., remote
Multicast messages – Spaces architecture creation).
Distributed garbage
collection.
Grasshopper has two methods supporting code mobility. One of them is move(),
while the other is copy(). This latter copies the agent to a remote destination. Note
that the cloneMe() method produces a local copy of the agent, in the same
execution environment. After migration the agent continues execution on its live()
method, unless it was specified otherwise in the migrating method call.
MAP has probably the most straightforward language constructs. It offers a go()
method which migrates the agent to a remote host and calls its exec() method on
arrival. Similarly, in the Mole platform migration is initiated by a call to the
migrateTo() method and the start() method is activated after the agent has
arrived to its destination. On the other hand, in Odyssey places and migrations can
have means (Mean) and tickets (Ticket) that define the reason of the visit. The
move is initiated by the go() method that calls live() on arrival.
Plangent has a simple goto() command that moves the agent to the specified
execution environment. As Plangent supports transparent mobility, the execution of
the agent simply continues upon arrival. In Voyager, however, the migration initiated
by a call to the moveTo() method results in the call of the specified callback
method. The callback method is mandatory for agents that initiate their own
migration. For simple objects, however, there is no need for specifying the callback
method as they are not running in the instance of migration (as the object initiating the
migration is the one that runs – note that Voyager does not support strong mobility,
therefore threads are cannot be migrated). In this case, the execution simply continues
after performing the move on the object initiating the migration of the other.
Table 4.11 summarizes the language elements for supporting communication and the
extra features of the mobile platforms (if any).
D'Agents has plenty of communication primitives. It supports messaging with
agent_send and agent_receive and it also offers event-based
communication (although not fully implemented) by agent_event and
agent_getevent. It has meetings (agent_meet, get_meeting, etc.) and it is
also possible to specify masks for messages, events and meetings to filter out
unwanted communication. Finally, D'Agent has low-level TCP/IP support.
In Aglets communications is organized as the passing of Message objects. These
objects can be send by synchronous, asynchronous and oneway methods
(sendMessage(), sendAsyncMessage() and sendOnewayMessage()).
Upon receipt messages are handled by the handleMessage() method. As an extra,
Aglets augments its messaging model with synchronization primitives.
In Ara an agent can announce its services by ara_announce or can meet with
another agent by ara_meet. Ara's extra feature is checkpointing that is initiated by
the ara_checkpoint command. On the other hand, Concordia offers
communication facilities based on Java RMI technology, which is augmented by
support for collaboration. The base class for this extra feature is the AgentGroup.
Grasshopper's communication is also mainly based on Java RMI, but it also has
additional features. First, it supports asynchronous method invocation with the help of
the FutureResult and MulticastResult classes. These are results of
remote method calls that are empty at the beginning but are filled up as the remote
partner has finished its computation. During the execution of the remote method, the
functionality in Java. It was a usable system, even though, that its metaphors were a
bit unusual. We are sorry, however, that it is discontinued.
The Plangent platform is an exciting marriage of AI and distributed technology. It is
promising, even if not for KNIXMAS. We think, however, that it is a bit
overcomplicated that makes its use in real applications hard.
Finally, the Voyager mobile system was the 'industry star' of the first generation. It is
still a very good system, but the lack of support for agent standards, especially for
MASIF might harm it. On the other hand, it was actually never claimed to be an agent
system. It is advertised as a CORBA ORB that supports mobility. One more note, on
the public mailing list on Voyager there are approximately 5 posts per day containing
queries like 'I try to apply your example to my problem, but it would not work. This
may indicate the huge number new users, but it may indicate just as well the presence
of some problems in the system, or in the documentation. (Note, however, that the
mailing list is for licensee of the unsupported free package, so solutions to the
problems mentioned might be rather easy having the documentation.)
Table 4.12 gives a final overview of our impressions concerning the surveyed
platforms.
of the systems between recent theoretical results and implemented solutions. On the
other hand, it is not surprising that the current platforms provide little to protect the
agents from the hosts they are running on, as this is still an open theoretical research
issue.
Finally, we would like to point out a system for future use in the KNIXMAS system.
The Odyssey system is out of question, due to its discontinued support and
development. So is Ara for the same reason and due to the fact that it does not support
our preferred language, Java. AgentTcl (D'Agent) has also only limited support for the
Java language and basically no support for any of the distributed industry standards.
Therefore we vote against the D'Agent systems as well.
The Mole system has proved to be too experimental and unstable, which means that
we cannot afford to build on it. The Plangent platform is really exciting, but includes
too many AI-like features that would be unused in KNIXMAS and therefore would
make its use inefficient. Concordia has neither CORBA, nor DCOM support that
makes it inappropriate for our purposes.
The arguments above leave us with four systems: Aglets, MAP, Grasshopper and
Voyager. At one level, any of these systems would be appropriate. The Aglets system,
however, is a bit outdated now; we need something more serious. The MAP platform
would qualify, but the lack of security mechanisms makes us alerted. Therefore, we
drop both of these systems.
It is hard to decide between Grasshopper and Voyager. Grasshopper is pretty
expensive, except the free evaluation version. On the other hand, Voyager has an
unsupported free package. Putting money away, the Grasshopper system has wider
support for agent standards (in fact, Voyager does not support any), while Voyager
has 'history' and an established (online) user community.
For these reasons, we have selected Voyager, as the mobile platform for the
KNIXMAS project.
5 Conclusions
We started out this report by outlining major trends in software engineering. These
included the spread of distributed computation, the increased localization of control
(e.g. in component and agent architectures); ubiquitous and ambient computing and
finally the renaissance of applied AI.
These observations were backed up by an overview of the underlying technologies.
We briefly summarized the essence of the agent-based approach and multi-agent
systems, discussed (distributed) component architectures, and introduced the idea of
mobile software components. Having all these done, we identified our preferences
concerning the KNIXMAS system. We concluded that we need a platform that
supports both mobility and industry standard distributed architectures. Among the
latter, we preferred CORBA with a possible compromise towards DCOM.
Before set out to find the appropriate infrastructure, we summarized what is to be
known about mobile software systems. Our intention with this was to outline the
major issues to be surveyed in mobile platform implementations. Our summary
included the background and major precursors of the concept, discussed the general
architecture and basic definition of the main notions. We have surveyed the most
common application areas of mobile technology, augmented by comments from the
point of view of their applicability to the future KNIXMAS system. This part of the
report also contained a detailed classification of different mobile techniques and
design approaches. We devoted a section to communication issues of mobile software
systems, as these form one of the most important areas of distributed system
development. We also investigated the state of the art in mobile software security,
discussing both obvious and hard problems with both solved and open issues. We
ended this general overview with a brief argument on why one should choose to use
mobile solutions in application development.
After defining the main concepts and identifying the hot issues, we devoted a short
section to related standards. We briefly discussed the Java RMI technology, the
KQML and FIPA ACL languages, as possible means of standardized inter-agent
communication. We also introduced the MASIF standard by the Object Management
Group (OMG), one of future's base standards.
Clarifying every important detail, we finally started to investigate concrete systems to
find one to use when developing the KNIXMAS system. In the first round, we have
selected 10 platforms among the approximately 30 available. These systems were
AgentTcl (D'Agents), Aglets, Ara, Concordia, Grasshopper, MAP, Mole, Odyssey,
Plangent and Voyager. We have downloaded and installed all of these systems,
carried out experiments with them, testing their usability concerning KNIXMAS. We
have devoted special attention to the following aspects: availability and support; ease
of installation; support for different platforms; amount and quality of documentation;
supported classes of mobility; supported industry standards; supported agent
standards; available administration tools; solutions provided for security issues;
programming languages available for use; general language constructs and those
supporting migration and language elements for communication.
Two systems have been excluded as their support and development was stopped. Our
results immediately excluded four more. This left us with four platforms: Aglets,
MAP, Grasshopper and Voyager. Due to different reasons, we preferred the later two,
but selected Voyager, because it is much cheaper and because it is backed with a
worldwide user community. Therefore, we are going to implement the mobile parts of
the KNIXMAS system on top of this platform.
6 References
[1] Aglets SDK V1.0.3, IBM Research Institute of Japan, http://www.trl.ibm.co.jp/aglets/
[2] Ara v1.0a, University of Kaiserslautern, Germany, http://www.uni-kl.de/AG-
Nehmer/Projekte/Ara/index_e.html
[3] Avvenuti M., Puliafito A., Tomarchio O.: W-MAP: A Web Accessible Mobile Agent Platform.
In Austrian-Hungarian Workshop on Distributed and Parallel Systems (DAPSYS98),
Budapest (Hungary), September 1998, http://sun195.iit.unict.it/Papers/dapsys98.ps.gz
[4] Baumann J., Hohl F., Rothermel K., Straßer M.: Mole - Concepts of a Mobile Agent System,
World Wide Web, Vol. 1, Nr. 3, pp. 123-137, 1998, http://www.informatik.uni-
stuttgart.de/cgi-bin/ncstrl_rep_view.pl?/inf/ftp/pub/library/ncstrl.ustuttgart_fi/TR-1997-15/TR-
1997-15.bib
[5] Baumann J., Radouniklis N.: Agent Groups in Mobile Agent Systems. In: H. König, K. Geihs
and T. Preuß (eds.) Distributed Applications and Interoperable Systems (DAIS'97), Chapman
& Hall, pp. 74-85, 1997, http://mole.informatik.uni-stuttgart.de/daisbaumann.ps.gz
[6] Box D.: Lessons from the Component Wars: An XML Manifesto, DevelopMentor, September
1999., The XML Magazine, http://www.devx.com/whitepapers/microsoft/xml2/default.asp
[7] Cabri G., Leonardi L., Zambonelli F.: How to Coordinate Internet Applications based on
Mobile Agents, Proceedings of the 7th IEEE Workshop on Enabling Technologies:
Infrastructures for Collaborative Enetrprises (WETICE ’98), Workshop on Coordination
Architectures for Distributed Web Applications, Stanford, USA, IEEE CS Press
[8] Cabri G., Leonardi L., Zambonelli F.: Reactive Tuple Spaces for Mobile Agent Coordination,
Proceedings of the 2nd International Workshop on Mobile Agents (MA 98), September 1998,
Springer Verlag LNCS N. 1477, http://sirio.dsi.unimo.it/MOON/papers/ma98.pdf
[9] Carr D. F.: Maturity and Availability, Web Week, Volume 3, Issue 7, March 24, 1997 ©
Mecklermedia Corp.
[10] Carzaniga A., Picco G. P., Vigna G.: Designing Distributed Applications using Mobil Code
Paradigms. In Proceedings of the 1997 International Conference on Software Engineering,
1997.
[11] Chavez A., Moukas A., Maes P.: Challenger: A Multi-agent System for Distributed Resource
Allocation, Proceedings of Agents '97 Conference, ACM, 1997.
[12] Ciancarini P., Knoche A., Tolksdorf R., Vitali F.: PageSpace: An Architecture to Coordinate
Distributed Applications on the Web, Fifth International World Wide Web Conference, May 6-
10, 1996, Paris, France, http://www5conf.inria.fr/fich_html/papers/P5/Overview.html
[13] Ciancarini P., Omicini A., Zambonelli F.: Coordination Models for Multi-Agent Systems,
AgentLink News Issue 3, July 1999, http://www.agentlink.org/newsletter/3/newsletter3.pdf
[14] Concordia v1.1.2, Horizon Systems Laboratory, Mitsubishi Electric Information Technology
Center America, Phones, http://www.meitca.com/HSL/Projects/Concordia/"
[15] CORBA, Common Object Request Broker Architecture, The Object Management Group,
http://www.omg.org/corba/
[16] Crystaliz Inc., General Magic Inc., GMD FOKUS, IBM Corp., Mobile Agent Facility
Specification, Joint Submission, The Open Group, 1997.
[17] Cugola G., Ghezzi C., Picco G. P., Vigna G.: Analyzing Mobile Code Languages. In Special
Issue on Mobil Objects Systems, LNCS. Springer-Verlag, 1997.
[18] D'Agents v2.0, Dartmouth College, USA, http://www.cs.dartmouth.edu/~agent/
[19] DCOM, The Distributed Component Object Model, Microsoft Inc.,
http://www.microsoft.com/com/tech/DCOM.asp
[20] Domel P., Lingnau A., Drobnik O.: Mobile Agent Interaction in Heterogenous Environment,
Proceedings of the 1st International Workshop on Mobile Agents, Berlin, LNCS 1219,
Springer-Verlag, 1997.
[21] FIPA, Foundation for Intelligent Physical Agents, http://drogo.cselt.stet.it/fipa/index.htm
[22] Fuggetta A., Picco G. P., Vigna G.: Understanding Code Mobility, IEEE Transactions on
Software Engineering, http://www.elet.polimi.it/people/vigna/listpub.html
[23] Gelernter D., Carriero N.: Linda in Context. Communications of the ACM, 32(4): 444-458,
1989.
[24] General Magic Inc., Introduction to the Odyssey API, http://www.generalmagic.com/
technology/ odyssey.html
[25] Ghezzi C., G. Cugola, G. P. Picco, G. Vigna. A Characterization of Mobility and State
Disrtibution in Mobile Code Languages. In Proceedings of the 2nd ECOOP Workshop on
Mobile Object Systems ("Agents on the Move"), 1996.
[26] Ghezzi C., Vigna G.: Mobile Code Paradigms and Technologies: A Case Study. In
Proceedings of the 1st International Workshop of Mobile Agents, LNCS 1219, Springer-
Verlag, 1997.
[27] Grasshopper 1.2.2, Forschungsinstitut für offene Kommunikationsysteme (IKV++), Germany,
http://www.ikv.de/products/grasshopper/
[28] Gray R. S., Kotz D., Cybenko G., Rus D.: Agent Tcl. In William Cockayne and Michael Zyda,
editors, Mobile Agents: Explanations and Examples, Manning Publishing, 1997. Imprints by
Manning Publishing and Prentice Hall,
http://agent.cs.dartmouth.edu/papers/gray:bookchap.pdf
[29] Gray R. S.: Agent Tcl: Alpha Release 1.1, December 1995. Available at
http://agent.cs.dartmouth.edu/manual/doc.1.1.ps.gz
[30] Gray R. S.: AgentTcl: A flexible and secure mobile agent system, PhD thesis, Dartmouth
College, 1997, ftp://ftp.cs.dartmouth.edu/TR/TR98-327.ps.Z
[31] Gray R.S, Kotz D., Cybenko G., Rus D.: D'Agents: Security in a multiple-language, mobile-
agent system. In Giovanni Vigna, editor, Mobile Agents and Security, Lecture Notes in
Computer Science, Springer-Verlag, 1998, http://agent.cs.dartmouth.edu/papers/gray:security-
book.pdf
[32] Gulyás L., Láng L., Nagy F., Nagy P., Tejfel M., Tenczer R.: Practical Comparison of Mobile
Software Systems, In Proceedings of the 4th National Object-Oriented Conference, Budapest,
Hungary, 2000. (In Hungarian)
[33] Gulyás L.: Application of Stigmergy - A Coordination Mechanism for Mobile Agents,
Proceedings of the 1st Hungarian National Conference on Agent-Based Computing (HUNABC
'98), Springer Budapest, 1999., pp 143-154.
[34] Gulyás L.: Mobile Code, Mobile Agents. In Proceedings of Networkshop '98, Hungarian
National Conference, Gyõr, 1998. (In Hungarian)
[35] Gulyás L.: Mobile Software Environments - A Survey, in Proceedings of Networkshop '99,
Nyíregyháza, 1999. (In Hungarian)
[36] Gulyás L.: Mobile Software Systems, Java 2 - A Travelling Guide for Programmers, Nyékyné
dr. Gaizler Judit (ed), 1999.Vol 2, pp 324-341. (In Hungarian)
[37] Harrison C.G., Chess D.M., Kershenbaum A.: Mobile Agents: Are they a good idea?, IBM T.J.
Watson Research Report, 1995.
[38] Hohl F.: A Framework to Protect Mobile Agents by Using Reference States . In: Proceedings
of the 20th International Conference on Distributed Computing Systems (ICDCS 2000). To
appear, http://mole.informatik.uni-stuttgart.de/papers/icdcs2000hohl.pdf
[39] JavaSpacesTM Technology, Sun Microsystems Inc, USA,
http://java.sun.com/products/javaspaces/index.html
[40] Johansen D., van Renesse R., Schneider F. B.: An introduction to the TACOMA Distributed
System - Version 1.0. Technical Report 95-23, "University of Tromsø and Cornell University",
June 1995.
[41] KIF, Knowledge Interchange Format, http://www.cs.umbc.edu/kif/
[42] Kleinman R.: JiniTM and Enterprise JavaBeanTM Technologies: The Distributed Client Meets
the Distributed Service, Ask Espresso Man, Java Developer Connection,
http://developer.java.sun.com/
[43] KQML, Knowledge Query and Manipulation Language, http://www.cs.umbc.edu/kqml/
[44] KSE, The ARPA Knowledge Sharing Effort, http://www.cs.umbc.edu/kse/
[45] Láng L.: A Survey of Mobile Agent Systems, M.Sc. Thesis, Loránd Eötvös University of
Sciences, Budapest, Hungary, 2000. (In Hungarian)
[46] Lange D. B., Chang D. T.: IBM Aglets Workbench, Programming Mobile Agents in Java,
White Paper, IBM Corp., September 1998., http://www.trl.ibm.co.jp/aglets/
[47] Lange D.B.: Java Aglet Application Programming Interface (J-AAPI), White Paper, IBM
Tokyo Research Laboratory, 1997.
[48] Lazar S., Weerakoon I., Sidhu D.: A Scalable Location Tracking and Message Delivery
Scheme for Mobile Agents, Technical Report, Maryland Center for Telecommunications
Research, University of Maryland Baltimore County, 1998.
[49] Milojicic D.: Mobile agent applications, Trend Wars, IEEE Concurrency, Vol. 7, No. 3, July-
September 1999. http://computer.org/concurrency/pd1999/pdf/p3080.pdf
[50] Minar N., Kramer K. H., Maes P.: Cooperating Mobile Agents for Mapping Networks. Agents
Everywhere, L. Gulyás, G. Tatai (eds.), Proceedings of the 1st Hungarian National Conference
on Agent-Based Computing, Springer Hungary, 1999.
http://lcs.www.media.mit.edu/people/nelson/research/routes-cia/
[51] Minar N.: Computational Media For Mobile Agents, http://nelson.www.media.mit.edu/
people/ nelson/research/dc/, 1996.
[52] Mobile Agent Platform (MAP) v2, University of Catania, Italy, http://sun195.iit.unict.it/MAP/
[53] Mole 3.0, University of Stuttgart, Germany, http://www.informatik.uni-
stuttgart.de/ipvr/vs/projekte/mole.html
[54] Nagy P.: Multi-Agent Coordination in Mobile Agent Systems, M.Sc. Thesis, Loránd Eötvös
University of Sciences, Budapest, Hungary, 2000.
[55] Nwana H. S., Lee L., Jennings N. R.: Co-ordination in Multi-Agent Systems, Software Agents
and Soft Computing - Towards Enhancing Machine Intelligence, LNAI 1198, Springer-Verlag
1997.
[56] ObjectSpace Inc., Voyager TM Technical Overview, Version 1.0, December 1997,
http://www.objectspace.com/Voyager
[57] Odyssey v1.0Beta2, General Magic Inc., USA,
http://www.genmagic.com/technology/odyssey.html [no longer valid]
[58] OMG MASIF, Mobile Agent Systems Interoperation Facilities, The Object Management
Group, ftp://ftp.omg.org/pub/docs/orbos/98-03-09.pdf
[59] Omicini A., Zambonelli F.: TuCSoN: A Coordination Model for Mobile Agents, Journal of
Internet Research, Vol. 8, No. 5, pp. 400-413, 1998.
[60] Parunak H. V. D.: “Go to the Ant”: Engineering Principles from Natural Multi-Agent Systems,
Annales of Operations Research, special issue on Artificial Intelligence and Management
Science, 1997.
[61] Peine H.: An Introduction to Mobile Agent Programming and the Ara System ZRI report 1/97,
Dept. of Computer Science, University of Kaiserslautern, Germany, 1997. http://www.uni-
kl.de/AG-Nehmer/Projekte/Ara/Doc/intro-prog.ps.gz
[62] Peine H.: Security Concepts and Implementation for the Ara Mobile Agent System, 7th IEEE
Workshop on Enabling Technologies: Infrastructure for Collaborative Enterprises, June 17-
19th, Stanford University, USA, 1998. http://www.uni-kl.de/AG-
Nehmer/Projekte/Ara/Doc/ara-security.ps.gz
[63] Picco G. P., Roman G-C., McCann P. J.: Expressing Code Mobility in Mobile UNITY, In
Proceedings of the 6th European Software Engineering Conference held jointly with the 5th
ACM SIGSOFT Symposium on the Foundations of Software Engineering (ESEC/FSE '97) (M.
Jazayeri, H. Schauer, eds.), LNCS 1301, Springer 1997.
[64] Plangent v1.0b8, Computer & Network Systems Laboratory, Corporate R&D Center, Toshiba
Corporation, Japan, http://www2.toshiba.co.jp/plangent/index.htm
[65] Puliafito A., Tomarchio O.: Advanced Network Management Functionalities through the use
of Mobile Software Agents. In 3rd International Workshop on Intelligent Agents for
Telecommunication Applications (IATA'99), Stockholm (Sweden), August 1999,
http://sun195.iit.unict.it/Papers/iata99.ps.gz
[66] Rácz A.: A Survey of Mobile Agent Systems, M.Sc. Thesis, Loránd Eötvös University of
Sciences, Budapest, Hungary, 1998. (In Hungarian)
[67] Riordan J., Schneier B.: Environmental Key Generation Towards Clueless Agents, in:
Giovanni Vigna (Ed.): Mobile Agents and Security. pp 15-24. Springer-Verlag, 1998.
[68] RMI, The Java Remote Method Invocation API, Sun Microsystems Inc, USA,
http://java.sun.com/products/jdk/rmi/index.html
[69] Sahai A., Morin C.: Enabling a Mobile Network Manager (MNM) through mobile agents, In
Proceedings of the Mobile Agents '98 Conference, LNCS, Springer-Verlag, 1998.
[70] Sander T., Tschudin C. F.: Protecting Mobile Agents Against Malicious Hosts, in: Giovanni
Vigna (Ed.): Mobile Agents and Security. pp 44-60. Springer-Verlag, 1998.
[71] Sander T., Tschudin C.: On Sofware Protection via Function Hiding. In: D. Aucsmith (Ed.):
Information Hiding II. Proceedings of the Second International Workshop, IH'98. Springer-
Verlag, Germany, 1998
[72] Schmidt D. C.: Overview of CORBA, http://www.cs.wustl.edu/~schmidt/corba-overview.html
[73] Sewell P., Vitek J.: Secure composition of insecure components. In Proceedings of the 12th
IEEE Computer Security Foundations Workshop (CSFW-12), Mordano, Italy, June 1999.
[74] Strasser M., Baumann J., Hohl F.: MOLE. A Java Based Mobile Agent System. In
Proceedings of the 2nd ECOOP Workshop on Mobile Object Systems ("Agents on the Move"),
1996.
[75] Sun Microsystems, Inc. The Java ™ Technology Home Page. http://java.sun.com/
[76] Vigna G.: Cryptographic Traces for Mobile Agents, in: Giovanni Vigna (Ed.): Mobile Agents
and Security. pp 137-153. Springer-Verlag, 1998.
[77] Voyager 3.1, ObjectSpace Inc., USA, http://www.objectspace.com/
[78] Voyager ORB 3.2 Developer Guide, ObjectSpace Inc. USA,
http://www.objectspace.com/products/documentation/voyager_html_docs/orb/index.htm
[79] Wong D., Paciorek N., Walsh T., DiCelie J., Young M., Peet B.: Concordia: An Infrastructure
for Collaborating Mobile Agents, First International Workshop on Mobile Agents 97
(MA'97)", Berlin, Germany, April 7 - 8, 1997,
http://www.meitca.com/HSL/Projects/Concordia/MobileAgentConf_for_web.htm
[80] XML, The Extensible Markup Language, The World Wide Web Consortium,
http://www.w3.org/XML/
[81] Young A.; Yung M.: Encryption Tools for Mobile Agents: Sliding Encryption, E. Biham (Ed.):
Fast Software Encryption. Proceedings of the 4th International Workshop, FSE'97, Haifa,
Israel, January 20-22, 1997., LNCS 1267, Springer-Verlag, 1997
7 Appendices
7.3 Abbreviations
ACCU Agent Communication Co-ordination Unit
ACL Agent Communication Language
ADI Administrator Interface
AI Artificial Intelligence
API Application Programming Interface
Ara Agents for Remote Access (University of Kaiserslautern, Germany)
ARPA Advanced Research Project Agency (USA)
ATP Aglets Transfer Protocol
CoD Code on Demand
COM Component Object Model
TM
CORBA Common Object Request Broker Architecture
CSCW Computer Supported Cooperative Work
DCOM Distributed Component Object Model
DDFC Distributed Document Component Facility
DKDB Dynamic Knowledge Data Base
DoS Denial of Service
DSU Decision Support Unit
EJBTM Enterprise JavaBean
FIPA Foundation Intelligent Physical Agents
FIPA ACL FIPA Agent Communication Language
GMAE Global Multi-Agent Environment
GUI Graphical User Interface
GUID Globally Unique Identifier
HTML Hypertext Markup Language
IBS Intelligent Base System
IDL Interface Definition Language
IIOP Internet Inter-ORB Protocol
IKB Intelligent Knowledge Broker
IP (address) Internet Protocol
TM
Java RMI Java Remote Method Invocation API
TM
Java
JiniTM
JMS Java Messaging Service API