AMO Project - Exploiting Autonomous Mobile Objects -

Akinori YonezawaUniversity of Tokyo

yonezawa@is.s.u-tokyo.ac.jp http://www.yl.is.s.u-tokyo.ac.jp/

2

What is AMO?

AMO -- Autonomous Mobile Object OBJECT in the sense of OO

distinguishing from ambiguous AGENTs

Concurrent and distributed Migrates across networks Migrates by itself, on its own initiative

a la Telescript’s go-command

3

Why Autonomous Mobility Needed?

Dynamic Flexibility visited sites give the info about where

to move next visiting sites and interacting directly

with visited sitesoften give the information available only at

visited sitesoften leads to most appropriate mode of

interaction

4

MotivationsExploiting the concept of AMOs

departing from the dichotomy of messages and objects

the old idea of distinguishing messages from objects are sometime artificial

objects (instead of messages) should sometime be passed around

Experimenting Autonomous Mobile Objects Telescript did not prevail because too

complicated and too slow

5

Background

Seamless Network of Heterogeneous Machines Networks of PDAs, PCs, WSs, MPPs, and SMPs

Mixed Use of Heterogeneous Objects Fine/Coarse grained objects Mobile/Concurrent/Distributed objects Audio/Visual/Text objects

6

Migrating Objects(I)

Raw Advantages

reducing intersite communication overhead (1-3 Order of Mags)

object as natural migration unit of procedure and data

7

Migrating Objects(II)

Conceptual Advantages visiting sites allows minimum communication

overhead for exploiting site-local/specificcomputation power data contents geographic associative infoinformation brokers

planting interface/coordinating agents after clossing as session on mobile PDA

8

Migrating Objects(III)

Migratory interface non-interruptive contiuation of sessions throug

h site transfer Enabling generic/meta server

easy to customize server by sending code --- remote evaluation

9

Issues in Object Migration(I)

Object identity and its references identity guarantee

update references after migrationuse of forwarder after migration

types of references change Migration of computation

dynamic code/class loading code safety check migration of execution state

10

Issues in Object Mobility(II)

Who moves objects? Object moves itself -- executing (go <site>) primitiv

e in method e.g., our AMO, Telescript, Aglets, AgentSpace, Kafka, Od

essey Object move other objects

downloaded objects (e.g., applets …)as argument objects in remote method call• call-by-move objects (e.g., Emerald objects)• call-by-visit (e.g., Emerald objects)

remote object creation

11

Issues in Object Mobility(III)Moving items

code / class contents of instance vars program counter/execution stack a bundle of threads

Dynamic Binding of Names free names in an objects get bound upon object migr

ation free names in an object get bound upon object arrival

12

Our Research Issues for AMOsLanguage designLanguage Semantics/Computation Models

Calculus of mobile objects ([Sekiguchi97,98])other distributed calculi (D-pi-calculus and D-Join-

Calculus) do not treat AMOs

Linear Modal Logic Model ([Kobayashi98])Language-based security conceptsImplementation level security measures

13

Applications of Mobility

Sophisticated search robotsRemote database interrogatorsInteraction agents, interface assistantsActive badge servers/trackersMulti-user network gamesDistributed encryption key server

problem

14

AMO Language Features

Remote call and Controlled MobilityAutonomous MobilityOn-object-arrival triggeringOn-name-binding triggeringFirst order environment objects, ambient obj

ectsObject/Method-wise capability-based securit

y

15

Remote Calls and Controlled Mobility

Remote object creationRMI (synchronous, asynchronous)Call-by-move, call-by-visitRemote object fetching (object downloadin

g)Dynamic Class loading

16

Autonomous Mobility/Migration

(goto <site>) synchronously or asynchronously

(goto <site> <continuation>) synchronously or asynchronously,

(goto-and-return <site>)(goto <site> <env-obj>)

17

Upon object-arrival, triggering

Execution of the continuationInvocation of some method in some objectBeing bound to some name/channel of so

me objectBinding its free name to local/remote obje

ctKnowing the local default ambient object

18

Upon name-binding, triggering

Invocation of method in some objectExecution of continuationExecution of specified sequence of actions

19

Upon object-departure,

getting some names unboundgetting some names wrapped (closure ma

king)specifying where to returnspecifying whom to communicate with afte

r moving

20

Object Activation upon

Message arrivalObject arrival

ordinary objects ambient objects

Free name binding all free names partial set of free names

21

First Order Ambient/Environment Objects

Object carrying info. mapping from names to objects

Default ambient object for a siteCollecting site-specific info as ambient obj

ectsObject activation with supplied ambient obj

ect

22

Security Issues

Sources of Danger memory leak network fault capability violation

Security Measures Language Design level Language Implementation level Encryption-based

23

Java Security Measures

Java has no security measure except use of security manager library which enhances security check

VM-level check is rather weak

24

Our Security Measures

Language Design Level Method/Object-wise capability Providing tickets, permissions a la Telescript f

or migrating objects Exception handling constructs for network fault

Language Implementation Level Typed Virtual Machine Code - extending the no

tion of types for security

25

Code Representation for Transmission(I)

High-level representation easy to verify, optimize high load-time cost not-tolerant with foreign programming

languages

26

Code Representation for Code Transmission(II)

Low-level representation hard to verify not suitable for multi-platforms low load-time cost accommodates a variety of

programming languages

27

Myths of Low-level Code Collapsed

actually, not hard to verify Proof-carrying code[Necula] Typed Assembly Language[Morrisett]

indeed, adaptive to multi-platform Omniware byte-code[Adl-Tabatabai]

28

Proof-Carrying Code

a code with its proof of safetyMerits

no dynamic check high expressiveness of safety policy

Problems proof generation proof size

29

Typed Assembly Language

Introduces types into assembly language level(cf. gcc and gdb)

Allows polymorphic type systemAllows stack-based execution modelProblem

no notion of safety and security

30

Our AMO Typed Secure VM

typed secure virtual machine instruction architecture-independent instruction set type system for security and optimization accepts a variety of programming

languages(including a large subset of C, C++)

(PCC + TAL)/2

31

Current Status

Under modification gcc that outputs virtual machine

instruction(almost finished)Under implementation

SPARC translator(almost finished) Intel i386 translator

Started to develop secure type system for virtual machine

instruction