Most of the available distributed systems today are based on the client/server model, which is implemented through some form of remote procedure calls, or remote objects in the case of the object-based model. The client/server paradigm however, has its own limitations. Most notably, all interactions between client and server must go through the network as shown in Figure 1.
Another approach that is forming a new paradigm for distributed computing is mobile agents. This approach is attractive since the reliability of the network connection is not crucial. we will see why this is so in the next section.
This article will give you an introduction to mobile agents and describe some of the most widely talked-about mobile agent systems in Java that could be used to implement mobile agents. It should be noted that the reason I talk more about Voyager (see below) than any other agent system is because I find it easier to use than other mobile agent systems, and it has a number of innovative ideas implemented in it. Also, it comes with a great deal of documentation.
Mobile agents are programming entities that can freely roam the network on behalf of the user. They can maintain state information and make intelligent decisions using it. Mobile agents differ from applets in that they can independently roam among different machines on the Web, and are not limited to being downloaded once from server to client. Network reliability is not an issue when working with Mobile Agents, for the following reasons:
If a client requires extensive communication with a particular server somewhere on the network, then it is attractive to implement such a system as Mobile Agents. This is because if the agents require such extensive communication with a remote server, the agent may move closer to the remote server, reducing the network traffic, and thus it will be able to perform its tasks more quickly. Figure 2 demonstrates the idea of this paradigm.
- Mobile agents do not consume much bandwidth. As a matter of fact, they only consume network bandwidth when they move.
- They continue to execute after they move, even if they lose network connectivity with their creators.
Application of Mobile Agents:
Before talking about the frameworks available for developing mobile agents in Java, it is important for us to understand what this technology can do for us (software developers) as well as end users. Mobile agents seem to be useful for many different applications. Despite the fact that there are not many distributed computing problems that cannot be solved without mobile agents, nevertheless mobile agents can make certain applications easier to develop and may improve reliability and efficiency. An attractive area in which to use mobile agents is in processing data over unreliable networks. In such networks, the low-reliability network can be used to transfer agents, rather than a chunk of data, from place to place. In this paradigm, the agent can travel to the nodes on the network, process the information on those nodes without the risk of network disconnection and then return home.
Requirements for Mobile Agents
Even though mobile agents represent a useful new paradigm to distributed computing, they have seldom been used in practice. The reason for this is due to the fact that there are a number of technical as well as social challenges to implementing mobile agents. Technical challenges include, among others, difficulties with portability and security. Due to the heterogeneity of the Internet, a mobile agent must be able to run on many different platforms, and thus it must be written in a machine independent language. The security challenge is a more complicated one. As agents are executing on remote machines, there must be some sort of guarantee that they will not do any harm to the servers they are executing on.
Mobile agents raise issues similar to applets. There are several security issues to be considered in mobile agent-based computing. Some people think of mobile agents as viruses since they may exhibit similar behavior. However, analyzing agent's code to determine whether it is likely to exhibit virus-like behavior is a difficult problem. One approach to the security issues can be resolved by devising a security policy similar to that of applets. Applets cannot access the file system of the host downloading them.
What Language Should I Use?
Mobile agents can be written in any language (e.g., Perl, Tcl, Python, etc.) and may be executed in either machine or interpreted language. however, in order to support heterogeneity it is preferable and beneficial to write the agent in an interpreted language. With Java on the scene, it represents an ideal host language for writing mobile agents. This is due to the fact that Java bytecodes will run on any platform that has a Java interpreter without the need for recompilation.
Java-based Development Tools
The widespread adoption of Java is one of the major reasons of the current explosive interest in mobile agents. A number of companies have created development environments for writing mobile agents. The most talked-about development tools for mobile agents are: Odyssey from General Magic, Aglets from IBM Japan, and Voyager from ObjectSpace. Please see the list of available commercial mobile agents near the end of this article.
General Magic's Odyssey
Before Java came onto the scene, General Magic's Telescript - a C++-based language for creating mobile agents - was the most widely talked-about agent system. The three principal concepts implemented in Telescript are: agents, places, go. These three concepts together form the best name for mobile agents: "agents go places".
It should be noted that General Magic first coined the term mobile agents and in 1997 they received a patent for it. However, with Java coming onto the scene and promising platform independence, General Magic started developing Odyssey in Java. Odyssey is more or less a generic system that implements the basic functionality needed for creating mobile agents. Please refer to the refences for more information on Odyssey.
IBM Japan's Aglets
The Aglet Workbench from IBM Japan has received a lot of press coverage. this is probably due to the fact that their workbench was one of the early Java-based development tools for mobile agents. One thing, however, that is implemented in Aglets and lacking in the other agent development tools is GUI. The example agents that come with the system have GUIs. One drawback I noticed about Aglets is their programming model -- it is a bit complex - and probably this is due to the GUI stuff embedded into them. Note that Danny Lange, who was one of the main members of the Aglet's project, is now working on Odyssey for General Magic! For more information on Aglets please refer to the references.
ObjectSpace is a young consulting and development firm based in Dallas, Texas. Since the introduction of Java they have moved into that wonderful technology and produced the Java Generic Collection Library (known as JGL). This was their first Java product and it has been licensed by all major Java IDE vendors. As a matter of fact it is included with Borland's JBuilder.
Their second Java-based product is Voyager. Voyager is a Java agent-enhanced object request broker. Using voyager, you can:
- Remote-enable any Java class without modifying its code in any way
- Use regular Java message syntax to construct remote objects, send them messages and move them between applications
- Quickly create mobile agents that can roam a network and continue to execute as they move
- Locate agents easily and send them messages as they move and work.
Voyager uses 100% Pure Java and requires Java 1.1 as it uses serialization and reflection extensively. Voyager's key communication to support inter-agent communication is known as "Virtual Object." The Virtual Object is a powerful kind of proxy to agents or remote objects. With JavaSoft's Remote Method Invocation (RMI) mechanism, the developer will have to go through a series of steps to first describe the interfaces and then the implementation of the object. With Voyager, however, this is not necessary. Voyager provides a tool known as a Virtual Code Compiler (vcc) that takes any existing Java class, either a .java or a .class file, and creates the Virtual Object mirror of the class. For example, if you have a Java class named "myClass.class", you could use Voyager's "vcc" to process the myClass.class file and create VmyClass.class file. Note the "V" that stands for Virtual. Now, "VmyClass.class" exhibits some of the properties of an agent. Thus, you can instantiate, communicate with and migrate instances of myClass around the network.
The communication facility provided in Voyager is very flexible in the sense that it provides asynchronous, synchronous and future remote method calls. Method calls across address spaces have the same semantics as local calls. They are also polymorphic in the sense that they allow access to local as well as remote objects through virtual object proxies using the same syntax. Objects in Voyager can be created in remote address spaces and migrated from address space to another address space, each having its own life cycle.
Just like all other Java mobile agent systems, Voyager provides an agent server known as "voyager". However, the migration mechanism implemented in Voyager is innovative in the sense that it is not necessary to run the "voyager" agent server on all the nodes on the network. This is so because a virtual object can migrate not only between agent servers but also to other Java runtimes of other virtual objects.
Security in Voyager
Voyager provides support for the standard Java security manager system. If a Java program has a security manager, then once that security manager is installed it cannot be uninstalled or replaced. With the security manager installed, every time an object attempts to execute an operation that could possibly compromise security, the Java runtime system checks with the program's security manager to determine if the operation is allowed. If the operation is allowed, flow will proceed as normal. If the operation is not allowed, a "SecurityException" is thrown.
Voyager provides a security manager called "VoyagerSecurityManager" that can be installed when starting an application. This security manager works as follows: if a class is loaded via the application's CLASSPATH then that class is considered to be a "native object" and thus it is allowed to perform any operation. On the other hand, if the class is loaded across the network from another program, the class is considered a "foreign class" and thus its operations are restricted on a per-operation basis.
Voyager is available for free commercial use from http://www.objectspace.com/Voyager. A great deal of documentation is available for Voyager. This documentation includes an agent comparison white paper, comparing Voyager to Odyssey and Aglets, and another paper comparing Voyager to RMI. The documentation also includes over 170 pages of User Guide and a technical overview.
Commercial Agent Systems
There are a number of commercial agent systems available in the market today, including:
FTP Software: http://www.ftp.com
Kyma Software: http://www.info.unicaen.fr/~serge/kyma.html
IBM's Aglets: http://www.trl.ibm.co.jp/aglets
General Magic's Odyssey: http://www.genmagic.com/agents
About the Author
Qusay H. Mahmoud is a Senior Software Engineer in The School of Computer Science at Carleton University, Ottawa, Canada. Before joining Carleton University, he worked as a Software Designer at Newbridge Networks. Qusay holds a B.Sc. in Data Analysis and a Masters degree in Computer Science, both from The University of New Brunswick, Canada. Qusay can be reached at [email protected]