A Programming Model and System Support
for Disconnected-Aware Applications on
Resource-Constrained Devices
(FarGo-DA)
MSc seminar
by
Weinsberg Yaron
www.dsg.technion.ac.il/fargo-da
January 6, 2002
Outline

Introduction

FarGo-DA’s Programming Model

A sample FarGo-DA application

Runtime infrastructure

Status and Future Work

Summary
Thesis Domain



Modern wide-area networks are characterized by:

Dynamic changes of bandwidth, load, machine
capacities and availability.
Requires high level of adaptability from distributed
software systems.
We follow the distributed object programming
model and use Object mobility to:




increase performance
decrease cost
attain high availability
The need: new models and techniques for
designing wide-area sw systems.
Research Objectives

A generic framework for constructing disconnectedaware applications.



A new model and techniques for designing
disconnected-aware applications.


Enable developers to encode connection semantics.
Dynamically changing the application layout upon
(re)disconnection.
Separating the connection layout from the application
logic.
A lightweight mechanism for management and of
disconnection and reconnection
Assumptions

Focus on Voluntary disconnection.




User initiated
enables the system to prepare for disconnection
One-to-many
Uni-directional client-server applications.


NLPCs act as active clients only, and are not
servers of any interaction.
The disconnection request is always initiated by the
NLPC (client), not by any server.
FarGo Overview


Application objects interact across multiple hosts
using remote method invocations (RMI)
FarGo adds a dynamic layout


Add dynamic relocation while preserving the
distributed object abstraction
All references into and out of a migrating object must
remain valid.
site A



site B
FarGo Overview


Application objects interact across multiple hosts
using remote method invocations (RMI)
FarGo adds a dynamic layout


Add dynamic relocation while preserving the
distributed object abstraction
All references into and out of a migrating object must
remain valid.
site A



site B
FarGo Overview

A unique aspect of FarGo is the ability to associate
movement semantics with component references.

The semantics can be changed dynamically.
Source
component

A component
reference

Target
component
The semantic
goes here…

FarGo support the following semantics:

Link, Pull, Stamp, Duplicate.
A Sample FarGo Reference

A Pull reference:
use
r
Core A
Link

Pull

A
relocator
Core B

When  moves,  moves along.

Useful for frequent or data-intensive interaction.
A Sample FarGo Reference

A Pull reference:
use
r
Core A

Link
Pull

Core B

When  moves,  moves along.

Useful for frequent or data-intensive interaction.
FarGo-DA’s Programming Model

A new programming model:



A framework that enables developers to specify
architecture-oriented (re)disconnection policies.
A runtime for interpreting and carrying the policies upon
disconnection,reconnection.
FarGo-DA Extends the FarGo implementation with:



A whole new class of Disconnected-Aware (or DA) semantics.
An extended FarGo invocation mechanism (and FarGo
compiler)
An extended FarGo serialization mechanism
FarGo-DA’s Programming Model


Complet: A mobile java component.
DA-Complet: A complet that is aware of the core’s
connectivity



Only DA-Complets are affected by (re)disconnection
Core: A process that can execute, send, and
receive complets.
Complet Reference: A reference that points to a
complet ( “MetaRef”)


Reifies (re)disconnection semantics.
Accessible via system methods:
MetaRef metaRef = Core.getMetaRef(target);
metaRef.setDA(new Clone(),new Merge());
Facet 1
Application Logic Design

Identify complets and their interactions.

Complets are “semantically remote to each other”



object parameters are passed by value
complets are passed by reference.
Physically, complets may be co-located or remote.
Facet 2
DA Connection Layout

Mark the DA components.


Non-DA components are not affected.
Define FarGo-DA’s connection semantics via reference
types:

Disconnection Semantics:



Clone, Replace , StoreAndForward, Depart
Define migration priorities.
Reconnection Semantics:

Merge, Purge, Overwrite, Last
Disconnection Semantics

A Clone reference.

Core A



Clone
I want to
Disconnect!

Disconnection Event

Core B
When core A disconnects,  is cloned to the locality of .
The default connection semantics.
Within each core, the system notifies all DA-complets
about the coming disconnection.

Enable to dynamically change the connection semantics
MetaRef metaRef = Core.getMetaRef(beta);
metaRef.setDA(new Clone());
Disconnection Semantics

A Clone reference.

Clone
Core B
Core A
I am the
clone complet
(replica)




I am the original
complet
The local reference is updated.
the clone complet has the same ID as the original
complet.
Disconnection Semantics

A Replace reference.

Core A

lik
e
Core B
1.
2.
3.
same interface.
same binding-name.
equivalence method
will figure it out…
 locates a local instance of ’s type and connects to it.



Replace
If non-exist, a new one is created.
Useful when:
 reduced functionality (smaller footprint) is sufficient.
 the origin complet cannot be migrated.
Disconnection Semantics

A Replace reference.

Core A

lik
e

Core B
 locates a local instance of ’s type and connects to it.


Replace

Disconnection Event
If non-exist, a new one is created.
Useful when:
 reduced functionality (smaller footprint) is sufficient.
 the origin complet cannot be migrated.
Disconnection Semantics

A Replace reference.

Core A

lik
e
Core B
 locates a local instance of ’s type and connects to it.



Replace
If non-exist, a new one is created.
Useful when:
 reduced functionality (smaller footprint) is sufficient.
 the origin complet cannot be migrated.
Disconnection Semantics

A StoreAndForward reference.

Core A




StoreAndForward

Disconnection Event

Core B
A special kind of reference: Store + Forward.
All invocations are one-way, in order to enable the source
complet to continue its work.
All invocations are stored at the local NLPC, pending for
reconnection.
The number of invocation stored is limited and can be set
by the developer (with a runtime limit).
Disconnection Semantics

A StoreAndForward reference.

Core A




Method invoked…

StoreAndForward
Local buffer
Core B
AStoring:
special kind of reference: Store + Forward.
- method
All
invocations are one-way, in order to enable the source
number
complet
to continue its work.
- parameters.
All invocations are stored at the local NLPC, pending for
reconnection.
The number of invocation stored is limited and can be set
by the developer (with a runtime limit).
Disconnection Semantics

A StoreAndForward reference.

Core A




StoreAndForward
Local buffer
Core B
method invoked!
Upon Reconnection, the runtime forwards the pending
invocations to the remote complet.
No return values.
An example use of this reference type is for outgoing
email messages, CVS commits, instant messaging etc.
Disconnection Semantics
a remote thread
method invoked.
created
A Depart reference.

User
Invoker


Depart
return value
method
invoked!
Core A




Core B
return value is saved if  is
return valueare
is available:
All invocations
handedcurrently
over to
the remote core prior
disconnected.
 can pull for
it remote execution
to disconnection,
can be notified
Upon reconnection the results, if any, are transferred to
the source complet
Useful to spawn heavy remote computations without the
need to be continuously connected
Partly implemented (based on Miki Abu’s work,ICDCS01)
Disconnection Semantics

Complet Prioritization

NLPCs are resource constrained.




not all clone jobs can be fulfilled.
FarGo-DA provides a simple interface to setting
priorities, by an additional parameter to the setDA
method.
At runtime, the system carries out the
disconnection semantics based on the priority
order.
Invocations on references without target complets
are gracefully handled via FarGo-DA exceptions
MetaRef metaRef = Core.getMetaRef(target);
metaRef.setDA(new Clone(),new Merge(),Priority.High);
Reconnection Semantics

A Merge reference.

Core A
Merge


Merging…
Core B
Reconnection Event

I want to
Reconnect the
When core Anetwork…
reconnects, ’s clone is merged with the

original complet (explained later).
The default reconnection semantics.
Reconnection…
Reconnection Semantics

A Merge reference.
merged!!
!

Core A



Merge
Core B
When core A reconnects, ’s clone is merged with the
original complet (explained later).
The default reconnection semantics.
Reconnected!!!
Reconnection Semantics

A Purge reference.

Core A



Purge


Core B
Reconnection Event
I want to
Reconnect the
When core Anetwork…
reconnects, ’s clone is purged.
 is reconnected to .
Analogous to methods [in] parameters in RPC
Reconnection…
Reconnection Semantics

A Purge reference.

Core A




Purge
Core B
When core A reconnects, ’s clone is purged.
 is reconnected to .
Analogous to methods [in] parameters in RPC
Reconnected!!!
Reconnection Semantics

An Overwrite reference.

Overwrite

Overwrite
Core B
Core A

Reconnection Event
I want to
opposite
of Purge.
Reconnect
the
network…

The
The state of the cloned complet overwrites the state
of the original complet.

Analogous to methods [in/out] parameters in RPC

 is reconnected to .

Reconnection…
Reconnection Semantics

An Overwrite reference.


Overwrite
Core B
Core A

The opposite of Purge.
The state of the cloned complet overwrites the state
of the original complet.

Analogous to methods [in/out] parameters in RPC

 is reconnected to .

Reconnected!!!
Reconnection Semantics

A Last reference.

Last

Comparing timestamps…
Core B
Core A

Reconnection Event

I want to
The state of
the complet
with the latest timestamp wins.
Reconnect
the
network…
The clocks of
the NLPC and the remote server should be

synchronized.
 is reconnected to .

Reconnection…
Reconnection Semantics

A Last reference.

Core A



I won!!!

Last
Core B
The state of the complet with the latest timestamp wins.
The clocks of the NLPC and the remote server should be
synchronized.
 is reconnected to .
Reconnected!!!
Conflict Resolution

In order to resolve conflicting updates between replicas
we must assume application specific knowledge.

FarGo-DA offers two mechanisms in order to resolve
merging conflicts:

Callback methods- The Merge callback method.
void Merge(Complet archive,Complet replica,
Log localLog,Log remoteLog)
{
// Application-specific merging code
}
remote log

local log
archive


r

replica
Core A
invoked on the
original complet
Core B
a
original
Conflict Resolution

Reconciliation operators
encapsulation of primitive types + a state variable that
represents a built-in merging method.

public class
BankAccount_
extends DisconnectedAwareComplet
{
private discInt
balance = new discInt(Operation.Add);
}

FarGo-DA provides the following types:


discInt, discLong, discString
And the following operations:

Add, Max, Min, Average, Random, Last, First.
Conflict Resolution

Each reconciliation operator must implement the
discType interface.

User defined types are created by implementing the
merge method declared at discType interface.

FarGo-DA’s Runtime supports the merging of
reconciliation operators, contained in Java’s basic
container classes (i.e., Vector, Array).
Conflict Resolution

How reconciliation operators work ?


Merge

Core B
Core A
Introspection


+
-discInt balance’ ;
-discInt balance;
-discString account ‘ ;
-discString account;
-discInt balance;
-discString account;
Introspection

merged!!
!
FarGo-DA Example
ManageAnywhere
adds a new
product to the
order



the current
customer
calculates
the product is a simple tool for collaborative
ManageAnywhere
get management
the available
price
the
to beaccording
used bytoremote
sales forces.
balance
quantity
Each sales agent is equipped with a NLPC.
The NLPC may or may not be connected to the central facility,
depending on the cellular coverage in the visited area.
Application Logic Design
Handles all
service requests.
The agents user
interface.
customers
pre-paid accounts
- financial calc
- product’s price calc
Configurator
Logic
GUI
Inventory
1
Accounts
BasicConfigurator
1
n
n
service provider
products inventory
Product
CompanyAccount
-NLPC
product’s price calc
class
- smaller public
footprint
Server
ComapnyAccount_
extends DisconnectedAwareComplet
{
private Integer prePaidBalance= 60102;
private discInt totalPurchase =
new discInt(Operation.Add);
}
Connection Layout Design
A look at the
Logic complet
public class Logic_extends DisconnectedAwareComplet
{
MetaRef mr = Core.getMetaRef(accounts);
mr.setDA(new Clone(),new Merge(),Priority.LOW);
mr = Core.getMetaRef(configurator);
mr.setDA(new Replace(),new Purge(),Priority.High
mr = Core.getMetaRef(inventory);
mr.setDA(new StoreAndForward(),null,Priority.LOW
}
Disconnection Exemplified
System Design
Core Architecture
- Manages the Reconnection
and Disconnection procedures.
- Realized by the
DisconnectionManager (DM)
DM
FarGo-DA’s Implementation
provide a general parameter
passing schemeThe FarGo-DA’s
Implementation
enables disconnected
operation.
System Design
Complet Reference Structure
same interface as 
holds the connection
semantics.

- points to  or to
a remote tracker
- RMI object
The connection reference type is encapsulated in a
meta-reference object.
System Design
FarGo-DA’s invocation model

In order to support disconnected operation, a new
invocation scheme was implemented in FarGo-DA.

FarGo assumed that the complet is “alwaysconnected”:

available on the local core
s

c
available on the remote core through a remote tracker.
s

T
T
remote
T
c
Upon invocation, FarGo always try to invoke the
complet. In FarGo-DA this is a reference specific
property (for example, StoreAndForward stops the
invocation flow)
System Design
FarGo-DA’s invocationInvocation
modelcontinues
to complet!
decision returned.
Invocation starts
here…
connector’s preInvoke method is activated:
continue invocation ?
store data ?
log ? etc…
System Design
The Disconnection Procedure

Core A
Clone

Disconnection Event


User Asks to Disconnect…
Core B
System Design
The Disconnection Procedure

Clone
D
M


Core B
Core A
DM is loaded………….
System Design
The Disconnection Procedure

Clone
D
M


Core B
Core A
New Job:
 : should be
cloned
Creating Internal Database…
System
Design
DM discovers that…
The Disconnection Procedure
Create a new
-  : should be replaced
one!!!

D
M
Clone


Looking for …


Core B
Core A
 Is serialized…
 type
 Is serialized…
disconnection buffer
Cloning…
 type
System Design
The Disconnection Procedure
ready to reconnect!

D
M
Clone




Core B
Core A
Update References…
Disconnection Completed!
System DM
Design
use the already
The Reconnectioncreated
Procedure
database.

D
M
Merge




Core B
Core A

+

=
User Reconnects….
merged
System Design
The Reconnection Procedure

D
M
Merge



merged
Core B
Core A
User Reconnects….
System Design
The Reconnection Procedure

Merge
D
M

merged
Core B
Core A
Update References…
Reconnection Completed!
Status and Future Work

Publications:




A programming Model and System Support – to be
published in ICSE’02 (May 2002)
Simulation for NLPC using FarGo’s monitoring API
(Hovav' s thesis, MA2000)
System is fully implemented (using JDK1.8) and will
soon be available for download.
Ongoing work:



DA-Application profiling.
Weakly-Connected Operation.
More applications.
Summary

A new programming model:




System Design:





Design time (logical) structural rules.
Loose coupling between application-logic and
connection layout (re)design.
Keeping a uniform (and familiar) language, tools, and
object model.
Create a new invocation model to support disconnected
operation.
A system component to handle the (re)disconnections.
Implementation of the disconnection semantics is built
into a new serialization mechanism
Simple yet powerful conflict resolution mechanisms.
An implemented model and system.