MA Tutorial 3

1
Tools USA 2000 Mobile Agents

Introduction To Mobile
Agent Systems
and Applications
Bob Tarr
Danko Nebesh
Sterling Foster
Department of Defense
Introduction To Agents Introduction To Agents
2
Mobile Agents Tools USA Tools USA 2000
Mobile Agent Systems and Applications Mobile Agent Systems and Applications
33
The Agent-Based View The Agent-Based View
l Human agents - known concept
Real estate agent
Travel agent
l What if we designed software using agents as our key
abstraction?
l Natural and easy-to-understand mechanism to describe a variety
of applications
l Powerful metaphor for designing and implementing complex
software systems, since multiple cooperating agents can be used
to solve very formidable problems
44
A New Development Methodology A New Development Methodology
Distributed
Systems
Database &
Knowledge base
Technology
Information
Retrieval
Machine
Learning
agents
Cognitive
Science
AI &
Mobile Code
Objects
1982
Agents
1998
Structured
Programming
1975
= =
Tim Finin, 1998
3
55
Examples of Agent Applications Examples of Agent Applications
l User-interface agents
Microsoft Office Assistant
Microsoft Agents
l Personal (expert) assistants
Calendar managers
Investment assistants
l Electronic commerce agents
Travel agents
Shopping agents
Auction agents
l Network management
66
Examples of Agent Applications Examples of Agent Applications
l Business process agents
Data-driven workflow management
l Information management agents
Email filtering agents
Web browsing assistants
Notification agents
Resource discovery agents
l Agents for entertainment and games
Believable agents
4
77
What is a Software Agent? What is a Software Agent?
l No consensus definition yet
l Since agents can play roles in many different types of applications
and since current agent research is so varied, there may never be a
consensus
l But several key concepts have emerged
l Lets look at some definitions:
An agent is a component of software and/or hardware which is capable of
acting exactingly in order to accomplish tasks on behalf of its user (Nwana,
1996)
An agent is a computer system, situated in some environment, that is
capable of flexible autonomous action in order to meet its design objectives
(Jennings, Sycara and Wooldridge, 1998)
88
Characteristics of Software Agents Characteristics of Software Agents
l Autonomous
Proactive
Goal-directed
Long-lived
l Adaptive
Adapt to their environment and users
Learn from their users, other agents and their own experience
l Cooperative
Cooperate with human agents and other software agents
Utilize various agent communication languages
Advertise their capabilities and understand the capabilities of other agents
5
99
Types Of Software Agents Types Of Software Agents
Adaptive
Cooperative
Autonomous
Interface
Agents
Collaborative
Agents
Intelligent
Agents
Collaborative
Learning
Agents
Hyacinth Nwana, 1996
10 10
Why Use Software Agents? Why Use Software Agents?
l Reduce human work
Many tasks can be performed faster and more accurately by a software
agent
l Handle information overload
Agents can automatically sift through the vast amounts of unstructured
information available on the web
l Provide automated help to the vast hordes of untrained users
l Provide a new, more powerful methodology to develop complex
software systems
6
Agents
Agents
12 12
Mobile Software Agents Mobile Software Agents
l Stationary Agent
Executes only on the system where it begins execution
If it needs information on another system, or needs to interact with an agent
on another system, it uses a standard client-server communication
mechanism such as RPC, RMI, DCOM, CORBA
l Mobile Agent
Not bound to the system where it begins execution
Can move from one system to another within the network
Transports both its state and its code with it
7
13 13
Client-Server Client-Server
Build me a desk Build me a desk
Host A Host A
Client Client
Host B Host B
Server Server
Desk Plans Desk Plans
Workshop Workshop
14 14
Remote Execution Remote Execution
Build me a desk Build me a desk Desk Plans Desk Plans
Host A Host A
Client Client
Host B Host B
Server Server
Workshop Workshop
8
15 15
Mobile Code Mobile Code
Tell me how to build a desk Tell me how to build a desk
Host A Host A
Client Client
Host B Host B
Server Server
Workshop Workshop
16 16
Mobile Agent Mobile Agent
Let me use your workshop Let me use your workshop
to build a desk to build a desk
Host A Host A
Client Client
Host B Host B
Workshop Workshop
9
17 17
Mobile Code Mobile Code
l Code obtained from a remote, possibly "untrusted" system, which
is executed on your local system
l Examples:
Web applets
Executable email attachments
Proxies downloaded as part of a distributed object technology, such as Java
RMI or Jini
l In a general sense, mobile agents are also mobile code, since,
from the view of the system receiving the mobile agent, (possibly
untrusted) code is being downloaded to it
18 18
Strong Vs Weak Mobility Strong Vs Weak Mobility
l Strong Mobility
Migration of agent code, data and execution state
l Weak Mobility
Migration of only the agent code and data
l Strong mobility is difficult to accomplish!
If the agent code is interpreted, access to the execution state is difficult to
obtain
If the agent code is compiled before execution, the execution state is
represented by the stack. Transporting the stack and rebuilding it on a
different host, which can be an entirely different architecture, is a non-
trivial task.
10
19 19
Mobile Agent System Checklist Mobile Agent System Checklist
l Agent Mobility - the ability to transport agents between computers
l Agent Naming - the ability to assign globally unique names to agents to
distinguish one agent from another
l Agent Authentication - the ability to authenticate the identity of the owner
(authority) of an agent
l Agent Permissions - the ability to assign permissions to agents that restrict
access to data and unintended consumption of computer resources. Selected
agents may have the ability to grant permissions to other agents or re-negotiate
their own set of permissions
l Agent Collaboration - the ability to request and respond to requests for
establishing a meeting with another agent. Agents should also have the ability
to begin and end meetings with other agents and enforce rules for the meetings
l Agent Creation - the ability for agents to create other agents locally and
remotely. New agents may have the authority of the existing agent and either
the same permissions or a subset of them
l Agent Life Cycle - the ability to control the life-span of agents by age and
resource consumption
20 20
Mobile Agent System Checklist Mobile Agent System Checklist
l Agent Termination - the ability to terminate agents gracefully, thereby allowing
them to notify other agents they are collaborating with
l Agent Staging - the ability to write to disk agents that must wait for long
periods of time for events to occur
l Agent Persistence - the ability to checkpoint agents to disk so that they survive
crashes on their host computers
l Agent Interaction - the ability for related agents to interact. The means of
interaction might depend upon whether the agents occupy the same or different
computers.
l Agent Management - the ability to manage a collection of agents in the system
l Agent Tracking - the ability to track and locate agents that have migrated to
other computers
l Agent Debugging- the ability to monitor and log agent activities and exceptions
11
21 21
Reasons To Use Mobile Agents Reasons To Use Mobile Agents
l Danny Langes Seven Good Reasons For Mobile Agents
They reduce network load
They overcome network latency
They encapsulate protocols
They execute asynchronously and autonomously
They adapt dynamically
They are naturally heterogeneous
They are robust and fault-tolerant
There is still no killer app for mobile agents!
22 22
Benefits Of Mobility Benefits Of Mobility
l Better support for mobile clients
Intermittent network connection
Relatively low-bandwidth connection
Limited storage and processing capabilities
l Reduced network traffic for some applications
Home
Non-Mobile: 2(n-1) Connections
Home
Mobile: n Connections
12
23 23
Security Issues with Mobile Agent Systems Security Issues with Mobile Agent Systems
l Masquerading
Agent poses as another agent to gain access to services or data at a host
Host assumes false identity in order to lure agents
l Denial of Service
Agents may attempt to consume or corrupt a hosts resources to preclude
other agents from accessing the hosts services
Hosts can ignore an agents request for services or access to resources
l Unauthorized Access
Agents can obtain access to sensitive data by exploiting security
weaknesses
Agent interferes with another agent to gain access to data
24 24
Security Issues with Mobile Agent Systems Security Issues with Mobile Agent Systems
l Eavesdropping
With agents that are interpreted, the host can inspect their internal
algorithms and data, such as the maximum price the agents owner is
willing to pay for item X
l Alteration
Hosts can change an agents internal data or results from previous
processing to influence the agent
l Repudiation
After agreeing to some contract, an agent can subsequently deny that any
agreement ever existed or modify the conditions of the contract
13
25 25
Agent Standardization Efforts Agent Standardization Efforts
l Object Management Group (OMG) Agents Working Group
Recommends standards for agent technology
Mobile Agent System Interoperability Facilities (MASIF) - draft
specification
www.omg.org
l FIPA - Foundation For Intelligent Physical Agents
Non-profit organization which promotes the development of specifications
of generic agent technologies that maximize interoperability within and
across agent-based applications
FIPA 98 - seven part specification
www.fipa.org
26 26
Agent Standardization Efforts Agent Standardization Efforts
l DARPA - Defense Advanced Research Projects Agency
Has several agent-related programs
Control of Agent-Based Systems
DARPA Agent Markup Language (DAML)
www.darpa.mil
14
Distributed Object
Technologies
Distributed Object
Technologies
28 28
Distributed Object Technologies Distributed Object Technologies
l Remote procedure calls (RPC)
l Remote Method Invocation (RMI)
l CORBA
l Jini
l JavaSpaces
15
29 29
Remote Procedure Calls (RPC) Remote Procedure Calls (RPC)
l Provides a high-level mechanism
for an application to use a remote
service
Calls are expressed as ordinary
procedure/function calls
Underlying network
communication is hidden from the
user
l Available implementations:
SUN RPC
DCE RPC
30 30
RPC RPC
l The required client-side and server-side stubs are generated from
an RPC specification file using an RPC compiler (e.g. rpcgen)
l The client stub translates the procedure arguments to a flattened
form and transmits them to server
l The client stub receives the response from the server and un-
flattens the returned data
l The call is usually synchronous: the client is blocked until the
procedure returns
16
31 31
Remote Method Invocation (RMI) Remote Method Invocation (RMI)
l Provides a distributed object capability for Java applications
l The client stub and server stub (skeleton) are generated
automatically using the rmic compiler from the actual Java code
that implements the remote object
32 32
RMI RMI
l A method can get a reference to a remote object:
By looking up the remote object in some directory service. RMI provides a
simple directory service called the RMI registry for this purpose.
By receiving the remote object reference as a method argument or return
value
l Uses Java object serialization to marshal and unmarshal method
arguments
l Supports the dynamic downloading of required class files across
the network => Mobile Code!
Java-centric!
17
33 33
CORBA CORBA
l CORBA - Common Object Request Broker Architecture
Developed by the Object Management Group (OMG)
Generic framework for distributed object applications
Language and platform independent
Object interfaces defined in an Interface Definition Language (IDL)
An Object Request Broker (ORB) facilitates the client-server
request/response action
34 34
CORBA ARCHITECTURE CORBA ARCHITECTURE
l CORBA Architecture
18
35 35
CORBA ORB and IDL CORBA ORB and IDL
l Object Request Broker (ORB)
The Object Bus
Static/Dynamic method invocations
Supports method invocations of remote objects written in any supported
language
l CORBA Interface Definition Language (IDL)
Defines a remote interface
Used by IDL compiler to generate stubs and skeletons
Purely declarative; no implementation
Syntax similar to C++
Language bindings available for C, C++, Ada, Smalltalk, Cobol, Java
36 36
CORBA Services CORBA Services
l Naming Service
Allows objects to locate other objects by name
l Trader Service
Allows server objects to publicize their available services in a yellow
pages directory
Provides very sophisticated lookup capabilities, e.g. Find all services that
can process 1 GB of data at a cost of less than $10
19
37 37
Jini Jini
l Jini is a new Java-centric framework for developing distributed
services developed by SUN
l Core Jini infrastructure operations:
Discovery: Services and clients locate and obtain references to lookup
services
Join: Service registers its services with one or more lookup services
Lookup: Clients locate and contact services using the lookup services
Leasing
All services set up a renewable lease with the registry
If the service does not renew lease before it lapses, the registry deletes the
services entry
Ensures that data in registry is current
38 38
Jini Jini
l The Jini lookup service is a better directory for remote objects
than the RMI registry
Allows for more powerful searching of registry
Stores more information about the services
Maintains the required client proxy for the remote object
Client proxies (stubs) are automatically downloaded from the lookup
service => Mobile Code!
20
39 39
JavaSpaces JavaSpaces
l JavaSpaces are based on the Linda programming language that
was introduced in 1982
Applications communicate by reading and writing tuples into a distributed
tuple space
Clients and servers can use this tuple space to pass data between each other
Built on top of Jini
Must install Jini
Must start all Jini related services
Simple idea, simple to use
40 40
l A Space
Shared network-accessible object repository
The following are methods in the Space class
write() - store an object in the Space
read() - create a local copy of the specified object in the Space
take() - create a local copy of the specified object and remove the original
from the Space
Matching objects in a Space
Create a template object of the same type that is to be retrieved
Fill in values that must be matched
Use the template when calling the read method
If more that one object can match the template:
Only one object will be returned
No way to know which object will be read
No way to iterate through a set of matching objects
21
41 41
l Key features
Shared - behaves like a shared memory that can be accessed concurrently
by remote objects
Persistent - objects remain in a space until they are removed or until their
lease expires
Associative lookup - objects are not accessed by memory location, but by
values of attributes
Transactionally secure - the transaction model allows the grouping of
operations on the space into atomic units. Usage of the transactional model
is optional.
From Objects
to
Mobile Agents
From Objects
to
Mobile Agents
22
43 43
Mobile Agent Attributes Mobile Agent Attributes
l State
Object state - the values of its instance variables
Execution state - its runtime state
l Implementation (Code)
Carried with agent
Obtained at new host location
Downloaded over the network on demand
l Unique identifier
l Security credentials
44 44
Mobile Agent State Mobile Agent State
l Object State
Owner
Originating host - so the agent can return home
Current host
Travel log - so one can inspect the agents itinerary
Data - the data that is to be processed, this could be an object, or a single
item, an XML document, or anything that the agent is meant to carry
Directory (Registry or Trader) Service Reference - so the agent can
discover what services or agents are available and where they are
23
45 45
Mobile Agent Infrastructure Mobile Agent Infrastructure
What infrastructure features do we need for mobility?
l Agents need to:
Use resources available on their host machine
Communicate with other agents (and objects)
Move about in a heterogeneous network
Protect themselves against malicious agents and hosts
These capabilities are provided by the
Mobile Agent Infrastructure
46 46
Mobile Agent Infrastructure Mobile Agent Infrastructure
Agent Server Agent Server
(Agent Run-Time (Agent Run-Time
Environment) Environment)
(Agent Execution (Agent Execution
Environment) Environment)
Host Host
Operating System Operating System
Agent Agent
Migration Migration
Agent Agent
Communications Communications
Access Access
To Resources To Resources
Security and Authentication Security and Authentication
Agents Agents
24
47 47
Agent Server Agent Server
l The Agent Server provides an execution environment for the
mobile agents
l It provides the following services:
Authentication of incoming agents
Agent dispatching and receiving services
Agent communication services
Controlled access to local resources
l In addition, the Agent Server could be customized to provide
additional services (lookup services, document translation
services) that a visiting agent can utilize
48 48
Languages For Mobile Agents Languages For Mobile Agents
l To provide platform independence we need a scripting or
interpreted language
l Java is an excellent choice!
Platform independent
Secure execution via bytecode verifier and security manager
Dynamic class loading over the network
Object serialization for agent transport
But strong mobility is not easy to do in Java, since Java objects can not
normally access the execution state of the Java Virtual Machine
l Other Languages
Tcl, Eiffel, Obliq
25
49 49
Agent Migration Techniques Agent Migration Techniques
l Low-level: TCP/IP sockets
l Use existing transport mechanisms
RMI
HTTP
l Develop a customized agent transfer protocol
Allows support for other features, such as authentication
l Flatten the agent for transmission over the chosen transport
mechanism
If Java is the implementation language, use Java object serialization
50 50
Dispatching An Agent Dispatching An Agent
l Agent decides it wants to move to another host. It invokes a
method provided by the Agent Server (AS), such as
moveTo(host).
l The moveTo() method:
Initializes the transfer, possibly authenticating the transfer with the
receiving host
Serializes the agent
Sends the agent to the receiving host
Suspends the thread the agent was using, possibly returning the thread back
to a thread pool
26
51 51
Receiving An Agent Receiving An Agent
l The Agent Server (AS) is listening for incoming agents on some
well-known port
l When a request to receive an agent is detected, the AS:
Authenticates the incoming agent
De-serializes the agent
Assigns a new thread to the agent and resumes execution of the agent. In a
weak mobility system, the AS resumes execution of the incoming agent by
invoking a well-known method (for example, run()) or by invoking a
method specified in the moveTo() call.
moveTo(HostA); // Invoke agents run() method
moveTo(HostA, onArrival); // Invoke agents onArrival() method
52 52
Agent Communications Agent Communications
l Agents need to communicate with other agents and objects
l Use existing distributed object technologies
RPC
RMI
CORBA
l Develop a custom agent communications capability
May be desirable to add certain features to the agent system, such as, an
agent location tracking capability
27
53 53
Agent Communications Agent Communications
l Types of messages
Synchronous
Execution of sender blocked until a reply is received
One-Way
Asynchronous
No reply ever sent
Fire-and-forget
Future-Type
Asynchronous
Sender immediately gets a handle or placeholder to the reply which may not be
available yet
Sender can obtain the reply by polling, blocking or via a callback
54 54
Directory Service Directory Service
l Directory services are useful in any distributed system
Both mobile agents and stationary services register their capabilities with
the directory service
Agents can then lookup other agents or services with the desired properties
Must be accessible remotely
l Some possible implementations
RMI registry
Jini lookup service
CORBA Trader service
LDAP/JNDI
28
55 55
Directory Service Directory Service
l Possible items an agent or service would publish in the directory
service
What it does
Where it is located
What type of input it expects
What type of output it generates
Cost of the service
Quality of the service
Agent
RMI
Agent
RMI
29
57 57
Agent RMI Agent RMI
l An example mobile agent system built using Java RMI
Uses customized Agent Servers which provide a specific service, in this
case looking for a particular menu item from a restaurant menu
The agent is transported using Java object serialization provided by
invoking an RMI remote method (moveTo()) on the remote Agent Server
l This example has an agent visiting an itinerary of restaurants,
searching the restaurant menu for a particular item, for example,
"Salmon". The agent then returns to its home location with a list
of restaurants which have that item on their menu.
58 58
Agent RMI Agent RMI
l Classes
IAgentServer - the interface implemented by the Agent Server
AgentServer - the abstract base class for all Agent Servers
Restaurant - a concrete Agent Server which allows visiting agents to query
a menu for a specific item
Agent - the mobile agent
DataObject - the data to be processed carried by the agent
Home - starting Agent Server for our test program
30
59 59
IAgentServer.java IAgentServer.java
import java.rmi.*;
// This interface declares the methods of the Agent Server that
// can be remotely invoked.
public interface IAgentServer extends java.rmi.Remote {
public void moveTo(Agent a) throws RemoteException;
}
60 60
AgentServer.java AgentServer.java
import java.rmi.*;
import java.rmi.server.*;
import java.rmi.registry.*;
// The Agent Server.
public abstract class AgentServer
extendsUnicastRemoteObject
implements IAgentServer {
public AgentServer() throws RemoteException {}
// This method dispatches (and receives!) the agent to the
// remote host.
public void moveTo(Agent a) {
a.setLocal(this);
Thread t = new Thread(a);
t.start();
}
31
61 61
AgentServer.java AgentServer.java
// This method must be provided by customized Agent Servers
// providing a unique service.
public abstract DataObject process(DataObject data);
}
62 62
Restaurant.java Restaurant.java
import java.io.*;
import java.util.*;
import java.rmi.*;
// A customized Agent Server providing a restaurant service.
public class Restaurant extends AgentServer {
private String restaurantName;
private Vector menuItems;
public Restaurant(String restaurantName, String filename) throws
IOException {
this.restaurantName = restaurantName;
menuItems = new Vector();
BufferedReader menuFile = new BufferedReader(new
InputStreamReader(new FileInputStream(filename)));
while ((String str = menuFile.readLine()) != null)
menuItems.addElement(str);
}
32
63 63
public String toString() {
StringBuffer temp = new StringBuffer(restaurantName + "\n");
for (int i = 0; i < menuItems.size(); i++)
temp.append(((String)menuItems.elementAt(i)) + "\n");
return temp.toString();
}
// This method provides the customized service used by the
// visiting agent. In this case, the service is to lookup
// items in the restaurants menu.
public DataObject process(DataObject data) {
StringBuffer output = new StringBuffer();
for (int i = 0; i < menuItems.size(); i++) {
String temp = (String)menuItems.elementAt(i);
if (temp.indexOf(data.getQuery()) != -1)
output.append(temp + "\n");
}
64 64
if (output.length() > 0)
data.addResult(restaurantName + "\n" + output.toString()
+ "\n");
data.updateHistory(restaurantName);
return data;
}
// We get the restaurant name and menu file menu from the
// command line.
public static void main(String args[]) throws IOException {
String hostName = null;
String restName = null;
String menuFile = null;
Registry r = null;
if (args.length != 2) {
System.out.println("usage: java Restaurant restaurantName
menuFile");
System.exit(-1);
}
33
65 65
else {
restName = args[0];
menuFile = args[1];
}
Restaurant rest = new Restaurant(restName, menuFile);
try {
hostName =
java.net.InetAddress.getLocalHost().getHostName();
r = LocateRegistry.getRegistry(hostName);
r.rebind(restName, rest);
System.out.println("Restaurant " + restName + " ready.");
} catch(Exception e) {
System.out.println(Problem registering restaurant: " + e);
System.exit(-1);
}
}
}// class Restaurant
66 66
Agent.java Agent.java
import java.rmi.*;
import java.io.*;
import java.util.*;
// The Mobile Agent.
public class Agent implements Runnable, Serializable {
private Stack itinerary;
private DataObject data;
transient private AgentServer local;
// The menu query is an attribute of the DataObject carried
// by the agent.
public Agent(String query) {
itinerary = new Stack();
data = new DataObject(query);
}
public void setLocal(AgentServer local){
this.local = local;
}
34
67 67
// Add a new restaurant to the agent's itinerary.
public void addToItinerary(String restaurantName) {
try {
String hostName =
Registry r = LocateRegistry.getRegistry(hostName);
itinerary.push((IAgentServer) r.lookup(restaurantName));
} catch(Exception e){
System.out.println("Problem looking up restaurant: " + e);
}
}
68 68
// The method called by the AgentServer when the agent arrives
// at its new destination.
public void run(){
try {
data = local.process(data);
if (!itinerary.empty()) {
IAgentServer temp = (IAgentServer)itinerary.pop();
temp.moveTo(this);
}
} catch(RemoteException e) {
System.out.println("Problem moving: " + e);
}
}
}//class Agent
35
69 69
DataObject.java DataObject.java
import java.util.Vector;
import java.io.*;
// The class that describes the data the agent carries.
// It includes the menu query, the query results and the
// itinerary history.
public class DataObject implements Serializable {
private String query;
private Vector results;
private Vector history;
public DataObject(String query) {
this.query = query;
results = new Vector();
history = new Vector();
}
public String getQuery() {return query;}
public void addResult(String menuItem) {
results.addElement(menuItem);
}
70 70
DataObject.java DataObject.java
public void updateHistory(String placeName) {
history.addElement(placeName);
}
public String toString() {
StringBuffer temp = new StringBuffer("The following serve: "
+ query + "\n\n");
for(int i = 0; i < results.size(); i++)
temp.append(results.elementAt(i) + "\n");
temp.append("Visited the following restaurants: ");
for (int i = 0; i < history.size() - 1; i++)
temp.append(history.elementAt(i) + ", ");
if (history.size() != 0)
temp.append(history.elementAt(history.size() - 1) + "\n\n");
return temp.toString();
}
}//class DataObject
36
71 71
Home.java Home.java
import java.io.*;
import java.util.Vector;
import java.rmi.*;
// Starting Agent Server for a simple test program.
public class Home extends AgentServer implements IAgentServer {
public Home() throws IOException {}
// The process method here simply prints out the query results
// contained in the DataObject.
public DataObject process(DataObject data) {
System.out.println("At Home:");
data.updateHistory("Home");
System.out.println(data);
return data;
}
72 72
Home.java Home.java
// We get the menu item to search for from the command line.
public static void main(String args[]) throws IOException {
String hostName = null;
String query = null;
Registry r = null;
if (args.length != 1) {
System.out.println("Usage: java Home menuItem");
System.exit(-1);
}
else {
query = args[0];
}
Home h = new Home();
try {
hostName =
r = LocateRegistry.getRegistry(hostName);
r.rebind("Home", h);
System.out.println("Home ready.\n");
37
73 73
Home.java Home.java
} catch(Exception e) {
System.out.println("Problem registering: " + e);
}
Agent a = new Agent(query);
a.setLocal(h);
// Build the itinerary stack of restaurants we want the
// agent to visit.
a.addToItinerary("Home");
a.addToItinerary("Fish");
a.addToItinerary("Deli");
Thread t = new Thread(a);
t.start();
}// main
}// class Home
Mobile Agent Systems Mobile Agent Systems
38
75 75
Mobile Agent Systems List Mobile Agent Systems List
AgentSpace (UK) V0.9b3 University of Hull/University of Sunderland
AgentSpace 1.2 Universidade Tcnica de Lisboa (IST/INESC)
Aglets 1.0.3/1.1 IBM Tokyo Research Laboratory
Ajanta Alpha 1.0 University of Minnesota
AMASE 1.1 AMASE Consortium (ACTS project AC346)
AMETAS 1.0 Johann Wolfgang Goethe-Universitt, VSB
Anchor Toolkit 1.0beta Lawrence Berkeley National Laboratory
Ara 1.0a University of Kaiserslautern
ARCA 2.3 University of Catania - ITALY
Bee-gent Beta1.2 TOSHIBA Corp.
Bond Rel Nov.99 Purdue University
Cborg 3.0 Vrije Universiteit Brussels
Concordia V1.1.3 Mitsubishi Electric ITA
D'Agents 2.0 Dartmouth College
Dejay 0.9.4 Hamburg University
EAS 1.0 Alpha ANSER
FarGo 0.2.2 Technion - Israel Institute of Technology
ffMAIN 2.0 Johann-Wolfgang-Goethe-Universitaet
Grasshopper 1.2.2 IKV++ GmbH
Gypsy 0.5 Technical University of Vienna
76 76
Hive 0.6 MIT Media Lab
IMAJ Alpha UNINOVA/FCT + ISEL
J-SEAL2 1.0 Beta 3 CoCo Software Engineering Gmbh
JAE 1.2 Aachen University of Technology (RWTH)
JAM 0.61+0.79i Intelligent Reasoning Systems
JAMES v2.0.1 University of Coimbra, Portugal
JavaNetAgents 0.9 LIP6/ONERA
JavaSeal 1 University of Geneva
JCAFE 1.0 MITRE Corporation
Jumping Beans 1 Ad Astra Engineering, Inc.
Kaariboga 1999-12-04
Klaim 1.1 University of Florence/University of Pisa
Knowbot 1.0a2 CNRI
M0 Messengers 0.27.11 University of Geneva/Uppsala University
MAgNET 1.0 University of California, Santa Barbara
MAP 2.0 University of Catania - IIT
MATS Beta British Telecom
MESSENGERS 2.0 University of California, Irvine
MILLENNIUM 1.0 University of Oviedo
MIPLACE 2.1.2 NEC Corporation
39
77 77
Mobidget 1.1 NEC Corporation
Mogent 1.0 NanJing University, China
Mole 3.0 University of Stuttgart, IPVR
muCode 1.0 Politecnico di Milano
Nomadic Pict Alpha University of Cambridge
NOMADS 0.3 University of West Florida
Odyssey None General Magic, Inc.
Pathfinder 0.9 National Chung-Hsing University, TAIWAN
Planet Alpha University of Tsukuba, Japan
Plangent 1.0beta7 TOSHIBA Corp.
rmi64 1.0.0 Technische Universitt Wien
SeMoA 0.3 Fraunhofer IGD
SOMA 2.0 University of Bologna
Telescript None General Magic, Inc.
TuX (Tacoma UniX) 2.0 University of Troms
Voyager 3.3 ObjectSpace, Inc.
WASP 2.0 Darmstadt University of Technology
Source: The Mobile Agent List
http://www.informatik.unistuttgart.de/ipvr/vs/projekte/mole/mal/mal.html
78 78
Telescript Telescript
l Developed by General Magic
l First commercial mobile agent implementation, 1993
l Proprietary language
l Marketed the Mobile Agent Paradigm for E-Commerce
l Users:
Personal Digital Assistants (PDAs): Sony Magic-Link; Motorola Envoy,
Panasonic NeoNet with the Magic Cap OS
AT&T PersonalLink Service
l US Patent No. 5603031:
System and Method for Distributed Computation Based upon the
Movement, Execution, and Interaction of Processes in a Network,
February 1997
l No longer in use or available, but important historically!
40
79 79
Telescript Concepts Telescript Concepts
l Agent - a process that controls its movement from one Place
process to another within the network
l Place - a process that provides a computing context within which
Agent processes are run
l Agents and Places
Subclasses of the Process class
The computation for an Agent or Place is defined by its live() method
The live method is suspended when an Agent traverses the network
80 80
Telescript Language Constructs Telescript Language Constructs
l Ticket Object
An Agent uses a ticket to specify where it should go and how it expects to
get there
Ticket objects contain destination information such as address, name, and
class, they also specify the protocol to use perform the transfer (TCP, PPP)
Ex: Create a Ticket to return home
Telename name := here.name.copy();
Teleaddress addr := here.address.copy();
Ticket home := Ticket(name, addr));
l Permit Object
Permits are used to grant capabilities, such as the ability to create or clone
Agents
Permits are also used to govern the amount of time, and resources used by
an Agent
Ex: Create a Permit which will expire after 100 teleclicks
Permit tempPermit := Permit(100);
41
81 81
l go command
Transports an Agent to the destination specified by a Ticket object
go is a private sealed (final) operation of class Agent
Returns a TicketStub object which describes the trip
Ex: Command to transport an Agent to its home computer
*.go(home); // or self.go(home);
l send command
Agents have the ability to create a copy of themselves
The send command will send the copies of the Agent to a list of
destinations
Ex: Create copies of myself and transport copies to all the destinations in
sendList
self.send(sendList);
82 82
l meet command
Allows Agents to interact with other Agents at a Meeting Place
Agents only interact through a meeting (exchange references to each other)
Ex: Request a meeting with an Agent specified in a Petition object
agentToMeet := here@MeetingPlace.meet(aPetition, nil);
42
83 83
Telescript Example Telescript Example
l Agent visiting restaurant places and bringing back menus
MenuAgent: class (Agent) = {
private
theKeys: List[String, Equal];
home: = Ticket(here.name.copy(); here.address.copy());;
public
initialize: op(theKeys: copied List[String, Equal]; Permit;
Permit|Nil; Integer|Nil) = { ^;};
live: sponsored op(Exception|Nil) = {
aPlace: Telename;
menuItems: String;
sendList := List[Ticket, Equal]();
84 84
Telescript Example Telescript Example
try {
// Lookup restaurants to visit.
self.go(Ticket(nil, nil, LookUpPlace.name, nil,nil, nil));
for iLoop: Integer to theKeys.length {
aPlace =
here@LookUpPlace.returnValue(theKeys.get(iLoop));
sendList.add((sendList.length+1), Ticket(aPlace));
}
// Send out clone agents to all of the restaurants.
if (self.send(sendList) != nil) {
menuItems = here@Restaurant.getMenu;
self.go(home);
here@Home.menuReport;
}
} catch error: Exception { error.dump(); }
};
};
43
85 85
Aglets Aglets
l Developed by IBM, Tokyo Research Laboratory
l Co-designed by Danny Lange and Mitsuru Oshima
l First widely available implementation of mobile agents
l Aglet = Agent + Applet
l Written entirely in Java
l Uses Java object serialization and RMI
l Provides a graphical Aglet viewer called Tahiti
l Version 1.0.3 is available for free from:
http://www.trl.ibm.co.jp/aglets/index.html
l Version 1.1 is available for free evaluation from the same site
86 86
Aglet Concepts Aglet Concepts
l Aglet - the mobile Java object
l Proxy - a representative of an aglet
Acts as a security shield for an aglet
Controls and limits direct access to an aglet
Provides location transparency for the aglet
l Context - the execution environment for aglets
l Engine - the Java Virtual Machine running on a host which
supports one or more Contexts
Called the Aglet Server
The agletsd program is used to start an Aglet Server on a specific port
The agletsd program can also start the Tahiti Alglets Viewer
44
87 87
Aglet Operations Aglet Operations
l Creation - create a new aglet in a context and start its execution
l Cloning - make a copy of an aglet
l Dispatching - send an aglet to another context, possibly on
another host
l Retraction - pull an aglet from its current context back to the
requesting context
l Deactivation/Activation - temporarily halt/restart the execution of
a aglet
l Disposal - halt the execution of an aglet and remove it from its
current context
88 88
The Aglet Life Cycle The Aglet Life Cycle
Lange and Oshima, 1998
45
89 89
Aglet Event Model Aglet Event Model
l Aglet programming model is event-based
l Aglets have associated listeners which catch events in the life-
cycle of a aglet
l Listeners/Events
Clone Listener/Clone events
About to be cloned, Clone created, After cloning
Mobility Listener/Mobility Events
About to be dispatched, About to be retracted, Arrival in new context
Persistence Listener/Persistence Events
About to be deactivated, After activation
90 90
The Aglets API The Aglets API
l Interfaces
AgletProxy - provide a handle to an aglet. References to an AgletProxy
are obtained when creating/cloning an aglet or by dispatching an aglet.
clone() - create a copy of the aglet. Returns a proxy for the cloned aglet.
dispatch(destination) - send the aglet to the specified destination
dispose() - dispose of the aglet
activate() - forced activation of a deactivated aglet
deactivate(interval) - deactivate the aglet for the specified time interval
getAglet() - get the aglet this proxy manages
getAgletID() - get the aglet's ID
getAgletInfo() - get info about the aglet
And others
46
91 91
AgletContext - provides the execution environment for aglets
createAglet(codeBase, className, initArgs) - create a new aglet of the
specified class. The code for the aglet is located via the codeBase URL.
retractAglet(location, agletID) - retract the specified aglet from the given
location
getAgletProxy(agletID) - get a proxy for the specified aglet
getAgletProxies() - get an enumeration of all aglet proxies in the current
context
And others
MobilityListener - interface for receiving mobility events
onDispatchng(mobilityEvent) - invoked when the aglet is being dispatched
onReverting(mobilityEvent) - invoked when the agent is retracted
onArrival(mobilityEvent) - invoked when the aglet has arrived at its
destination
92 92
l Classes
Aglet - abstract base class for all aglets. Programmers extend this class to
build customized aglets.
clone() - clone the aglet and the proxy for the aglet. Returns the proxy.
dispatch(destination) - send the aglet to the specified destination
dispose() - dispose of the aglet
deactivate(interval) - deactivate the aglet for the specified time interval
run() - entry point for the aglet's own thread of execution. Invoked upon
successful creation, dispatch, retraction or activation of this aglet.
onCreation(initArgs) - initialize the new aglet. Called only once in the
lifetime of an aglet.
onDisposing() - invoked when an attempt is made to dispose of this aglet
lots more
47
93 93
Aglets Example Aglets Example
// Aglet which visits a list of restaurants and gets menus.
public class MenuAglet extends Aglet {
private Stack places = new Stack{}; // Restaurants to visit
private Vector menus = new Vector(); // Menus
private String restName;
// Initializes the aglet.
// Only called the very first time this aglet is created.
public void onCreation(Object init) {
// Populate list (stack) of restaurants to visit.
places.push("atp://home.com:9000");
places.push("atp://fish.com:9001");
places.push("atp://deli.com:9002");
}
94 94
// run() is executed on creation and each successful dispatch.
public void run() {
// Invoke Menu.getMenu() which accesses local resources to
// get the menu of this restaurant.
Menu menu = Menu.getMenu();
menus.add(menu);
// Where next?
if (places.empty()) {
// Must be back home!
// Display menus and dispose of myself.
System.out.println("Done visiting. Menus found: " + menus);
dispose();
}
48
95 95
else {
// Get next restaurant to visit.
restName = (String) places.pop();
// Go there!
try {dispatch(new URL(restName));}
catch (Exception e) {}
}
} // run()
} // class MenuAglet
96 96
Voyager Voyager
l Developed by ObjectSpace, Inc.
l Combines traditional distributed computing with mobile agents
l Written in Java
l Provides an Object Request Broker (ORB) that supports
Object mobility
Remote object creation
Remote-enabling of any class without explicit stub (proxy) generation
Remote messaging with forwarders in the event that the remote object has
moved
CORBA (IIOP), RMI and DCOM communications
An integrated naming service
l Version 3.2 is available for free for internal, not-for-fee
applications from:
http://www.objectspace.com/downloads/
49
97 97
Voyager Concepts Voyager Concepts
l Voyager Server - the Voyager ORB. Acts as an Agent Execution
Environment providing agent migration and communication
facilities
l Proxy - the representative for a remote object. Voyager can
generate proxies at runtime without an explicit proxy(stub)
generation step
l Advanced Messaging
Synchronous
One-Way
Future
98 98
Voyager Remote Object Creation Voyager Remote Object Creation
l To create a remote object use the Factory.create() method:
Factory.create(className, url);
l Example:
// Local Object
IStockmarket market1 = (IStockmarket) Factory.create("Stockmarket" );
// Remote Object
IStockmarket market2 = (IStockmarket)
Factory.create("Stockmarket", "//dallas:8000");
l Instances of the Stockmarket class implement the IStockmarket
interface
l Factory.create() returns a reference to a proxy object which itself
refers to a local object or a remote object. (Can use the getLocal()
method of the proxy to get a local reference to a local object.)
50
99 99
Voyager Method Invocation Voyager Method Invocation
l Invocation of methods on a remote object can now easily be done:
// Get stock quote on SUN
Float quote = market2.quote("SUN");
100 100
Voyager Naming Service Voyager Naming Service
l The Voyager ORB provides an integrated naming service that can
be used to bind, unbind and lookup names of remote objects
Namespace.bind(name, object) - bind a name to an object
Namespace.rebind(name, object) - rebind a name to an object
Namespace.lookup(name) - lookup a remote object and return a proxy
to it
l Example:
// Bind the remote object referenced by the market2 proxy as "NASDAQ"
Namespace.bind("//dallas:8000/NASDAQ", market2);
// Lookup the remote object named "NASDAQ"
IStockmarket market = (IStockmarket)
Namespace.lookup("//dallas:8000/NASDAQ" );
l Voyager also provides implementations of CORBA IOR (ior:)
and RMI (rmi:) naming services
51
101 101
Voyager Object Mobility Voyager Object Mobility
l To move an object in Voyager first requires that the object's
mobility facet be obtained using the Mobility.of() method
l A facet is a secondary object attached to a primary object at
runtime to give it additional functionality
l The mobility facet interface IMobility provides these methods:
moveTo(url) - move to the Voyager Server (ORB) with the specified
URL
moveTo(object) - move to the Voyage Server (ORB) that contains the
specified object
l Example:
IMobility mobility = Mobility.of(market); // Get mobility facet
mobility.moveTo("//tokyo:9000"); // Move the market object
102 102
Voyager Mobile Agents Voyager Mobile Agents
l To create a mobile agent in Voyager, first get the agent facet of an
object using the Agent.of() method
l The agent facet interface IAgent provides these methods:
moveTo(url, callback, [args]) - move to the Voyager Server with the
specified URL and then restart execution by invoking the specified
callback method with the specified optional arguments
setAutonomous(flag) - if flag is true, make the agent autonomous, such
that it will not be garbage collected
getHome() - return the URL where this agent's agent facet was first
created
l Example: Have an object move itself and invoke its process()
method on arrival
IAgent agent = Agent.of(this); // Get agent facet
agent.moveTo("//foobar:8001", "process"); // Move
52
103 103
Voyager Example Voyager Example
// Voyager agent which visits a list of restaurants and gets menus.
public class MenuVoyagerAgent {
private Stack places = new Stack{}; // Restaurants to visit
private Vector menus = new Vector(); // Menus
private String restName;
// Constructor for agent.
public MenuVoyagerAgent() {
// Make this object a Voyager agent.
Agent.of(this).setAutonomous(true);
// Populate list (stack) of restaurants to visit.
places.push("//home.com:9000");
places.push("//fish.com:9001");
places.push("//deli.com:9002");
}
104 104
// atRestaurant() is executed when the agent arrives at each
// restaurant.
public void atRestaurant() {
// Invoke Menu.getMenu() which accesses local resources to
// get the menu of this restaurant.
Menu menu = Menu.getMenu();
menus.add(menu);
// Where next?
if (places.empty()) {
// Must be back home!
// Display menus and allow myself to be GC'ed.
System.out.println("Done visiting. Menus found: " + menus);
Agent.of(this).setAutonomous(false);
}
53
105 105
else {
// Get next restaurant to visit.
restName = (String) places.pop();
// Go there!
Agent.of(this).moveTo(urlString, "atRestaurant");
}
} // atRestaurant()
106 106
public static void main(String args[]) {
try {
// Start the Voyager server.
Voyager.startup("9000");
// Create the agent.
MenuVoyagerAgent mva = new MenuVoyagerAgent();
mva.atRestaurant();
} catch (Exception e) {}
} // main()
} // class MenuVoyagerAgent
54
107 107
Mole Mole
l The Mole research group was founded in 1995 at the University
of Stuttgart.
l Current member of the research group are Joachim Baumann,
Fritz Hohl, Markus Strasser, Markus Schwehm
l The Mole mobile agent system was first released in 1996
l Version 3.0 is available for free from the Mole home page:
http://www. mole.informatik.uni-stuttgart.de/docs/
108 108
Mole Concepts Mole Concepts
l Agents
System agents
Interface with components outside the agent system such as a file system
Provide resources to Agents within the agent system
Do not move
User agents
Can communicate with other agents including system agents
Access external resources by messaging system agents
Can move to other locations
55
109 109
Mole Concepts Mole Concepts
l Locations
Places where agents meet
Every agent that is not in transit resides in a location
Identified by a DNS style location name
l Engines
Instance of the Mole runtime system running in a JVM
Locations reside inside of engines
Contain static methods that an agent can call like Engine.out() for
outputting text to the engine console
110 110
Mole Operations Mole Operations
l All agents inherit from either the SystemAgent class or the
UserAgent class
l All agents that move must implement the MobileAgent interface
l The following methods of SystemAgent and UserAgent are often
overridden by agents:
init(parameters) - called once to initialize the agent
prepare() - called when agent is created and after every time it moves
start() - called once agent is created or after it moved
stop() - called before an agent moves
end() - called before an agent dies
receiveMessage(msg) - called to receive remote messages
56
111 111
Mole Operations Mole Operations
l Some of the methods that an agent can call:
getName() - return the unique name of the agent
getCurrentLocation() - return the location object at which the agent
currently resides
migrateTo(location) - move the agent to the specified location
createChild() - create a child agent
createAgent() - create a peer agent
112 112
Mole View Mole View
l MoleView
A graphical view of everything running within an engine.
Has a console to which the engine writes output.
Allows a user to start new agents using the GUI.
57
113 113
Jumping Beans Jumping Beans
l Developed by Ad Astra Engineering, Inc.
l Awards
Best Java Framework at the SIGS Conference for Java Development in San
Jose, CA, 1998
Best Framework at OOP '99 in Munich
l Security is an integral part of the framework
l Evaluation (3-client) copy of Version 1.1 is available at
http://www.jumpingBeans.com/
114 114
Jumping Beans Architecture Jumping Beans Architecture
Jumping Beans
Agency
Host A
Mobile App
Mobile App
Jumping Beans
Agency
Host B
Mobile App
Jumping Beans
Agency
Host C
Mobile App
Jumping Beans
Agency
Host D
Jumping Beans
Server
Mobile App
Client/Server architecture enables a robust security model for mobile
applications and the ability to manage and monitor activity in the system
58
115 115
Jumping Beans Concepts Jumping Beans Concepts
l Agency - client software that facilitates the receipt and dispatch of
mobile applications and enforces security. Each Agency must
register with the Jumping Beans Server.
l Jumping Beans Server - central management point
Primary function is to enforce security
Mobile applications are never deserialized or executed on the server
l Mobile Application - serializable Java objects which can jump
from computer to computer while executing. Must implement the
MobileApp interface.
116 116
Jumping Beans API Jumping Beans API
l MobileApp Interface - this interface provides callbacks for mobile
application events: creation, dispatch, arrival and destruction, and
others
l MobileAppContext Class - each mobile application is assigned an
instance of this class which provide access to the Jumping Bean
services
l ItineraryNode Class - each object of this class forms a node in a
tree, and the tree forms the itinerary. Multiple children coming
from a single node represents a fork in the itinerary.
59
117 117
l Interfaces
MobileApp - interface mobile applications implement to receive
notification of Jumping Bean events
afterArrival(mobileAppContext) - called after the mobile application arrives
at an Agency
afterCreation(mobileAppContext) - called after the mobile application is
created
beforeDispatching(mobileAppContext) - called before the mobile application
is dispatched
receiveMessage(userDefinedMessageType, message, mobileAppContext) -
called when a remote process sends a message to this mobile application
And others
MobileAppListener - similar to MobileApp interface, but is provided for
non-mobile host software to be notified of mobile application events
118 118
l Classes
Agency - a Jumping Beans client. A Jumping Beans host must instantiate
this class. Then all of the JumpingBeans services are available to the host.
Only one instance of this class per JVM.
createMobileApp() - create a new mobile application
deactivateMobileApp() - deactivate a mobile application for a specified
duration
dispatchMobileApp(MobileAppID) - dispatch a mobile application to the
next itinerary destination
listAllMobileApps( ) - list all of the mobile applications currently in the
agency
listMobileAppsInDispatchQueue() - list the mobile applications waiting to be
dispatched
60
119 119
MobileAppContext - each mobile application has an instance of
MobileAppContext to request actions of Jumping Beans
deactivate() - deactivate the mobile application for a specified duration
dispatch() - move the mobile application to next node in Itinerary
dispatchTo(destinationAgency) - move the mobile application to a specific
destination host
getAgencyID() - Where am I now?
getItinerary() - Where am I going?
getStatus() - How am I doing?
destroy() - terminate mobile application classes
120 120
ItineraryNode - tree representation of the mobile applications itinerary. It is
illegal to edit nodes which represent agencies already visited by the mobile
application.
appendBranch(ItineraryNode) - add a branch from this node after all of the
other branches from this node
getChildNodes() - get a list of all of the branches from this node
insertBranch() - add a branch from this node in a specific position relative
to the other branches from this node
setCycleIfAlternatesUnreachable(boolean) - if true the server will
continue cycling: first try the primary destination, then the alternates in
order, otherwise the server will wait for the last alternate destination
isFullyEditable() - determine if it is legal to edit this node. If this node
represents an agency which the mobile application has already visited, it is
illegal to edit this node
61
121 121
Jumping Beans Security Jumping Beans Security
l Jumping Beans security is based on:
ACLs, user log-ons, certificates, public/private keys, digital signatures
And by forcing all mobile applications through the central Jumping Bean
server when mobile application are jumping between clients
l During transport, security is enforced jointly by the server and the
receiving client
l Each mobile application carries a non-mutable audit log which
records events in the life of the mobile application (i.e.. clients
visited)
l Jumping Bean ACLs can also place limits on a mobile
application, such as the:
Maximum number of jumps a mobile application may take during its
lifetime
Maximum size of code and data for a mobile application
122 122
Hive Hive
l Developed at MIT Media Lab
l Designers: Nelson Minar, Matthew Gray, Oliver Roup, Raffi
Krikorian, and others
l Problem Domain: Things That Think - take the power of
computers and networks and put them into everyday objects
l Design goal was to develop a framework for an ecology of
distributed agents
l Decentralization is important for a system to be able to adapt and
grow (modeled after the Web)
l Hive is open Java source and free software, distributed under the
GPL
l Current version available at http://www.hivecell.net/
62
123 123
Hive Architecture Hive Architecture
Cell - a server-like program
running on a specific computer
which acts as a host for a
population of Agents.
Shadow - API to a local
resource residing at a cell
Agent - Active computation
that uses the local resources
and communicates with each
other.
Hive Components
Physical Device - screen
display, digital camera, toaster,
etc.
124 124
Hive Concepts Hive Concepts
l Cell - nodes in the decentralized network running the Hive
software
l Cells provide:
An environment in which Agents can operate and consume resources of the
Cell
A facility for the life-cycle and mobility of Agents
Host services which are local to that Cell as Shadows and provide a way
for Agents to access them
A set of services to facilitate Agents and Shadows to find each other
A password-based security scheme to protect a host from Agents running
on its Cell
63
125 125
l Shadow - a software representation to a device or local resource
associated with a Cell.
l Shadows provide:
An interface for the capabilities available on a particular device
Example: to query and manipulate the state of a Motor device
public float getSpeed();
public void setSpeed(float speed);
Physical protection for the device
Example: to prevent a motor from becoming overheated the setSpeed method
would have an upper limit on the motor speed
Concurrency protection for a device
Example: Ensure that only one Agent at a time has control of the motor device
l Shadows are not accessible remotely from the network. Only
Agents co-located in a Cell are allowed access to the Shadow.
126 126
l Agent - an active computation that uses the local resources and
communicates with peers
l Hive Agent Characteristics:
Separate thread of execution and an agenda to perform computation on their own
A host and location where it performs computation and consumes resources
Potentially mobile to allow Agents to interact with resources on different Cells
Designed defensively to decide to accept or deny messages and commands from
other Agents
Self-describing to facilitate the ad-hoc discovery and interaction with other
Agents and resources available
64
127 127
l Lookup scheme to support ad-hoc interaction
Problem: With the decentralized nature of Hive how do Agents find Shadows and
other Agents they are interested in communicating with?
Solution:
Agents and Shadows are self-describing
Agents can call methods on a Cell to find Agents or resources that match a
particular description
Agents are described in terms of:
Syntactic Descriptions to answer the question: What type of thing is it?
Defined by the Java type-hierarchy for objects at design time
Example: An object might implement a particular interface
public interface Toggleable {
public void setState(boolean state);
public boolean getState();
}
128 128
Agents are also described in terms of:
Semantic Descriptions to answer the question: What is the meaning or purpose
of this thing?
Provides context about the object such as location, owner and capabilities
Resource can use an arbitrary set of key-value pairs to describe itself
Example: A Toggleable desk lamp might describe itself as follows:
role = light-switch
owner = tarr@cs.umbc.edu
location = ECS room 227
install-date = 2000.08.01
65
129 129
Hive Applications Hive Applications
l Counter Intelligence - investigating future appliances in a networked kitchen,
such as:
Mr. Java, an intelligent coffee machine
Scents Sense, a digital nose integrated with an oven
Intelligent Refrigerators that know their contents and when to order more of a
particular item
l Wearable Computing
Personal Locator - tracks the location of a person with a wearable computer and
can let other people know their location
Personal Theme Music - when a user enters a room, his or her wearable sends a
message to a Hive agent to play a song the user has chosen
l Honey, I Shrunk the CDs - MP3-based jukebox
Poker chip sized discs contain a song title and radio frequency ID tag
User selects a disc and places on a table with a RF tag reader
MP3 file is retrieved and played
Mobile Agent
Design Patterns
Mobile Agent
Design Patterns
66
131 131
Design Patterns Design Patterns
l Design patterns have proven very useful to the object-oriented
design community
l Well-structured object-oriented systems have recurring patterns of
classes and objects
l Knowledge of the patterns that have worked in the past allows a
designer to be more productive and the resulting designs to be
more flexible and reusable
l Each pattern is a three-part rule, which expresses a relation
between a certain context, a problem and a solution. -
Christopher Alexander
l Patterns can also be applied to the development of mobile agent
systems!
132 132
Mobile Agent Design Patterns Mobile Agent Design Patterns
l Classifications of Mobile Agent Design Patterns
Agent Patterns - deal with the architectures of agents and agent-based
applications
Communication Patterns - deal with the way agents communicate with one
another
Travelling Patterns - deal with the ways that agent migration is handled
Task Patterns - deal with the way complex tasks are broken down and
delegated to one or more agents
Interaction patterns - deal with the way agents locate other agents and
services
Coordination Patterns - deal with the ways agents coordinate their activities
Deugo and Weiss, 1999
67
133 133
Aglets Patterns Aglets Patterns
l Danny Lange, Yariv Aridor and Mitsuru Oshima documented
several agent design patterns during the development of the
Aglets system
Traveling Patterns - deal with the movement of agents
Itinerary - maintains a list of destinations and defines a routing scheme
Forwarding - supports automatic forwarding of agents to another host
Ticket - encapsulates additional information for dispatching an agent to a host,
including retry counts, permissions, time-out values
Task Patterns - deal with the delegation of tasks among agents
Master-Slave - defines a scheme where a master agent can delegate a task to a
slave agent
Plan - supports the coordination of multiple tasks on multiple hosts by multiple
agents
134 134
Aglets Patterns Aglets Patterns
l More Aglets Patterns
Interaction Patterns - deal with the way agents locate other agents and
services
Meeting - provides a way for two agents to meet and interact on a specified
host
Locker - provides a private storage area for an agent at a given host
Messenger - provides a special agent which can carry a message from one
agent to another
Finder - provides a service for naming and locating agents with specific
capabilities
Organized Group - supports the grouping of agents and allows all agents in the
group to travel together
68
135 135
The Silva and Delgado Agent Pattern The Silva and Delgado Agent Pattern
l Silva and Delgado, University of Lisbon, developed a general
agent pattern which can be used to develop and manage
distributed agent-based applications
Examples of Mobile Agent
Applications
Examples of Mobile Agent
Applications
69
137 137
AutoPilot: Automating Complex Workflows AutoPilot: Automating Complex Workflows
l Problem
Workflow applications require complex process coordination and
communication between a set of distributed tools
Examples: insurance claim processing; image and document
management/processing
l Research Focus
Dynamic data-flow problems without pre-defined processing paths
Distributed processing architectures that are scalable, flexible and
extensible
l Approach
Develop data-driven mobile software agents that seek out processing
services and data to accomplish a task
138 138
AutoPilot Architectural Design Metaphors AutoPilot Architectural Design Metaphors
l Agent
Autonomous object that controls its movement through a
constantly changing distributed processing environment
Agents carry the data being processed, meta-data and control
logic
l Place
Place is a process that offers services to visiting agents
Place Attributes: type of data the service handles, cost of
service and quality of service
Provides unified interface: dataObject = process(dataObject)
l Workflow Service Broker (WSB)
Provides Yellow Pages directory services to Agents
Maintains a list of active Places and information about data
types handled, cost and quality of service provided
Data
Language ID
70
139 139
AutoPilot TIPSTER Text Processing Example AutoPilot TIPSTER Text Processing Example
LanguageID 1
LanguageID 2
User 2
English Filter
Agent Launcher
Spanish MT
document
agent

LanguageID 3
Spanish Filter
User 1
documents
Agent pool
140 140
AutoPilot Components AutoPilot Components
l Service Provider Places
ServiceProvider is an abstract class from which all Places inherit
Provides methods for:
Loading and instantiating the Places configuration parameters
Registering with the nearest Workflow Service Broker the following attributes:
data type handled, cost of service and quality of service
Recording processing statistics: number of documents processed, errors,
average CPU time, average document size
Shutting down the Place
71
141 141
l Workflow Server Brokers (WSB)
Distributed, multi-tiered hierarchy of WSB Places
Our current implementation uses a Master WSB at a well-known location
with local WSBs at each host
Local WSBs store information about the Places available on the local host
Agents consult the local WSB first
To ensure that local resources are used when available
If a desired service type is not registered with the local WSB, the query is then
passed up to the WSB at the next higher level
The WSB recommends the next Place in the agent's processing path
The recommendation is based on data type handled, "service quality" and
"service cost
Information in the WSB is stored as a four-tuple representing service type,
service name, data type processed, and location
142 142
l Workflow Server Brokers (WSB)
WSB queries are formatted like DNS names with wildcards. The format is
serviceType.serviceName.dataType.location
Example: Translate.MerlinTerp.Spanish.Host:8001
Agents query WSB by data type
For example, the query (Translate.*.Spanish.*) would return all
services at all locations which provide Spanish machine translation
All entries in the WSB are created when a Place registers with the WSB
A simple leasing mechanism allows the WSB to maintain a list of entries
that represent Places that are truly available
72
143 143
l Agent Pool
Used to limit the number of agents that are in the system at any given time
Agent Pool is populated at system start-up time
Size of pool is determined by the system configuration
When an agents returns from processing it is returned to the pool
l Agents
Agent Itinerary Stack
Used to pre-plan part or all of an agents processing path
Can be used to deliver a document to several people
Each service provider can push one or more items onto the stack
Each service provider can pop one or more items from the stack
Used to dynamically determine the route through the various processing places
(one node look ahead)
144 144
l Agents
Basic Agent Control Loop
control() {
// Anything to do?
if (itineraryStack.empty() || currentState.equals(TERMINATE)
|| (place = getNextPlace(itineraryStack)) == null)
homePlace.agentPoolReturn();
appendTravelogue(place);
// Move to next place and invoke atPlace()
moveTo(place, "atPlace");
}
atPlace() {
// Do local processing.
process(document);
// What next?
control();
}
73
145 145
AutoPilot Implementation AutoPilot Implementation
l Early Implementations
Telescript: powerful agent development language; poor overall system
performance
C++: implementation facilitated by Agent/Place/WSB metaphor; single
machine only
l Java Implementations
Odyssey: based on RMI serialization mechanism; better performance than
Telescript
Voyager: based on proprietary high-speed serialization mechanism; easy to
mix remote object messaging and object mobility
l Current implementation uses ObjectSpace's Voyager
146 146
AutoPilot Performance Enhancements AutoPilot Performance Enhancements
l Co-location of lightweight services
By co-locating services whose processing cost is less than or equal to the
cost of agent movement overall system performance can be increased
l Simplifying the Agent payload
Representing the same data in a less complex state, for example XML, can
represent a considerable cost saving in the critical serialization operation
l Minimizing off machine querying of the WSB
Have local WSBs at each host
l Remote reference data only when necessary
In some circumstances, it is better to move the data with the agent than
remotely reference it
It is the responsibility of the system designer to decide, based on the
specific nature of the application, how much of the data to move, the
circumstances under which data should move, and how best to optimize the
data for serialization
74
147 147
Application of Mobile Agents to
Distributed Databases
Application of Mobile Agents to
Distributed Databases
l Problem
Providing users with relevant and up-to-date information from multiple
data sources
Complex task because:
Data sources can be distributed across the network
Heterogeneity at various levels: hardware, software and terminology
l Approach
System of collaborating autonomous agents (both static and mobile) to
interact with distributed information sources, gather, merge and present
query results to the user
148 148
Agent-Based Distributed Data Access Agent-Based Distributed Data Access
Meta-Schema Agent
InfoSource1: CarDealers
InfoSource2: Consumer Reviews
InfoSource3: Car Insurance
InfoSource4: Govt Recall/Safety
InfoSource1 Agent
InfoSource4 Agent
InfoSource3 Agent
InfoSource2 Agent
Mobile Query
Agent
What are the best deals on
highly rated and safe minivans?
75
149 149
Types of Agents for Distributed Data
Access
Types of Agents for Distributed Data
Access
l InfoSource Agent
Static agent co-located with the information source
Provides a common interface for mobile query agents
Knows the information source protocols to submit requests and how the returned
results are formatted
l Meta-Schema Agent
Static agent
Maintains information published by various information sources about
their contents and location
l Query Agent
Mobile to migrate between distributed information sources to gather data
Carries, merges and formats the gathered data
150 150
References References
l Aglets
www.trl.ibm.co.jp/aglets/index.html
Lange and Oshima, Programming and Deploying Java Mobile Agent with Aglets, Addison-
Wesley, 1998
l CORBA/MASIF
www.omg.org/
l CoABS/DAML
www.darpa.mil/
l FIPA
www.fipa.org/
l Hive
www.hivecell.net/
l Java Spaces
http://www.javasoft.com/products/javaspaces/
Freeman, Humpfer, Arnold, JavaSpaces Principles, Patterns, and Practices, Addison-Wesley,
1999
76
151 151
References References
l Jumping Beans
http://www.jumpingBeans.com/
l Jini
www.sun.com/jini/
www.jini.org/
Arnold, OSullivan, Scheifler, Waldo, Wollrath, The Jini Specification, Addison Wesley,
1999
l The Mobile Agent List
www.informatik.uni-stuttgart.de/ipvr/vs/projekte/mole/mal/mal.html
l Mole
www. mole.informatik.uni-stuttgart.de/docs/
l RMI
java.sun.com/products/jdk/rmi/
l Voyager
www.objectspace.com/downloads/

MA Tutorial 3

Uploaded by

Copyright:

Available Formats

You might also like

MA Tutorial 3

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

MA Tutorial 3

Uploaded by

Copyright:

Available Formats

1

Tools USA 2000 Mobile Agents

You might also like