An Overview of Mobile Software Systems - Semantic Scholar

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.


3


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 Program

Structured Programming

ObjectOriented Programming

AgentOriented Programming

How does a unit External behave? (code)

Local

Local

Local

What does a unit External do when it runs? (state)

External

Local

Local

When does a unit External run? (activation)

External (called)

External (message)

Local (rules, goals, etc.)

Table 1.1 Increasing localization in software engineering methodologies [60]


4


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., MTA SZTAKI, Department of Distributed Systems

5


'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 intercomponent 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 MTA SZTAKI, Department of Distributed Systems

6


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 nonstandardized. 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. MTA SZTAKI, Department of Distributed Systems

7


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. MTA SZTAKI, Department of Distributed Systems

8


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 multiagent 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.


9


Component

Component

Component

Component

Distributed System

Network 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

Computational Environment


Component



Component

Component






Host

Host

Host

Hardware

Component

Figure 1.4.2 Mobile systems do not hide the network architecture. The programmer must take it into account [22] Traditional distributed systems can be conceived within a virtual machine framework (although, it does not necessarily means that they are interpreted). This is depicted in Figure 1.4.1. Traditional technology provides a layer (i.e., the 'virtual machine') that hides the network architecture from the components (and thus from the programmer). On one hand, this eases the programming burden as provides transparency of communication among the application's components independently of their actual location. However, on the other hand, this may result in inefficient implementation. MTA SZTAKI, Department of Distributed Systems

10


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 11 MTA SZTAKI, Department of Distributed Systems


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 agentbased 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 interhost 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, MTA SZTAKI, Department of Distributed Systems

12


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.


13


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 clientserver 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.)


14


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. MTA SZTAKI, Department of Distributed Systems

15


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 16 MTA SZTAKI, Department of Distributed Systems


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).


17


2.3

Architecture Execution Units

CCoommppuut at at itoi onnaal l EEnnvvi ri roonnmmeennt t

CCoommppuut at at it oi onnaal l EEnnvvi ri roonnmmeennt t

CCoommppuut at at itoi onnaal l EEnnvvi ri roonnmmeennt t

Operating Operating System System

Operating Operating System System

Operating Operating System System Software

HHoosstt

HHoosst t Network

HHoosstt 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. MTA SZTAKI, Department of Distributed Systems

18


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 mobility The allowed number of migration Strength of mobility

What's moving?

Transparency

How migration handled is at the language level?

How many moves are allowed and when? What is moving with the code?

The whole program or a part of it (a fragment, procedure, object, etc.) One-hop or multi-hop mobility. The former only allows for the migration of yet unexecuted code. Strong or weak mobility and migration The latter only transfers global and instance variables with the code. The former also carries the execution state (stack, local variables, thread state, etc.). In case of transparent mobility, the programmer only issues a command (or calls a 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


19


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 mechanisms

Code and execution state management

Strong mobility

Weak mobility

Migration

Proactive

Remote cloning

Reactive Proactive

Code shipping

Reactive Stand-alone code

Synchronous Asynchronous

Immediate Deferred

Code fetching

Code fragment

Synchronous

Stand-alone code

Synchronous

Code fragment

Synchronous

Asynchronous

Asynchronous

Immediate Deferred

Immediate Deferred

Data space management

Asynchronous

Immediate Deferred

Binding removal 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'.


20


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)

–

code data processor

Client-Server

Remote Evaluation Code on Demand Mobile Agent

code data processor code processor

data processor code data

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 MTA SZTAKI, Department of Distributed Systems

21


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

Weak

Multi-hop

Remote Evaluation Code on Demand

Strong

Mobile Agent

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


22


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 Cloning (local clone) Agent

Agent

„B” computing environment Cloning (remote clone)

Agent

Communication Agent

Agent1

Migration Communication Persistent storage

Disposal (programmed or automatic)

Creation

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 MTA SZTAKI, Department of Distributed Systems

23


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 intercomponent 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.


24


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.


25


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 predetermined 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


26


(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 interagent communication. An example of remote method invocation is the Java RMI system.

Common Namespace

Control-Driven

Data-Driven

DIRECT COMMUNICATION

BLACKBOARD

Messaging Method Invocation

MEETING

Anonymous Interaction

Group meeting Event-based

LINDA-LIKE

Service point 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.


27


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.


28


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.


29


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 byproducts 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.


30


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 executing hosts.

Category IV

Secure communication.

against

the

Table 2.4 Security issues of mobile systems


31


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 2.9.2.1.1

Solutions Offered by the Literature 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 MTA SZTAKI, Department of Distributed Systems

32


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.


33


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


34


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.


35


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., timebased 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 MTA SZTAKI, Department of Distributed Systems

36


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 predetermined 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.


37


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.


38


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 multiagent 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 MTA SZTAKI, Department of Distributed Systems

39


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 MTA SZTAKI, Department of Distributed Systems

40


established standards. Therefore, we do not waste space on repeating these wellunderstood 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 interobject 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 MTA SZTAKI, Department of Distributed Systems

41


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.


42


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. MTA SZTAKI, Department of Distributed Systems

43


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 MTA SZTAKI, Department of Distributed Systems

44


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 MTA SZTAKI, Department of Distributed Systems

45


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 MTA SZTAKI, Department of Distributed Systems

46


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 MTA SZTAKI, Department of Distributed Systems

47


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. MTA SZTAKI, Department of Distributed Systems

48


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.unikl.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 weakconnection/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 MTA SZTAKI, Department of Distributed Systems

49


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.unistuttgart.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. MTA SZTAKI, Department of Distributed Systems

50


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. MTA SZTAKI, Department of Distributed Systems

51


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. AgentTcl (D'Agents)

Aglets Ara Concordia Grasshopper MAP Mole

Odyssey Plangent Voyager

Supported Platform Comments UNIX, Linux, Free BSD, Aix, IRIX, Digital OSF1, Solaris Java 1.1 Sparc/Solaris, Linux Java 1.1.5 Installation set for Win32 and UNIX. Java 1.1.6 or higher Java 1.2 Java 1.1.3-1.1.6 Due to the installation scripts, non-UNIX systems are hardly supported. Java 1.1 Support for Solaris 2.51 Java 1.1 or later and Windows 95/NT. Previous versions had Java 1.2 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.


52


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. AgentTcl (D'Agents)

Aglets Ara

Concordia Grasshopper MAP Mole Odyssey Plangent Voyager

Ease of Installation Requires recompilation, changes to the source and precisely selected versions of auxiliary tools. OK with minor problems. Requires recompilation, changes to the source and precisely selected versions of auxiliary tools. OK OK OK Major problems. OK OK OK

Comments Manual installation.

Manual installation. Manual installation.

Installation program. Installation program. Manual installation. Under documented. Semi-automated. Installation program. 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). MTA SZTAKI, Department of Distributed Systems

53


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 brochurelike nature of the set, while in the case of Plangent; we did not find the number of examples enough.

AgentTcl (D'Agents) Aglets Ara Concordia Grasshopper MAP Mole Odyssey Plangent Voyager

Quality of Documentation ***

Comment

**

API Doc. A ***** book is available, however. Minimalist API, good tutorial. APIDoc, moderate tutorial. API Doc. Minimalist documentation. Minimalist documentation. API Doc. Well-documented, but too few examples. A bit brochure-like.

*** *** ** * * ** **** ****

Well-written, but partly outdated.

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 preselection phase we performed and to the tendency in mobile technology development. MTA SZTAKI, Department of Distributed Systems

54


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.

AgentTcl (D'Agents) Aglets Ara Concordia Grasshopper MAP Mole Odyssey Plangent Voyager

One-hop vs. Multi-hop Multi-hop Multi-hop Multi-hop Multi-hop Multi-hop Multi-hop Multi-hop Multi-hop Multi-hop Multi-hop

Strong or Weak

Transparent?

Strong9 Weak Strong Weak Weak Weak Weak Weak Strong Weak

YES NO YES NO, BUT… NO, BUT… NO NO NO YES 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.


55


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. AgentTcl (D'Agents) Aglets Ara Concordia Grasshopper MAP Mole Odyssey Plangent Voyager

CORBA planned √ √ (default) planned √

DCOM -

Java RMI √ √ √ √ (default) planned √

√

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. AgentTcl (D'Agents) Aglets Ara Concordia Grasshopper MAP

MASIF -

FIPA ACL -

KQML -

XML -

planned √ √

in the works √ -

-

√ -

(may not be complete)

Mole Odyssey Plangent Voyager

Table 4.6 The mobile platforms' support for agent standards


√ 56


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. AgentTcl (D'Agents) Aglets Ara Concordia 10 Grasshopper MAP Mole Odyssey Plangent Voyager

API √ √ √ √

Console √ √ √ -

GUI √ Limited

√ √ √ √ √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.


57


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.

AgentTcl (D'Agents) Aglets

Ara


Host Protection

Agent Protection

Secure Communication

Propriety PGP-based authorization. Resource limits and access control. Based on Java Sec. Manager User & domain authentication Fine-grained, like the JDK1.2 security model. Propriety model: allowances Limited CPU&memory usage for the agent's lifetime and per place. Agent carries a host trace. Agent identification. Resource permission. Based on the Java Security Manager. In the works. Hard to know. Based on the Java Security Manager. Limited. Pluggable security manager. Favors Java Security Manager. (Access control lists.)

Nothing.

Agent protection while in transit.

Nothing.

Integrity Checked between Servers within a Domain

In the works. (Non-mutable parts signed.)

In the works. (SSL)

Nothing.

Nothing.

Nothing.

SSL

Nothing. Nothing. Nothing.

In the works. Nothing. Nothing.

Nothing. Nothing.

Nothing. Nothing.13

12

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).


58


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 AgentTcl (D'Agents)

Aglets Ara


Supported Programming Language(s) Tcl (available) Java (available upon request) Scheme (promised) Java C/C++ Tcl Java (in the works) Java Java Java Java Java PlangentScript (PERL and Java-like) Java for low-level components. 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 MTA SZTAKI, Department of Distributed Systems

59


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 (D'Agents)

agent_begin agent_end

Aglets

class Aglet

agent_submit agent_jump agent_fork dispatch(), clone() à onDispatching(), onArrival()

Ara

ara_agent

Concordia

class Agent

Grasshopper

abstract class Service class StationaryAgent class MobileAgent class Agent abstract class Agent class SystemAgent class UserAgent interface MobileAgent class Agent, class Place class Worker, class Task Actions, Preconditions, Postconditions, A command to execute the action Dynamic aggregation: facets Mobility.of() Agent.of(), setAutonomous()

MAP Mole

Odyssey Plangent Voyager

itinerary à startTrip() ara_go ara_fork class Itinerary addDestination() launchAgent() cloneMe(), copy(), move() à live() or specified method go() à exec() migrateTo() à start()

class Ticket, class Means go() à live() goto() moveTo() à the specified 'callback' method

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 MTA SZTAKI, Department of Distributed Systems

60


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. MTA SZTAKI, Department of Distributed Systems

61


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. AgentTcl (D'Agents)

Aglets

Ara Concordia Grasshopper

MAP Mole Odyssey Plangent Voyager

Communication

Other

agent_send, agent_receive agent_event, agent_getevent agent_meet, get/reject/accept_meeting tcpip_read, tcpip_write message/meeting/event masks class Message sendMessage(), sendAsyncMessage(), sendOnewayMessage() – handleMessage() ara_announce, ara_meet Java RMI AgentGroup Java RMI class FutureResult, class MulticastResult listServices(), listMobileAgents(), listStationaryAgents() sendSyncMessage(), receiveSyncMessage() getAgentList() Java RMI registerMeForService(), serviceProvidersOf() class Petition meet() Java RMI + CORBA Naming Service Sync/OneWay/Future.invoke(), Multicast messages – Spaces architecture

-

Synchronization, monitors.

ara_checkpoint Support for collaboration. MASIF's full agent management functionality.

MASIF's agent management functionality. class OdysseyApplet ORB's object management functionality (e.g., remote 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(). MTA SZTAKI, Department of Distributed Systems

62


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 MTA SZTAKI, Department of Distributed Systems

63


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.


64


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) Aglets Ara Concordia Grasshopper MAP Mole Odyssey Plangent Voyager

One of the pioneers. Even though it has made a step towards multi-language support, its Tcl-based model is deemed to disappear. The 'academic star' of the first generation. Extensible architecture. An attractive idea for multi-language support, but with messy implementation. An 'over weighted' system with interesting communication and collaboration infrastructure. The 'industry star' of the future? The 'academic star' of the future? The lack of security support might prove to be fatal. A project aiming at publication. Some documented functionality does not even exist. It was a promising system. It is a pity it got dropped. Exciting marriage of AI and distributed technology. It is a bit overcomplicated. 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


65


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 66 MTA SZTAKI, Department of Distributed Systems


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 MTA SZTAKI, Department of Distributed Systems

67


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.


68


6 [1] [2] [3]

[4]

[5]

[6] [7]

[8]

[9] [10]

[11] [12]

[13] [14] [15] [16] [17] [18] [19] [20]

[21] [22]

References Aglets SDK V1.0.3, IBM Research Institute of Japan, http://www.trl.ibm.co.jp/aglets/ Ara v1.0a, University of Kaiserslautern, Germany, http://www.uni-kl.de/AGNehmer/Projekte/Ara/index_e.html 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 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.unistuttgart.de/cgi-bin/ncstrl_rep_view.pl?/inf/ftp/pub/library/ncstrl.ustuttgart_fi/TR-1997-15/TR1997-15.bib 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 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 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 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 Carr D. F.: Maturity and Availability, Web Week, Volume 3, Issue 7, March 24, 1997 © Mecklermedia Corp. 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. Chavez A., Moukas A., Maes P.: Challenger: A Multi-agent System for Distributed Resource Allocation, Proceedings of Agents '97 Conference, ACM, 1997. 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 610, 1996, Paris, France, http://www5conf.inria.fr/fich_html/papers/P5/Overview.html 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 Concordia v1.1.2, Horizon Systems Laboratory, Mitsubishi Electric Information Technology Center America, Phones, http://www.meitca.com/HSL/Projects/Concordia/" CORBA, Common Object Request Broker Architecture, The Object Management Group, http://www.omg.org/corba/ Crystaliz Inc., General Magic Inc., GMD FOKUS, IBM Corp., Mobile Agent Facility Specification, Joint Submission, The Open Group, 1997. Cugola G., Ghezzi C., Picco G. P., Vigna G.: Analyzing Mobile Code Languages. In Special Issue on Mobil Objects Systems, LNCS. Springer-Verlag, 1997. D'Agents v2.0, Dartmouth College, USA, http://www.cs.dartmouth.edu/~agent/ DCOM, The Distributed Component Object Model, Microsoft Inc., http://www.microsoft.com/com/tech/DCOM.asp 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. FIPA, Foundation for Intelligent Physical Agents, http://drogo.cselt.stet.it/fipa/index.htm Fuggetta A., Picco G. P., Vigna G.: Understanding Code Mobility, IEEE Transactions on Software Engineering, http://www.elet.polimi.it/people/vigna/listpub.html


69


[23] [24] [25]

[26]

[27] [28]

[29] [30] [31]

[32]

[33]

[34] [35] [36] [37] [38]

[39] [40]

[41] [42]

[43] [44] [45]

Gelernter D., Carriero N.: Linda in Context. Communications of the ACM, 32(4): 444-458, 1989. General Magic Inc., Introduction to the Odyssey API, http://www.generalmagic.com/ technology/ odyssey.html 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. Ghezzi C., Vigna G.: Mobile Code Paradigms and Technologies: A Case Study. In Proceedings of the 1st International Workshop of Mobile Agents, LNCS 1219, SpringerVerlag, 1997. Grasshopper 1.2.2, Forschungsinstitut für offene Kommunikationsysteme (IKV++), Germany, http://www.ikv.de/products/grasshopper/ 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 Gray R. S.: Agent Tcl: Alpha Release 1.1, December 1995. Available at http://agent.cs.dartmouth.edu/manual/doc.1.1.ps.gz 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 Gray R.S, Kotz D., Cybenko G., Rus D.: D'Agents: Security in a multiple-language, mobileagent system. In Giovanni Vigna, editor, Mobile Agents and Security, Lecture Notes in Computer Science, Springer-Verlag, 1998, http://agent.cs.dartmouth.edu/papers/gray:securitybook.pdf 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) 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. Gulyás L.: Mobile Code, Mobile Agents. In Proceedings of Networkshop '98, Hungarian National Conference, Gyõr, 1998. (In Hungarian) Gulyás L.: Mobile Software Environments - A Survey, in Proceedings of Networkshop '99, Nyíregyháza, 1999. (In Hungarian) 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) Harrison C.G., Chess D.M., Kershenbaum A.: Mobile Agents: Are they a good idea?, IBM T.J. Watson Research Report, 1995. 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 JavaSpacesTM Technology, Sun Microsystems Inc, USA, http://java.sun.com/products/javaspaces/index.html 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. KIF, Knowledge Interchange Format, http://www.cs.umbc.edu/kif/ 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/ KQML, Knowledge Query and Manipulation Language, http://www.cs.umbc.edu/kqml/ KSE, The ARPA Knowledge Sharing Effort, http://www.cs.umbc.edu/kse/ 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)


70


[46] [47] [48]

[49] [50]

[51] [52] [53] [54] [55]

[56] [57] [58] [59] [60]

[61]

[62]

[63]

[64] [65]

[66]

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/ Lange D.B.: Java Aglet Application Programming Interface (J-AAPI), White Paper, IBM Tokyo Research Laboratory, 1997. 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. Milojicic D.: Mobile agent applications, Trend Wars, IEEE Concurrency, Vol. 7, No. 3, JulySeptember 1999. http://computer.org/concurrency/pd1999/pdf/p3080.pdf 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/ Minar N.: Computational Media For Mobile Agents, http://nelson.www.media.mit.edu/ people/ nelson/research/dc/, 1996. Mobile Agent Platform (MAP) v2, University of Catania, Italy, http://sun195.iit.unict.it/MAP/ Mole 3.0, University of Stuttgart, Germany, http://www.informatik.unistuttgart.de/ipvr/vs/projekte/mole.html Nagy P.: Multi-Agent Coordination in Mobile Agent Systems, M.Sc. Thesis, Loránd Eötvös University of Sciences, Budapest, Hungary, 2000. 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. ObjectSpace Inc., Voyager TM Technical Overview, Version 1.0, December 1997, http://www.objectspace.com/Voyager Odyssey v1.0Beta2, General Magic Inc., USA, http://www.genmagic.com/technology/odyssey.html [no longer valid] OMG MASIF, Mobile Agent Systems Interoperation Facilities, The Object Management Group, ftp://ftp.omg.org/pub/docs/orbos/98-03-09.pdf Omicini A., Zambonelli F.: TuCSoN: A Coordination Model for Mobile Agents, Journal of Internet Research, Vol. 8, No. 5, pp. 400-413, 1998. 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. 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.unikl.de/AG-Nehmer/Projekte/Ara/Doc/intro-prog.ps.gz Peine H.: Security Concepts and Implementation for the Ara Mobile Agent System, 7th IEEE Workshop on Enabling Technologies: Infrastructure for Collaborative Enterprises, June 1719th, Stanford University, USA, 1998. http://www.uni-kl.de/AGNehmer/Projekte/Ara/Doc/ara-security.ps.gz 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. Plangent v1.0b8, Computer & Network Systems Laboratory, Corporate R&D Center, Toshiba Corporation, Japan, http://www2.toshiba.co.jp/plangent/index.htm 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 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)


71


[67] [68] [69] [70] [71]

[72] [73] [74]

[75] [76] [77] [78] [79]

[80] [81]

Riordan J., Schneier B.: Environmental Key Generation Towards Clueless Agents, in: Giovanni Vigna (Ed.): Mobile Agents and Security. pp 15-24. Springer-Verlag, 1998. RMI, The Java Remote Method Invocation API, Sun Microsystems Inc, USA, http://java.sun.com/products/jdk/rmi/index.html 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. 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. 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. SpringerVerlag, Germany, 1998 Schmidt D. C.: Overview of CORBA, http://www.cs.wustl.edu/~schmidt/corba-overview.html 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. 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. Sun Microsystems, Inc. The Java ™ Technology Home Page. http://java.sun.com/ Vigna G.: Cryptographic Traces for Mobile Agents, in: Giovanni Vigna (Ed.): Mobile Agents and Security. pp 137-153. Springer-Verlag, 1998. Voyager 3.1, ObjectSpace Inc., USA, http://www.objectspace.com/ Voyager ORB 3.2 Developer Guide, ObjectSpace Inc. USA, http://www.objectspace.com/products/documentation/voyager_html_docs/orb/index.htm 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 XML, The Extensible Markup Language, The World Wide Web Consortium, http://www.w3.org/XML/ 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


72


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/


73


7.2

A List of Major Mobile Software Systems

Name of the system

Prg. Languages Tcl

Developer Dartmouth College, USA

Accessibility stopped

Aglets Ara AMASE

Java Tcl, C, Java ?

free free n/a

Concordia CyberAgents D'Agents Facile

Java Java Tcl, Scheme, Java Standard ML

FarGo

Java

ffMAIN Grasshopper

Tcl, Perl, Java Java

Gypsy JAMES

Java Java

Java-2-go

Java

JIAC Jumping Beans

Java Java

IBM, Japan University of Kaiserslautern, Germany Deutsche Telekom, Motorola Paris, Sony Europe, University College London, DAI Lab, Berlin, etc. Mitsubishi, USA FTP Software Inc., USA Dartmouth College, USA European Computer Industry Research Centre, München Technion - Israel Institute of Technology University of Frankfurt, Germany Forschungsinstitut für offene Kommunikationsysteme, IKV++ Technical University of Viena, Austria University of Coimbra, Siemens, Portugal University of California at Berkeley, USA DAI-Lab, Berlin, Germany Ad Astra Engineering, Inc., USA

Kafka Knowbot System Software MAP Messengers Mobiware Middleware Toolkit MOA Mole MonJa Obliq Odyssey Plangent

Java Python

Fujitsu, Japan Corporation for National Research Initiatives (CNRI), Reston, VA

Java M0 Java

University of Catania, Italy University of Zurich, Switzerland Columbia University, USA

free free n/a

Java Java Java Obliq Java PlangentScript Java

The Open Group, USA University of Stuttgart, Germany Mitsubishi, Japan Digital Inc., USA General Magic Inc., USA Toshiba Corporation, Japan.

– free binary n/a stopped free

Sumatra

Java

University of Maryland, USA

n/a

Tacoma

Python, Scheme, Perl Telescript

Tromsø and Cornell University, Norway General Magic Inc., USA

free

Java

ObjectSpace Inc., USA

AgentTcl (see D'Agents)

Telescript

free eval. stopped free free (for academia) free demo version free free demo version n/a proriatery free (seems old) n/a free demo version binary n/a

stopped

(ancestor of Odyssey)

Voyager


free unsupported version

74


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) Java RMI Java

TM

Internet Protocol Java Remote Method Invocation API

TM

JiniTM JMS

Java Messaging Service API


75


JVM

Java Virtual Machine

KIF

Knowledge Interchange Format

KNIXMAS

Knowledge-shared, XPS-based Research Network Using MultiAgent 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


76

An Overview of Mobile Software Systems - Semantic Scholar

An Overview of Mobile Software Systems - Semantic Scholar

Suggest Documents

Software Components Evaluation: an Overview - Semantic Scholar

An Overview of Mobile Mapping Systems

Wireless Telemedicine Systems: An Overview - Semantic Scholar

Wireless Telemedicine Systems: An Overview - Semantic Scholar

Software Architecture - An Overview of the State-of ... - Semantic Scholar

An Overview of mobile-Augmented Reality in ... - Semantic Scholar

An Overview of mobile-Augmented Reality in ... - Semantic Scholar

An overview of mobile banking adoption among ... - Semantic Scholar

An Overview of the REX Software Architecture - Semantic Scholar

An Overview of Major Satellite Systems - Semantic Scholar

Mobile Recommender Systems - Semantic Scholar

An Overview on Analysis Tools for Software ... - Semantic Scholar

Mobile Recommender Systems: An Overview of Technologies and ...

Software Configuration Management Overview - Semantic Scholar

An assessment of systems and software ... - Semantic Scholar

Ethnopharmacology: An Overview - Semantic Scholar

Overview Component-based Software ... - Semantic Scholar

Provesicular drug delivery systems: An overview ... - Semantic Scholar

Vehicular Social Systems: An Overview and A ... - Semantic Scholar

Software Architecture for Mobile Distributed ... - Semantic Scholar

Recommender Systems: An Overview

Mobile Agents and Software Deployment - Semantic Scholar

An Overview of Jason - Semantic Scholar

An Overview of Multidimensional Visualization ... - Semantic Scholar