Dept. of Computer Science, Faculty of Sciences, Vrije Universiteit Amsterdam; de Boelelaan 1081a, 1081 HV Amsterdam, The Netherlands Agents, and in particular mobile agents, offer a means for application developers to build distributed applications. Given homogeneity of agent platform and code base, agentmigration is possible. However, many agent platforms exist, differing substantially in thesupport for agents. Write once - run everywhere is not yet true for agents.
Heterogeneity of agent platforms, combined with heterogeneity in code-bases of agents, leads to an interesting question concerning agent mobility: can an agent migratein a heterogeneous environment? The answer is relatively simple: an agent needs to beadapted to its destination agent platform and code-base, e.g. by an agent factory.
[In E. Alonso, D. Kudenko, and D. Kazakov (Eds.), Proceedings of the AISB’02 Sym- posium on Adaptive Agents and Multi-Agent Systems, 2002, pp. 116-119.] Agent Factory
An agent factory is a facility that creates, and modifies, software agents, see [2]. It canbe used to adapt agents so that they can use specific programming languages and run ondifferent agent platforms. The design of an agent within an agent factory is based ona blueprint. The blueprint of an agent specifies a configuration of conceptual buildingblocks defining the agent’s functionality and behaviour. In addition, one or more con-figurations of detailed building blocks are specified, defining an operationalisation of theconceptual functionality and behaviour.
A mapping is defined between building blocks at conceptual level and detailed level.
A detailed description of a building block includes the operational code. For each con-ceptual description, a number of detailed descriptions may be devised and vice versa.
These detailed descriptions may differ in the operational language, but also in, for exam-ple, the efficiency of the operational code. The conceptual descriptions may differ in themodelling paradigm, but also in, e.g., the detail in modelling an agent’s functionality.
Building blocks themselves are configurable, but cannot be combined indiscrimi- nately. The open slot concept is used to regulate the ways in which components arecombined. An open slot has associated properties at both levels of abstraction that pre-scribe the properties of the building block to be “inserted”.
Generative Migration
The principle of generative migration [1] is depicted in Fig. 1. A blueprint of an agent’sfunctionality is transported together with information on the agent’s state. At its desti-nation, an agent factory regenerates the executable code of the agent on the basis of thisblueprint. Upon activation, the agent restores its state and resumes execution.
Figure 1: Example scenario of an agent migrating to a different environment.
Ideally, an agent factory is able to (re)generate an agent such that it retains all of its functionality and access to services: transparent adaption. However, this may notbe possible in situations requiring generative migration. An agent needs to be aware ofcharacteristics of its current incarnation, including limitations in functionality providedby its current incarnation and services offered by the current agent platform.
Migration including (re)generation of agents is a more complex process, than migrationwithout agent re-generation. Four migration scenarios are distinguished[1]: homoge-neous migration, cross-platform migration, agent-regeneration migration, and heteroge-neous migration.
Agent factories, and generative migration, are services available to agent platforms.
Currently, they are supported by AgentScape [3], a middleware layer that supports large-scale agent systems. A prototype of generative migration is being built.
This research is supported by the NLnet Foundation, http:// www.nlnet.nl. The authorswish to acknowledge the contributions made by Hidde Boonstra, David Mobach, OscarScholten and Sander van Splunter.
[1] F. M. T. Brazier, B. J. Overeinder, M. van Steen, and N. J. E. Wijngaards. Agent factory: Generative migration of mobile agents in heterogeneous environments. InProc. of the ACM Symposium on Applied Computing (SAC02), pages 101–106, 2002.
[2] F. M. T. Brazier and N. J. E. Wijngaards. Automated servicing of agents. AISB journal, 1(1):5–20, 2001. Special issue on agent technology.
[3] N. J. E. Wijngaards, B. J. Overeinder, M. van Steen, and F. M. T. Brazier. Supporting Internet-scale multi-agent systems. Data and Knowledge Engineering, 41(2-3):229–245, 2002.

Source: http://www.njewijngaards.dds.nl/pubs/bnaic2002_gm.pdf

Microsoft word - rachel whiteread final.doc

For Immediate Release: December 1, 2009 Contact: Sarah L. Stifler, Communications, 310-443-7056, sstifler@hammer.ucla.edu The Hammer Museum Presents Rachel Whiteread Drawings in First Drawings Retrospective of the British Artist On View January 31 – April 25, 2010 Los Angeles – This winter the Hammer Museum presents a retrospective of drawings by Rachel Whiteread


MATERIAL SAFETY DATA SHEET BLEND PM 8020 (9704) 1. CHEMICAL PRODUCT AND COMPANY IDENTIFICATION EMERGENCY TELEPHONE NUMBERS (FOR EMERGENCIES INVOLVING CHEMICAL SPILLS OR RELEASE)Toronto, ON (416) 226-6117 Montreal, QC (514) 861-1211 Winnipeg, MB (204) 943-8827Edmonton, AB (780) 424-1754 Calgary, AB (403) 263-8660 Vancouver, BC (604) 685-5036 WHMIS Classification / Symbol: READ

Copyright 2014 Pdf Medic Finder