Understanding Code Mobility

Understanding Code Mobility Li Jingyue IDI/NTNU 28/10/2002

Distributed Applications on Wide-area Networks • The size and pervasiveness of computer networks are increasing • New ways of using networks • The communication infrastructure is evolving accordingly, but... • ...The computational infrastructure is not • The traditional solution ...

Mobile Code • Code mobility can be defined informally as the capability to dynamically change the bindings between code fragments and the location where they are executed.

Related Work • Remote batch job submission • Process migration Transfer an OS process to another machine • Object migration Move object among address space

Characters of Related Work • The main purpose is load balancing • Target to small-scale networks • Loacation is hidden

The Mobile Code Approach • Code mobility is exploited on an Internet-scale • Programming is location aware. • Mobility is under programmer’s control • Mobility is not performed just for load balancing

A Mobile Code Framework • Technology • Paradigm • Application

A Mobile Code Framework • Technology • The languages and systems that provide mechanisms enabling and supporting code mobility

A Mobile Code Framework • Paradigm • The architectural styles that the application designer uses as building blocks in defining the application architecture

A Mobile Code Framework • Application • Application domains are classes of applications that share the same general goal, e.g. Distributed information retrieval or electronic commerce

A Mobile Code FrameworkPart one - Technology • Distribute Virtual Machine • Mobility Mechanism • Code and Execution State Management • Data Space Management • Execution and translation mechanisms • Commnuication mechanisms • Security mechanisms

The Classical Approach component component True Distributed System Network operating system Network operating system Network operating system Core Operating System Core Operating System Core Operating System Host Host Host

The Mobile Code Approach component component Computational Environment Computational Environment Computational Environment Network operating system Network operating system Network operating system Core Operating System Core Operating System Core Operating System Host Host Host

Components Hosted by CE Code segment Executing state … … … … … … Data space Executing unit Resource Computational Environment

Component Hosted by CE • Executing units (EU) represent sequential flow of computation. Typical examples of EUs are single-threaded processes or individual threads of a multi-threaded process. • Code Segment • Execution State • Data Space • Resources represent entities which can be shared among multiple EUs, such as a file in a file system

Classical Approach Vs. Mobile Code Approach • TDS (True Distribute System) • Network transparency • E.g. CORBA programmer is usually unaware of the network topology and interacts with a single, well-known object broker • CE (Computational Environment) • CE retains the “identity” of the host where it is located. The purpose of the CE is to provide applications with the capability to dynamically relocate their components on different hosts.

Classical Approach Vs. Mobile Code Approach (cont) • In the classical approach, each EU is bound to a single CE for its entire lifetime, the binding between the EU and its code segment is static • In the mobile code system, the execution state, and the data space of an EU can be relocated to different CE

A Mobile Code FrameworkPart one - Technology • Distribute Virtual Machine • Mobility Mechanism • Code and Execution State Management • Data Space Management • Execution and translation mechanisms • Communication mechanisms • Security mechanisms

Code and Execution State Management • Strong mobility is the ability of a system to allow migration of both the code and the execution state of an EU to a different CE • Weak mobility is the ability of a system to allow code movement across different CE

Code and Execution State Management –Strong Mobility • Strong mobility • Migration • Remote cloning • Migration and remote cloning can be • Proactive • Reactive

Code and Execution State Management – Weak Mobility • Mechanisms supporting weak mobility are characterized according to • Direction of code transfer • Code shipping • Code fetching • Nature of the code being moved • Stand-alone code • Code fragment • Synchronization of invocation and execution • Synchronous • Asynchronous • Time of execution • Immediate • Deferred

Data Space Management • When an executing unit migrate, its data space is modified • Modification may involve • Changing the bindings to resource • Migrating some of the resources along with the executing unit • The policies that can be applied rely on • The nature of resource • The type of binding to the resource

Characterizing Resources • Resources <identifier, value, type> • Resource • Transferrable • Free • Fixed • Non-transferrable • Executing units may have multiple bindings to different resources, or multiple bindings to the same resource

Characterizing Bindings to Resources • Binding by identifier • At any time, the executing unit that owns the binding must be bound to a given, uniquely identified resource • Binding by value • Although the actual instance can change, its value must not change as a consequence of migration • Binding by type • At any time, the resource bound must be compliant with a given type

The Space of Alternatives

Execution and Translation Mechanism • Mobile code poses specific requirement, as the code must be • Portable: the target platform is a network of heterogeneous machine. The goal is to ”write one, run many” • Secure: incoming code must be checked in order to prevent accidental or malicious damage to the hosting environment

Challenges & Strategy • Challenges • The mobile code translation would force the run-time support of the sender machine to be aware of the platform of the receiver machine in order to select appropriate native executable code for transmission • Strategy • Source code is compiled in an intermediate, lower-level language, which is in turn interpreted

Translation in the Presence of Mobility • General problem A program written in a language a must be sent to a computational environment that supports a set of languages A= {a1, a2,...an} ? • The solution is local translation and remote translation

Local Translation • The program written in a is translated at the source computational environment in a language a’=t(a) in A, sent to destination • Translation may take place: • After coding: the common solution • Before transfer: can leverage off of information available at run-time about the languages supported at the destination

Remote Translation • Translation take place at destination, after the transfer is completed, and produces a language a’’= t(a’) in A • Translation may take place • Before execution: the code transfered is translated completely before being executed • Just in time: it is translated piecemeal as soon as the execution flow reaches untranslated portions of the code

Communication Mechanisms • Provide the capability to exchange information among roaming executing units • In current mobile code system, mechanisms are usually simple and heavily constrained • Adaptation to the mobile setting is difficult, and poses the theoretical challenges • Two dimension of classification • Number of parties involved • Location of parties involved

Communication Mechanisms • Point-to-point mechanisms • Asynchronous message passing • Streams • Multi-point mechanisms • Events • Shared memory

Security Mechanism • Security Threats • Spoofing (of executing units and computational environments) • Eavesdropping • Service misuse( e.g., use network services on a CE to attack another)

Security Mechanism • They can be classified in: • Inter-CE: Provide security across computational environment • Intra-CE: Provide security within a given computational environment

A Mobile Code FrameworkPart two - Paradigram • Mobile code design paradigms abstract away from the details of mobile code technology • Interaction pattern define the coordination and relocation of components needed to perform a service

Architectural Abstractions • Components • Code Components: encapsulate the ”know-how ”to perform a particular computation • Resource Component: Data and devices used during the computation • Computational components: Active executors capable to carry out a computation, as specified by the corresponding ”know-how” • Interactions • Events involving components • Sites • Support component execution and local interaction

Paradigms • Client – server (CS) • Remote Evaluation (REV) • Code on Demand (COD) • Mobile Agent (MA)

Make A Chocolate Cake Tom and Jerry interact and cooperate to make a chocolate cake. In order to make the cake(the result of a service), a recipe is needed ( the know-how about the service), as well as the ingredients ( movable resources), an oven to bake the cake (a resource that can hardly be moved), and a person to mix the ingredients following the recipe ( a computational component responsible for the execution of the code). To prepare the cake all these elements must be co-located in the same site.

Client-server (CS) Please make me a chocolate cake Resource code Tom Jerry ... Request Reply Site A Site B

Client-server (CS) A computational component B (the server) offering a set of services is placed at site SB. Resources and know-how needed for service execution are hosted by site B as well. The client component A, located at SA, requests the execution of a service with an interaction with the server component B. B performs the service requested and delivered back to the client with an additional interaction.

Remote Evaluation (REV) Please make me a chocolate cake. Here is the Recipe.. Tom code Jerry Resource Request ... Reply Site A Site B

Remote Evaluation (REV) In the REV paradigm, a component A has the know-how necessary to perform the service but it lacks the resource required, which happen to be located at a remote site SB. Consequently, A sends the service know-how to a computational component B located at the remote siteB, in turn, executes the code using the resources available there. An additional interaction delivers the results back to A.

Code On Demand (COD) Please tell me the recipe Tom Jerry Resource Request ... Reply Site A Site B code

Code On Demand (COD) In the COD paradigm, component A is already able to access the resources it needs, which are co-located with it at SA. However, no information about how to manipulate such resources is available at SA. Thus, A interacts with a component B at SB by requesting the service know-how, which is located at SB. A second interaction takes place when B delivers the know-how to A, which can subsequently execute it.

Mobile Agent (MA) Here I am. Can I use your oven? Jerry Resource Tom Move ... Site B Site A code

Mobile Agent (MA) In the MA paradigm, the service know-how is owned by A, which is initially hosted by SA, but some of the required resources are located on SB. Hence, A migrates to SB carrying the know-how and possibly some intermediate results with itself. After it has moved to SB, A completes the service using the resources available there

Understanding Code Mobility