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

2. Overview Motivation FarGo Programming model TODO Application Layout Programming in FarGo Implementation Strengths, weaknesses and relevance to embedded systems References

3. Motivation Growing adoption of large scale networking infrastructure Large deployment space Constantly changing environments Need for scalability

4. What do we need? Distributed programming model that provides a dynamic layout capability without compromising on explicit programmability of the layout and yet retains as much as the local programming language.

5. FarGo Extension of Java Separation between programming application logic and programming application layout. Provides extensive dynamic layout capability Programming model to specify co-location relationships Monitoring service

6. Programming Model Complets  Basic building block  Collection of local objects  Minimal unit of relocation Complet references  Connection between complets  Set of complet references define relationships between complets  Controls layout of applications Core objects  Make up the light runtime infrastructure  Provide system support

7. Programming Model (2)… Anchor  Object whose interface is the interface of the complet Complet Closure  Defined by the reachability graph of objects and references starting from the anchor except complet references

8. Semantics of intra and inter complet references Deals with relocatability and cross address-space operation Within a complet  All objects -> by local reference Across complets  Regular objects -> by value  Anchor objects -> by complet reference

9. Complet reference types Link(  )  Basic complet reference from  to  with no constraints on co/re-location semantics 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 is used

10. Complet reference types Pull(  )  Ensures co and re-location between complet Co-location:  and  are co-located Re-location: If  relocates,  moves to the locality of    can be referenced by at most one Pull reference  It is transitive  Useful when the two complets need to interact frequently and/or require heavy data-transfer on each interaction yet they cannot be programmed inside a single complet

11. Complet reference types Duplicate(  )  Ensures co and re-location between complet with a copy of  Co-location:  and  are co-located Re-location: If  relocates, a copy of  moves to the locality of   Useful when target complet can be easily replicated without violating logical semantics of the application  Replication can speed up performance and increase reliability

12. Complet reference types Stamp (  )  Ensures co-location between complet by using a local instance of target complet 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  Instance of  ’s type is free to move regardless of   Used for facilitating a constant connection from a mobile complet to a non-mobile complet

13. Complet reference types Bi-directional Pull (  )  Ensures co-location between complet Co-location:  and  are co-located Re-location: If  relocates,  moves to the locality of  and vice versa  Most powerful but expensive relocation reference  Effectively defines group re-location semantics  Requires a hidden back-reference from target to each of its sources

14. TODO Application A multi-user tool for management of a project’s to do list

15. Monitoring facility in FarGo Monitor measures performance and resource consumption Notifies application upon occurrence of events This service (provided by core) can be used through – Layout (Monitoring) API High-level scripting language

16. Layout Programming in FarGo The three layers : Layout API High-level Scripting language Graphical tool for Layout Management

17. Layout API (1) Application can ask monitor to perform measurements Provides means to register for events Simple distributed extension of standard Java event model

18. Layout API (2) Provides for means to interact with core and its services. Movement of Complets Manipulation of Relocators Interaction with Naming service Interaction with Monitor service

19. High-level Scripting language For (dynamically) embedding relocation scripts to the application Scripts are written in event-action style On event [at core] do actions E.g. completArrival(complet, sourceCore)

20. High-level Scripting Language (2)

21. FarGo Graphical Monitor Visualizes state of FarGo application used by an administrator to view and manipulate the layout of applications using easy point-and- click operations. used by an administrator

22. Implementation

23. How does FarGo differ from Aglets, Voyager? Aglets do not support tracking Aglets do not communicate using simple Java invocations Relocation policy tightly integrated with application logic Fargo has internal monitoring and profiling service

24. People and Roles Dr. Issy Ben-Shaul - Head of research Ophir Holder (Ph.D. Candidate) - Chief architect and project leader - Runtime environment - FarGo Shell - Examples and documentation Hovav Gazit (M.Sc. Student) - Monitoring and profiling service - FarGo Compiler v0.1 - Significant contribution to the overall design. Boris Lavva (Research Staff) - FarGo demonstration for ICSE'99 - FarGo's website design and maintenance - Extensive technical help

25. Related links The FarGo Toolkit is available from this website: http://www.dsg.technion.ac.il/fargo/ Also includes FarGo toolkit documentation and FarGo programming guide General mobility bibliography http://www.cnri.reston.va.us/home/koe/ bib/index.html

26. Example Applications PingPong Boomerang Reporter Informer TODO

27. Strengths Weaknesses Relevance to Embedded systems