Dynamic layout of Distributed Applications in FarGo

1. Dynamic layout of Distributed Applications in FarGo Ophir Holder Israel Ben-Shaul Hovav Gazit

2. Overview • Motivation • FarGo • Programming Model • Layout Programming • Implementation • Related Work

3. Motivation • Large deployment space • Changing nature of environments • Static approaches for the layout • Dynamic approaches to defer decisions till runtime • Challenge to design a model that provides a dynamic layout which has a good mix of both approaches

4. FarGo • Extension of Java • Provides extensive dynamic layout capability • Monitoring Service • Separation between the application logic and the application layout

5. 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 • It’s interface is the interface of the complet

6. Programming Model • Complet Closure • Defined by the reachability graph of objects and references starting from the anchor except complet references • Core objects • Support relocation

7. Complet References • Link(a,b) • Default complet reference from a to b with no constraints on co-location or relocation • Co-location: a and b may or may not be co-located • Re-location: relocation of a does not affect the location of b and vice versa • Used when no layout programming has been performed

8. Complet References • Pull (a, b) • This reference used to ensures co-location between complets • Co-location: a and b are co-located • Re-location: If a relocates, b moves to the locality of a • b can be referenced by at most one Pull reference • Used when the two complets need to interact frequently they cannot be programmed inside a single complet

9. Complet References • Duplicate (a, b) • Similar to Pull • Co-location and re-location with a copy of b • Co-location: a and b are co-located • Re-location: If a relocates, a copy of b moves to the locality of a • Used when target complet can be easily replicated without violating semantics of the application • This speeds up performance and increase reliability by reducing network messages

10. Complet References • Stamp (a, b) • Similar to duplicate • a locates a local instance of b type • Co-location: a and some instance of b’s typeare co-located • Re-location: If a relocates, an instance of b’s typeis located in a’s new locality and gets attached to it • Facilitates a constant connection from a mobile complet to a non-mobile complet

11. Complet References • Bi-directional Pull (a, b) • Most powerful but expensive • Similar to Pull but the target can pull the souce as well • Co-location: a and b are co-located • Re-location: If a relocates, b moves to the locality of a and vice versa

12. 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

13. Implementation

14. Strengths • Separation between the application logic and the application layout • Support dynamic relocation of distributed objects not supported in distributed computing environments like CORBA, DCOM or RMI • Above mentioned environments provide movement primitives and leave the rest to the programmer. Fargo uses references that occupy relocation semantics • Monitoring information is provided by FarGo • Flexible and dynamic component relocation

15. Weaknesses • No deletion of complets • Difficult to copy a complet to another core • example: if we would like to have the same instance of a complet at 2 different cores we need to create a dummy complet with duplicate connection

16. QUESTIONS ???