DYNAMIC LAYOUT OF DISTRIBUTED APPLICATIONS IN FarGo

1
DYNAMIC LAYOUT OF DISTRIBUTED APPLICATIONS IN
FarGo BY Ophir Holder Israel Ben-Shaul Hovav
Gazit
Presented By- Sudhanshu Bhushan November 7, 2006
2
Presentation Outline

• Motivation
• FarGo
• Programming Model
• Layout Programming
• FarGo above all
• Conclusion

3
Overview

• The paper presents a novel programming model to
  provide dynamic layout capability.
• Advocates the separation of programming of the
  application logic from the programming of the
  application layout.
• Presents a system FarGo - that allows this
  separation and also the precise control of the
  layout policy dynamically at runtime.
• Compares FarGo with existing approaches and
  explains why it provides the best of all worlds.

4
FarGo

• Separates programming of the Application Logic
  from the programming of the Layout.
• Permits the manipulation and control of
  Component Location at runtime.
• It is an extension of JAVA
• The references can be associated with rich
  semantics that describe various co- and
  re-location relationships between components
• Inter-component references which embodies co
  and re-location semantics act as the abstraction
  vehicle

5
Need for Dynamic Layout

• Static layout
• Component layout is fixed early in the design
  time
• Assumptions made early in design time are
  unlikely to hold during deployment time.
• Likely that the application logic and the layout
  will be tightly coupled.
• Not suited to be scalable.
• Layout changes would require reverse-engineering
  
• Conventional Static Layout is inadequate for
  large scale distributed systems.

6
DYNAMIC LAYOUT

• Defer layout decisions to runtime
• A lot more flexible
• Can allow objects to migrate at runtime and
  still maintain connection semantics
• Allows a separation of programming of
  application logic from programming of the
  layout
• Scalable
• Migration entity granularity

7
Fine Grained Approach

• Supports relocation for all objects
• Flexible
• Mobility support in all objects may cause
  unnecessary overheads
• All objects need to adhere to remote call
  semantics
• Assumes lack of shared memory

8
Coarse Grained Approach

• Application is divided into a set of processes
  that can move during execution
• Each process is populated with a large number of
  object, all of which share the same address
  space.
• Clearly separates local and remote invocations
• Inter-process references are considered remote
• Rigid boundaries restrict the power of dynamic
  relocation.

9
The FarGo Approach

• Takes a Middle-grained approach
• The unit of relocation is called a Complet which
  is a collection of local objects
• A complet may be co-located or remote to other
  complets
• Co-located complet references are turned into
  local references thereby improving performance.
• As a complet moves, its dynamically changes its
  locality relationship with other complets.

10
Programming Model

• Complets
• Basic building blocks(modules)
• Relocation
• Collection of objects (one such called anchor)
• Complet References
• Connect complets
• Same complet reference can be local or remote
• Anchor
• Its interface is the interface of the complet

11
Complet Reference

• Complets are connected by inter-complet
  references.
• Complet references may be local at times and
  remote at other times.
• Complet references can be associated with rich
  semantics of co- and re-location relationships
  between complets.
• The relationships can be interrogated and can
  evolve over time.
• Complet references are syntactically transparent.

12
Knowledge of Software Internals
Host A

• Link
• Pull
• Duplicate
• Stamp
• Bi-directional Pull

a
ß
Host B
a
13
Layout Programming

• Layout API
• Enables embedding of layout algorithms within
  application
• Provides means to register events and perform
  measurements
• The API is based on a simple distributed
  extension of standard Java event model
• High Level Scripting Language
• Scripts written in an Event-Action style
• on event at core do actions
• eg. completArrival(complet, sourceCore)
• Graphical tool for Layout Management
• Visualizes the state of a FarGo application
• Used to control and manipulate running
  applications

14
FarGo Alternatives

• CORBA, DCOM and JAVA RMI
• Based on an object oriented extension of RPC
• Dont support dynamic relocation of distributed
  objects.
• Language based approaches
• Uses a new programming language that supports
  mobility
• E.g. Distributed Oz and Facile
• Very difficult to convince programmers to use a
  new language

15
Continue..

• System based approaches
• Using an existing language along with a set of
  libraries and runtime support to provide mobility
• Strong Mobility
• Involved movement of a full programs context,
  including the stack and program counter.
• E.g. Sumatra
• May results in non-portable implementation
• Weak Mobility
• Only the objects code and state ins moved.
• E.g. FarGo, Aglets

16
Conclusion

• The paper presents a novel programming model to
  provide dynamic layout capability
• Provides a new dimension of flexibility the
  ability to program dynamic layout policies
  separately from application logic
• The approach carefully balances between
  programming scalability and system scalability
• Its implementation in JAVA and the use of
  component references makes it attractive and
  intuitive to programmers
• It provides an event-based scripting language and
  a event-monitoring system for managing and
  controlling the layout.

17
Discussion