[Top]

[Back]

[Next]

[Bottom]

4 Mobile Agent Systems

"One doesn't discover new lands without consenting to lose sight of the shore for a very long time" - Andre Gide

4.1 The Mobile Agent Paradigm

Mobile (or transportable) agents are a direct extension of the client/server technology. In the client/server paradigm (Renaud, 1993), communicating entities have fixed and well-defined roles; a server offers a set of services and a client makes use of those services. This model also implies a strict sense of dependency; clients are dependent upon servers to provide the services that they require. The communication mechanism that takes place between a client and a server is through a message passing protocol since network communication is assumed. However, message passing has been criticised as being too low level, requiring programmers to determine network addresses and synchronisation points themselves.

The Remote Procedure Call (RPC) system developed by Sun Microsystems Incorporated (Bloomer, 1992) attempts to remove the burden of these details from the programmer. This is achieved by allowing the client to request a service to be executed on a server in the same way that it would make a local function call. These services are represented by stubs, which are template function calls that pass through to the RPC subsystem. The location of the server, the initiation of the service and the transportation of the results are handled transparently to the client.

However, a fundamental problem exists with client/server architectures when considering distributed information management. If the server does not provide the exact service that the client requires, for example the server only provides low-level services, then the client must make a series of remote calls to obtain the end service that it requires. This may result in an overall latency increase and in intermediate information being transmitted across the network which is wasteful and inefficient, especially for large amounts of data. Moreover, if servers attempt to address this problem by introducing more specialised services, then, as the number of clients grow, the amount of services required per server becomes unfeasible to support.

Other client/server systems include the Common Object Request Broker Architecture (CORBA) (Object Management Group, 1993) which attempts to make the client/server paradigm more accessible by adopting the object-oriented principles of object reuse, inheritance and encapsulation, and, the Distributed Computing Environment RPC (Open Software Foundation, 1992) which offers security and authentication facilities and an interface of user-level threads instead of sockets to achieve a higher level of abstraction.

Subprogramming alleviates the problem of client/server architectures somewhat by allowing clients to launch subprograms at the node where the service is located. In this way, any number of requests can be initiated locally and the subprogram can process the intermediate results before transmitting the actual results to the client once it has finished. Example subprogramming systems are SUPRA-RPC (Stoyenko, 1994), Remote Evaluation (REV) (Stamos et al., 1990) and Network Command Language (NCL) (Falcone, 1987).

Although subprograms can migrate on their initial launch, they cannot subsequently move to other systems or resources. This restricts their ability to communicate with each other since they may not execute for large periods of time and also maintains the rigidity of the client/server relationship. Additionally, subprograms are generally written explicitly for a specific client, so their reusability is minimised.

The mobile agent paradigm attempts to address the issues that are raised by the client/server and subprogramming paradigms. Typical characteristics of mobile agents are their ability to migrate at will, autonomy in their actions, a peer-to-peer personality and a processing and network independence from their original location.

Mobility is a desirable characteristic in agents for a number of reasons (Harrison et al., 1995):

• Efficiency. If an agent can move across networks to the location where resources reside, then network traffic can be reduced since the agent can preprocess data and decide which is the most important information to transfer. This is a crucial aspect when considering users who connect through a low bandwidth link.
• Persistence. Once a mobile agent is launched, it should not be reliant on the system that launched it and should not be affected if that node fails. The concept of an agent moving between network nodes gives it the ability to `survive' and to reach as many resources as possible. This is useful for mobile computer users due to the fact that they can log on, launch an agent, log off and check later on its progress.
• Peer-to-peer communication. A failure of the client/server paradigm is the inability of servers to communicate. Mobile agents are considered to be peer entities and, as such, can adopt whichever stance is most appropriate to their current needs. For example, when a mobile agent is interrogating a resource it takes the role of a client. However, when another mobile agent wishes to query it, then it becomes a server. This allows for great flexibility in dealing with network entities and distributed resources.
• Fault tolerance. In a client/server relationship, the state of the transaction is generally spread over the client and the server. In the event of a network or server failure during a request, it is difficult for the client to reclaim the situation and re-synchronise with the server because the network connection will have been lost. However, since mobile agents do not need to maintain permanent connections and their state is centralised within themselves, failures are generally easier to deal with.

4.2.1 Migration

Just as a mobile agent is fundamentally different to a process, so too is agent migration different from process migration; the difference lies in who decides where and when to move. In process migration, migration is normally forced upon a process by the system, due to resource location, load balancing and other similar factors. This is generally a complex and intensive operation. With mobile agents, it is the agent who decides when to move and the underlying infrastructure must support and execute this request. Enforced migration can only be effected upon an agent in extreme circumstances, for example, if the agent attempts to perform a forbidden action.

There are two approaches to moving agents between network nodes:

• State-oriented. This system allows agents to move at any point in their execution, usually through a mobility imperative (such as go, jump or move). When this command is initiated, the current state of the agent is encapsulated and transferred across the network to the receiving network node. Once received, execution of the agent resumes at the instruction following the mobility imperative. The capture of an agent's state can be achieved either by the agent itself or by the infrastructure, both of which are non-trivial tasks.
• Stateless. With a stateless system, agents can move at any point in the code, but restart their execution from the beginning of their code rather than the point of migration. This means that before the agent can move, all state information must be written to a data repository or knowledge base that is encapsulated and transferred with the agent. At the receiving network node, if it needs to, the agent must restore its state manually from the repository. Such systems are easy to migrate, but make writing the agent difficult since all of the state store/restore burden resides with the agent.

4.2.3 Route Determination

• Predetermination. This is where the agent is given the destinations that it must visit when it is launched. This is useful in situations where the activities of an agent need to be carefully controlled, for example, when making consistent alterations to resources or where the order in which network nodes are visited is important.
• Dynamic determination. This method dictates that the agent has been given complete freedom over the network nodes that it can visit. The mobile agent may simply make a random choice, which is quite difficult unless it knows what nodes are available, or it may make a decision based upon its own node-knowledge history or information gained from other agents. This type of freedom is useful for data mining agents where a wide field of interrogation is required.
• Hybrid determination. This is an amalgamation of pre- and dynamic determination methods. Put simply, the mobile agent is given a list of destination nodes that it must (or must not) visit, but can still exercise some discretion if a potential node offers data or services that are compatible with the agent's goals. Alternatively, the agent is equipped with a set of criteria that determine the type of nodes that it can visit; nodes that do not fit these criteria cannot be visited by the agent. This is useful in situations where the speed (and maybe quality) of data return is more important that the depth of data covered.

• Network-oriented. Agents communicate through some network-based mechanism, such as message passing. This means that the communicating parties do not have to be residing on the same node or even the same network.
• Node-oriented. Agents communicate through some local inter-process communication mechanism, such as files, shared memory or anonymous pipes. This means that the communicating parties must be currently executing on the same network node.

• Synchronously. The communicating parties must arrange for a time to communicate and must synchronise before data can be transferred. This is typically used for situations where data transfer is important and needs to be confirmed or there is to be some interactive dialogue, for example, agents querying each other's knowledge bases.
• Asynchronously. The communicating parties can communicate with each other at will: the data is received as the receiving party checks for it. This is a much lazier approach than synchronous communication and is generally used for transferring informative data.

• Local environment. Mobile agents are restricted to communicating with the local network environment to ensure that the intermediate data transfer problem associated with the client/server paradigm does not arise; they must move between local environments to access data. The only time agents are allowed to communicate with remote environments is in determining the resources or services that exist there, in trying to determine the location of another agent or in transferring results back to the original node of the agent.
• Other agents. Communication between agents is useful in a number of contexts; to allow agents to share information about nodes, to allow agents to interrogate other agents' knowledge bases and in coordinating activities between agents for collaborative work. Nearly all current mobile agent systems provide some form of communication abstraction for agents, typically called meet or talk for example, which simplifies the process of agent location and negotiation. However, it is no trivial matter to organise meeting points between mobile agents, due to their mobility!
• Users. At some point, mobile agents will need to communicate their results back to the user that initiated them. Typically, mobile agents log their data with an agent at the user's network node and this either presents the information `as is' or preprocesses it in some fashion. In most resource discovery activities, this task is often performed by another agent which collates the information and organises it into a format which is suitable for the user to view. Additionally, this agent may integrate with the user's desktop environment to present the information using the most appropriate applications, for example, rendering RTF in Word or spreadsheet information in Excel.

4.3.1 Agent TCL

All services that are available within the system are provided by agents, transportable or stationary. Agents can be written in a language that supports interpretation, such as TCL or Java (Gosling et al., 1995), but the authors indicate that compiled agents might be possible in a limited capacity. For example, an agent written and compiled in C might not be able to migrate, due to its platform dependence.

At each Agent TCL site, a server resides and handles the management of local agents and incoming agents. The server also provides mechanisms for enforcing security, providing a hierarchical name space in which agents can be referenced and allowing agents to address each other locally.

Agents move between sites in a state-oriented fashion by issuing the mobility imperative agent_jump. This command packages the state of the agent and transfers it to a destination site where the server restarts the agent at the instruction after the mobility imperative. The method in which the agent is communicated is determined by the transport system advocated by the local site server, for example, TCP/IP, email, etc.

The execution of agents is handled by an interpreter that is appropriate to the source language of the mobile agent. In Agent TCL, the interpreter of TCL was extended to support three extra modules (figure 4.2); a security module that prevents an agent from performing malicious actions, a state capture module that packages and restores the internal state of an agent and a server API module that allows interaction with the server to provide migration and agent communication, for example.

The alpha release of Agent TCL only supports synchronous, network-oriented communication through the commands agent_meet to initiate a communication with another agent, and agent_accept which completes and synchronises the two agents. Also, movement between sites is predetermined with a set of machines being specified in the agent's code. However, future work will look at making agents aware of their environment so that they can plan a migration strategy.

The Agent TCL architecture has been used in three information retrieval applications. The first is in the domain of technical reports, the second in text-based medical records and the third in three-dimensional drawings of mechanical parts.

4.3.2 TACOMA

TACOMA considers agents, either stationary or mobile, to be the computational unit of the system. As such, agents that are mobile operate in a stateless mode and each agent has three storage mechanisms. A folder is the essential unit of data that is accessible by an agent (figure 4.3); folders can be stored in filing cabinets which are stationary data repositories, or in briefcases which are containers that agents carry with them. When an agent migrates between sites, state information is stored inside a folder called DATA, and the code for the agent itself is stored within another folder called CODE (both within the same briefcase associated with that particular agent). At the receiving site, the code of the agent is extracted from the CODE folder and executed; the agent must look in the DATA folder for its data and state information.

There is only one abstraction for both communicating with other agents and transporting agents between sites; the meet operation. When an agent wishes to move to a new site, an entry is added to a folder called HOST in the agent's briefcase indicating where to move. This is a predetermined movement mechanism but the author's are attempting to remove the HOST folder by implementing a scheduler which partially automates the migration process.

To initiate the move, the agent meets with the interpreter called ag_tcl on the remote site, thus:

meet ag_tcl briefcase

meet some_agent briefcase

TACOMA also has mechanisms for firewall agents (tag_firewall) and RPC-style communicating agents (tag_rpc). The tag_firewall agent provides an entry point to a site and a convenient point to perform such functions as authentication, access control and accounting. tag_rpc allows client agents to block while they are awaiting results from a server agent.

The future of the TACOMA project lies in investigating mechanisms for fault tolerance, for example, by using rear guards. A rear guard is a special agent that is left behind when an agent migrates; it is responsible for launching a new agent should a failure cause an agent to vanish and for terminating itself when it is no longer necessary.

4.3.3 Telescript

At the basic level, agents can move between places which are logical areas associated inside Telescript engines; an engine can support multiple places but has an outermost place called the engine place. Engine places themselves run within a larger context, known as a region, which are the connection points for the Telescript network. A region can consist of multiple engines running multiple places (figure 4.4).

Upon going to a place, the engine managing that place must authenticate the agent and either grant or deny access. If access is denied, then agents can be routed to a special place, called purgatory, where they are allowed to live for a short time in a limited environment. This allows them to recover and select a new destination.

However, if access is granted, then the agent enters that place and can communicate with other agents if the place is designated as a meeting place. The engine managing the meeting place mediates a meeting protocol between two agents in a synchronous and network-oriented manner, giving each agent the chance to accept or reject the meeting.

Telescript is currently being used in the AT&T PersonalLink(TM) network for mobile communications and is seen as a potential mobile computing mechanism for Personal Digital Assistants (PDAs).

4.3.4 An HTTP-Based Infrastructure for Mobile Agents

The architecture itself (figure 4.5) consists primarily of an agent server, which is a process that executes on every host that can be accessed by agents. Its tasks include accepting agents, creating an appropriate runtime environment for agents to execute within, supervising the execution of agents and terminating agents if required. In addition to this, the agent server must also organise the transfer of mobile agents to other hosts, manage communication between agents and their users, and perform authentication and access validation.

Mobile agents that move between agent servers are launched from a home server, which keeps track of the agent's progress through the network. Agents are transferred as encapsulated Multipurpose Internet Mail Extension (MIME) documents in a stateless manner, by POSTing them to a special URL that is managed by an agent server. Upon receiving this agent, the agent server parses the code of the mobile agent and determines whether it is acceptable. If the agent can execute on the site, then the agent server launches it within an appropriate runtime environment and forwards a URL to the home server of the agent to inform the user of its new location.

Communication between agents is also achieved through HTTP in an asynchronous manner only; each agent server maintains an information space which is accessible to agents via POSTing and GETting. The agent server mediates access to entries within its information space by checking the requesting agent's credentials against the Access: header that was supplied with the entry.

At present, the framework is incomplete. For example, there is no provision for synchronous communication between agents, there is a painful lack of adequate security measures and agent servers must be aware of their neighbours to enable mobile agents to decide where to move to next.

4.3.5 Conclusions

Although each of these mobile agent architectures support differing levels of functionality, they each attempt to address the same problem, namely, enabling portions of code to execute on different machines within a wide-area network.

Table 4.1: Comparison of Mobile Agent Architectures

		Characteristics
		Migration	Acquisition	Route Determination	Communication
	Agent TCL	State-oriented	None explicitly	Predetermination	Network-oriented, synchronous
	TACOMA	Stateless	None explicitly	Predetermination	Network-oriented, synchronous
	Telescript	State-oriented	Web integration	Dynamic determination	Network-oriented, synchronous
	HTTP-Agents	Stateless	Web integration	Hybrid determination	Node oriented, asynchronous

Table

The weakest system is the HTTP-based infrastructure for mobile agents due to its primitive agent migration mechanism and simplistic communication model, for example, how can mobile agents pass real-time data between each other? However, asynchronous communication is desirable when an agent needs to issue multiple information requests and then process the results at a suitable time. The concept of a shared information space where agents can advertise their services is useful in arranging for mobile agents to meet and share data.

TACOMA also suffers from a stateless migration policy which hampers the ease at which migration can be achieved from the point of view of the programmer writing a mobile agent. Additionally, TACOMA's lack of dynamic determination means that a programmer must be aware of the locations that an agent can visit before it can be launched. This is advantageous for predicting the path and position of an agent, but limits its functionality. However, TACOMA's data storage model is very flexible and the actual way in which information is transferred between agents and servers is beautifully simple.

The main problem with the Telescript architecture is that it only supports the Telescript language (which must be entirely supported by Telescript engines) and is not open to researchers to develop. On the other hand, the Telescript language was designed for writing mobile agents so migration is well supported, security is intrinsic to the system and communication between Telescript agents is handled through meeting places and also directly between agents.

Agent TCL appears to be the most flexible architecture, since it supports state-oriented migration, multiple languages and networking protocols and a comprehensive communication subsystem. Once the predetermined routing of agents is resolved and some security measures are implemented, it will be a flexible and powerful mobile agent system.

One feature that all of these mobile agent architectures have currently failed to address is in defining a domain of applicability; they all concentrate on the mobility of agents rather than the integration of agents with information resources. General Magic, for example, has been recently criticised by the mobile agent community for concentrating the Telescript language too closely on the migration aspect and not considering integration with the desktop and third-party applications. To remedy this situation, General Magic are looking to integrate Telescript mobile agents into the desktop in a heterogeneous fashion by using the abstract windows toolkit (AWT) in the Java programming language. Further, they have recently produced a set of integration tools, called Telescript Active Web Tools, which provide class hierarchies to enable Telescript agents to integrate with Web servers and resources.

4.4 Summary

The next chapter describes the requirements for a mobile agent architecture that can support, but is not limited to, distributed resource management. It is hoped that the future development of this architecture will provide the integration of distributed information resources and third-party applications through the use of an extensible and flexible mobile agent subsystem.

[Top]

[Back]

[Next]

[Bottom]