An Overview of Mobile Software Systems: L. Gulyás, L. Kovács, A. Micsik, B. Pataki, I. Zsámboki

An Overview of Mobile Software Systems
L. Gulyás, L. Kovács, A. Micsik, B. Pataki, I. Zsámboki
Department of Distributed Systems,

MTA SZTAKI,
Computer and Automation Research Institute
of the Hungarian Academy of Sciences
MTA SZTAKI Technical Report

TR 2000-1
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
MTA SZTAKI, Department of Distributed Systems 2

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 Trends in Software Engineering

This subsection briefs on recent advances of software technology. Although, the
points made here are rather everyday knowledge, we think this briefing is useful to
put our more specific subject (mobile computation) in its right context. Moreover, the
following discussion is deliberately remains on the conceptual level. The more
technical issues are kept for the following subsection.
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.)
Table 1.1 Increasing localization in software engineering methodologies [60]

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.
1.1.3 Artificial Intelligence Goes Mainstream

As a result of increased localization, components are more and more left on ‘their
own’. That is, software components need means to implement their assigned
autonomy to solve the task delegated to them. As autonomous problem solution is the
domain of artificial intelligence research, there is a tendency to incorporate AI
technologies into everyday software engineering under the cover of the ‘autonomous
agent’ label. It must be noted, however, that as autonomous problem solution is a
rather broad term, the techniques needed to implement it might vary in a pretty wide
range. In some cases it only means timely reactions to the changing environment (e.g.
to network failures), while on the other end it can well mean heavy-duty problem
solvers at work.
The KNIXMAS system incorporates both simple reactive techniques (e.g., to adapt to
the network's performance) and complex, expert system-based modules. The former is
used in network aware modules such as the agent dispatcher, adaptive blackboard,
while the latter is exploited in Intelligent Base Systems (IBSs). More specifically, in
the IBSs Decision Support Units (DSUs) and Supervisor Expert Systems (SXPSs) use
these techniques.
The KNIXMAS system also includes adaptive techniques for local and global
feedback mechanisms that are located somewhere in between the two extremes
mentioned above. The intelligent search and information retrieval agents (Intelligent
Knowledge Brokers, IKBs) also make use of AI solutions.
1.1.4 Ubiquitous and Ambient Computing

Another twist is ubiquitous and ambient computing which is, the same time, the result
and the driving force of the tendencies described above. With computing machinery
occupying our everyday gadgets the slogan 'the network is the computer' gains
another meaning and another level of importance. On one hand, this development
would not be possible without the shift in the common understanding of computation
caused by the distributed approach. On the other hand, this process will further stem
the efforts put in the development of different solutions to deal with extremely
distributed systems, implementing applications in traditionally unvisited domains.
While the KNIXMAS system is not currently addressing issues closely related to
ambient computing, its very nature – i.e., providing uniform, location-independent
access to information and knowledge – is logically analogous to ubiquitous
computing. Although, unlike in the case of popular ubiquitous and ambient scenarios,
the KNIXMAS architecture is based on traditional computing machinery (e.g.,

'regular' computers: PCs and workstations) its highly distributed nature makes
considering related technologies (e.g. mobile computing) worth exploring.
1.2 Technical Background

This subsection summarizes the middleware technologies used in common distributed
applications. This overview, in fact, provides the technical background for the
tendencies described above. As a thorough and detailed overview is out of the scope
of this report, it is restrained to only briefly overview the most important related
technologies.
1.2.1 (Distributed) Component Architectures

The concept of components is an 'augmented' version of industrial object-oriented
technology. Its primary goal is to enable collaboration and cooperation amongst
software development organizations. In essence, these architectures attempt to provide
an infrastructure on which software components built by different vendors can be
easily arranged into a fruitful application. That is, its primary function is to act as glue
between multiple pieces of software.
Distributed component architectures take this approach a step further in conformance
with the distribution trend described in the previous section. It has two goals: to
simplify system development and maintenance by creating reusable pieces of code (as
does component technology in general); and to allow objects installed on different
computers to communicate over a network. There are distributed object systems for
particular programming languages (e.g., EJB, see Section 1.2.1.3); and there are
architectures which require the creation of language-independent interfaces (as does
CORBA and DCOM, see Section 1.2.1.2 and Section 1.2.1.1).
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).
Figure 1.2.1 The OMG Reference Model [72]

Object Services are domain independent interfaces that help the management of and
interaction between different objects. They include functionality as the discovery of
other available services (e.g., Naming or Trading service).
Common Facilities are horizontally oriented component facilities that support a wider
range of end-user applications (e.g., the Distributed Document Component Facility,
DDFC). Domain Interfaces are oriented toward specific application domains. Finally
Application Interfaces consist of the components of a particular application.
All OMA components are linked together by the Object Request Broker (OMG) or as
it is commercially named, by CORBATM. This architecture automates many common
network programming tasks such as object registration, location, and activation;
request de-multiplexing; framing and error-handling; parameter marshalling and
demarshalling; and operation dispatching.
CORBA is defined at the source code and specification level. The binaries
implementing the components are vendor-specific, thus can differ significantly from
one another. Moreover, ORBs implementations (and architectures) are also non-
standardized. On one hand, this goes against the 'off-the-shelf components' trend, but
on the other, it provides for wider and easier access, as vendors are encouraged to
transform their proprietary solutions into CORBA compliant ORBs.

CORBA ensures interoperability between such different platforms, architectures and

implementations through different protocols and interface languages. Perhaps the
most important protocol is the Internet Inter-ORB Protocol (IIOP) that is the lingua
franca of the ORBs. On the other hand, programmers must provide an interface
description of their components in order to be able to deploy them into CORBA
ORBs. The language for these descriptions is the Interface Definition Language
(IDL). IDL is the 'common virtual layer' between CORBA components, based on
which interoperation becomes possible. CORBA also have support for dynamic
discovery of component services.
1.2.1.3 EJB and Jini

The Enterprise JavaBean (EJB) technology is the distributed component architecture
for the Java platform, developed by the Sun Microsystems Inc. The core metaphor of
the technology is the (Enterprise) JavaBean. Briefly, EJBs are Java business logic
components, which can be deployed within any application server that supports the
EJB Container API.
Java technology provides a base for the development of software independent of both
the hardware and operating system environment. EJBs extend this paradigm to the
server by providing additional independence from various legacy infrastructures such
as messaging middleware, multithreading and transaction support.
Therefore, EJB technology can be considered as a unifying layer over different
component architectures. On one hand, it is empowered by Java's built-in network
support. Moreover, besides its higher level Java Messaging Service (JMS) API, it
provides access to both CORBA and DCOM protocols for inter-container
communication.
Apart from EJBs, Sun Microsystems provides another interesting distributed
architecture. The Jini technology is focused on the unification of a collection of
services, such as intelligent devices into a Jini Federation. Jini was designed to
support ubiquitous and ambient computation. It is empowered by Java's platform
neutral computation environment, which makes it ideal for embedded applications.
Jini Federations are self-organized dynamic networks of smart components. They
intended use is in smart devices. Therefore, the technology is less appropriate for
global or wide area network applications. (On the other hand, devices in a Jini
Federation make use of novel approaches to distributed computing, such as mobile
code techniques. See Section 2.2 for the possible applications of the mobile
approach.)
Both EJB and Jini are popular language specific technologies. Although, both of them
are supporting distributed applications, they do so at different levels and using
different core assumptions. For the purposes of the KNIXMAS system, only EJBs
would be of importance. See Section 1.5.3 for a more detailed discussion.
1.3 Agents, Multi-Agent Systems

It is difficult to briefly and generally define the common term: agent. This is due to
the fact that the term is heavily (over) used in such different research fields as
philosophy, cognitive science, artificial intelligence or computer technology. In this
paragraph we introduce the term from a common base of computer science and
artificial intelligence.
According to the least constraining definition, an agent is an active entity that is

embedded in an environment, which it senses and acts upon. An agent is assumed to
be reactive, i.e. it should be capable of reacting to events in its environment. This
could mean simple answers or more complex adaptation as well.
A more constraining definition requires an agent to be autonomous. An agent's
autonomy means that it carries out its task without close surveillance (in contrast to
e.g. a word processor that is bound to the input of the user). A common interpretation
of autonomy (especially in the artificial intelligence domain) is goal-directedness, i.e.,
the agent has a goal (a task to solve, etc.) and acts independently in order to achieve it.
(Note that in this context, reactiveness ensures that the agent can carry out its task
despite dynamical changes in its environment.) Another property often associated
with autonomy (and goal-directedness) is pro-activity, which means that the agent is
not constrained to reactions to events in its environment only, but it can itself initiate
actions on its own. From now on, if without attribute, the term agent will mean an
autonomous agent.
Real applications usually contain more than a single agent. That is, they form multi-
agent systems. Multi-agent systems (MASs) can be homogenous or heterogeneous
depending on whether the participating agents belong to the same class (or more
generally, on whether they share a common goal). Another property of MASs is that
they can be open or closed that marks whether the MAS only contains agents
developed by the same programmer (vendor).
Multi-agent system development raises special problems as well. 1 These issues
usually are rooted in the agent interactions. These interactions can be direct or
indirect. In the latter case the environment mediates the interaction. Indirect
interactions can easily occur unintentionally, which makes the system unpredictable
or hard to predict.
As a consequence of these problems, an important aspect of MAS development is
coordination. Coordination accounts for the process which aims at and the effort the
agents undertake to assure that system-level constraints are not broken and that the
overall goal of the system is achieved. To achieve coordination and co-operation
among the agents there should be channeled ways of interaction. A natural way of
interaction is (peer-to-peer) communication.
In case of closed MASs, the protocol and language of the communication (c.f. Agent
Communication Language, ACL) can be proprietary, but in case of open MASs, the
use of standard communication approaches is of paramount importance. The major
existing agent communication standards are discussed in Section 3.1.
1.4 Mobile Software Systems

As mentioned above, large scale distributed systems are gaining more and more use
and importance, due to the evolution of technology and to the interest of the market. A
sound technological and methodological background, however, does not always
support their development. This is mainly due to the fact that the methods developed
for small size distributed systems do not always scale up.
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.
Component Component Component Component
Distributed System
Network Network Network

Operating System Operating System Operating System
C o r e Operating System Core Operating System C o r e Operating System
Host Host Host
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.
Component Component Component Component Component
Computational Computational Computational

Environment Environment Environment
Network Network Network

Operating System Operating System Operating System
Core Operating System Core Operating System Core Operating System
Host Host Host

Hardware
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.
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.
1.5 What Technology to Use (for KNIXMAS)?

In this section we look back at the technologies surveyed above and collate them, in
order to identify the focus of further studies. First we compare autonomous and
mobile agents. Then we study the relations between component and mobile
technologies. Finally, we decide what component (object) architecture to focus on.
1.5.1 Autonomous vs. Mobile Agents?

Mobile Static
Autonomous (Autonomous) Mobile Agent Autonomous Agent
Non-autonomous Mobile Object Traditional Object
Table 1.2 Mobility and autonomy are orthogonal.
Mobile computation is a way of implementing distributed systems. That is, its essence
is the technical possibility to move software components over the network, even under
execution. In this sense, mobility is orthogonal to autonomous agent-technology
expressed as applied artificial intelligence. That is, an autonomous agent can either be
mobile or static, while a mobile software component can either be autonomous or not
(see Table 1.2).
Figure 1.5.1 The relation between agent-based and mobile systems.

The term mobile agent introduces some confusion here as, according to the mobility
literature, it denotes a subclass of mobile software systems (see Section 2.5) and has
to do with neither rationality nor autonomy in the AI sense. On the other hand, the
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.
1.5.2 Mobile Agent vs. Component (Object) Architectures?

Component (object) architectures are a novel trend in implementing distributed
computational systems. They provide ways to encapsulate code and data, and to hide
the network architecture from the programmer. That is, they usually follow the static
binding approach that makes references over the network nearly as transparent as
references in the same computer.
On the other hand, mobile agents provide explicit means to handle changes in the
underlying network architecture through the dynamic binding described in previous
paragraphs above. They allow the developer to program inter-component and inter-
host accesses directly, even by allowing her program to move over to the other host,
thus making the cost of communication cheaper.
Although, these technologies seem to be so different that makes impossible their
cooperation, we think that they are rather complementary than exclusive. Indeed,
novel mobile software systems provide support for major distributed component
platforms (e.g., CORBA or DCOM) and vice versa, there exists object request brokers
(ORBs) that allow for the migration of their components (see e.g., Voyager in Section
4.2.10). There seems to be a convergence, instead of the anticipated divergence. We
think, this technological development is a major advancement in distributed
technology. It means that the developers of distributed systems can freelz decide what
approach to use. They can even use different approaches for different components,

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.
1.5.3 What Component Architecture?

In this paragraph we discuss the question of what component architecture to prefer
when choosing the middleware to implement the KNIXMAS system. Our main
concerns include the architecture's availability on different platforms, the stability and
industrial acceptance of the given architecture, how much the solutions the
architecture provides match those of our needs and finally the level of support for
software mobility. This latter concern has two sides, however, we are also interested
in how much mobility fits into the concept of the given architecture, but it is just as
important whether existing mobile systems provide bridge to the given component
platform.
It is clear that the Jini technology has little in common with the goals and needs of the
KNIXMAS system, thus we exclude it from further investigation. Similarly,
Enterprise JavaBeans are more suited for a 3-tier client-server architecture than for a
more distributed application containing equal modules and components. Moreover,
while it is usually not that hard to provide access to EJBs from mobile systems, and
vice versa, current systems do not explicitly support EJBs. Therefore, we vote against
the use of them.
Both CORBA and DCOM support most of the existing platforms and had been
successfully used in some large projects. CORBA is somewhat more mature as a
cross-platform technology, while DCOM has an army of developers who already
know COM programming. DCOM also benefits from user-friendly Windows tools,
while the source-level standardization makes CORBA more suited for applications
including mobile code. For these reasons, we think that the best approach to take is to
choose a mobile middleware system that provides support for CORBA. If this system
has bridges to DCOM that's a plus, but we set our priorities to favor CORBA.
2 Foundations of Mobile Software Systems

This section provides a brief introduction into the foundations of mobile software
systems. The underlying reason for this discussion is to back our survey presented in
Section 4 and to identify the main issues and aspect to be addressed in it.

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.1 Introduction and History

The growth of the Internet caused a never seen increase and dynamism in the
computing resources available to application development. This has meant a radical
improvement of the underlying hardware and communication infrastructure, which
requires software solutions adapted to the new circumstances. One of these new
solutions is mobile computation or mobile code technology2 that tries to provide
architectures fitting the dynamism and distributed nature of the global network.
As described in Section 1.4, this model allows for dynamic binding between code
components and the hosts executing them. That is, components are allowed to travel
in the network. Hence, what differentiates this model from the well-known client-
server model is that besides data, code is allowed to move, too.
Naturally, the migration of the code causes network traffic, but the underlying
assumption of mobile computation states that this is, for some reason, more
favourable than the network traffic generated by data transfer. A reason could be that
the code describing complex search rules is smaller than the raw data on which it is to
be performed.
Mobile computation is not without precursors. It is originated in process migration
and other experiments carried out more than 10-20 years ago. The motivation behind
migration is different, however. While process migration was mainly concerned with
operating system-level load balancing, mobile computation also addresses different
issues. As mobile computation moved up to the middleware level, it tends to support
heterogeneous architectures, operating systems and even heterogeneous
administrative domains on the network. For this reason, mobile computation tends to
use interpreted languages, which is an important divergence from original process
migration ideas. Another difference is that while process migration tried to move the
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.)
computation at an arbitrary point of its execution (from 'the outside', in response to

external commands), mobile computation realizes the fact that it is much easier to
transfer code when it is ready to move. That is, there was a shift in the source of
migration. In process migration the underlying system initiated the transfer, while in
the case of mobile computation usually the code itself initiates the migration. (For this
reason, mobile code components are often referred to as mobile agents. Although, this
is somewhat misleading, see Section 1.5 and Section 2.5, we will also use these terms
interchangeably when it does not decrease the clarity of the text.)
As mobile computation is implemented at the middleware level it is closely related to
other distributed component architectures, e.g. DCOM and CORBA (as expressed in
Section 1.2.1). Furthermore, mobile computation has lot in common with active
networks.
2.2 Application areas in general and for KNIXMAS

In this sub-section we overview the main application areas of mobile software
systems. Our aim is to provide a general summary, which takes into account the major
industrial and academic application directions. Therefore, we do not constrain it to
deal with scenarios applicable in KNIXMAS only. On the other hand we keep the
possibilities and requirements of KNIXMAS in mind and for every presented scenario
we discuss its relevance to the KNIXMAS system.
Being part of an introduction to the foundations of mobile software systems, the
approach of this sub-section is rather general. Therefore, it cannot provide a
conclusion on whether and how to use mobility in KNIXMAS. This will be provided
later, after investigating different theoretical arguments in favor and against mobility
(in Section 2.10) and after surveying existing systems (in Section 4). Our conclusions
are presented in Section 5.
2.2.1 Distributed Information Retrieval

On benefit of mobile technology is that it reduces the network load in case of
applications which process large amount data stored in distributed databases,
according to complex search criteria which exceeds the capabilities of a general
database server. This scenario clearly complies with the underlying assumption of
mobile computation. The agent carries complex search criteria that augment the
capabilities of the server. Furthermore, these information agents or soft-bots can carry
beliefs about their user's preferences that would help their dynamic decision at the
database sites. The typical application domain of this scenario is electronic commerce
where seller and buyer agents are visiting the 'virtual marketplace' to collect offers
matching the user's preferences.
On the other hand this scenario is very much similar to that depicted in the design of
the KNIXMAS system. In KNIXMAS the core information is stored in local
Intelligent Base Systems (IBSs) which are embedded in Local Research and Working
Networks (LRWNs). To achieve system-level cooperation these LRWNs must
exchange knowledge in form of intelligent knowledge acquisition. This means that the
participants of the network must access the dynamically updated distributed
knowledge information, no matter where it got produced or happened to be stored. As
a consequence, search agents (Global Search Agents, Sub-Search Agents and
Knowledge Exchange Agents) must roam the network to execute complex queries on
the different IBSs.
2.2.2 Support for Mobile Users

Another important application area is providing support for mobile users (c.f. mobile
computing). Mobile users have only temporary network connection with limited
bandwidth and they only have limited computational and storage (memory and disk)
capacities. The user, however, may assign a more complicated task (e.g. the retrieval
of some information) to an agent and send it out to the network. This can be done
during e.g. a short dial-up connection, following which the agent can autonomously
travel on the network and accomplish its task, exploiting the resources of computers
permanently connected to the network. Thus, tasks of arbitrary complexity can be
solved, independently of the capabilities of the originating machine. After acquiring a
solution, the agent returns to its owner during one of the next network connections of
the user and reports on its results. If the result is simple enough, it can be
communicated through standard e-mail messages, instead of travelling back to the
originating host.
The current architecture of the KNIXMAS system does not particularly support
mobile users. The envisioned use of the system is researchers located at different
locations of the world, in different working and computational environments, but all
using 'old-fashioned', stationary workstations. Therefore, our application environment
does not really matches to the scenario presented in this paragraph. In the long run,
however, as an option for extension and further research, the KNIXMAS system
might be augmented with support for mobile users. While this clearly seems to be one
of the requirements for information systems of the future, this option is not yet part of
the project.
2.2.3 Real-time Access and Maintenance

Another application domain is the real-time access and control of special
networked instruments. Control of equipment whose control is sensitive to network
delays belongs to this class of applications. An agent using the computational
capabilities of the instrument itself or that of a close computer can provide timely
answer to critical events by reducing the time needed for the exchange of messages. It
can evaluate the signals received from the instrument in real-time, based on its
knowledge base and act as the situation requires. The agent may send reports and
summaries to its owner over the network (as these memos are less sensitive to
network delays).
While we have used the term 'instrument' up to now, one of the most important
applications belonging to this domain is the management of large
(telecommunications) networks. Moreover, this application area is also related to
embedded computation, where smart devices are empowered by embedded
computational facilities (e.g., see the briefing on Jini in Section 1.2.1.3).
The KNIXMAS system neither includes special equipment needing real-time control
nor devices with embedded computation. Moreover, the Intelligent Base Systems
(IBSs) and the Local Research and Working Networks (LRWNs) are administered by
local staff. Therefore, the scenario presented in this paragraph is not relevant for the
KNIXMAS system.
2.2.4 Smart Cards

Software mobility is being used in such novel application areas as that of smart
cards. General purpose (e.g., JavaTM based) chip-cards require technologies to
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.2.5 Automatic Software Update, Extensible Servers

The scenario presented in this paragraph is similar to the one presented in the
previous one, namely to the use of mobile software with an application environment
containing smart cards. The automatic software update scenario also relies only on
a subset of mobile technology, more specifically on the code on demand design
paradigm (see Section 2.5). Automatic software update means that the applications
on the network are automatically upgraded with code downloaded from the network.
This solution makes the administration of workstations much easier than as it is now.
Another implementation of the same idea is the use of extensible servers. This
solution is, in a way, the counterpart of automatic software update. The main insight
behind this technique is that the services a server of the network offers are hard to
dynamically upgrade or alter. They can hardly adapt to the changing needs of the user
community. This is due to the fact that it is extremely difficult to predict the real
demand the server will face with (especially in the case of such open systems as the
Internet). As the upgrade causes the outage of the actual services, only demands
valuable enough to compensate for these losses are served. This results in the practice
that only paramount demands are satisfied.
The extensible server scenario proposes a server architecture that can be dynamically
extended by uploaded mobile agents. These agents can be 'internal' (produced by the
organization running the server, in response to the demand) or 'external' (written by
the user herself, based on public APIs to the server). The architecture can be limited
to 'internal' agents only, depending on the actual policy of the server administrator.
Another application area of automatic software update and the extensible server
architecture is embedded computation. In this setup smart devices are empowered by
computational capabilities which are scattered all over of our living environment. On
one hand, these devices are of limited capacity to store all possible application
interfaces. While on the other, their management and possible upgrade would pose an
unbearable difficulty unless mobile techniques were used. One of the pioneers of this
area is the Jini technology (see Section 1.2.1.3 for more).
While there would be room for automatic software update in the KNIXMAS system
(e.g., potential upgrades could be downloaded from a central repository), the current
architecture does not include this solution. The concept of extensible servers,
however, is very much incorporated into the design of the Intelligent Base Systems
(IBSs). These modules, in fact, are only interfaced both with the Local Research and
Working Networks (LRWNs) and with the global KNIXMAS system through mobile
agent APIs, or through extensible servers (see Local Mobile-Agent Environments and
Global Mobile-Agent Environments in the IBS specification).

2.3 Architecture
Execution
Units
CCoommppuut at at itoi onnaal l CCoommppuut at at it oi onnaal l CCoommppuut at at itoi onnaal l

EEnnvvi ri roonnmmeennt t EEnnvvi ri roonnmmeennt t EEnnvvi ri roonnmmeennt t
Operating
Operating Operating
Operating Operating
Operating
System
System System
System System
System
Software
HHoosstt HHoosst t HHoosstt

Network
HHaarrddwwaarree
Figure 2.3.1 The conceptual architecture of mobile systems

The most important pre-condition that makes the migration of software components
possible is the receiver host's capability of executing them. To achieve this, mobile
computation is based on a special distributed architecture that consists of
computational environments. The applications are built of executing units that run in a
set of computational environments. Although the networked computers themselves
could play the role of these computational environments, their heterogeneity and other
problems prevent this. In practice, virtual machines are used, as depicted in Figure
2.3.1.
While the general conceptual architecture of mobile software systems can be outlined
on a higher level, as we did above, the implementation details of today's concrete
systems are far from being uniform or standardized. There are proposals or
recommendations, and also standardization efforts (Section 3 presents them in more
detail), but a more unified approach can rather be expected from the fact that there is
more and more market demand to interface mobile systems to existing standards of
the distributed systems domain. A very important development of the recent two years
was that several mobile architectures made existing standards (e.g., CORBA, Java
RMI, DCOM) accessible for their users. Additionally, several new implementations of
traditional architectures (e.g., ORBs) have augmented the original concept by the
support of mobility.
2.4 Classes of mobility and migration

There are several ways to classify the different approaches and solutions to mobility
and code migration. In this paragraph we first present the most important of these,
then we project these taxonomies upon each other, to provide a deeper understanding
of their meaning and inter-dependencies.
The first question to ask is how generous the system is concerning mobility, that is,
how many times a code fragment is allowed to move. According to this, a system can
choose to support one-hop or multi-hop mobility. In case of one-hop mobility, the
code fragment is allowed to move only once, before its execution is started. On the
other hand, in the case of multi-hop mobility, migration can take place an arbitrary
number of times, at arbitrary points of the code's execution.
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.
Table 2.1 Major categories of mobility

The another interpretation of the ‘what is moving?’ question is perhaps even more
important. To make this interpretation more clear, we could rephrase the question as
what the code is moving with or what the code carries with itself: the initial
parameters required for the code fragment, internal state information, etc. According
to this we speak about weak and strong mobility (or migration). In the former case,
the code is only allowed to take – in object-oriented terms – its data members (global
variables or local instance variables) with itself. In the latter case the execution state
(the content of the execution stack, thus local variables and actual parameters, the
program counter of the threads under execution) accompanies these data. Clearly,
strong mobility provides a more comfortable environment for the programmer, but it
is also clear that it requires the underlying architecture to face harder problems and
results in more costly code both in terms of execution time and of network traffic. On
the other hand weak mobility poses less burden on the mobile system but makes the
design and implementation of mobile applications less straightforward. The
programmer must take care of the encoding of important dynamic information (e.g.,
by storing them in instance variables) and must ensure the correct continuation of the
algorithm after recovery (e.g., based on the data stored in instance variables).
An another classification approach is that of transparent and non-transparent
migration that measures how transparent is the initiating of the move and the recovery
from it. An example of the former is when the execution of the code continues on the
command following the one initiating the migration. On the other hand, the case when
the place of continuation is fixed (e.g., a start() method) or is to be specified before

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.
Mobility Code and execution state Strong Migration Proactive

mechanisms management mobility Reactive
Remote cloning Proactive
Reactive
Weak Code shipping Stand-alone Synchronous
mobility code
Asynchronous Immediate
Deferred
Code Synchronous
fragment
Deferred
Code fetching Stand-alone Synchronous

code
Deferred
Code Synchronous
fragment
Deferred
Data space Binding removal

management Network reference
Re-binding
By copy
By move
Figure 2.4.1 Another taxonomy of mobile systems [22]
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'.
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.
2.5 Design Paradigms for Mobile Applications

After characterizing different the mobile approaches from a low-level, technical
perspective, we overview the abstract design models of mobile applications. For this
summary we'll use the framework of Carzaniga et al.[10] We are interested in the
ways in which different resources of computation can be organized on the network.
We investigate a hypothetical scenario in which two components (A and B), located
on different hosts, must interact in order to accomplish a task. According to the
framework used, there are three main abstract resources needed for the interaction.
These are the code, the data and the processor (i.e., the abstract machine that
processes the code and holds state information derived from previous executions).
These resources are distributed between the two locations. The different distributions
account for different design paradigms, as summarized in Table 2.2. (For the sake of
comparison we also included the client-server paradigm.)
Initiator (A) Co-operator (B)
Client-Server code
– data
processor
Remote code data
Evaluation processor
Code on Demand data code
processor
Mobile Agent code data
processor
Table 2.2 Design paradigms for mobility.

(The boldfaced typesetting indicates where interaction takes place.)
Remote evaluation: The initiating component (A) has only the code to execute. The
other side (B) offers its processing capabilities and data (e.g. computational
resources). Therefore, A sends its code to B which, having all resources together,
executes it. The result us sent back to the initiating side. This mechanism can be used
in a recursive manner, i.e., some parts of the execution may be further delegated to
another host (e.g., C), resulting in a tree-structured execution.
Code on demand: This scenario 'mirrors' the one above. The initiating side (A)
posses the required data and the computing power (processor), but misses the code to
be executed on them. The code is stored at B. Therefore, A contacts B and downloads
the code which gets executed on A. The result remains at A. An example of this
scenario is the applet construct of the JavaTM language and this is the solution used in
general purpose smart card systems. (Note, however, that in case of applets the main
reason for mobility is the location of the processor, as for security reasons the applet
is not usually allowed to access local data.)
Mobile Agents: In this scenario, the initiator (A) has both the code and the processor,
but lacks the data to act upon. The latter is stored at B. According to the underlying

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).
2.6 Mobility Classes for Design Paradigms

In the two previous paragraphs we have introduced both low-level, technical and
higher-level, design-phase classifications of mobile systems and applications. Now,
we investigate the relations of these classes, as summarized in Figure 2.6.1.
One-hop Multi-hop
Weak Remote Evaluation
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.
2.7 The Life Cycle of Mobile Agents

In order to fully understand the mechanisms the different mobile systems offer and
mobile components are subjected to, in this paragraph, we overview the different
possible events of a mobile component. The life-cycle of mobile agents is summarized
in Figure 2.7.1. Note that the figure shows a generalized case. The existing mobile
environments usually support only a subset of this functionality.
„A” computing environment „B” computing environment
Agent
Cloning Agent
Cloning (remote clone)
(local clone) Communication
Agent Agent1 Agent

Migration
Communication
Disposal Persistent
Creation (programmed or storage
automatic)
Disk Storage Disk Storage
Figure 2.7.1 Life cycle of a mobile agent

After its creation, the mobile agent 'wakes up' in a computational environment (A in
the figure). This process usually means that the code needed for creation is loaded into
the the executing computing environment. In this environment, the agent can clone
itself (the clones 'inherit' the actual state information of the cloning agent). The
produced clone can be local or remote, depending on the targeted computational
environment, in which the clone starts its execution. The target is usually determined
by the cloning agent.
Besides cloning the agent itself can communicate to other agents which can be local
or remote. The way of communication is determined by the mobile architecture and,
as discussed in Section 2.8, may differ from mobile system to mobile system. The
agent can migrate to another host (e.g., to B in the figure), too.
The execution of the agent may be suspended (upon the agent's or external request).
In this case the code of the agent, together with its actual state information is stored on
disk. The format of the persistent storage, its conformance to open standards is a very
important attribute when comparing different mobile systems. Some systems store
their agents automatically for checkpointing reasons at a specified time rate or
depending on specific events (cloning, migration, etc.).
After accomplishing its task, the agent terminates and the resources held by it are
freed. The existing systems differ in their approach to termination and resource
deallocation. Some systems use automatic distributed garbage collection algorithms

which take off the burdain of termination-administration from the programmer. The
condition for termination also differs in the existing mobile environments. The
simplest approach is to link the termination to the end of the code or to the call of a
specific method. There exist, however, more sophisticated methods, too. For example,
the termination could be triggered if a pre-specified date is reached, an amount of time
has elapsed or if a limit of resource consumption is achieved. These mechanisms are
used in open systems, running a huge number of agents. Especially, they are useful in
information retrieval applications where no exact solution for the task can be
specified. The solution reached having consumed a limited amount of resources is
accepted.
2.8 Communication in Mobile Systems

Demo applications of mobile software systems usually contain only a single agent
roaming the network that interacts with the hosts it visits. This is a mistaken
stereotype, however, which possibly roots in the fact that developers of such mobile
systems are mainly concerned with the actual implementation of the roaming
possibility and therefore they are eager to show it off. However, distributed
applications rather consist of a number of components and this is independent of the
presence of mobility.
Components of such a system must be coordinated to achieve the goal for which the
system was constitued. To coordinate, the components must most likely communicate.
As a matter of fact, communication is necessary even in the 'stereotype' setup cited
above, since the mobile component roaming the network must somehow interact with
the hosts it visits. This section is dedicated to the issues and techniques of inter-
component communication in distributed systems in the presence of mobility. For the
sake of simplicity, from now on, we'll often refer to mobile components as mobile
agents.
2.8.1 Local or Remote Communication

Different mobile software systems use pretty different solutions to support
communication. The main conceptual difference between these different approaches
is whether they support remote communication, that is, the possibility to access a
component running on a different host from the one on which the initiating agent is
running.
The main argument in favor of limiting communication to interaction among agents
on the same host roots in the underlying assumption of mobile computation. This
assumption states that the transfer of code is cheaper than that of data. Therefore,
advocates of local communication argue, it is useless to access remote components. If
interaction is needed, the agent must move to the remote host and access its partner
locally.
Other systems allow remote communication, saying that it must be left to the
programmer to decide whether code or data transfer is more appropriate. The idea
behind this argument is that while parts of the application might require code
mobility, often communication only means the exchange of short messages which are
well under the size of the code component.

The systems that exclude remote communication usually introduce metaphors to

describe the execution environment and the interactions taking place inside them.
Examples of such metaphors are meeting place and market place. In some cases, these
systems also introduce the notion of stationary agents to denote services that the host
provides for visiting agents. These notions introduce a common interface for
communication. Agents only need to interact with other agents present in the local
executing environment and can still access whatever service they need. Note,
however, that the presence of these kind of metaphors or stationary agents does not
necessarily mean that remote communication is not allowed. The introduction of such
logical constructs is getting more and more popular.
It is easy to see that the implementation of remote communication is much harder than
that of local interaction4. It is even harder, if interaction between migrating
components is allowed. Only the determination of the actual location of the partner
agent can indeed require significant time and processing. This problem is usually
solved by a proxy mechanism: the migrating agent leaves a proxy behind that
forwards forthcoming calls to its new location. Naturally, as the list of previously
visited hosts grows this solution allows less and less performance. To overcome this,
some systems introduce backward linking to proxies left behind on the route to update
their pointers upon another migration. This solution reduces the cost of agent location,
but increases that of migration. Clearly, there is a trade-off between keeping the
proxies up to date and keeping the cost of migration low.
Another issue associated with agent proxies is their deallocation upon the agent's
disposal. This is wither solved by backward linking which makes the finding of
related proxies easy or by distributed garbage collection mechanisms that identify
abandoned objects and thus outdated proxies.
An alternative solution for finding the partner agent is the provision of a registry
service. In this setup a dedicated host stores (agent name, agent location) pairs.5 Of
course, this database should be updated whenever an agent it contains moves. This
update can be automatic (performed by the mobile infrastructure) or manual (initated
by the migrating agent itself). The former is exemplified by the MAP system (see
Section 4.2.6), while the later is used in most CORBA-related systems (c.f. CORBA's
Naming Service), thus e.g., in Voyager (see Section 4.2.10).
Most of current mobile agent systems prefer the registry mechanism, since it is easy to
implement and provides good performance. We must not, however, a serious
disadvantage of this solution. Namely, that it reintroduces a single point of failure into
the system, as the centralized registry service can become a bottleneck in the
distributed application.
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.
2.8.2 Control- and Data-Driven Communication

Remote and local communication is identical from a more conceptual perspective. In
this sense, more important questions are what actually drives the communication, how
is it organized, etc. There are two basic answers to these issues.
According to the control-driven approach agents are open to the environment that
includes several channels of communication (communication media). When an agent
wants to communicate to another agent, it initiates one of these channels. It places a
message on it, which gets propagated to its addressee by the communication media
(according to the communication rules). Consequently, the receiving agent is
informed of the initiated communication and can act accordingly (refuse
communication, process the message and answer it, or store it for future answer, etc.).
What is important is that the communicational act directly and promptly effects the
behavior of both parties [13].
The data-driven approach does not allow for direct control of the party's behavior.
In this model agents are closed with respect to the communication media and
communication is implemented through data exchange. Basically, the communication
media behaves like a shared dataspace. Communication rules constrain the allowed
data structures and the ways how items can be disposed or removed. In contrast to the
control-driven model, the communication media does not provide a virtual
'controlling' connection between the parties, but requires the agents to pro-actively
seek for possible messages addressed to them [13].
Control-driven communication is best used when the system is built of a pre-
determined number of agents of pre-determined types, whose dependencies are known
beforehand. On the other hand, in open systems where the possible number or type of
agents is unknown and there is less to know about the exact hierarchy of these
components, data-driven communication can prove to be the best choice. As open
applications more and more populate the giant see of the Internet, data-driven
communication tools are getting more and more popular (see Sun's JavaSpaces as an
example [39]).
2.8.3 Detailed Models of Communication

The major communication models presented in the previous paragraph can be refined
according to the partners' access to common namespace as it shown in Table 2.3. By
access to common namespace we mean that the initiating agent can address its partner
through its name or its ID. If this is not the case, we consider the interaction to be
anonymous, even though the agent most likely has some indirect knowledge about the
identity of its partner.
2.8.3.1 Direct Communication

We call the control-driven version of communicating agents sharing a common
namespace direct communication. This is the most common version of interaction in
distributed systems. It has two major forms: messaging and (remote) method
invocation6. In the case of messaging, the initiating agents compose a message
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
(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
Anonymous Interaction MEETING LINDA-LIKE

Group meeting Service point
Event-based Messaging
Method Invocation
Table 2.3 Detailed models of communication (based on [13])
2.8.3.1.1 Synchronous and Asynchronous Calls

In addition to sending information to its partner the sender agent may require an
answer to its message. The answer can either mean a message in response or a return
value of a method invocation. If the answer is provided immediately (i.e., the sender's
execution is suspended until the arrival of the answer), we talk about synchronous
communication (messaging, etc.). On the other hand, in case of asynchronous
communication, the sender continues its execution, but keeps a reference of the future
reply. It can check for its arrival later or can be notified by the underlying
infrastructure upon arrival.
2.8.3.1.2 The Implementation of Remote Calls

In the case of remote method invocations there is an additional technical difficulty,
that is, the caller must have a low-level reference to its partner. Usually this reference
is provided by a local stub (proxy), which is paired by a remote skeleton (proxy). In
reality, the caller only communicates to the local stub that transforms the call and its
parameters into a transportable form and sends it through to the remote skeleton. It is
its task to decode the information and forward the call to the called partner. In case of
a possible answer the process is executed in reverse order.
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.
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.

2.8.3.3.1 Group Meeting

A group meeting is like everyday department meetings. It is defined by advertised
coordinates (e.g., location and time) and a pre-determined group of agents (e.g.,
department members) can join it. Those joined (attending) the meeting are receiving
the information (messages or events) advertised by a subset of the participants, those
who have the privilege to 'talk'.
Group meetings are considered anonymous, even though, the agents must have the
knowledge to identify the meeting. The reason for this is that besides this knowledge
the agents don't need any more information to interact. The interaction takes place
through events delivered to the subscribed participants. This process resembles pretty
much to event-driven solutions (usually it is even implemented in this way). Meetings
can be coupled to executing environments (e.g., to hosts) or can have a more abstract
structure.
Tools for communication through group meetings are implemented, e.g., in the
Concordia system (see Section 4.2.4).
2.8.3.3.2 Service Points

The other subclass of the meeting model consists of service points. Service points are
symbolically named (computational) services. Some agents can subscribe as one,
while others can retrieve who is subscribed. This model is analogous to finding a
garage through the Yellow Pages (YP). Several garages are advertising themselves by
listing their services under the 'Garage' item in the YP. When an agent needs one, it
queries the YP for a garage and select one from the list it receives.
Server agents can register themselves to the YP that stores (symbolic name, agent
name) pairs. Clients need to know no more than the name of the service they are
intending to use. When accessing a server agent, symbolic names can be resolved
automatically or manually. In the first case, the client simply communicates to a
service (referring to it through its symbolic name) and the execution environment
takes care of the routing of messages to the appropriate server agent. This solution is
exemplified in the Ara system (see Section 4.2.3). In fact, the name 'service points', is
rooted in this scenario.
On the other hand, in the second case, the client must query the YP to receive a
reference to the server agent (e.g., possibly its unique agent name). An example of
this solution can be found in the Mole system (see Section 4.2.7).
Independent of the way symbolic names are resolved, service points only provide
means to identify the communicating partners. Actual communication takes place
either in the form of messaging or method invocation, just like in the case of direct
communication (see Section 2.8.3.1).
Symbolic names need not by unique. If there are more than one agent provided with
the same symbolic name, the YP service is free to return whatever service agent it
considers appropriate. Therefore this communication model makes dynamic load
balancing possible, provided the execution environment (host) implements such
algorithm.

2.8.3.4 Linda-like Communication, Tuple Spaces

The anonymous data-driven communication model is called Linda-like
communication, due to its resemblance to the Linda architecture [23] developed to
describe concurrent systems. An alternative name for this architecture is tuple spaces.
Linda-like communication takes place through tuples written into a shared dataspace
(the tuple space). The tuples are retrieved using a pattern-matching algorithm. The
potential receivers supply the communication media with patterns for each value in
the tuple (these values can contain jokers or wild-card characters) and they receive the
matching tuples in response.
Just like blackboard architectures, tuple spaces 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 tuple spaces organized into
some structure. For mobile systems, usually distributed tuple spaces are used. E.g.
every host can have one on it. In this setup, agents usually have access to the local
tuple space, but some systems also allow for remote tuple space access.
Tuple space 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, separate packages are available
implementing tuple spaces for distributed systems. These packages are usually by-
products of reactive Linda-like architectures (see Section2.8.3.5).
2.8.3.5 Reactive Tuple Spaces

An interesting and very important extension of the Linda-like communication setup is
the model of reactive tuple spaces. In this model the way communication acts (tuple
placements and retrievals) are handled is allowed to change over time, in response to
these acts or to other events. That is, the communication media is allowed to be
reactive (to react to events it receives).
In theory, other models of communication could also be extended in this way,
allowing the communication media to change. However, no such extended model had
been neither described nor implemented to our knowledge, except reactive tuple
spaces.
Reactive tuple spaces are important, since they allow for easy implementations of
different access policies or stigmergetic coordination [33]. Another important benefit
of reactive tuple spaces that the coordination media is actually programmed. In this
way, the application logic is divided into two parts between the execution
environments and the (possibly moving) agents. On one hand, this reduces the size of
mobile code (and contributes to the efficiency of migration), while on the other, it
separates some aspects of coordination from the agents, thus making a clear logical
and architectural distinction between algorithm and coordination logic.
Reactive tuples spaces are implemented as extensions to existing distributed
middleware architectures, thus to mobile software systems. There are a couple of such
systems in existence, e.g. Sun's JavaSpaceTM package [39], the PageSpace system
[12], the MARS package [8], or the TuCSoN system (programmable in Prolog) [59].
These extensions also provide implementations both for both the Linda-like and the
blackboard communication model.

2.8.4 Multicast and Broadcast Communication

In the sections before we overviewed the major models of communication. During
this survey we mainly focussed on setups in which the communication act is
addressed to a single agents. In some cases, however, it becomes necessary to address
all participating agents or a set of them. These are the cases of broadcast and multicast
communication, respectively.
Among the current mobile software systems only a few support multi- or broadcast
messaging in a direct way (e.g., by providing a single command or method to
implement it). Naturally, multicast communication can be easily, but less
conveniently implemented with the simple tools peer-to-peer communication. In
general, multicasting fits more suitably into event-based communication architectures,
in which messages are propagated by the (distributed) communication media. This
setup of communication can also be easily implemented on blackboard or tuples space
architectures.
2.8.5 Message Format and Language

The format or language of the information passed is at least as important as the
communication model in use. While this latter may determine a basic structure (e.g.,
tuples in case of Linda-like architecture or function calls in case of method
invocation), the more detailed protocol is still needs to be specified. 'Closed
applications' (i.e., when only components from the same vendor or those known
before are interacting) can use proprietary languages and protocols . 'Open
applications' that may face with a changing environment, on the other hand, must base
their communications on established standards. This issue will be further discussed in
Section 3.1.
2.9 Security Issues and Their Solutions

One of the most important issues concerning mobile computation is security. With
the growing number of (e-mail) viruses, everybody is aware of the paramount
importance of ensuring the safety of code and data stored on networked hosts. On the
other hand, mobile software systems raise less obvious security concerns, too. This
section discusses the main aspects of mobile agent security and solutions proposed to
overcome them.
2.9.1 Categories of Mobile System’s Security

The different security issues raised by mobile software are summarized in Table 2.4.
Category I Protecting the host against the agents
(or the agents against each other).
Category II Protecting a group of hosts.
Category III Protecting the agent against the
executing hosts.
Category IV Secure communication.
Table 2.4 Security issues of mobile systems

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.
2.9.2 Offered Solutions

It is clear from Table 2.4 that the security issues of mobile software systems are
symmetric. That is, they include the protection of both the agents and the hosts. In
contrast to this, the research efforts concerning these issues seem to be assymetric.
Most of the works is about category I (and possibly category II) issues. This is due to
the fact that these problems seem to be more critical regarding the market acceptance
of mobile systems. If the host is vulnerable people will be reluctant to run mobile
environments and allow foreign agents to visit their computer. This could indeed
block the technology's acceptance. Similarly, in the case of applications running over
a local area network, it is less risky to assume a safe host than a non-malicious agent,
as a single erroneous agent can destroy the server on which it is running.
Some of the security issues described in Section 2.9.1 are similar to issues known
from different applications. These issues are relatively easy to handle, and the
literature proposes a range of possible solutions to deal with them. Another issues are
new, unique and their solutions are less obvious to find. This section discusses both of
these classes, that is, the main ideas of the solutions proposed for the different
categories. This will be followed by a short comment on what of these proposals find
their ways to implementation in current mobile software systems.
2.9.2.1 Solutions Offered by the Literature
2.9.2.1.1 Categories I and IV

As mentioned above, the security issues of these categories are similar to those of
general applications of open networks. Therefore, their solutions also use approaches

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.

2.9.2.1.3 Category III

The hardest among all security issues raised by mobile software is protecting agents
against the hosts they are executing on. An ideal protection mechanism should
provide code and execution integrity (code privacy), solutions for computing with
secrets (data privacy) and prevention of denial of service attacks against agents (e.g.,
bombarding the agent with false messages or supplying it with insufficient resources).
Code integrity is closely related to software privacy. As we will see, solutions to that
issue are proposed against our problem, too.
Threats to be considered can be classified as exogenous threats (those performed
during the agent's migration or when it is stored on disk) and as endogenous threats
(those performed by the execution host). The prevention of data unauthorized
disclosure (of either the code or the data) is made harder by the fact that a set of hosts
may collaborate in the fraud.
The problems of preventing code disclosure is well demonstrated by the so called
'linking problem' [73]. Consider the case when an agent needs to calculate a function
F, on input X provided by the untrusted host U. As a consequence of the underlying
assumption of mobile computation, F should be evaluated on U. The result Y is to be
protected, so it must be signed by the agent (using signature algorithm S) and
communicated back to the agent's owner. As a first approach, the code on Figure 2.9.1
would solve the problem.
moveTo(U)
Y=F(X)
Z=S(Y)
sendBack(Z,Y)
Figure 2.9.1 A wrong solution to the 'linking problem'.

It is clear, however, that the presence of observation outrules this sequential approach.
An observer with access to the code would easily separate the Y=F(X) statement to
get access to the secret result. As a consequence, code fragments like this should be
protected in a holistic way.
Before surveying the state of the art in the field of protecting agents against malicious
hosts, we note that no code systems could be expected to provide an ultimate solution.
This is a general property of encryption systems, which was recently demonstrated by
several code-cracking challenges. As technology improves, so it makes codes more
vulnerable. The goal of a secure mobile agent system can only be to ensure privacy
for the life time of the agent, that is realistically expected to be short in respect to
technological improvements.
2.9.2.1.3.1 The Common Agreement: No Solution

The common agreement in the mobile software community or the 'folklore' as put by
some critiques is that no solution exists for category III problems [70]. It is clear that
the executing host must have deep knowledge about the agent's code and the data it
uses or carries. The common claim is that it basically means that the code is executed
in clear text form. Therefore, people with access to this information (e.g., the owner or

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.)
2.9.2.1.3.2 Hardware Solutions

Despite the common agreement on the non-existence of ultimate solutions, some
argue in favor of trusted hardware platforms. This solution requires the presence of a
special hardware component, which internal architecture is unknown to the public.
Therefore, advocates claim no one can tamper with neither the agent's code nor its
data.
The main disadvantage of this solution is that it reduces the number of possible
execution environments, thus makes the concept inapplicable to open environments
like the Internet. Another argument against this approach is that it is usually relatively
easy to remove the fragment of the code that checks the presence of the special
hardware (see the 'linking problem' in Section 2.9.2.1.3).
Finally, hardware solutions are bound to be expensive. This could only be eliminated
by mass production, but the spread of the hardware tool makes creating fake versions
more profitable and thus more attractive.
2.9.2.1.3.3 Code Obfuscation

Another solution proposed by critiques of the common ‘folklore’ is code obfuscation.
This approach goes in a way against the 'clear text assumption' described above. It
proposes an extensible set of transformations to be applied to the code. These
transformations produce code harder to read, but with identical results.
This is a proposal coming from the software privacy domain. Therefore, it is only
concerned with the prevention of unauthorized disclosure. Still, the main problem
with the algorithm is that it cannot prevent disclosure. It only makes it harder.
Although, in some cases this can be enough, since the agent should only be protected
during its life-time. Therefore, short-living agents may indeed profit from this
approach. Another problem, however, is that the proposed transformations usually
results in code with poorer efficiency.
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.
2.9.2.1.3.4 Sliding encryption

Sliding encryption is another proposal rooting in software privacy. It proposes that the
program code is to be encrypted by a secret key [81]. Only a small window containing
the actual point of execution would be decrypted on the fly, making possible its
execution. As execution proceeds the passed code fragments are encrypted again.
In general, the comments about code obfuscation (see Section 2.9.2.1.3.3) apply here
as well. The proposal has nothing to say about e.g., execution integration. Moreover,
dynamic decryption and encryption decreases efficiency. Finally, it is clear that this is
also a solution, which only makes the task of observers harder.
2.9.2.1.3.5 Clueless agents

Clueless agents are proposed as a solution to prevent code and data disclosure [67].
The main idea is that the observer may have access to the information, but it should
not be able to understand what it is for.
This idea is implemented through conditional code. The execution of conditional code
is triggered by a special event in the environment (e.g. a specific point in time or the
arrival of a message). Therefore, the observer may be aware what algorithm the agent
is intending to perform, but could not know on what input. Of course, clear text
conditionals would not suffice here, as they would allow the observer to deduce the
real meaning of the code. The trick is that even the agent does not know the exact
condition. It only scans a specific channel, codes the received events by a one-way
hash function and compares it with a stored constant. If the two results match, the
condition is satisfied. As the pattern is only stored in encrypted form, the exact trigger
is impossible to deduce. It is clear, however, that this trick depends on the existence of
one-way hash functions.
Clueless agents allow for the construction of more sophisticated constructs. E.g., time-
based encryption mechanisms are possible. Also, the execution of a specific task
could be made dependent on the number of cooperating agents, by creating the hash
of the required threshold as a pattern to match against the actual number of
cooperators.
The main problem with this solution is that it cannot prevent tampering with the code.
It can neither protect the data carried with the agent. However, it can prove useful in
e.g., applications of smart cards (making the code executed dependent on the card
inserted into the reader), etc.
2.9.2.1.3.6 Tracing of Execution

Execution tracing does not deal with data privacy, nor it attempts to provide code
integrity. What it offers is the proof of tampering [76]. It is based on public key
encryption and one-way hash functions. It assumes that the agent's code is static and
that public keys are assigned to each host. Moreover, it makes use of the (unrealistic)
assumption that public keys are generally and quickly accessible from every node of
the network.
It labels elements of the code as black or white statements, depending on whether the
given instruction processes input from the environment or only operates on internal
values, respectively. It then requires executing hosts to create a trace of execution.
The trace consists of a pair for each statement. The first member of the pair is the

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.
2.9.2.1.3.7 Computing with Encrypted Functions

The expression ‘computing with encrypted functions’ denotes a bunch of inter-related
ideas that goes against 'mobility folklore'. That is, it questions the fact that (mobile)
code should be executed in a clear text form. It favors provable security over difficult
to break arguments [71].
The basic idea is similar to the way coded language messages work. The sentence
'Uncle Paul has managed to raise his children' can be communicated over an open
channel or even an untrusted person could be asked to deliver it, since no one, except
the members of a secret community, are aware of its real meaning.
The approach promises to protect the code, to prevent unauthorized runs and to
identify the source of unauthorized copies. Clearly, it is at least as important to
software privacy as to mobile computation.
The main problem with this proposal is that it is only a theoretical result. Moreover, it
is not even complete. It is proved that such mechanisms exists for polynomials over
rings Ζ/Ζ (provided that certain assumptions of algorithm theory hold). However, it is
a completely open issue whether a similar algorithm can be constructed for general
purpose, turing-complete languages.
Therefore, this solution is currently unusable in practice. We have only reported it
here, for the sake of completeness.
2.9.2.2 Security Issues in Practice and in KNIXMAS

After summarizing the literature on proposed solutions for security issues raised by
mobile software systems, let us have a few words on practical issues. The first thing to
note is that according to our survey of major mobile systems, mobile security in
practice is a way behind theory (see Section 4.3.8 for more details). Moreover, it is
evident that the asymmetry of efforts noted in Section 2.9.2 is more significant in
respect to implementations. Mobile systems are weak in general regarding security,
but they particularly perform low when it comes to protecting agents against
malicious hosts. Clearly, market demand is making developers to concentrate on
category I and category IV issues and it is also clear that potential customers are
unaware of the dangers of agents' vulnerability.

Concerning the KNIXMAS system, we are in a lucky position. Or we are just

planning to implement a typical 'user application' in the sense that we only need
security of category I and IV. Clearly, our agents will only visit trusted hosts (those
participating in the KNIXMAS network) and they will only carry publicly available
information. (Except that they will demonstrate the interest of the party on behalf of
whom they are working. But on one hand, this party is usually just another agent, so
the connection to a human person becomes rather indirect. And on the other hand,
research networks are typically about cooperation and not competition. Therefore, the
disclosure of the interests of a participating researcher is not considered a real loss.)
As KNIXMAS hosts will only allow KNIXMAS agents to visit them, the need for
category II security can also be eliminated. (Let us assume that our agents are not
buggy.) This leaves us with the need to protect the host and with that of secure
communication. The two categories usually covered by mobile software systems in
existence. Of course, different systems provide these services at different levels, so
security remains an important concern when choosing a particular system. This
concern will be discussed against the background of concrete, detailed information in
Section 4.3.8.
2.10 Why Mobility? Arguments: Pros and Cons

The literature containing arguments in favor and sometimes against mobility abounds.
In the following we attempt to summarize the main points on each side. A main
argument in favor of the mobile approach is that in provides a natural structuring
technique and thus helps to handle a lot of problems, moreover code and data in a
uniform way. In fact, this claim is fairly similar to that of concerning the use of
autonomous agents and multi-agent systems in general, which makes its relevance
more acceptable in our eyes.
Opponents of the approach often ask for more concrete advantages, e.g., in the form
of a "killer application", which would clearly demonstrate the superiority of the
approach. There have been several initiatives and attempts to provide such problem,
but recently the mobility community seems to be settled to the opinion that no such
thing exists and that, in fact, it is not even needed. The claim is that mobile code and
other, more traditional approaches are interchangeable, i.e., every application can be
implemented in either way. 8 This equity makes relative advantages especially
relevant.
The most important of these relative advantages is performance. The argument of
increased performance appears on both sides. Sometimes it is the reason for turning
towards mobility, while in other cases this serves as the main objection. Clearly, this
issue depends very much on the actual setup (application, network environment, etc.).
One thing to note, however, is that most of these arguments are only speculations.
Very few rigorously scientific measurements have been done to compare the different
approaches. Most of the works were carried out either using abstract models or
measuring only a very narrow application area. [49]
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.
Another important concern against mobility is the issue of manageability.

Components dynamically changing their locations are feared by software engineers as
they are lacking the established programming model. This problem, however, is pretty
similar to those raised by autonomy in multi-agent systems, so an emerging solution
can very much be expected from the collaboration of the multi-agent and mobility
communities. The main barrier in front of this synergy is the traditional perception
that mobility is about a single agent ’hacked together’ that visits a site; while multi-
agent system research is about collaboration and coordination in the abstract. We
think this is not true anymore.
2.10.1 Application Properties that Make Mobility Appropriate

In this subsection we present a “check-list” that collects possible requirements for an
application to become a potential candidate for mobile solutions.
1. The networking environment is either unreliable or of limited bandwidth.
Alternatively, the networked components have only temporary connections to the
network or have only limited computing power.
2. The application requires the processing of huge distributed databases of which
task only a limited size result is expected.
3. The application requires access to data that cannot be transferred through the
network (e.g., due to security concerns, etc.).
4. The application requires real-time control of remote components in the presence
of significant network delays (see 1.).
5. The application requires the periodic update or extension of the used software
components throughout the entire application network. (E.g., changing protocols
or dynamic formation of supply networks, etc.)
6. The application requires the use of multi-purpose components with limited
computational or storage capacity (e.g., smart cards as “intelligent bar code”). See
1 and 5.
Most of these items have already been addressed in Section 12.2. Here, we only want
to make a few comments on them.
The first item suggests that the mobile approach is to be used "on the edge of
networking" [49]. The increasing performance of computing machinery, however, is
claimed to eliminate this point (as suggested by Petrie [49]). We don not believe in
this. As performance improves, so it raises more and more demand; extending
distributed computation to yet untouched areas. This possibility is well demonstrated
by the appearance of the Wireless Application Protocol (WAP) for handheld
telecommunications devices. This protocol allows for Internet access from mobile
telephones, but the same time, it reintroduces severe bandwidth limitations on
common widespread network applications.
Another important thing to note is that item 5 and 6 cover the case when mobile
software encapsulate proprietary protocols, acting as intermediaries between
incompatible systems. Of course, these incompatible systems must provide the same
mobility layer, but that is far easier a task than adopting the protocols themselves.
All in all, we accept the arguments of Harrison et al. [37] who think that traditional
distributed technologies address all cases enlisted above, but none of them address the

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.
2.10.2 Hard Problems that Make Mobility Inappropriate

The main barrier in front of the spread of mobile component technology seems to be
the increased level of security concerns. As it was reported in Section 12.9.2, neither
the theoretical base, nor the practical implementations are complete. Still, it is a
paradox, as mobile software systems are feared, mainly as potential threats against the
execution environment. One of the issues that are theoretically solved and handled
appropriately by most mobile platforms (see Section 14.1.8). On the other hand, some
claim that this issue is nothing else than chatter. They say that severe security holes
are continuously detected in most commercial systems and still, users are happy to
buy and use them…
Another hard issue is strong migration. In the old days of mobile computation, there
was a quest for platforms implementing strong mobility. It is a rather hard task,
however. Therefore, more and more systems have decided against this heavy duty and
provided only weak mobility. It turned out that most applications do not really need
strong mobility. This led to the situation that ‘pioneer systems’ providing strong
mobility seem to loose out and newcomers with Java-based weak migration support
take the lead (see Section 14.3.11). It must be noted, however, that this boom of weak
mobility systems was strongly determined by the design decisions of the popular Java
system.
There are a few other problems that are often mentioned as potential sources of failure
for mobile software technology. These are the poor availability and documentation of
mobile platforms; the missing support and tools for easy installation; and finally the
lack of graphical user interfaces (GUI) for development and administration. It is clear
that these aspects are important, if not vital for a technology. Therefore, we have
devoted special effort to the study of these properties in current mobile agent
platforms (see Section4.1).
2.10.3 Why Mobility in KNIXMAS?

Our application in the KNIXMAS project satisfies at least one of the items presented
above as possible reasons to turn toward mobile technology. The KNIXMAS system
involves the processing of distributed databases, therefore mobile agents are a
straightforward structuring technique. Moreover, the KNIXMAS project is deemed
with neither increased security concerns, nor an urging need for strong mobility.
These reasons form a solid basis supporting the use of the mobile approach.
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

established standards. Therefore, we do not waste space on repeating these well-

understood benefits, but look promptly at our subject.
Perhaps, the most important or at least, the most interesting standard would be one
that defines rules for implementing a mobile agent. That is, standardizing the
languages mobile agents are programmed in, or at least, the format to which they are
compiled and executed. Such a standard would provide real interoperability between
various mobile platforms, allowing an agent created by one programmer using a given
mobile architecture to visit a foreign host supporting another platform. This would
make dynamic autonomous distributed applications open-ended.
Naturally, such standard is nearly impossible to define. Even if it was possible, it
could easily become one of those ideas that remained one paper and never got real
acceptance. As a consequence no such standards, not even task forces aiming at its
definition exist. On the other hand, efforts to implement bridges and cross-compilers
between different platforms have been theoretically proposed for several times. In a
sense, multi-language mobile platforms, such as Ara and D'Agents represent an
attempt to provide this functionality, but they are constrained by their specific internal
architecture. Moreover, as discussed in Section 4.3.11, the effect of these systems on
the general development of the field is decreasing.
It is tempting to look at the idea of code-level standardization as one belonging to the
domain of fairy tales, but surveying current mobile systems one realizes that, in fact,
there is a language supported by the vast majority of platforms. This de facto standard
is the JavaTM language. This is the reason why we will shortly discuss the Java RMI
technology among inter-agent communication standards.
3.1 Inter-agent communication

Even if code-level standardization is out of question application interoperability can
be improved by establishing common standards for information exchange, that is, for
communication. This goal is much easier to achieve and still pretty useful. This high
cost/benefit ratio caused actually several standards to emerge, which are shortly
discussed in the following paragraphs.
3.1.1 Java RMI

Sun Microsystem's Java RMI technology is a low-level standard for remote inter-
object communication for Java [68]. It was not designed with code mobility or agents
in mind, but still it become the common denominator of many mobile platforms. This
is due to the fact that most contemporary mobile software systems are written in Java.
Therefore, Java RMI support comes basically for free.
Java RMI is an application programming interface (API) defined for remote
communication by the Java development team. It allows for the invocation of methods
on an object residing on a remote host in a seamless form, just like if it was running
on the local computer. This facility requires that the remote object implements a
specified interface (basically a set of methods) and that the hosts each run a dedicated
service (i.e. the RMI daemon).
Putting it in a simplified way, the interaction goes as follows. When a method
invocation is initiated, the actual parameters of the call are serialized using Java's
serialization method and passed to the remote partner. Upon receiving the call and the
parameters, the remote object deserializes the parameters and executes the selected
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.3 FIPA ACL

The FIPA ACL was and being developed by the Foundation for Intelligent Physical
Agents (FIPA) and its goals are basically the same as the KQML language (see
Section 3.1.2 for details) [21]. It was started years later than the other effort was
initiated and similarly to that, it is also only available as a draft.
Not only its goals are similar, but the fundamental solutions are also pretty close to
KQML. The FIPA ACL is also draws from the speech acts theory and does not
specify the details of the underlying communication infrastructure. Therefore, it can
also be implemented on top of common standards such as the socket layer or Java
RMI.
The FIPA ACL was developed as a mainly industry initiative, in contrast of KQML
which was a rather academic enterprise. Perhaps, this fact is responsible for FIPA
ACL's increased emphasis on practical, usability issues and for the fact that it was
already implemented by at least one mobile platform (see Grasshopper in Section
14.1.6). KQML is not supported by any mobile system, to our knowledge.
Moreover, there is a trend indicating that FIPA ACL is taking over KQML's role in a
wider context. More and more agent developers (in the most general meaning) are
considering to support FIPA ACL, instead of KQML.
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).
3.2 Agent system interoperability

Besides inter-agent communication, there is another domain where non-compatible
agent systems should be standardized. This is the domain of agent management and
agent retrieval. That is, interoperations at the agent system level.
The Mobile Agent System Interoperability Facilities (MASIF) is such a standard that
was defined by the Object Management Group (OMG) [58]. Besides, identifying a
conceptual model for mobile platforms and for agents, MASIF also specifies
requirements for the basic functionality of the agent system. Migration properties to
be supported and security characteristics to be implemented are also part of the
specification.

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.
4 Mobile Platforms for KNIXMAS

In this section we report on our study of concrete mobile software systems. Our
enterprise has involved the following steps. First, we set out and overviewed the main
theoretical issues related to mobile code and mobile computation. A summary of these
studies has been presented in Section 2.
After understanding the theory of mobile agent systems, we have collected a list of
available mobile systems. This task has proven to be impossible to complete as we
found that there is an extreme oscillation on the number and set of available systems
supporting mobile computation. This is due to the fact that mobile agents are, on one
hand, a popular research area and, on the other, a middleware technology with high
level expected profitability. In addition to this, mobile systems keep disappearing as
research grants end or as the vendor earns only a low profit rate and decides to drop it.
Fortunately, the latter case is pretty rare, that is, supported mobile systems are usually
stable and systems usually get dropped due to the fact that the research team has
reached its goals (e.g., putting it sarcastically, all members of the group received
PhDs, etc.). All in all, at the time of the survey there were approximately 30
middleware architectures supporting code migration available (see Appendix 7.2 for
details).
As a consequence of the oscillation described above, one has to identify the core
development efforts when surveying mobile software systems in order to choose one
of them for long-term use. We had done so, selecting 10 mobile architectures for
further study. Even with this rigorous pre-study, however, we had happened to choose
one system that was later completely dropped by its developer company (see Odyssey
in Section 4.2.8). We had also chosen another that is still available, but no longer
developed (see Ara in Section 4.2.3) and one that was once dropped, but later
regained support (see Aglets in Section 4.2.2).
After selecting the 10 systems mentioned above, we had downloaded them all for
further investigation. We had installed and learned each of these systems, developed

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.
4.1 Aspects of the Study
4.1.1 Availability and Support

First among all aspects in our study was the availability of the software. Really, we
could not afford to invest in a middleware system without having a closer look at it
beforehand. Therefore, we have checked all encountered systems whether it has a free
(e.g. for academic purposes) or an evaluation version. Naturally, we preferred systems
available free of charge to those requiring a significant investment for professional
use. This has not prevented us, however, from experimenting with commercial
systems from the telecommunications and software industry. Even with the
acknowledged leader of pricing.
Another issue closely related to availability is the support that accompanies a given
system. This service is often connected to the version one posses (e.g. free and
evaluation versions go without any support, while full-featured commercial versions
have a full user helpdesk service). As we have not purchased the systems evaluated in
this report we have no basis to rank supports which accompany only commercial
versions. Therefore, we can only report on the level of support the given mobile
software systems provide for non-commercial (academic or evaluation) versions.
4.1.2 Supported Platforms and Ease of Installation

The next major aspect of our survey investigated which platforms are supported by
the selected mobile platforms. Clearly, this is an important issue as the KNIXMAS
system is aiming to provide a homogenous application layer over a heterogeneous set
of operating systems and hardware platforms. Therefore, systems that only supported
a given family of architectures (e.g. UNIX-like systems or Windows 9x/NT) have
been ranked low compared to those systems supporting a wide variety of underlying
infrastructure. As most of the systems investigated were built on top of Sun's JavaTM
language, another issue has surfaced. Namely, we had to identify what versions of
Java are supported by the given mobile platform. It was important, since Java has
developed a lot in recent years and different versions have diverged a lot. Even
though, backward compatibility is provided, several auxiliary tools (e.g. development
environment, extension packages or browsers) only support a given range of versions.
Moreover, backward compatibility to older versions is not guaranteed in coming
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.
4.1.4 Supported Classes of Mobility

Apart from the very general aspects described above, we have studied the selected
systems from more technical perspectives, too. As the first of these, we have
investigated what classes of code mobility are supported by the given platform. As it
is discussed in Section 2.6, several taxonomies of mobile techniques exist, forming a
complex multi-dimensional property space. We wanted to position the systems of the
study in this property space. Therefore we have checked our mobile platforms against
all possible classifications.
We have not forgotten, however, the requirements of the KNIXMAS system. We
preferred multi-hop mobility to one-hop migration, although, one may argue that the
KNIXMAS project does not really need it. This may be true in the point of view of
minimal functionality, but it clearly does not hold in the context of general
applicability and the freedom of design. We wanted to preserve the possibility for
more robust and more flexible implementation that indeed profit from multi-hop
mobility.
On the other hand, KNIXMAS does not need strong mobility. Its presence, however,
could significantly improve the comfort of the programmer, but mainly due to the fact
that strong mobility makes transparent migration possible. Therefore, even though, we
ranked strong mobility higher than weak mobility, this score has received lower
weight in final scoring.
4.1.5 Support for Industry Standards

Another technical aspect to check was the support the selected mobile platforms
provide for established industry standards with respect to distributed systems and
communication infrastructures. The requirements against which the selected platforms
were checked were support for CORBA, DCOM and Java RMI.
The reasons for the selections above are manifold. In Section 1.5.2 we have set our
priorities for an implementation based on both industry standard distributed
architectures and on mobile components. Therefore, we were looking for mobile
platforms supporting at least one of CORBA or DCOM. According to our selection in

Section 1.5.3 to prefer CORBA to DCOM, we were biased towards CORBA support.
Despite this, we have surveyed DCOM support to allow other aspects to out weight
this preference. This did not happen, however, but that will be reported in Section
4.3.11.
The reasons for checking Java RMI support were different, however. It was mainly
motivated by our bias towards the JavaTM language as a programming platform. We
have preferred Java for several reasons. First, for its platform independence. The
KNIXMAS system is to be implemented over an extremely heterogeneous
international network, therefore platform neutrality is of paramount importance.
Second, the wide range of development tools, APIs and extensional packages
available for the language made Java particularly attractive.
4.1.6 Support for Agent and Content Standards

Another aspect of the survey was to check the mobile platforms for their support for
different agent and content standards. Namely, for the Mobile Agent System
Interoperability Facilities (MASIF), for the Knowledge Query and Manipulation
Language (KQML), for the FIPA Agent Communication Language (FIPA ACL), and
for the Extensible Markup Language (XML), which were described in Section 13.
The main focus, however, was on support for MASIF, the Mobile Agent System
Interoperability Facilities. A mobile platform that supports this standard is highly
preferable for KNIXMAS due to several reasons. First, MASIF compliant platforms
would make the interoperation of components implemented in different systems
possible. Second, MASIF integrates with CORBA; our preferred distributed
component architecture. And third, MASIF allows for the remote management of
mobile platforms that would make possible the centralized or at least hierarchical
administration of the KNIXMAS system.
4.1.7 Administrative Tools

We have also surveyed the selected systems for the administration tools they
provided. The need for such tools is obvious. An important point, however, was
whether the platforms have network aware management facilities. This was motivated
by the fact that KNIXMAS is an extremely large, widely distributed international
system that must provide tools for local and domain level administration, just as for
cooperation network level management.
An ideal system would provide an easy-to-use management console for monitoring
events and for everyday administration, but also it should have a text-based interface,
too. This second is needed as the graphical interface imposes a constraint on the
possible network locations (terminals) from which the administrative task can be
performed. Moreover, a mobile platform ideally provides an Application
Programming Interface (API) for agent system and agent management. The presence
of such an API makes the development of automated, KNIXMAS aware management
and administration tools possible.
4.1.8 Solutions for Security Issues

No need to say, the way how security issues are dealt with is of paramount
importance. As it was emphasized in Section 12.10.3, security plays a major role in

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.1.9 Language Constructs, Programming Style

Finally, we have surveyed the programming layer of the mobile platforms. This aspect
is very important, as it is the level the developer faces the most. Also, it determines
the duration and efficiency of the development. It is important that the model and the
language capture the main notions of mobility and also that it provide adequate and
easy-to-use tools to handle them.
Naturally, the ease of programming is related to the transparency of mobility (see
Section 12.4), but that is not the only factor to take into account. Even a platform
supporting transparent mobility can perform worse than another platform that does not
support transparent migration, if the notions it provides are poorer or badly chosen.
The first property to check, concerning this aspect, is the supported (used)
programming language. Some systems provide multi-language support. In case of
these, it is important to identify the most established language, as these multi-lingual
systems were usually implemented as a single language platform and converted later
to their current form. This history often has the side effect that the notions of the
platform are more suited to one language that to another.
It is also important to identify the main constructs of the language (e.g., agent,
process, service, etc.) and the language solution for mobility. As there are a wide
variety of these solutions, it is useful to put them beside one another to develop a
deeper understanding of how these platforms work.
We have checked for the support of different models of communication and the
language primitives that implement the conversation. It is needless to say what
influence these 'extensional' constructs may have on the overall design and behavior
of the system.
Finally, we have included a slot for extras, too. Several different things have been put
here, from support of applets, to management models and checkpointing, and to
support for agent collaboration, etc. Of course, these features could not be compared
to one another, but their presence or quantity contributed to our overall impression
about the systems.

4.2 The Studied Mobile Systems

In this section we briefly present the 10 subjects of our survey. We identify the exact
versions of the studied systems, the developer organization, together with a short
history of the platform and a public location to access it. We have also included the
results of our survey on the platform's availability and the support their developers
offer.
4.2.1 Agent TCL (D'Agents)

D'Agents (formerly AgentTcl) is an experimental system being developed at
Dartmouth College, USA. It is free for non-commercial use and downloadable from
http://www.cs.dartmouth.edu/~agent/. E-mail support is available from the
developers.
AgentTcl was one of the first mobile agent systems. It was built on top of the Tcl
language. It received worldwide attention for its support for strong mobility and for its
promises to implement all security aspects of mobile code. These promises, however,
have not been kept. Instead, its developers decided to shift toward multi-language
support and changed its name to D'Agents.
The D'Agents system, just like its ancestor AgentTcl is a general-purpose mobile
agent platform, without any specified application focus.
We tested version 2.0 of D'Agents.
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

available for evaluation from http://www.meitca.com/HSL/Projects/Concordia/. The

evaluation version includes no support.
Concordia is a framework for development and management of network-efficient
mobile agent applications for accessing information anytime, anywhere and on any
device supporting Java.
We tested Concordia v1.1.2.
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.6 Mobile Agent Platform (MAP)

The Mobile Agent Platform (MAP) is an experimental system developed at the
University of Catania, Italy. It is available from http://sun195.iit.unict.it/MAP/. No
support is available to our knowledge.
The MAP platform is relatively new and its developers are using it for network
management applications.
We tested MAP v2.
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 Detailed Results of the Study

In the subsections to follow, we present the detailed results of our study. Each of the
subsequent sections contains at least one table summarizing the main points of the
results gathered, accompanied by a discussion of the major issues.
4.3.1 Supported Platforms

This subsection reports on the software platforms the selected mobile systems
support. Originally, we planned to investigate whether the systems are possible to run
on different operating systems (e.g. on Win9x/NT, Unix, Linux and Solaris), but it
turned out that the setup is more complex. Some systems could indeed be classified
according to the traditional operating system dimensions. Some others, however, are
not. This is due to the fact, that these systems are implemented on top of the Java
Virtual Machine (JVM) and therefore they are supposed to be platform independent.
For our purposes, we can safely assume that this is true. Java has several versions,
however. While these are currently backward compatible, it is clear that older
versions cannot deal with mobile platforms requiring a new JVM. Moreover, this
backward compatibility is not guaranteed to be preserved. Therefore, we distinguished
different versions of Java.
To make things more complex, some mobile platforms that are built on top of Java
only provide installation utilities and management scripts for a limited set of operating
systems. Moreover, some systems explicitly state that documentation and support is
only provided for the specified environments.
The results of the survey from this aspect are summarized in Table 4.1. We handled
Java as a pseudo operating system, but identified the supported Java version(s). The
Java-based platforms' bias toward some given operating system environment is
included as a separate column.
Supported Platform Comments
AgentTcl (D'Agents) UNIX, Linux, Free BSD,
Aix, IRIX, Digital
OSF1, Solaris
Aglets Java 1.1
Ara Sparc/Solaris, Linux
Concordia Java 1.1.5 Installation set for Win32
and UNIX.
Grasshopper Java 1.1.6 or higher
MAP Java 1.2
Mole Java 1.1.3-1.1.6 Due to the installation
scripts, non-UNIX systems
are hardly supported.
Odyssey Java 1.1
Plangent Java 1.1 or later Support for Solaris 2.51
and Windows 95/NT.
Voyager Java 1.2 Previous versions had
support for earlier Java
versions.
Table 4.1 Platforms supported by the surveyed mobile systems
As discussed above, we preferred Java for the KNIXMAS system. Moreover, for
reasons of more complete functionality and of future compatibility, we preferred the
latest Java version to older ones. Therefore, support for Java 1.2.x is highlighted by
boldface typesetting in the table above.

4.3.2 Ease of Installation

In this subsection, we summarize our experiences about the installation of the given
platforms. We were interested in two issues, as shown in Table 4.2. First, how smooth
the systems' installation goes and second, whether an automated installation tool (e.g.,
a script) was provided. Ideally, a platform's installation means a simple run of an
installation program with an easy-to-use graphical user interface (GUI).
Most of the platforms installed smoothly. We have only experienced problems with
four systems. We had minor problems with Aglets, but those were easily overcome by
manual configuration. The Mole system caused harder problems. Its documentation
provided little help to solve our problems, even though, there was a large portion in its
manual dealing with possible installation problems. We think this to be an important
sign.
Our hardest problems, however, were caused by D'Agents and Ara. The installation of
both of these systems required recompilation not only the platform itself, but some
related packages, too. Moreover, these systems are rather sensitive to auxiliary
packages, the versions of whose should have been precisely selected. Even these
preparations have not been enough for the successful installation of these platforms.
Incompatibilities had to be worked around by minor changes made to the source.
Ease of Installation Comments
AgentTcl (D'Agents) Requires recompilation, Manual installation.
changes to the source and
precisely selected versions of
auxiliary tools.
Aglets OK with minor problems. Manual installation.
Ara Requires recompilation, Manual installation.
changes to the source and
precisely selected versions of
auxiliary tools.
Concordia OK Installation program.
Grasshopper OK Installation program.
MAP OK Manual installation.
Mole Major problems. Under documented.
Odyssey OK Semi-automated.
Plangent OK Installation program.
Voyager OK Installation program.
Table 4.2 Installation of mobile platforms
Although, installation is only carried out a few times during the development and
during the lifetime of the KNIXMAS system, we think that the ease of installation is
an important property. Especially, as we think that the carefulness by which an
installation set is prepared adds to the picture of the inherent quality of the system.
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).
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
4.3.4 Supported Classes of Mobility

After investigating general software features, we turned toward mobility-specific
properties. First, we have checked what classes of mobility are supported by the
selected platforms. Our results are summarized in Table 4.4.
As expected, all platforms support multi-hop mobility. This is both due to the pre-
selection phase we performed and to the tendency in mobile technology development.

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.
4.3.5 Support for Industry Standards

The next aspect of our survey was to check what industry standards the selected
platforms supports. In Section 1.5.2 we decided to use both mobility and distributed
component architectures for the development of the KNIXMAS system. While we
also decided to prefer CORBA better than DCOM, in Section 4.1.5 we discussed why
9
Strong in Java and Tcl, weak in Scheme.
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
4.3.6 Support for Agent and Content Standards

As discussed in Section 4.1.6, support of agent and content standards is important as
well. This has also been surveyed. Table 4.6 summarizes our findings. As in case of
the previous aspect, only support explicitly expressed is shown, but the table includes
announced plans and efforts, too.
MASIF FIPA ACL KQML XML
AgentTcl - - - -
(D'Agents)
Aglets planned - - -
Ara - - - -
Concordia - in the works - -
Grasshopper √ √ - √
MAP √ - - -
(may not be
complete)
Mole - - - -
Odyssey - - - -
Plangent - - - -
Voyager - - - √
Table 4.6 The mobile platforms' support for agent standards

According to our results, MASIF is supported by Grasshopper and MAP. It is not

clear, however, whether the complete specification is supported by the MAP platform.
Aglets has plans to implement MASIF support, but that is not available yet.
Support for the FIPA ACL is implemented by Grasshopper only, but Concordia
reported works on its implementation. As already mentioned in Section 3.1.2, KQML
is not supported by the mobile platforms (not by anyone among the non-surveyed
ones either, to our knowledge). Finally, both Grasshopper and Voyager announced a
module to support XML-based applications.
Clearly, from the point of view of the KNIXMAS system, the support that was
provided by the Grasshopper platform has the highest value. This is followed by
either MAP or Voyager. While we think MASIF more valuable than XML for our
purposes, the uncertainty of MAP's MASIF support makes us wonder. Therefore, we
leave the ranking between these two platforms open, considering this aspect of the
survey.
4.3.7 Administrative Tools

This subsection collects our findings concerning the administration tools available for
the surveyed platforms. In general, we can tell that there is an acceptable management
interface for all platforms, except D'Agents and Ara. That is good news.
It is also clear from Table 4.7 that the Grasshopper platform has outstanding facilities.
This is followed by the tools provided by MAP, Aglets and Voyager, to our ranking.
Note, however, that the GUI management tool for Voyager is only included in the
commercial release, that devaluate the platform's ranking.
API Console GUI
AgentTcl (D'Agents) - - -
Aglets √ - √
Ara - - -
Concordia 10 - - Limited
Grasshopper √ √ √
MAP √ - √
Mole - √ √
Odyssey - √ -
Plangent - - √
Voyager √ - √11
Table 4.7 Administrative tools provided by the surveyed mobile systems
4.3.8 Solutions for Security Issues

Security is one of the main concerns of users of mobile platforms. This subsection
summarizes the solutions provided by the surveyed systems. An overview of our
findings is provided in Table 4.8.
10
The commercial package has more.
11
In the commercial package only.
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).
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.
4.3.9 Language Constructs, Programming Style

Supported Programming Language(s)
AgentTcl (D'Agents) Tcl (available)
Java (available upon request)
Scheme (promised)
Aglets Java
Ara C/C++
Tcl
Java (in the works)
Concordia Java
Grasshopper Java
MAP Java
Mole Java
Odyssey Java
Plangent PlangentScript (PERL and Java-like)
Java for low-level components.
Voyager Java
Table 4.9 Programming languages supported by the tested platforms
This subsection discusses the language layer of the investigated mobile platforms.
First, we summarize the languages the platforms offer the program the agents in, as
shown in Table 4.9. We emphasize that (as already mentioned in Section 4.3.4) the
fact that a platform is implemented in a language (e.g., in Java) does not necessarily
means that it also makes programming possible in the same language. (And vice
versa, if a platform is programmable in a language that does not imply that it was

implemented in the same programming language). This statement is obvious in the

case of multi-lingual platforms, such as D'Agents and Ara. They use a language to
implement the core system and the different programming layers on top of that, but it
is completely independent of that what languages these layers support. On the other
hand, single language platforms can also have different implementation and
programming language. This is the case with Plangent.
Aglets, Concordia, Grasshopper, MAP, Mole, Odyssey and Voyager support Java and
Java only. Plangent has its own script language, named Plangent (that provides some
access to Java and makes use of some of its functionality). D'Agents and Ara are
multi-lingual systems. They both are supposed to support three languages, but have
one of them unavailable (Scheme in case of D'Agents and Java in case of Ara).
Moreover, the Java layer of D'Agents is only available via private e-mail request to
the authors, which makes the robustness of this layer at least questionable. On the
other hand, as we already mentioned in Section 4.1.9, systems supporting multiple
language layers usually have their preferred 'home platform'. This is Tcl in case of
D'Agents (c.f. AgentTcl) and seems to be the same for Ara, too.
We had an expressed bias toward mobile platforms enabling programming in Java.
According to this constraint all platforms qualified in theory. Due to our comments
above, however, Ara and D'Agents has been moved to the end of the queue.
Base constructs Migration
AgentTcl agent_begin agent_submit
(D'Agents) agent_end agent_jump
agent_fork
Aglets class Aglet dispatch(), clone() à
onDispatching(), onArrival()
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.
Table 4.11 Communication services and extras

In Aglets, migration is initiated by calling either the dispatch() or the clone()
method that provide the expected functionality. Aglets does not offer transparent
mobility, however. It rather follows an event-driven model. Among several other
events, an onDispatching event is delivered to the agent (the onDispatching()
method is called on the agent) just before it leaves the host, while an onArrival()
event hits it upon arrival. Aglets also supports the itinerary concept. An agent can
have an itinerary assigned to it that can be initiated by calling the startTrip()
method.
Concordia supports itinerary-based mobility only. Itineraries are represented by
objects belonging to the Itinerary class. New destinations can be added by the
addDestionation() method, while the trip is initiated upon the call of
launchAgent().

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

initiator may continue its on task. MulticastResult is even more interesting. It

can have more than one remote source from where it receives the result.
MulticastResult can be parameterized to wait for the result of all sources or to
content with the first result. Moreover, Grasshopper allows for the querying of the
services (mobile or stationary agents) available in the local execution environment
(listServices(), listMobileAgents(), listStationaryAgents()).
As an extra, we note that agent management is implemented according to the MASIF
model.
The MAP system supports inter-agent messaging by the sendSyncMessage(),
receiveSyncMessage() pair. It also makes the querying of local agents possible
(getAgentList()). Similarly to Grasshopper, the extra of MASIF compliant
agent management is available in MAP, too.
The Mole platform offers a mixed model of Java RMI and service point
communication. Service points are registered by the registerMeForService()
and queried by the serviceProvidersOf() method. On the other hand,
Odyssey only supports meetings. Meetings are initiated by the meet() method and
their required characteristics are described by a Petition class. Odyssey has the
extra functionality to support Applets (OdysseyApplet) as execution
environments.
While Plangent has inherent support for none of the communication models discussed
in our report, Voyager offers a full range of functionality. It supports Java RMI
communication. Besides this, synchronized, future-type and one-way messages can be
invoked by Sync.invoke(), Future.invoke() and OneWay.invoke()
respectively. Moreover, it supports efficient multicast messaging by a special
hierarchical architecture, named Spaces and has a distributed garbage collection
mechanism to free unused agents. This mechanism also provides sophisticated
solutions for agent life-cycle management. As a consequence of Voyager's deep
integration with CORBA, the platform supports the CORBA Naming Service and has
an ORB's management functionality as an extra.
4.3.10 General Comments

After presenting the detailed findings of our survey of selected 10 mobile agent
platform, let us briefly summarize our impressions about these systems.
The D'Agents system was one of the pioneer mobile agent platforms. It then moved
towards multi-language support, but it still carries its Tcl inheritance with it.
Whatever interesting and well written, we expect it to disappear in the mid-term
future.
The Aglets system is has an open, extensible construction. E.g., it implements agent
migration over a propriety protocol (Agent Transfer Protocol, ATP), but makes that
public. Same idea with the agent management tool that is based on a public API.
Aglets used to be the 'academic star' of the first generation. That is, it was considered
the best for a long time among members of the mobility community who could not
afford to purchase commercial platforms. It was so popular that the force of the user
community changed IBM's mind when it once dropped the project and discontinued
its availability.

The Ara platform implements an attractive, multi-lingual architecture, but the

implementation is a little messy (non-standard compilers for the languages, syntactical
differences between the supported layers and etc.) Its development has been stopped.
Impressions
AgentTcl (D'Agents) One of the pioneers. Even though it has made a step towards
multi-language support, its Tcl-based model is deemed to
disappear.
Aglets The 'academic star' of the first generation.
Extensible architecture.
Ara An attractive idea for multi-language support, but with messy
implementation.
Concordia An 'over weighted' system with interesting communication and
collaboration infrastructure.
Grasshopper The 'industry star' of the future?
MAP The 'academic star' of the future?
The lack of security support might prove to be fatal.
Mole A project aiming at publication. Some documented functionality
does not even exist.
Odyssey It was a promising system. It is a pity it got dropped.
Plangent Exciting marriage of AI and distributed technology. It is a bit
overcomplicated.
Voyager The 'industry star' of the first generation.
ORB with mobility and not mobile platform with CORBA
support. Modular construction.
Table 4.12 Impression summary

The Concordia mobile agent platform has interesting communication and
collaboration features, but the system in whole seems to be overweight. We may be
wrong, but our understanding is that this property, together with its distribution policy
(e.g., it is not a free software) will never allow for a significant 'market' share.
The Grasshopper system is the potential 'industry star' of the second generation. It has
many features, integrates well with a lot of standards with both from industry and
academia. Unfortunately, it is priced according to its value.
The MAP mobile system can become the 'Aglets' of the second generation. It is a nice
experimental system. We have liked its straightforward simplicity. A possible source
of uncertainty, however, is that there is little known about its developers. It is not
clear, whether it was a single project or it is part of a longer enterprise. We hope it
will continue. Especially, as the complete lack of security support is fatal for most
applications.
The development of the Mole platform seems to be motivated by the urge of paper
publication. Its manual has notes like 'that method should only be invoked if such and
such is true, otherwise the system will crash'. That is, our impression is that the actual
implementation was a bit hacking-like. Moreover, some functionality documented in
published research papers (e.g., group communication) is not eve implemented. The
platform has no 'main program'; everything should be coded as an agent. And what
makes things worse, the agents must be run manually from a console. Really, this
platform does not qualify for real applications.
The Odyssey system was a descendant of the famous TeleScript platform, the first
mobile agent platform ever. It basically re-implemented TeleScript's exciting

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.
4.3.11 Conclusions and the Selected System

In the sections above we have presented a report on our survey involving 10 mobile
software platforms. Even though, we had selected these platforms carefully among the
pool of available systems, some of them proved to be unusable, while others'
development have discontinued.
As a general result of our survey, we can attempt to draw the main properties of
current mobile agent platforms. As a first note to this, we would like to point out that
it seems that the technology has been established and strong commercial systems have
been emerged. There are more and more powerful implementations of the basic
concept that are appropriate for professional application developers. Similarly, there is
an increasing emphasis on supporting industry standards. Clearly, this is a very
important and useful development.
In parallel with the trends mentioned above, mobile platforms that are not based on
Java technology seem to loose out. As a consequence, the importance and popularity
of multi-language systems (such as Ara and D'Agents) is also decreasing. This
development has a major drawback, however. Java technology does not support
strong mobility. Therefore, this technical possibility is disappearing. On the other
hand, some argue that there is not real need for strong mobility and these recent
developments are, in fact, the result of this discovery.
On the front of inter-agent communication, Java RMI has taken the lead. It is natural,
considering that it is a Java-based technology. Indeed, Java RMI is a great and
powerful technology (some had even argued that it must be considered a mobile code
platform in itself). On the other hand, however, complex inter-agent communication
and coordination patterns require more complex infrastructure. Therefore, we think
that systems providing other communication and coordination tools besides Java RMI
are more useful.
The main insufficiency of current mobile platforms can be found in the domain of
security issues. Although, most of the more serious systems have managed to
establish good protection for the host and communication, there is a clear gap in most
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.1 Public Resources on Agents and Mobility

(1) Cetus Links on Distributed Objects & Components: Mobile Agents,
http://www.cetus-links.org/oo_mobile_agents.html
(2) Mobility Mailing List, http://mobility.lboro.ac.uk/
(3) Jeremy Hylton: Mobile Code Bibliography,
http://www.cnri.reston.va.us/home/koe/bib/
(4) World Wide Web Consortium (W3C): Mobile Code Systems,
http://www.w3.org/MobileCode/
(5) The Mobile Agent List (MAL), University of Stuttgart,
http://www.informatik.uni-stuttgart.de/ipvr/vs/projekte/mole/mal/mal.html
(6) Fritz Hohl: Security in Mobile Agent systems,
http://www.informatik.uni-stuttgart.de/ipvr/vs/projekte/mole/security.html
(7) Mobile Agent References, Distributed Systems Group,
http://www.infosys.tuwien.ac.at/Research/Agents/ref.html
(8) Mobile Code, Agents and Java, Distributed Systems Group,
http://www.infosys.tuwien.ac.at/Research/Agents/
(9) UMBC AgentWeb, http://agents.umbc.edu/
(10) Mobile Agents, UMBC AgentWeb, http://agents.umbc.edu/mobile/
(11) Agent Programming and Scripting languages, UMBC AgentWeb,
http://agents.umbc.edu/technology/asl.shtml
(12) Robert Tolksdorf: Programming Languages for the Java Virtual Machine,
http://grunge.cs.tu-berlin.de/~tolk/vmlanguages.html
(13) AgentLink (EU ESPRIT), http://www.AgentLink.org/

7.2 A List of Major Mobile Software Systems

Name of the system Prg. Languages Developer Accessibility
AgentTcl Tcl Dartmouth College, USA stopped
(see D'Agents)
Aglets Java IBM, Japan free
Ara Tcl, C, Java University of Kaiserslautern, Germany free
AMASE ? Deutsche Telekom, Motorola Paris, n/a
Sony Europe, University College
London, DAI Lab, Berlin, etc.
Concordia Java Mitsubishi, USA free eval.
CyberAgents Java FTP Software Inc., USA stopped
D'Agents Tcl, Scheme, Java Dartmouth College, USA free
Facile Standard ML European Computer Industry Research free
Centre, München (for academia)
FarGo Java Technion - Israel Institute of free demo
Technology version
ffMAIN Tcl, Perl, Java University of Frankfurt, Germany free
Grasshopper Java Forschungsinstitut für offene free demo
Kommunikationsysteme, IKV++ version
Gypsy Java Technical University of Viena, Austria n/a
JAMES Java University of Coimbra, proriatery
Siemens, Portugal
Java-2-go Java University of California at Berkeley, free
USA (seems old)
JIAC Java DAI-Lab, Berlin, Germany n/a
Jumping Beans Java Ad Astra Engineering, Inc., USA free demo
version
Kafka Java Fujitsu, Japan binary
Knowbot System Python Corporation for National Research n/a
Software Initiatives (CNRI), Reston, VA
MAP Java University of Catania, Italy free
Messengers M0 University of Zurich, Switzerland free
Mobiware Java Columbia University, USA n/a
Middleware
Toolkit
MOA Java The Open Group, USA –
Mole Java University of Stuttgart, Germany free
MonJa Java Mitsubishi, Japan binary
Obliq Obliq Digital Inc., USA n/a
Odyssey Java General Magic Inc., USA stopped
Plangent PlangentScript Toshiba Corporation, Japan. free
Java
Sumatra Java University of Maryland, USA n/a
Tacoma Python, Scheme, Tromsø and Cornell University, free

Perl Norway
Telescript Telescript General Magic Inc., USA stopped
(ancestor of Odyssey)
Voyager Java ObjectSpace Inc., USA free
unsupported
version

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

JVM Java Virtual Machine

KIF Knowledge Interchange Format
KNIXMAS Knowledge-shared, XPS-based Research Network Using Multi-
Agent Systems
KQML Knowledge Query and Manipulation Language
KSE Knowledge Sharing Effort
LMAE Local Multi-Agent Environment
LRWN Local Research and Working Network
MA Mobile Agent
MAE Multi-Agent Environment
MAL Mobile Agent List (University of Stuttgart, Germany)
MAP Mobile Agent Platform (University of Catania, Italy)
MAS Multi-Agent System
MASIF Mobile Agent System Interoperability Facilities
OMA Object Management Architecture
OMG Object Management Group
OOP Object-Oriented Programming
ORB Object Request Broker
RE Remote Evaluation
RMI Remote Method Invocation (see Java RMITM)
RPC Remote Procedure Call
SGML Standardized General Markup Language
SSL Secure Socket Layer
SXPS Supervisor Expert System
TCP/IP Transfer Control Protocol / Internet Protocol
URL Uniform Resource Locator
WAP Wireless Application Protocol
WRS Work-Research Spaces
W3C The World Wide Web Consortium
XML Extensive Markup Language
XPS Expert System
YP Yellow Pages

An Overview of Mobile Software Systems: L. Gulyás, L. Kovács, A. Micsik, B. Pataki, I. Zsámboki

Uploaded by

Document Information

Original Description:

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

An Overview of Mobile Software Systems: L. Gulyás, L. Kovács, A. Micsik, B. Pataki, I. Zsámboki

Uploaded by

Copyright:

Available Formats

An Overview of Mobile Software Systems

L. Gulyás, L. Kovács, A. Micsik, B. Pataki, I. Zsámboki

Department of Distributed Systems,

MTA SZTAKI Technical Report

MTA SZTAKI, Department of Distributed Systems 2

1.1 Trends in Software Engineering

MTA SZTAKI, Department of Distributed Systems 3

Table 1.1 Increasing localization in software engineering methodologies [60]

MTA SZTAKI, Department of Distributed Systems 4

1.1.3 Artificial Intelligence Goes Mainstream

1.1.4 Ubiquitous and Ambient Computing

MTA SZTAKI, Department of Distributed Systems 5

1.2 Technical Background

1.2.1 (Distributed) Component Architectures

MTA SZTAKI, Department of Distributed Systems 6

Figure 1.2.1 The OMG Reference Model [72]

MTA SZTAKI, Department of Distributed Systems 7

CORBA ensures interoperability between such different platforms, architectures and

1.2.1.3 EJB and Jini

1.3 Agents, Multi-Agent Systems

According to the least constraining definition, an agent is an active entity that is

1.4 Mobile Software Systems

Component Component Component Component

Network Network Network

C o r e Operating System Core Operating System C o r e Operating System

Host Host Host

Component Component Component Component Component

Computational Computational Computational

Network Network Network

Core Operating System Core Operating System Core Operating System

Host Host Host

1.5 What Technology to Use (for KNIXMAS)?

1.5.1 Autonomous vs. Mobile Agents?

Figure 1.5.1 The relation between agent-based and mobile systems.

1.5.2 Mobile Agent vs. Component (Object) Architectures?

MTA SZTAKI, Department of Distributed Systems 12

1.5.3 What Component Architecture?

2 Foundations of Mobile Software Systems

MTA SZTAKI, Department of Distributed Systems 13

2.1 Introduction and History

computation at an arbitrary point of its execution (from 'the outside', in response to

2.2 Application areas in general and for KNIXMAS

2.2.1 Distributed Information Retrieval

2.2.2 Support for Mobile Users

2.2.3 Real-time Access and Maintenance

2.2.4 Smart Cards

2.2.5 Automatic Software Update, Extensible Servers

MTA SZTAKI, Department of Distributed Systems 17

CCoommppuut at at itoi onnaal l CCoommppuut at at it oi onnaal l CCoommppuut at at itoi onnaal l

HHoosstt HHoosst t HHoosstt

Figure 2.3.1 The conceptual architecture of mobile systems

2.4 Classes of mobility and migration

Table 2.1 Major categories of mobility

MTA SZTAKI, Department of Distributed Systems 19

Mobility Code and execution state Strong Migration Proactive

Code fetching Stand-alone Synchronous

Data space Binding removal

Figure 2.4.1 Another taxonomy of mobile systems [22]

2.5 Design Paradigms for Mobile Applications

Table 2.2 Design paradigms for mobility.

MTA SZTAKI, Department of Distributed Systems 21

2.6 Mobility Classes for Design Paradigms