The Spider Model of Agents

1
The Spider Model of Agents

• Freeman Huang
• Supervisor Dr. Skillicorn
• CISC at Queens University

2
General Background

• The increase of distributed computing complexity
• Fast growth of online applications and data
  amount
• Global distribution of data
• Heterogeneity data formats, systems, devices,
  networks
• New computing structures are emerging to deal
  with the higher complexity, which are expected to
  be more efficient and more flexible. Mobile agent
  technology is one of them.
• Mobile agent is an active program that can move
  itself from one computer to another within a
  network, and execute some desired computation on
  each computer. Among all properties of mobile
  agents, mobility is emphasized.

3
Motivation Problems

• Security concern is the security mechanism
  inherited from client/server systems enough?
• Blurring of agent mobility and communication.
  mobile agent can communicate with all other
  agents and hosts, mobility becomes an extra
  optional feature.
• Confusion of virtual mobility and physical
  mobility. Communication with mobile agents needs
  to locate virtually mobile objects, bringing in
  higher complexity and complicating system design.
• Systems too complex without clear definitions,
  difficult to understand and verify.

4

• The Proposed Spider Model
• Communication always local, mobility is a
  necessity for distributed computation.
• Local communication well defined as service
  calls.
• Avoid locating virtually mobile objects arms.
  Assign different mobility properties to spider
  and arm.
• Well defined boundary and responsive nature of
  spider ensure both security of spiders and
  security of arms.
• Hierarchical architecture of locality

5
My Research Work

• Design of the Spider Model of Agents
• Define the roles of spiders and arms, and the
  relationship and interactions between these two
  types of objects
• Formalization of the model
• Formal definition of Spider and Arm
• A set of reduction rules as semantics
• Encoding of the formalism in ambient calculus
• Implementation of a prototype of the model in
  Java
• Experimental applications built on top of the
  prototype
• Network traverser
• Online book hunter

In the following I will explain the problems I
identified in major existing mobile-agent models
and how the Spider Model improves on these
problems.
6
IBM Aglets Aglet

• public abstract class Aglet implements
  java.io.Serializable
• public Object clone ( )
• public void deactivate (long duration)
• public void dispatch (URL destination)
• public void dispose ( )
• public void subscribeMessage (String name)
  
• public void waitMessage ( )
• public boolean handleMessage (Message message)
  
• public void run ( )
• Please notice the communication ability of the
  Aglet.

7
IBM Aglets AgletProxy
An AgletProxy acts as a handle of an aglet and
provides a common way of accessing the aglet
behind it.

• For security reasons, any aglet that wants to
  communicate with other aglets first obtain the
  proxy object, and then interact through this
  interface. When invoked, the proxy object
  consults the Security Manager to determine
  whether the caller is permitted to perform the
  method.
• Another important role of the AgletProxy
  interface is to provide the aglet with location
  transparency. If the actual aglet resides at a
  remote host, the proxy forwards the requests to
  the remote host and returns the result to the
  local host. Remote communication is intensively
  involved and complex location tracking is needed.

8
Runtime Environment AgletContext
public interface AgletContext public
AgletProxy createAglet(URL codebase, String
code) public AgletProxy getAgletProxy
(AgletID id) public AgletProxy
retractAglet(URL destination, AgletID id)

• Any authorized callers can get an AgletProxy and
  invoke the corresponding aglets methods.
• Any authorized callers can ask to retract an
  Aglet from a remote site.
• No control on Aglet activities such as
  communication

9
Comparison the Spider Model

• Any arm activities can only be calls to local
  spider services, so that spiders control on
  their own resources is guaranteed.
• Arms cannot directly communicate with remote
  objects
• Mobility is also a local spider service for the
  arms to call, and is the only way to carry out
  tasks remotely.
• There is no need to locate or forward messages to
  highly mobile arms so that there is no need to
  keep track of them.
• Spiders only respond to arms service requests
  and cannot have initiative actions upon arms
  except authentication and authorization. Arms
  handles are never given out. Arms do not respond
  to any outside messages and invocations.

10
Mobile Ambients

• Mobile computation and mobile devices are unified
  as one type of objects mobile ambients, which
  are mobile environments of computations. Mobility
  is represented as an ambient crosses other
  ambients boundaries under permissions. Ambient
  calculus gives a firm semantics to express
  ambient activities. The problems are
• How to locate an ambient after its move?
• n1in m . in n2 . P mn2out m . Q
  mn1in n2 . P n2Q
• How to locate a computation after its ambient is
  absorbed?
• n1in m . in n2 . P mopen n2 n2Q
  m n1in n2 . P Q
• Simple computation may have to be expressed by
  many steps
• of abstract ambient actions, and hard to
  implement.
• mn1out m . in n2 . ltxgt . n3out n2 . in m .
  (x) open n3 (y) . P
• n2 open n1 .
  ltvgt

11
Comparison the Spider Model

• Spiders are relatively stationary and easy to
  locate by mechanisms on underlying network
  (physically mobile).
• There is no need to locate highly mobile arms,
  because there is no need to communicate with
  them.
• Arm actions and spider services are all
  implementable. Hard-to-implement primitives such
  as open are excluded.
• Primitives of the Spider Model encapsulate
  combinations of abstract ambient primitives.

12
Findings

• Clear separation of mobility and communication
• Only one way to do any task, easier to reason
  about and
• implement systems and deploy resources
  appropriately.
• Easier to understand systems (build up mental
  models)
• Better security for mobile agents
• Communication through intermediate services
• Simpler to design agents and predict agent
  activities
• Deadlocks harder to set up
• Avoidance of virtual mobility simplifies system
  design.
• Formalization of the model
• Gives a tool to describe and verify systems
• Helps to understand and design systems
• Must consider implementability

13
Properties of Mobile Agents

• Mobility A mobile agent can move itself between
  computers.
• Intelligence An agent can interact with and
  learn from the environment and make decisions
  accordingly.
• Autonomy An agent can take control of its own
  actions without the supervision of its creator,
  even in long-term running.
• Loyalty An agent performs computation on behalf
  of its user.
• Recursion An agent can create child agents for
  subtasks if necessary.
• Collaboration An agent can cooperate and
  negotiate with other agents.
• Asynchrony in a distributed computing
  environment cooperating mobile agents can perform
  their computations concurrently, and possibly on
  different sites.

14
physical mobility move while the virtual name
remains fixed. Such objects can be located in
constant steps, mapping the virtual names to the
physical addresses. e.g. A mobile phone,
moving while the phone number remains the same
a web server, accessible through the same domain
name. virtual mobility once move, the virtual
name as well as the physical address changed.
Such objects are hard to locate, the complexity
of redirection is undetermined. e.g. mobile
agent.
15
Advantages of Mobile Agents

• Communication efficiency Remote tasks are
  carried out by agent mobility, generating less
  network traffic.
• Distributed process control simplicity Many
  distributed computing problems go back to
  centralized cases.
• Tolerance for network fault and limitations
  Mobile agents do not require continuous network
  connection, and can adapt to the network traffic.
• Higher concurrency and asynchrony More than one
  agent can be created and sent to different places
  for a divisible task, giving higher efficiency.
• Adaptability to heterogeneity The intelligence
  of mobile agent should provide adaptability to
  handle heterogeneity.

16
The Spider Model

• The Spider Model of Agents distinguishes two
  types of computational entities spiders and
  arms, which may be matched to conventional agent
  hosts and mobile agents.
• Spider

• Is distributed, can be nested.
• Has name, globally unique, virtually fixed.
• Can host arms, admission is subject to
  authentication.
• Provides resources and services to residing arms
  subject to authorization.
• Must provide a basic set of services regarding
  arms admission, resource allocation, movement
  and termination. Additional services vary from
  spider to spider.
• May be able to create new arms.

17
The Spider Model ( cont.1 )

• Arm

• Resides on some particular spider at any
  observable time, can move from one spider to
  another, carrying id information for
  authentication and authorization.
• Must get admission to enter a spider, must
  request for resource to stay and do any
  computation.
• Can call authorized services of its host spider,
  e.g. ask to move to another spider, ask to die,
  ask to settle to become a new spider.
• Is not accessible by name, only the id
  information is accessible to its host spider. Can
  interact only with its host spider by calling the
  spiders services.

18
The Spider Model ( cont.2 )

• Services

To invoke services is the only way an arm
interacts with its environment. How much freedom
an arm has on a spider depends on what services
the spider provides. All spiders must provide the
following basic services

• Mobility service send and receive arms.
• Resource manager authorize resources upon arms
  requests and monitor the usage.
• Termination service stop an arms execution upon
  the arms request
• Settlement service convert an arm into a new
  spider upon the arms request.

19
Formalization of the model

• To solve problem3, we construct a formalism of
  the Spider Model. Spider and Arm are defined in
  Ambient style. The formalism is actually a
  restrictive form of safe ambient calculus.
• The formalism includes
• Formal definition of Arm
• Formal definition of Spider
• A set of reduction rules as semantics
• The formalism can be used for mathematical
  description and reasoning about mobile agent
  activities and agent system properties. Due to
  restriction on form, the reasoning is simplified.

20
Formalization of the model ( cont.1 )

• Arm

a, b arm names A, B
arm processes 0
inactive process
A B parallel
processes E . A
arm action E atomic
action of an arm C
arms internal computation action R
arms service
request from the host spider
moveto(attrs ) ask to move to spider
s die
ask to be terminated reqres(q)
ask for resource amount q
settle(attrs ) ask to be
converted into spider s getserv(p)
request other service with
parameter p
21
Formalization of the model ( cont.2 )

• Spider

s, t spider names S,
T spider processes
0 inactive
process S T
parallel processes sT
child spider aA
residing arm V
service responding to arms' requests
moveArm move an arm to
a specific spider receiver
authenticate and launch incoming arm
rma(q) resource
manager for arm a kill
terminate an arms execution
settleArm convert an arm
into a specific spider service
parametric interface for other
local services
22
Formalism of the model ( cont.3 )

• Reduction Rules

Mobility If s knows about t, qgtqmv and a can
get admission to t s amoveto(attrt ) . A
moveArm rma(q) treceiver
smoveArm t aA receiver rma(qmin)
(R-mov1) Resource
authorization ( if qgtqrr ) s areqres(q1) .
Arma(q) saA rma(qqq1qrr )
(R-auth) Settlement ( if qgtqsttl and s can
create t ) s asettle(attrt ) settleArm
rma(q) s tT settleArm
(R-sett) Termination s adie kill rma(q)
skill
(R-die) Resource exhaust s aE.A
kill rma(0) skill
(R-exht) Others
regarding internal computation, general service
call,
23
Prototype Implementation

• Arm

public class Arm extends Thread implements
java.io.Serializable private transient
Spider hostSpider//the current host spider
private AgentID myID //arm's ID for
authentication ...... protected boolean
moveMeTo(SpiderAddress spiderAddress) ...
protected void die( ) ... protected
Resource requestResource(Resource resource) ...
protected boolean settle(Vector
serviceNames) ... protected Result
getServ(String serviceName, Vector parameters)
... ...... public AgentID showID( ) ...
public void run( ) ...
24

• Spider

public class Spider extends Thread private
Resource resource // resource granted by
parent private Hashtable myArms // the
residing arms private Hashtable childSpiders
// child spiders private ArmReceiver
armReceiver new ArmReceiver( ) private
ResourceManager resMgr new ResourceManager(this,
myArms) ...... public Spider( ... )
...... resMgr.start( ) // start
the resource manager armReceiver.start( )
// launch the arm receiver ......
public boolean moveArmTo(Arm arm, SpiderAddress
destination) ... public boolean kill(Arm
arm) ... public Resource grantResource(Arm
arm, Resource requestAmt) ... public
boolean settleArm(Arm arm, Vector servNames)
... public Result service(Arm arm, String
servName, Vector params) ...
25
(No Transcript)
26
(No Transcript)
27
(No Transcript)
28
(No Transcript)