In the last few years, several systems and programming environments have appeared to support the development of Internet applications based on mobile agents. Nevertheless, there are still several open research issues to make the mobile agent technology widely accepted: among the others, appropriate programming languages and coordination models, security, efficiency and standardisation.
In mobile agent applications, one of the fundamental activities is coordination between the agents and the entities they encounter during execution, being they other agents or resources of the hosting EEs. However, mobility and openness of the scenario imply different problems than traditional distributed systems. As argued in [CabLZ98a], coupled coordination models (for example message-passing) do not suit mobile agent applications and force complex design choices. Instead, fully uncoupled (Linda-like) coordination models based on local tuple spaces have the necessary adaptivity to suit a wide and heterogeneous networked scenario and lead to simpler application design. An agent arriving at a site exploits a local tuple space for its interactions by using always the same set of primitives. Both inter-agent interactions and accesses to the local resources occur via the tuple space.
Our work starts from the consideration that the raw Linda model lacks the necessary flexibility and adaptivity to deal with a dynamic heterogeneous environment as Internet. Further flexibility and safety stem from the definition of reactive Linda-like coordination models in which the semantics of the interactions can be programmed to meet both specific needs of the agents and peculiar characteristics of the EE.
We stress that our aim is not to build a new engine for the execution of Java-agents. Instead, the goal is to develop a general and portable coordination architecture for Java agents. The MARS tuple space is only loosely coupled to the agent server and it is not bound to any specific server implementation. In fact, it may be associated to different Java-based mobile agent systems, as IBM Aglets or Odyssey, with only a slight extension: i.e., the execution engine must keep the reference to the local space and provide it to incoming agents. In fact, the mobile agent server has to keep a reference to the MARS local tuple space to be provided to each agent arriving on a node (step a of figure 1), the local server provides it this reference (step b). The mobile agent server adopted for the first prototype is the Java-to-go package [Mes97], a well-documented environment, developed at the University of California at Berkeley (CA).
As an agent is bound to the local tuple space, it can access to it for reading, extracting and putting tuples (step c in figure 1). Then, an agent associatively retrieves information from the tuple space: it can be either primitive data items or references to objects that represent EE resources. In addition, the tuple space can be exploited for inter-agent communication. For these reasons, the problem of dynamically binding local references to mobile entities [FugPV98] is solved in MARS by dynamically extracting references from the local tuple space.
MARS defines a reactive tuple space model in which the effects of the operations on the tuple space can be dynamically modified. Agents access to the tuple space always with the same basic set of operations (Linda-like). Specific reactions (implemented as methods of Java objects) can be associated to the accesses to the tuple space made by mobile agents (step d in figure 1).
There are four components to be considered when associating reactions: reaction (Rct), tuple item (T), operation type (O) and agent identity (I). The association of a reaction to an access is represented via a 4-ple (Rct, T, O, I): the reaction (i.e., the method of a Java object Rct) is executed when an agent with identity I invokes the operation O on a tuple matching T. Therefore, the association of reactions to tuples is dealt with meta-level tuples that can be considered enclosed in a meta-level tuple space which follows the same associative mechanisms of the base-level tuple space. Putting and extracting tuples from the meta-level tuple space provide to install and de-install reactions associated to events at the base-level tuple space. A 4-ple (possibly with some non-defined values) associates the reaction to all the accesses that matches the 4-ple. A match in the meta-level triggers the corresponding reaction.
We forward the interested reader to [CabLZ98b] for a detailed description
of MARS and of its reaction model.
As an example, in the area of distributed information retrieval, the MARS architecture can be exploited to rule the access of the agents to the local data of the EE. By means of the reactions, the local administrator of one site can enforce the security policies of the environment and preserve the integrity of the local data from malicious agents. Agents, by their side, can exploit reactions to coordinate with other agents of the same application, for example to avoid multiple visits on the same site or to retrieve data in an incremental way.
Another interesting application area is electronic commerce. Let us
consider a "buyer" mobile agent that roam through specific commercial sites
to look for a stock of given stuff with the constraint of a maximal buying
price. The MARS architecture can be exploited by integrating contracting
capabilities, in the form of reactions, directly into the tuple space.
For example, appropriate reactions can provide to dynamically evaluate
the willing of the buyer agent as it attempts to read information û
in the form of tuples û from the tuple space: instead of fixing a
price for its product, the local site can dynamically evaluate the product
prices and the corresponding tuples depending on the agent request.
Another important issue we are investigating relates to security and
aims to define the extent to which agents can be allowed to program reactions
on remote tuple spaces. On the one hand, it is not clearly feasible to
let agents freely distribute reactions onto remote sites. On the other
hand, only the capability for agents to install application-specific reactions
would provide the degree of flexibility and adaptivity required by mobile
agent applications.