Concordia Agents have the ability to travel through a computer network. At programmer discretion, an agent can be instructed to move from one machine to another. During its travels, an agent maintains its internal state, meaning any information it retrieves along its travels is remembered when it arrives at a new destination. More exactly, the state of all of an agent's member variables persists through each network transmission. The work of transporting the agent is handled transparently by the agent system.
Concordia Agents are themselves Java objects. As objects, agents are composed of both data (the agent's state) and executable code (the agent's Java bytecodes). Moving an agent around a network requires the movement of the agent's state as well as its bytecodes. Thus a traveling agent can be pictured like the following:
The fact that Mobile Agents move both their state and bytecodes around a network makes them very different from either distributed objects or web applets. In the world of distributed object systems, such as CORBA or DCOM, stationary objects can use the network to remotely call the methods of other objects. While two objects communicate across the network, neither object actually moves. World Wide Web applets provide a mechanism for bytecodes to be downloaded from a web server to a web browser, but provide no mechanism for any state information to travel. An applet object does not travel from the server to the client, rather the applet bytecodes are downloaded, in exactly the same way as an HTML page is downloaded, and then those bytecodes are used to create an object. Once the applet is created, it stays within the browser and cannot move.
The fact that agents are mobile also means that the mechanisms needed for retrieving
and loading of bytecodes are different than in the case of Java applications and applets.
In the above example, MyAgent contains two member variables of type AgentObject
and AnotherObject. The bytecodes for these classes would be stored on a
computer filesystem, in files named AgentObject.class
and AnotherObject.class. Since Concordia
Agents travel, it is possible for an agent to travel to a machine where the AgentObject
and AnotherObject classes are not installed and the AgentObject.class and AnotherObject.class files do not exist on the
local file system. For example, in a development environment, such as the one shown in Figure 2, it is certainly possible that the bytecodes of an agent under
development would not have been installed on a server used for testing.
Figure 2 - Class Loading Scenario
This scenario can lead to a potential problem in that if the MyAgent creates an object of type AgentObject or AnotherObject while executing on the test server, a mechanism is needed to move the bytecodes from the developer's workstation to the test server. To handle such cases, Concordia utilizes a hybrid push-pull model for moving of bytecodes.
Concordia's pull model operates in a manner very similar to the way that a web browser downloads the bytecodes for an applet. Every agent carries a URL pointing to the location of its codebase on its home machine (referred to as its homeCodebaseURL). In most cases this codebase will be a location on a web server. If the Concordia Server discovers that the bytecodes required by an agent are not present on its local file system, the server sends a network request to the codebase to load the bytecodes. In most production cases, this is an HTTP request to a web server. Concordia also incorporates a automatically pushed with push model in that once a class has been downloaded, it will, from then on, be pushed with agent's bytecodes around the network as depicted in Figure 1.
In some cases, a simple pull model for class loading is not appropriate. For example, if an agent is going to travel far from its home machine, across a WAN or the Internet, a network request to load classes can be slow and very expensive. If an agent travels through a firewall, it may be impossible for it to send a request back to its codebase. To handle such cases, Concordia allows the user or developer to specify a list of related classes when launching the agent. The related classes automatically travel with the agent and are always available to it during its travels. In the example shown in Figure 1 and Figure2, if the Concordia developer included AgentObject and AnotherObject in the related classes list, then the bytecodes for these classes would be pushed with the agent to each server to which it travels. If the related class list contains a complete list of all the classes the agent needs during its travels, then thehomeCodebaseURL does not need to be specified since no requests to the codebase are necessary.
Performance of an agent application can be tuned using the related class list. The more bytecodes that travel with the agent, the more network resources are needed to transmit the agent. However, network requests to retrieve code, also consume network resources. In general, if the agent will be travelling across a WAN, wireless network, or the Internet, reliability can be gained by specifying a fairly complete related classes list. If a class will definitely be needed by an agent at each stop in its travels, then pushing that class with the agent will yield the best performance. If a class may not be needed by an agent (i.e. an instance of the class is only created under exceptional circumstances) and the agent is traveling in a high speed, reliable network, then the pull model can yield the best performance.
An agent's Itinerary defines where it travels on the network . The Itinerary specifies a list of Destinations, each of which specifies where the agent is to travel and what work it is to do when it arrives there. Within a Concordia system, where the agent travels is specified as the hostname of the particular server, and what work to accomplish is specified as the name of a method of the agent which should be allowed to execute on that machine.
An agent's travel and execution is managed by an object called the AgentManager which runs as a component of the Concordia Server. The AgentManager handles: