In order for mobile agents to be prevalent a suitable technology base needs to be installed on a large number of machines on the net. Selecting the technology is not a small task: it needs to fulfill all the characteristics discussed above and it needs to be real, deployable. No system perfectly meets all the requirements, but the Java system from Sun Microsystems [AG96] is the best available system today. Java is a combination language and operating system that has working implementations and a large degree of market acceptance. At the time this paper was written (December 18 1996) Java 1.0 is delivered in final form and Java 1.1 has just entered beta.
Java takes a virtual machine approach to portability. Java programs are shipped as bytecode; the bytecodes are a simple stack language that is interpreted by a virtual machine on the compute server. Some of the overhead of a Java interpreter can be reduced by ``just in time'' compiling: having the Java machine to compile the bytecodes down to native object code for execution. Even with a portable bytecode representation the exact semantics of every possible Java instruction needs to be specified in order for Java programs to be portable between different implementations. In practice, Java code has not been completely portable. Small tweaks to programs are usually required when moving between Java platforms. The incompatibilities are largely because of differences in the correctness and completeness of different virtual machine implementations.
Java has enjoyed an enormous amount of market acceptance in a very short amount of time. A large part of Java's quick spread has been because of aggressive marketing. Sun swiftly delivered a Java implementation to Netscape, thereby giving the average Internet user access to Java and creating a cultural phenomenon. More importantly, Sun has been mostly open about the Java technology, publishing specifications and APIs and giving away development tools. The Java design is unhampered by restrictions on distribution; free Java implementations are even underway [Jol96].
The actual use of Java so far has largely been in the very limited environment of applets for Web browsers. Applet environments are unsuitable for distributed computation; most browsers do not stay running very long and the applet security model does not allow enough resource access. There are a few Web pages that use embedded applets to distribute computation out to browsers but these are largely proofs of concept. Java must be deployed outside the browser in order to effectively create a computational medium.
One of Java's main strengths is that it gives simple access to Internet communication. Source code for software can be transparently downloaded from anywhere on the Internet. Custom socket level transmission of byte streams is easy with existing Java class libraries. However, Java 1.0 does not have any standard facility for sending objects over the net, nor is there a standard way to invoke a method on a remote object. Ad hoc solutions are currently possible, but Java 1.1 adds two new standard facilities to make distributed objects easy. Object serialization [Jav96b] allows objects to be sent via byte streams for network transmission. Remote method invocation [Jav96a] allows object methods to be called over the network. These packages are already available in the Java 1.1 beta release.
Java 1.0 takes an entirely physical-security approach to protecting machines from hostile programs [FM96]. A special object, a security manager, defines which resources a Java program is allowed to access. In the familiar case of Java applets the applet security manager creates a sandbox that prevents access to many resources including writing on the local hard drive and network communication to anywhere other than the host the applet came from. The Java virtual machine also contains a bytecode verifier that does static checks to prevent forbidden code sequences from being loaded, thereby ensuring the unbreachability of the sandbox surrounding the incoming code.
Java 1.0 does not have any implemented mechanisms for social enforcement of security policy. There are no guarantees about where a given piece of Java code comes from. Java 1.1 explicitly addresses this limitation with a Security API that includes digital signatures for Java code.
Currently used Java security managers are fairly inflexible: in practice, Java programs either have full access or run under strict applet restrictions. However, the security manager is a replaceable module. With the addition of class signatures it will be possible to selectively give access to certain resources depending on how much the server trusts the particular agent it is executing. A third party implementation is already available in E, a Java extension [E96]. Java 1.1 includes access control lists [Jav96c] that could form the basis of a system to define specific security policy for agents depending on trust level.
Java does not address the issue of security guarantees for agent code running on a Java virtual machine. Secure hardware implementations of Java should be possible but are unlikely to be commonly used. Several obfuscation programs exist to hide the structure of transported agents, but obfuscation does not stop determined attackers. It is not clear that it is possible to protect agents from servers that deliberately misexecute their code in any system.
Java also does not address the question of resource accounting. There do not appear to be any implementations of Java virtual machines that track the resources used by programs. Counting CPU, bandwidth and memory usage in a Java interpreter should be fairly simple, although the problem becomes more difficult in compiled code. The thread scheduler is probably the right place to add in CPU accounting, the garbage collector can determine memory usage, and the socket classes can track bandwidth usage. Implementing these systems efficiently will be challenging.
Java also currently has no explicit support for digital cash payments. The cryptographic basics of these systems are possible in any language; preliminary Java implementations do exist. A secondary issue is the actual distribution of digital cash: is there some easy (and secure) way to give an agent digital money to carry along with it as it executes? Efficiency of handling payments will also be a concern.
Several systems exist today to implement mobile agent facilities in Java. One limited application is found in ``servlets,'' Java code that runs on Web servers (analogous to applets running on a browser). JavaSoft's Jeeves [Jee96] is the most active servlet platform under development now. Jeeves is an HTTP server written in Java; it can be extended by loading in new Java classes from either the local disk or the network. One possible application is to allow clients to upload a servlet into a Jeeves server to perform computation on the server. Servlets run in their own restricted environment but are allowed to open a network socket back to their home to perform arbitrary communication. Jeeves is essentially a simple mobile agent system but is restricted in that servlets are intended to run in only limited ways inside the HTTP server. Servlets are not commonly expected to travel multiple times.
Several preliminary efforts are under way to create full mobile agents in Java. Implemented packages include Mole from the University of Stuttgart [Mol96] and Java2Go from Berkeley [LM96]. The SAIC also has published an API for mobile agents [SAI96]. All of these systems are based on Java 1.0: they use some sort of ad hoc implementation of object serialization and remote method invocation to create mobile agents. These systems are of interest in their different design approaches but probably will not be contenders for serious world-wide deployment.
Finally, a promising mobile agents project called ``aglets'' is under development at IBM [LC96]. Aglets relies on two basic specifications: an API for aglets (J-AAPI) and the Agent Transport Protocol (ATP). IBM has explicitly stated their intention to make aglets ubiquitous. ATP and J-AAPI have been put forward as standards. The specifications and implementations are available for free (with a restricted prerelease evaluation license).
Aglets implement mobile agents in a straightforward way. Resource providers run servers that accept agents; anyone can upload an aglet into a server. Java and the J-AAPI gives aglets portability. Aglets rely on the object serialization and remote method of invocation of Java 1.1 for effective network communication. Server security is handled by special aglet security managers. The security system is configurable and should be flexible enough to allow a variety of options, including policies based on the upcoming code signature specification. Aglets do not address agent security or resource accounting. A usable alpha version of aglets is currently being shipped; however, it requires Java 1.1 which is itself only available in beta for a few operating systems. As the software becomes more mature aglets looks to be the most likely platform for future mobile agent research.
