Code Migration
Russell T. Potee, III
4 December 2007
Overview





What is Code Migration?
Code Migration Terminology
Resource Relocation and Binding Reconfiguration
Code Migration Paradigms
Incremental Code Migration with XML
What is Code Migration?


Code migration is when programs are moved from
one machine to another, often moving parts of its
execution environment along with it.
The intent is for the transferred program to
continue execution on the target machine.
What is Code Migration



Code migration is often used for load distribution,
reducing network bandwidth, dynamic
customization, and mobile agents.
Code migration increases scalability, improves
performance, and provides flexibility.
We will gain a more tangible understanding of
code migration when we get to the paradigms
section.
Code Migration Terminology


Code migration has been around for sometime, but
traditionally code migration technologies could not
agree on terms.
To understand code migration properly, we will go
over some standardized terms for code migration
as defined by Fuggetta et al.
Code Migration Terminology


Many code migration technologies provide
Computational Environments to support code
mobility.
Computational environments give applications the
ability to move components from one host to
another.
Code Migration Terminology


Code migration components consist of execution
units and resources.
Execution units can be divided into the following:

Code Segment


Data Segment



Set of instructions being executed
References to external resources
Files, printers, devices, et cetera
Execution Segment

Process state, private data, stack pointer, and instruction
pointer
Code Migration Terminology

Strong Mobility


Described as the ability to transfer both the code
segment and execution state of the execution unit from
one computational environment to another.
Weak Mobility


Described as the ability to transfer the code segment,
but not the execution state.
Typically, weak mobility applications have predefined
starting positions

For example - Java Applets
Code Migration Terminology

Strong code mobility is best characterized by two
terms:

Migration


is when an execution unit is suspended, transferred from one
computational environment to another, and resumes
execution.
Remote Cloning

is when a copy of the running execution unit is copied to
another computational environment while continuing
execution on the original executional environment.
Code Migration Terminology

Sender-initiated (proactive) migration


Transfer is initiated autonomously by the migrating
execution unit
Example


Uploading programs to a computational server
Receiver-initiated (reactive) migration


Transfer is initiated by an execution unit different from
the migrating execution unit
Example

Java applets are downloaded from a web server to the client
browser at the request of the browser.
Resource Relocation and Binding
Reconfiguration

When an execution unit migrates, the data space
needs to be reconfigured. This could involve rebinding or moving resources depending on the
type of resource.
Resource Relocation and Binding
Reconfiguration

Types of resources:

Transferable


This type of resources can be transferred from one machine
to another
Free or Fixed



Free resources can be easily moved from one machine to another.
For example, data files.
Fixed resources can be moved, but not easily. For example, moving
a database can be moved, but could slow performance.
Non-transferable


It is not possible to move this resource
For example, a local device such as a printer.
Resource Relocation and Binding
Reconfiguration

3 types of binding

Binding by identifier (strongest)


Binding by value (weaker)


Execution units refer to resources by unique identifiers
Execution units refer to resources based on the value/content
of the resources and want local access to this type of
resource
Binding by type (weakest)

Execution units refer a resource of a given type, often local
devices
Resource Relocation and Binding
Reconfiguration

Binding by identifier

Free transferable resource


It is best to move this type of resource with the execution
unit. Otherwise, the resource stays in the original
computational environment, and the execution unit will refer
to the resource by a network reference. Network references
are the least desirable because the execution unit will be
slowed due to network problems.
Fixed transferable and non-transferable resources will
need to use a network reference.
Resource Relocation and Binding
Reconfiguration

Binding by value

Free transferable resource


Fixed transferable resource


Can copy or move the resource from one computational
environment to another. Moving the resource may cause
problems if other execution units are accessing the resource.
Network references can be used, but again, this is least
desirable.
Can be copied or use network reference.
Non-transferable

Can use network reference.
Resource Relocation and Binding
Reconfiguration

Binding by type

Best to use re-binding. Re-binding involves the
execution unit removing the original binding, moving
to a new computational environment, and binding to
the same type of resource in the new computational
environment.
Resource Relocation and Binding
Reconfiguration
Fre e Tra n sfe ra b le Fixe d Tra n sfe ra b le N on -t ra n sfe ra b le
By Id e n t ifie r By m oving (or by
By netw ork reference By netw ork
netw ork reference)
reference
By V a lu e
By copying (or by
m oving, netw ork
reference)
By copying (or by
netw ork reference)
By Typ e
By re-binding (or by By re-binding (or by
copying, m oving,
copying, netw ork
netw ork reference) reference)
By netw ork
reference
By re-binding (or
netw ork reference)
Code Migration Paradigms

Defining a design paradigm, or software
architecture, is an important of the design phase of
software development. This section will identify
four design paradigms related to code migration.
Code Migration Paradigms

Client-Server (CS) Paradigm



The server component knows how to perform a
particular service.
The client component at location A requests execution
of the service from the server component at location B.
The server component executes the request and returns
the result to the client component.
Code Migration Paradigms

Remote Evaluation (REV) Paradigm



One software component (A) knows how to perform a
particular service, but does not have the resources to do
so.
The software component (A) sends the code
component to perform the service to another software
component (B) that has access to the necessary
resources.
Software component (B) performs executes the code
component and returns the results to software
component (A).
Code Migration Paradigms

Code on Demand (COD)



Software component (A) has accesses to resources at
its location, but does not know how to interact with the
resources.
Software component (A) requests a code component
from software component (B).
Software component (B) sends the code to (A), and (A)
executes the code component.
Code Migration Paradigms

Mobile Agent (MA)



Software component (A) knows how to perform a
particular service, but does not have the necessary
resources.
To access the resources, (A) becomes a mobile agent
(MA) by migrating the entire computational
environment (state, code, resources) to another location
that has the necessary resources.
The MA executes accesses the resources at its new
location and executes the service code component.
Incremental Code Migration with
XML



Incremental code migration is the ability to move, add,
remove, or replace code sections in a remote program.
Mobile Agents are considered to be at the highest level of
code mobility, where entire code and data segments can be
moved together.
However, incremental code migration decomposes mobile
agents into individual statements, thus increasing
flexibility and scalability.
Incremental Code Migration with
XML


By supporting incremental code migration, code
migration can be more applicable for mobile thin
clients, such as PDAs, user interfaces, etc.
The remainder of this section will explain how
XML can be used to provide incremental code
mobility.
Incremental Code Migration with
XML

XML allows users to define their own document
type definitions (DTDs), a grammar defining the
syntax of the document. XML documents always
reference a DTD so parsers know the grammar of
the document.
Incremental Code Migration with
XML




Elements of XML DTDs can be attributed to store the
values of identifiers, constants, and semantic information.
Thus, XML DTDs can be used to define the syntax
(instruction set) of programming languages.
XML documents that use the syntax defined in the DTD
to specify program functionality are called XML
programs.
Moving an XML program from one machine to another
achieves code mobility.
Incremental Code Migration with
XML
Example DTD for Microwave Instruction Set:
<?xml version=”1.0” encoding=”ISO-8859-1”?>
<!ELEMENT MicrowaveProgram (time | temperature |
popcorn | defrost | on | off | begin)
<!ELEMENT on EMPTY>
<!ELEMENT begin EMPTY>
<!ELEMENT off EMPTY>
<!ELEMENT popcorn EMPTY>
<!ELEMENT defrost EMPTY>
<!ELEMENT time *>
<!ATTLIST time time_value CDATA #required>
<!ELEMENT temperature (high | medium | low)>
<!ATTLIST temperature temp_value CDATA #required>
Incremental Code Migration with
XML







ON – turn on microwave
TIME – Number of minutes
POPCORN – pre-set time/temperature for heating
popcorn
DEFROST – pre-set temperature for defrosting
meat
TEMPERATURE – can set to high, medium or
low
BEGIN – start heating food
OFF – turn off microwave
Incremental Code Migration with
XML
Example XML Program for Microwave:
<?xml version=”1.0”?>
<!DOCTYPE MicrowaveProgram SYSTEM “Microwave.dtd”>
<MicrowaveProgram>
<on/>
<popcorn/>
<begin/>
<off/>
</MicrowaveProgram>
Incremental Code Migration with
XML


XML programs can be transferred as source code
and interpreted by the remote host, thus
establishing code migration.
Using XML we can change or add small fragments
of code to our programs instead of resending the
entire program.
Incremental Code Migration with
XML
Example XML Code Increment (this code increment replaces the popcorn instruction
with values that will burn the popcorn):
<?xml version=”1.0”?>
<!DOCTYPE popcorn SYSTEM “Microwave.dtd”>
<temperature temp_value=”high”>
<time time_value=”10”>
Incremental Code Migration with
XML


How do we specify where the replacement or
insertion of XML code increments take place?
One solution is to use XPointer


XPointer is an XML-related standard used to navigate
through XML documents.
By using XPointer, we can navigate through our XML
program and identify a code section where we would
like to insert our code, thus enabling incremental code
migration.
Incremental Code Migration with
XML

By specifying the
location of the popcorn
instruction, we can
replace the instruction
with the burn popcorn
instruction that was
previously defined.
Example XPointer reference to popcorn instruction:
root().child(1,popcorn)
Incremental Code Migration with
XML

Overall design view

Interpreter implementation


Code Mobility


By using an XML parser to establish a syntax tree and the DTD, an
interpreter can be written to execute the commands of the XML program
represented in the syntax tree.
With the DTD and interpreter on the target machine, the XML program
can be sent over to the target machine to be parsed into a syntax tree and
executed by the interpreter.
Incremental Code Mobility

With the DTD, interpreter, and XML program on the target machine,
XML code increments can be sent along with the XPointer navigation to
update the XML syntax tree supported by the XML parser and
interpreter.
Sources




Emmerich, W., Mascolo, C., Finkelstein, A., Fuggetta, A.,
“Implementing Incremental Code Migration with XML.”
International Conference on Software Engineering, 2000.
Picco, G.P., and Vigna, G: “Understanding Code Mobility.”
IEEE Trans. Soft. Eng., May 1998.
Milojicic, D., Douglis, F., Paindeveine, Y., Wheeler, R., Zhou,
S.: “Process Migration.” ACM Computing Surv., Sept 2000.
Tanenbaum, A., Van Steen, M.: Distributed Systems:
Principles and Paradigms, Upper Saddle River, NJ: Prentice
Hall, 2007