Technologies for the Development of Agent-based Distributed Applications[5]

Discussing the capabilities of Java-based agent systems in each of the areas listed in the section "Requirements for agent systems," existing systems will be referenced in this section for illustrative purposes. We survey existing Java-based mobile agent systems focusing on their ability to solve the three main problems discussed before.

Mobility

Agent systems based on Java can necessarily provide only weak mobility, because the Java virtual machine's (JVM) concept prohibits access to the execution stack. Hence, these systems define dedicated methods as "entry points," which are called if execution of the agent is to be resumed on the target system (see Broos et al. [3] for a list of such systems). Likewise, special callback methods ("pseudo-halt") are defined that are called upon relocation requests to the agent. Entry point and pseudo-halt methods must provide mechanisms to save and restore an agent's execution state in a manner that allows the agent to behave after a transfer in the same way that it would have using strong mobility.

While it is common practice to provide a single entry point for post-transfer execution [9, 1], there is also at least one example of a system that allows different entry points to be defined [10]. However, this feature can be emulated on single-entry point systems with little overhead. As a supportive function, most Java-based agent systems allow itineraries to be specified for a particular agent to define a set of hosts to be visited [9, 10]. To address the problem of tracking object references, some agent systems, for example, Grasshopper [10] and Mole [1], employ proxies that keep object references valid. IBM's Aglets [9] also uses proxy objects, but they only keep references valid if migrated together with the agent. The most simplistic approach, letting references become invalid, can still be found in a number of systems, e.g., Odyssey by General Magic. The need to manually track references not only constitutes considerable programming overhead but can also lead to problems when the agent attempts to restore object references after migrating [16].

Security

Because Java has an advanced security concept already built-in, security mechanisms are fairly easy to adopt for the purposes of agent systems. Mobile agent systems have to ensure confidentiality (data carried by the agent must not be accessible by unauthorized users), integrity (any manipulations, e.g., during migration, must be discovered), and authentication (the identities of both communication parties must be undoubted). Orthogonal to this, security issues can be categorized into internal (protecting the platform itself and agents from attacks by other agents, respectively as well as protecting agents against attacks from hosts) and external security (ensuring secure communication with the rest of the world outside a specific place).

External security is currently only available in few systems (see IKV++ [10]), where it is mainly achieved through the use of SSL (Secure Sockets Layer) and certificates. Because Java provides a comprehensive framework for handling certificates, this can be expected to change in the future.

Internal security is implemented in all available platform systems by means of Java's security manager, combined with access control lists [3].

Communication

Java-based systems by nature support Java's remote method invocation API as well as messaging. No agent platform supports communication on a semantically higher abstraction level, i.e., through agent communication languages facilitating knowledge representation on a high level of abstraction.

A potential disadvantage of interpreted languages such as Java is their potentially poor performance. Fortunately, considerable progress has been made in that area, improving the performance of interpreted languages through techniques like just-in-time compilation.

Other platforms

Today, no agent systems exist that allow for agents to be represented as machine-level binaries. The reason for this is that it would prevent platform independence. Although there would be huge performance gains compared to interpreted languages, this approach restricts respective systems to homogeneous computing environments, where homogeneous refers to both operating system as well as hardware architecture, thus eliminating one of the key advantages of mobile agent systems. Also, internal security mechanisms are difficult to implement.

One feature that is only available in platform systems that allow access to the execution stack is strong mobility. It can be questioned whether strong mobility is an important concept or weak mobility is already sufficient [16]. However, scenarios in which strong mobility cannot be replaced by weak mobility are hard to think of. Regarding the problem of tracking the validity of object references, agent systems have to implement mechanisms to copy referenced objects to the new place, either straight alongside the migration process, or dynamically ("on reference") when they are referenced after migration is completed. Since this problem likewise affects all agent platforms, all assertions made for Java-based platforms apply here as well.

[1]  [2]  [3]  [4]  [5]  [6]  [7]