EEL 6938 Mobile agents EEL 6938 Engineering Applications of Autonomous Agents Lotzi Bölöni

EEL 6938 Mobile agents Mobile agents are autonomous programs which move though a network and maintain their identity through this move. This is a stronger concept than “code mobility” such as Java applets, or client-side Javascript. Many agent systems were implemented with support for mobility. –And for many researchers, agents == mobile agents

EEL 6938 Motivation for mobility (cont’d) Mobile agents can provide better support for mobile clients. –Reduction of network traffic –Asynchronous interaction (good in case of intermittent connection) –Remote searching and filtering Mobile agents facilitate semantic information retrieval. –Move one step above simple keyword based search. Mobile agents facilitate real-time interaction with a server –Eg. space probes, real time control of a machine tool Mobile agent based transactions avoid the need to preserve process state in clients and servers –Instead, the process state is carried in an agent

EEL 6938 Motivations for mobility (cont’d) Agent based transactions scale better than RPC- based transactions Secure agent-based transactions have lower overhead than secure RPC. Mobile agents allow users to personalize server behaviour. Agents enable semantic routing. Not all these arguments are valid.

EEL 6938 Counter arguments and answers Most counter arguments are based on the fact that –What can be done with mobile agents can be done with RPC or –What can be done on the server, you can do it on the client. The “software engineering counterargument”: whereas each individual case can be addressed in some (ad-hoc) manner without mobile agents, a mobile agent framework addresses them all of them at once.

EEL 6938 Mobile code != mobile agents –But, the majority of mobile agent systems imply mobile code Transferring code between (heterogeneous) machines. Implies machine independent code. –Usually, it is implemented with some kind of virtual machine –But it can be also implemented with adaptation, recompilation etc. Types of mobile code: –Partially Turing machine complete languages (e.g. SQL, SVG) –Interpreted programming languages (Perl, Python, Javascript) –Virtual machine based compiled languages (Java, Telescript)

EEL 6938 Mobile code - applications Client-server queries (SQL) Client side browser applets: –Java applets –Javascript –ActiveX controls Remote code updates: –Software updates –Plugins Active –Confirmations –Javascript, Visual Basic for Applications – viruses and worms Mobile agents

EEL 6938 Mobile agents without code mobility Seeing control handoff as mobility –No code mobility involved. –Multithreading involves problems. Distributed systems as mobile agent systems In this approach, mobility is an analysis approach, not a design principle.

EEL 6938 Strong mobility

EEL 6938 Strong mobility Strong mobility assumes that agents can move at any point during their execution They are usually relying on: –Specially designed programming languages (eg. Telescript). –Modified virtual machines (eg. NOMADS / AromaVM)

EEL 6938 Custom language: Telescript Proprietary language, created by General Magic around –Highly influential, without being highly successful Interpreted language, which runs on a Telescript engine. –The company implemented engines running on PDA’s, PC’s etc “High Telescript”: –Object oriented language, inspired by Smalltalk –Compiled to Low Telescript “Low Telescript” –Postfix syntax for stack based implementation

EEL 6938 Telescript (cont’d) The basic network configuration is to run a Telescript Engine on each node of the network. A network of Telescript Engines provides a homogenous environment on which to build distributed systems. Basic class: Process. Telescript supports preemptive, prioritized multi-tasking of Process objects. A Process instance can be thought of as an object with a life of its own. A Place object represents a virtual space in which other objects can interwork (through local communication). Each Telescript Engine can support a number of places.

EEL 6938 Telescript (cont’d) An Agent object is a Process object which can migrate between Places. An agent may move between Places on the same Engine, or between Places which exist on different Engines. –The Telescript notion of a distributed system is a number of distinctly located places and a number of Agents which move between these Places. Places provide meeting locations for Agents. At a Place, Agents can exchange information and perform computation. Places also route travelling Agents. Persistent Objects --- Telescript Engines implicitly save and recover object state information. The Telescript world is divided into "regions". Each Engine uses a "regions" database to route migrating Agents. Places and Agents are identified using "Telenames": – Telename(Locally-Unique-Name, Region-Name)

EEL 6938 Telescript security Agents have "attributes" such as "identify" and "owning authority" which uniquely identify the Agent and the entity responsible for it. These attributes may be used for authentication. Telescript objects also have a "permit" attribute which may be used to limit the amount of resources which they may consume (e.g. a Place may ask an Agent to pay it 30 "Teleclicks" before granting it access to some resource). A secure "permits" feature is crucial to stop Agents from creating a crash-limited number of clones of themselves, exhausting resources, or other such anti-social behaviour. – Apparently you can't define a legal Telescript Place which holds visiting Agents to ransom unless you can circumvent security features and hack the Interpreter code!)

EEL 6938 Specialized JVM: NOMADS/Aroma NOMADS/Aroma is a Java based agent system with strong mobility support, developed at Boeing and University of West Florida. The standard Java JVM does not allow explicit execution state capture, thus we can not implement hard mobility. There are several solutions: –Modify (patch) the Sun JVM »Difficulty because of the native thread usage. –Implement a new JVM –Use preprocessors and a standard JVM.

EEL 6938 NOMADS Is composed of two parts: the agent execution environment (called Oasis) and the AromaVM. This provides two key enhancements: Strong mobility: the ability to capture and transfer the full execution state. Safe execution: the ability to control the resources consumed by the agents thereby facilitating guarantees of quality of service and protecting against denial of service attacks. These features, however come with a performance penalty.

EEL 6938 Weak mobility

EEL 6938 Weak mobility In the case of weak mobility, agents are allowed to transfer data only at specific instances. Weak mobility puts smaller requirements on the agent systems: –Traditional programming languages can be used: Java, Perl, Python, Lisp –Smaller performance penalty But there are still a number of challenges:

EEL 6938 Challenges in soft mobility Platform independent code –How do I handle heterogeneous systems? –What about _extremely_ heterogeneous systems? How to collect state / data? How to mark checkpoints (when is mobility possible)? Authorization, security, resource management Reliability problems How do I handle open files and other local resources? How do I handle global names? How do I send a message to a mobile agent? What is the address of the agent?

EEL 6938 Agent systems with weak mobility Most agent system designers considered that migration is a relatively rare even in the life of the agent system. –Thus: weak mobility The agent system is allowed to migrate, but migration is not a fundamental type of operation, but a problem to be solved –In Telescript, migration was the basic communication primitive! Examples: –Aglets, Jade, Concordia, Grasshopper, Bond 2, aIsland (JXTA) –About 60 agent systems on the Mobile Agent List –

EEL 6938 Standards for weak mobility Object Management Group (OMG), an international consortium dealing with interoperability specifications (e.g. CORBA) MASIF: Mobile Agent Facility –A specification, released in 2000, specifying how CORBA based agents should implement weak mobility –There are a number of conformant agent systems (eg. Grasshopper, partially Aglets) As of yet, FIPA did not release any standard for agent mobility. –But they did for mobile (nomadic) users, eg. PDAs etc.

EEL 6938 Aglets Java based mobile agent system –I have chosen to present this because of its major focus on mobility Research project at IBM Japan (from 1996) –Danny Lange and Mitsuro Oshima – As IBM decided to phase out the project it was released as an Open Source project –

EEL 6938 Aglets (cont’d) Goal: “Provide an easy and comprehensive model for programming mobile agents without requiring modifications to Java VM or native code”

EEL 6938 Aglet Lifecycle

EEL 6938 Agent lifecycle Instantiating: –Creating a new aglet from the codebase –Cloning (the clone has the same state as the original but different identity) An aglet can dispatch itself to a remote server by calling the Aglet.dispatch(URL dest) primitive. To be more precise, an aglet occupies the aglet context and can move from this context to others during its execution. Because the server may serve multiple contexts within one Java VM, and one host may serve multiple servers in one host the context are named as the following set –the address of the host, typically IP-address. –the port number to which the server is listening. –the name of context within the server. –Example: atp://aglets.ibm.com:1434/context_name –ATP:// Aglets Transport Protocol

EEL 6938 Aglet lifecycle (cont’d) Dispatching causes an aglet to suspend its execution, serialize its internal state and bytecode into the standard form and then to be transported to the destination. On the receiver side, the Java object is reconstructed according to the data received from the origin, and a new thread is assigned and executed. Aglets can be persistent. Since a mobile aglet needs to be serializable into a bit-stream, all mobile aglet can be persistent in nature. The Aglet.deactivate(long timeout) primitive causes an aglet to be stored in secondary storage and to sleep for a specified number of milliseconds.

EEL 6938 Migration events in Aglets

EEL 6938 Security issues in aglets / mobile agents For secure agent execution, the agent system must provide the following security services: Authentication of the Sender, the Manufacturer and the Owner of the Agent. –Who is responsible for this agent? –Who is responsible for the agent code? –Has the agent (code and state) been tampered with? Authorization of the Agent (or Its Owner) –What can this agent do? (E.g, can this agent access files?) Secure Communication between Agent Systems. –Can the agent protect its privacy? Non-repudiation and Auditing. –How can we ensure that a deal has been actually carried out? –Security-sensitive activities of agents must be recorded, and an administrator must be able to audit them.