Distributed-systems.net

Generative Migration of Agents
F.M.T. Brazier; B.J. Overeinder; M. van Steen; N.J.E. Wijngaards Department of Computer Science, Faculty of Sciences, Vrije Universiteit Amsterdam; de Boelelaan 1081a, 1081 HV Amsterdam, The Netherlands Abstract
Agents, and in particular mobile agents, offer a means for application developers to build distributed applications. Incurrent agent systems, mobility of agents is constrained by the environment of the agents: the agent platform (whichsupports agents) and the agent’s code base (e.g., DESIRE, Java). Generative migration is needed to adapt an agent toconform to its destination agent platform and code base. In this paper generative migration is described as a process of“transparently adapting” an agent. An agent can continue to function at its new location on a completely different agentplatform.
Introduction
based a blueprint. The blueprint of an agent contains aconfiguration of conceptual building blocks which speci- Agents, and in particular mobile agents, offer a means fies the agent’s functionality and behaviour. The blueprint for application developers to build distributed applica- also contains one or more configurations of detailed build- tions. In current agent systems, mobility of agents is con- ing blocks, which specify an operationalisation of the strained by the environment of the agents: the agent plat- conceptual functionality and behaviour.
form (which supports agents) and the agent’s code base A mapping is defined between building blocks at con- (e.g., DESIRE, Java). Within the same agent platform and ceptual level and building blocks at detailed level. (Note code base, agent migration has been shown to be possible.
that this mapping may be structure preserving, but that However, many agent platforms exist, differing substan- this is not necessarily ideal.) A detailed description of a tially in the support for agents. Write once - run every- building block includes the operational code. For each conceptual description, a number of detailed descriptions This heterogeneity of agent platforms, combined with may be devised and vice versa. These detailed descrip- heterogeneity in code-bases of agents, leads to an inter- tions may differ in the operational language (e.g., C++, esting question concerning agent mobility: can an agent Java), but also in, for example, the efficiency of the op- migrate across heterogeneous platforms? The answer is erational code. The conceptual descriptions may differ in relatively simple, as an agent needs to be adapted to fit its the modelling paradigm (e.g., UML, DESIRE), but also in, destination agent platform and code-base.
e.g., the detail in which an agent’s functionality is mod- In this paper generative migration (see Brazier et al.
(2002)) is described as a process of “transparently adapt- Building blocks themselves are configurable, but can- ing” an agent. Section 2 presents an overview of the prin- not be combined indiscriminately. The open slot concept ciples behind agent factories: the entities responsible for is used to regulate the ways in which components are processing blueprints. Section 3 describes the use of the combined. An open slot in a component has associated agent factory for generative migration. Section 4 investi- properties at both levels of abstraction that prescribe the gates implications of generative migration for agents and properties of the building block to be “inserted”.
agent factories. Section 5 discusses transparent adaption A prototype of the agent factory automatically (re- )designs an information retrieval agent: its blueprint andexecutable code. The blueprint of an existing simple in-formation retrieval agent is briefly described by Brazier Agent Factory
et al. (2002). This prototype agent factory itself is writ-ten in Java, and contains enough knowledge to (re-)design An agent factory is a facility that creates, and modifies, simple information retrieval agents.
software agents, see Brazier and Wijngaards (2001). Itcan be used to adapt agents so that they can use specificprogramming languages and run on different agent plat-forms. The design of an agent within an agent factory is Generative Migration
One of the strengths of the agent factory concept is that it provides a means to support migration of agents in heterogeneous environments. Section 3.1 discusses pre- conditions for successful migration of agents. Section 3.2describes the approach in agent-factory-enhanced migra- Figure 1: Example migration scenario in which agent A tion. Section 3.3 describes migration scenarios.
on Host 1 (written in Java, running on Ajanta) migrates toHost 2 (where it will be specified in DESIRE and running Migration pre-conditions
A mobile agent is simple an agent having the ability tomove between different machines, e.g. see Tanenbaum Host H2’s local agent factory receives the blueprint of and van Steen (2002). Agent migration entails transfer the agent and state information. This agent factory con- of both the agent’s executable code and state. The con- structs a DESIRE agent A on the basis of the blueprint of cept of generative migration is geared to weak mobility: agent A. This DESIRE agent A (i.e., a functionally equiv- parts of the state of the agent are migrated to another host.
alent incarnation of the Java agent A) runs on DESIRE’s Strong mobility, i.e. migrating running processes (includ- virtual machine (the DESIRE-interpreter), and is able to ing their memory usage, stack, heap, etc.), is not possible incorporate information on its state.
with generative migration, as in most cases agent executa-bles change.
Migration scenarios
Generative migration requires (1) agent factories, (2) implementation independent representations of agent Migration including re-generation of agents is a more functionality, and (3) implementation independent for- complex process, requiring more resources, than migra- mats of agent’s state (e.g., XML, RDF or OIL may be used, tion without agent re-generation. Four migration scenar- ios are distinguished in Brazier et al. (2002): Assuming that both the source and the destination host both have access to an agent factory (for simplic- • Homogeneneous migration. An agent migrates to ity’s sake), these agent factories need to have building another host without any changes in either the vir- blocks with comparable functionality. One solution is tual machine or the agent platform. This situation that the agent factories share the same libraries of con- is most common in practice, and does not warrant ceptual building blocks, but each have different libraries of detailed building blocks. Another solution is to have • Cross-platform migration. An agent migrates to an- conceptual building blocks in ZEUS (see Nwana et al.
other host with the same virtual machine, but a dif- (1999)) and DESIRE (see Brazier et al. (1997)) with com- ferent agent platform. Generative migration may be used to adapt the agent to the target agent platform,e.g. by using wrapper interfaces. If both agent Migration using the agent factory
platforms have the same standard interface (e.g.,advocated by Migration using an agent factory diverges from standard see FIPA (2001)), the agent need not be adapted.
mobility of agents in that it is not executable code withstate that is migrated, but instead the agent’s blueprint • Agent-regeneration migration. An agent migrates together with (parts of) the agent’s state. Consider the to a host with a different virtual machine, but following scenario for heterogeneous mobility (also de- scribed by Brazier et al. (2002)), depicted in figure 1.
is needed to regenerate the agent’s executable code An information retrieval agent A currently resides on for the target virtual machine and the agent plat- host machine H1. This host runs the Ajanta agent plat- form, developed by Tripathi et al. (1999), and supportsJava agents. The agent wants to move to another host: • Heterogeneous migration. An agent migrates to a host H2. Host H2 runs the DESIRE platform, and its host with a different virtual machine and a differ- agents run code generated by the DESIRE execution en- ent agent platform (see the scenario described in vironment, see Brazier et al. (1997).
Figure 1. In this situation, generative migration is In the process of migrating the agent A from host H1 needed to regenerate an agent for the target virtual to host H2, the agent first needs to store information on its machine and the target agent platform.
(mental) state. Then the agent factory on host H1 sendsthe blueprint of the agent, together with the state informa- The authors are unaware of agent platforms support- tion of the agent to the agent factory at host H2.
ing agent-regeneration migration and/or heterogeneousmigration.
(Re)Generation versus Adaptation
Generative migration has implications for both agents and agent factories. Not only do agents need to understand the concept of locality, but also the concept of incarnation.
Section 4.1 discusses implications for the role of agent factories. Section 4.2 briefly describes aspects of agentincarnations.
Role of Agent Factories
Agent factories are responsible for (re)generating an agent, while adhering to preferences of the agent andthe (destination) agent platform. An incarnation of an Figure 2: An agent’s incarnation involves not only its agent needs to be designed which may be executed by code and data, but also its immediate physical environ- a virtual machine at the target host, and which can in- terface with the agent platform at the target host. Theagent (re)generative process is responsible for minizingthe quantity and quality of the changes to the agent. The the incarnation of an agent. An agent’s code and data is process of regenerating an agent mainly depends on avail- executed in the context of a virtual machine; examples are the Java Virtual Machine and Prolog interpreters. The The agent regeneration process is facilitated by the agent has access to an interface to its agent platform via its two levels of abstractions distinguished within the agent virtual machine. Through this interface the agent can ac- factory: conceptual and detailed. In general, agent facto- cess services provided by the agent platform, e.g. (group) ries need to have building blocks with comparable func- communication, generative migration, etc.
tionality. In the general situation, a configuration of con- The agent needs to conform to both its target virtual ceptual building blocks needs to be constructed. Agent machine and its target agent platform interfaces. For rea- factories sharing common libraries of conceptual building sons of privacy and security, it is assumed that the state of blocks (with equal functionality) is a specific case, pro- an agent does not need to be adapted: an agent can easily viding common ground to the agent factories involved. In employ a programming language independent representa- this case, the configuration of conceptual building blocks tion format for its state (e.g., on the basis of XML, RDF or need not be changed. If an applicable configuration of OIL, see Horrocks et al. (2001)). The (re)generation pro- detailed building blocks is present for the target host, the cess has the goal to generate an operationalisation of the agent factory only needs to assemble this configuration (conceptual) functionality of the agent.
into operational code. In this case the adaptation is trans- In the ideal adaptation process, the agent does not parent to the agent: the agent need not be aware of the “notice” any changes to its incarnation. It still has ac- fact that it has another incarnation than before.
cess to all of its functionality, can resume execution from When no suitable configuration of detailed building its state, and can access services provided by its current blocks is available, a configuration of detailed building agent platform. When agent platforms, and virtual ma- blocks may need to be (re-)designed. The agent factory chines, differ extensively, it is up to the agent factory to needs strategic knowledge to decide on a configuration of detailed building blocks which minimizes the loss of In less ideal situations, an agent may be aware of functionality and services for the agent. In addition, the classes of services and functionality which may be un- agent factory may provide an agent with functionality to available during/for specific incarnations.
cope with the loss of specific functionality.
needs to adapt to this situation, e.g. by employing strate- An agent may be fitted with functionality for intro- gies for circumventing missing functionality and services spection, awareness of its abilities, and understanding (e.g., enlisting support by other agents).
functionality and services needed to achieve (its) goals.
An agent may specify preferences concerning its in- Such an agent can adapt its behaviour, and pursual of carnation. With these preferences, an agent can specify, goals, with respect to its current incarnation.
e.g., which functionality and/or services are of more im-portance to its (correct) functioning than other function- Agent incarnations
ality and/or services. An agent may, in addition, specifythat specific functionality and/or access to specific ser- The incarnation of an agent is entails activation of both vices may be (temporarily) unnecessary at a specific host.
the “code and data” of the agent in another environment The preferences specified by an agent may also state (the virtual machine possibly with another interface to an how the agent is to be informed of success or failure of agent platform.). Figure 2 depicts the concepts related to generative migration. Does the agent expect a message in a specific format? Does the agent expect information F. M. T. Brazier, B. J. Overeinder, M. van Steen, and concerning its current (dis)abilities as a facts-base? N. J. E. Wijngaards. Agent factory: Generative migra- Security and trust are of importance in generative mi- tion of mobile agents in heterogeneous environments.
gration. The agent trusts an agent factory to generate the In Proceedings of the AIMS Workshop at SAC 2002, “right” incarnation. An agent cannot be easily protected against a malicious agent factory, which e.g. may in-troduce code to spy on the agent. The administrator of F. M. T. Brazier and N. J. E. Wijngaards. Automated ser- an agent platform trusts its agent factory and libraries to vicing of agents. AISB journal, 1(1):5–20, 2001.
generate agents which cannot damage other agents, the FIPA. FIPA agent platform, 2001. http://www.fipa.org.
agent platform or the hosts running the agent platform andagents.
I. Horrocks, F. van Harmelen, P. Patel-Schneider, T. Berners-Lee, D. Brickley, D. Connoly, M. Dean,S. Decker, D. Fensel, P. Hayes, J. Heflin, J. Hendler, Discussion
DAML+OIL. http://www.daml.org/2001/03/daml+oil- Mobile agents are currently restrained in their mobility by their environment. Current agent platforms expect ahomogeneous environment, i.e. hosts running the same H. Nwana, D. Ndumu, L. Lyndon, and J. Collis. ZEUS: agent platform and the same virtual machine. This pa- A toolkit and approach for building distributed multi- per proposes an approach which transcends homogeneity agent systems. In Proceedings of the Third Interna- of agent platforms and virtual machines: generative mo- tional Conference on Autonomous Agents (Autonomous bility. In generative mobility, a blueprint of an agent’s Agents’99), pages 360–361, 1999.
functionality is transported, together with information onthe agent’s state. At its destination, an agent factory re- OMG. Mobile agent facility specification. OMG Doc- generates the executable code of the agent on the basis of ument formal/00-01-02, Object Management Group, its blueprint: a new incarnation of the agent. Upon activa- tion, the agent may restore its state and resume execution.
A. S. Tanenbaum and M. van Steen. Distributed Systems: Ideally, an agent factory is able to (re)generate an Principles and Paradigms. Prentice Hall, Upper Saddle agent such that it retains all of its functionality and access to services: transparent adaption. However, this may notbe possible in situations requiring heterogeneous migra- A. Tripathi, N. Karnik, M. Vora, T. Ahmed, and R. Singh.
tion. An agent needs to be aware of characteristics of its current incarnation, including limitations in functionality ings of the 19th International Conference on Dis- provided by its current incarnation and services offered tributed Computing Systems (ICDCS’99), pages 190– Generative migration is one of the services researched within the AgentScape project on worldwide scalable dis-tributed agent operating systems. Currently a prototype ofthe agent factory (namely the libraries of components) isbeing built that supports generative mobility.
Acknowledgements
This research is supported by NLnet Foundation, http://www.nlnet.nl. The authors wish to acknowledge the con-tributions made by Hidde Boonstra, David Mobach, Os-car Scholten and Sander van Splunter.
References
F. M. T. Brazier, B. D. Dunin-Keplicz, N. R. Jennings, and J. Treur. Desire: Modelling multi-agent systemsin a compositional formal framework. InternationalJournal of Cooperative Information Systems, 6:67–94,1997.

Source: http://www.distributed-systems.net/papers/2002.aisb-aamas.pdf