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() Default complet reference from  to with no constraints on co-location or relocation  Co-location: and may or may not be co- located  Re-location: relocation of does not affect the location of and vice versa Used when no layout programming has been performed

8. Complet References  Pull () This reference used to ensures co-location between complets  Co-location: and are co-located  Re-location: If  relocates,  moves to the locality of  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 () Similar to Pull Co-location and re-location with a copy of   Co-location: and are co-located  Re-location: If  relocates, a copy of  moves to the locality of  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 () Similar to duplicate locates a local instance of type  Co-location: and some instance of ’s typeare co- located  Re-location: If  relocates, an instance of ’s typeis located in ’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 () Most powerful but expensive Similar to Pull but the target can pull the souce as well  Co-location: and are co-located  Re-location: If  relocates,  moves to the locality of 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 ???