Strong Programming Model for Strong Weak Mobility Denis

Strong Programming Model for Strong Weak Mobility: Denis Caromel, et al. http: //Pro. Active. Object. Web. org OASIS Team INRIA -- CNRS - I 3 S -- Univ. of Nice Sophia-Antipolis, IUF 1. 2. 3. 4. 5. 6. 1 Denis Caromel Introduction to Pro. Active PM: Active Objects + Groups Mobile Agents Strategies for Localization GUI (Video) Applications: Load Balancing

Pro. Active Parallel Suite (1) Open Source + PROFESSIONAL SUPPORT 2 Denis Caromel

Pro. Active Parallel Suite: GUI 3 Denis Caromel

Pro. Active Parallel Suite: GUI 4 Denis Caromel

5 Denis Caromel

Pro. Active Parallel Suite: Deploy 6 Denis Caromel

Pro. Active Parallel Suite: Deploy 7 Denis Caromel

Deploy on Various Kinds of Infrastructures Internet Servlets Internet Clusters 8 Denis Caromel EJBs Databases Large Equipment Internet Parallel Machine Job management for embarrassingly parallel application (e. g. SETI)

Abstract Deployment Model Problem: Difficulties and lack of flexibility in deployment Avoid scripting for: configuration, getting nodes, connecting, etc. A key principle: Virtual Node (VN) + XML deployment file Abstract Away from source code, and Wrapping code: Machines Creation Protocols Lookup and Registry Protocols and infrastructures: Globus, ssh, rsh, LSF, PBS, SGE, IBM Load Lever, … Web Services, . . . Data management: File transfer 9 Denis Caromel

Scheduler and Resource Manager: User Interface 10 Denis Caromel

Scheduler: User Interface 11 Denis Caromel

Pro. Active Parallel Suite: Program 12 Denis Caromel

Pro. Active Parallel Suite: Program 13 Denis Caromel

Pro. Active Parallel Suite: Program 14 Denis Caromel

2. Distributed and Parallel Objects Pro. Active Programming 15 Denis Caromel 15

Pro. Active : Active objects JVM A ag = new. Active (“A”, […], Virtual. Node) V v 1 = ag. foo (param); V v 2 = ag. bar (param); . . . v 1. bar(); //Wait-By-Necessity JVM A v 2 v 1 ag A WBN! V 16 Java Object Active Object Future Object Proxy Denis Caromel Req. Queue Request Thread Wait-By-Necessity is a Dataflow Synchronization 16

Pro. Active: Inter- to Intra- Synchronization Sequential Multithreaded Distributed Synchronizations, Behavior: not dependent upon the physical location (mapping of activities) 17 Denis Caromel 17

Pro. Active : Explicit Synchronizations A ag = new. Active (“A”, […], Virtual. Node) V v = ag. foo(param); . . . v. bar(); //Wait-by-necessity Explicit Synchronization: - Pro. Active. is. Awaited (v); - . wait. For (v); // Test if available // Wait until availab. Vectors of Futures: 18 - . wait. For. All (Vector); // Wait All - . wait. For. Any (Vector); // Get First Denis Caromel 18

Pro. Active : Intra-object synchronization class Bounded. Buffer extends Fixed. Buffer implements Run. Active { Explicit control: Library of service routines: // Programming Non FIFO behavior run. Activity (Explicit. Body my. Body) { while (. . . ) { if (this. Full()) serve. Oldest("get"); else if (this. Empty()) serve. Oldest ("put"); else serve. Oldest (); Non-blocking services, . . . serve. Oldest (); serve. Oldest (f); Blocking services, timed, etc. serve. Oldest. Bl (); serve. Oldest. Tm (ms); Waiting primitives wait. ARequest(); etc. // Non-active wait. Arequest (); } }} Implicit (declarative) control: library classes e. g. : Blocking Condition Abstraction for concurrency control: do. Not. Serve ("put", "is. Full"); 19 Denis Caromel 19

Pro. Active: First-Class Futures Sequential Multithreaded Distributed Synchronizations, Behavior: not dependent upon the physical location (mapping of activities) 20 Denis Caromel 20

Wait-By-Necessity: First Class Futures are Global Single-Assignment Variables V= b. bar () a c. gee (V) c b v v 21 Denis Caromel c 21

Standard system at Runtime: No Sharing No. C: Network On Chip Proofs of Determinism 22 Denis Caromel 22

Calculus ASP: Asynchronous Sequential Processes 23 Denis Caromel

Proofs in GREEK ASP Confluence and Determinacy Future updates can occur at any time, Mobility does not change behavior 24 Denis Caromel

TYPED ASYNCHRONOUS GROUPS 25 Denis Caromel 25

Creating AO and Groups JVM A ag = new. Active. Group (“A”, […], Virtual. Node) V v = ag. foo(param); . . . v. bar(); //Wait-by-necessity A V Typed Group 26 Denis Caromel Java or Active Object Group, Type, and Asynchrony are crucial for Cpt. and GRID 26

Broadcast and Scatter Broadcast is the default behavior Use a group as parameter, Scattered depends on rankings cg ag JVM s c 1 c 2 c 3 c 3 JVM ag. bar(cg); // broadcast cg Pro. Active. set. Scatter. Group(cg); ag. bar(cg); // scatter cg JVM 27 Denis Caromel 27

Dynamic Dispatch Group Slowest cg ag c 0 c 2 c 1 c 4 c 3 c 6 c 5 c 8 c 7 JVM c 9 Fastest JVM c 0 c 2 c 1 JVM 28 Denis Caromel c 3 c 4 c 6 c 5 c 8 c 7 c 9 ag. bar(cg); JVM 28

Pro. Active Parallel Suite 29 Denis Caromel

Pro. Active Parallel Suite 30 Denis Caromel

3. Mobile Agents 31 Denis Caromel 31

Pro. Active : Migration of active objects Migration is initiated by the active object itself through a primitive: migrate. To Can be initiated from outside through any public method The active object migrates with: • all pending requests • all its passive objects • all its future objects Automatic and transparent forwarding of: • requests (remote references remain valid) • replies (its previous queries will be fullfilled) 32 Denis Caromel 32

Principles and optimizations Same semantics guaranteed (RDV, FIFO order point to point, asynchronous) Safe migration (no agent in the air!) Local references if possible when arriving within a VM Tensionning (removal of forwarder) 33 Denis Caromel 33

Principles and optimizations Same semantics guaranteed (RDV, FIFO order point to point, asynchronous) Safe migration (no agent in the air!) Local references if possible when arriving within a VM Tensionning (removal of forwarder) 34 Denis Caromel 34

Principles and optimizations Same semantics guaranteed (RDV, FIFO order point to point, asynchronous) Safe migration (no agent in the air!) Local references if possible when arriving within a VM Tensionning (removal of forwarder) direct 35 Denis Caromel 35

Principles and optimizations Same semantics guaranteed (RDV, FIFO order point to point, asynchronous) Safe migration (no agent in the air!) Local references if possible when arriving within a VM Tensionning (removal of forwarder) direct 36 Denis Caromel 36

Principles and optimizations Same semantics guaranteed (RDV, FIFO order point to point, asynchronous) Safe migration (no agent in the air!) Local references if possible when arriving within a VM Tensionning (removal of forwarder) direct forwarder direct 37 Denis Caromel 37

Principles and optimizations Same semantics guaranteed (RDV, FIFO order point to point, asynchronous) Safe migration (no agent in the air!) Local references if possible when arriving within a VM Tensionning (removal of forwarder) direct forwarder direct 38 Denis Caromel 38

Principles and optimizations Same semantics guaranteed (RDV, FIFO order point to point, asynchronous) Safe migration (no agent in the air!) Local references if possible when arriving within a VM Tensionning (removal of forwarder) direct forwarder direct 39 Denis Caromel 39

Principles and optimizations Same semantics guaranteed (RDV, FIFO order point to point, asynchronous) Safe migration (no agent in the air!) Local references if possible when arriving within a VM Tensionning (removal of forwarder) direct forwarder direct 40 Denis Caromel 40

Pro. Active : API for Mobile Agents Mobile agents (active objects) that communicate Basic primitive: migrate. To public static void migrate. To (String u) // string to specify the node (VM) public static void migrate. To (Object o) // joinning another active object public static void migrate. To (Node n) // Pro. Active node (VM) 41 Denis Caromel 41

Pro. Active : API for Mobile Agents Mobile agents (active objects) that communicate // A simple agent class Simple. Agent implements run. Active, Serializable { public Simple. Agent () {} public void move. To (String t){ // Move upon request Pro. Active. migrate. To (t); } public String where. Are. You (){ // Repplies to queries return (“I am at ” + Inet. Address. get. Local. Host ()); } public run. Activity (Body my. Body){ while (… not end of itinerary …){ res = my. Friend. what. Did. You. Find () // Query other agents … } my. Body. fifo. Policy(); // Serves request, potentially move. To } } 42 Denis Caromel 42

Pro. Active : API for Mobile Agents Mobile agents that communicate Primitive to automatically execute action upon migration public static void on. Arrival (String r) // Automatically executes the routine r upon arrival // in a new VM after migration public static void on. Departure (String r) // Automatically executes the routine r upon migration // to a new VM, guaranted safe arrival public static void before. Departure (String r) // Automatically executes the routine r before trying a migration // to a new VM 43 Denis Caromel 43

Pro. Active : API for Mobile Agents Itinerary abstraction Itinerary : VMs to visit specification of an itinerary as a list of (site, method) automatic migration from one to another dynamic itinerary management (start, pause, resume, stop, modification, …) API: my. Itinerary. add (“machine 1’’, “routine. X”); . . . itinerary. Set. Current, itinerary. Travel, itinerary. Stop, itinerary. Resume, … Still communicating, serving requests: itinerary. Migration. First (); // Do all migration first, then services, Default behavior itinerary. Request. First (); // Serving the pending requests upon arrival before migrating again 44 Denis Caromel 44

Dynamic itineraries A Host 4 Migration A Host 4 A Home 45 Denis Caromel Migration foo A Host 1 Host 3 Migration A Host 2 45

4. Localization 46 Denis Caromel 46

Forwarders Migrating object leaves forwarder on current site Forwarder is linked to object on remote site Possibly the mobile object Possibly another forwarder => a forwarding chain is built When receiving message, forwarder sends it to next hop Upon successful communication, a tensioning takes place 47 Denis Caromel 47

Other Strategy: Centralized (location Server) Host A Server S : Source A : Agent reference S A Host B 48 Denis Caromel Host C Host D 48

Centralized Strategy (2) Host A Server S : Source A : Agent reference S Server Update Migration Host B A Host C Host D A migrating object updates the server 49 Denis Caromel 49

Centralized Strategy (3) Host A Server S : Source A : Agent reference S Failed Update Message Migration Host B Host C A Host D A migrating object updates the server 50 Denis Caromel 50

Centralized Strategy (4) Ask for a new Host A reference Server Request S Response S : Source A : Agent référence Message ! But the AO might have moved again in the meantime … just play again. A Host B Host C Host D The source get a new reference from the server 51 Denis Caromel 51

Location Server vs Forwarder Server No fault tolerance if single server Scaling is not straightforward Added work for the mobile object The agent can run away from messages Forwarders Use resources even if not needed The forwarding chain is not fault tolerant An agent can be lost What about performance? 52 Denis Caromel 52

Forwarder vs. Server LAN (100 Mb/s) Response time (ms) vs. Communication rate Server better on a LAN 1 53 Denis Caromel 2 3 4 5 6 7 8 9 10 11 53

Forwarder vs Server MAN (7 Mb/s) Response time (ms) vs. Communication rate Forwarders sometimes better on a MAN 1 54 Denis Caromel 2 3 4 5 6 7 8 9 10 11 54

Formal Performance Evaluation of Mobile Agents: Markov Chains Together with Fabrice Huet and Mistral Team Objectives: Formally study the performance of Mobile Agent localization mechanism Investigate various strategies (forwarder, server, etc. ) Define adaptative strategies Modeling: Frequency of: – Message from source – Agent migration Time for: – Message transmission – Agent migration 55 Denis Caromel 55

Modeling of Forwarder Strategy No message One In-transit message 56 Denis Caromel 56

Modeling of Server Strategy 57 Denis Caromel 57

TTL-TTU mixed parameterized protocol TTL: Time To Live + Updating Forwarder: 5 s. After TTL, a forwarder is subject to self destruction Before terminating, it updates server(s) with last agent known location TTU: Time To Update mobile AO: After TTU, AO will inform a localization server(s) of its current location Dual TTU: first of two events: max. Migration. Nb: the number of migrations without server update max. Time. On. Site: the time already spent on the current site 10 5 s. 58 Denis Caromel 58

TTL-TTU mixed parameterized protocol Host A Server S : Source A : Agent reference S A Host B 59 Denis Caromel Host C Host D 59

TTL-TTU mixed parameterized protocol Host A Server S : Source A : Agent reference S Server Update F TTL Host B 60 Denis Caromel Migration TTU A Host C Host D 60

5. IC 2 D Interactive Control & Debug for Distribution Eclipse GUI for the GRID 61 Denis Caromel

GUI in Pro. Active Parallel Suite 62 Denis Caromel

GUI in Pro. Active Parallel Suite 63 Denis Caromel

Programmer Interface for Monitoring Debugging Optimizing 64 Denis Caromel

65 Denis Caromel

IC 2 D 66 Denis Caromel

Video 1: IC 2 D Monitoring, Debugging, Optimizing 67 Denis Caromel

Ongoing Work: 3 D View in IC 2 D 68 Denis Caromel

6. Example of Pro. Active Applications 69 Denis Caromel

Load Balancing 70 Denis Caromel 70

Load Balancing using Mobility (1) 71 Denis Caromel 71

Load Balancing using Mobility (2) Deals with heterogeneous machines, applications, and network. 72 Denis Caromel 72

Artificial Life Generation Sylvain Cussat-Blanc, Yves Duthen – IRIT TOULOUSE 1 Application J+1 25 J+5 300 CPUs J+6 J+7 Developpement of artificial creatures Version Pro. Active 73 Initial Application 1 PC 56 h 52 => Crash! Pro. Active Version 300 CPUs 19 minutes Denis Caromel

Artificial Life Generation Sylvain Cussat-Blanc, Yves Duthen – IRIT TOULOUSE 74 Denis Caromel

JECS : 3 D Electromagnetism Radar Reflection on Planes 75 Denis Caromel

Code Coupling : Vibro Acoustic (courtesy of EADS) 76 Denis Caromel

P 2 P: AO Overlay Network 77 Denis Caromel

78 Denis Caromel

79 Denis Caromel

Summary 80 Denis Caromel

Concurrency + Mobility + Parallelism Multi-Cores + Distribution Multi-Core to Distributed 81 Denis Caromel

Conclusion: Why does it move ? Thanks to a few key features: Connection-less, RMI+JMS unified Messages rather than long-living interactions 82 Denis Caromel

Conclusion: Why does it Communicate and Behave ? Thanks to a few key features: Because it Scales: asynchrony ! Because it is Typed: RMI with interfaces ! First-Class Futures: No unstructured Call Backs and Ports 83 Denis Caromel

Conclusion on Mobile Active Objects = a good unit of Computational Mobility Weak Migration OK (even for Load Balancing) Both Actors and Servers Ensuring communications: several strategies to choose from: Location Server Forwarders Mixed: based on TTL-TTU Primitive + Higher-Level abstractions: migrate. To (location) on. Arrival, on. Departure Itinerary, etc. Application to Mobile Telecoms: DLP, NH Avatar (NHA), Shared Space for Session Management 84 Denis Caromel 84

Summary-Perspective: Mobility at the Core 85 Denis Caromel

Pro. Active/ GCM Specifications for Components Services SLA Qo. S Open the way to Soft. +Serv. EU Industry with Clouds & Utilities, DAAS Denis Caromel 86

87 Denis Caromel

Parallel, Distributed, Hierarchical 3. Components Composing 88 Denis Caromel 88

Objects to Distributed Components (1) Component. Identity Cpt = new. Active. Component (params); A a = Cpt …. get. Fc. Interface ("interface. Name"); V v = a. foo(param); Io. C: Inversion Of Control (set in XML) A Example of component instance V Truly Distributed Components Typed Group 89 Denis Caromel Java or Active Object JVM 89

GCM: Grid Component Model GCM Being defined in the No. E Core. GRID (42 institutions) Open Source Object. Web Pro. Active implements a preliminary version of GCM Service Oriented: NESSI relation The vision: GCM to be the IT Service GSM Grid. COMP takes: GCM as a first specification, Pro. Active as a starting point, and Open Source reference implementation. 90 Denis Caromel

Grid. COMP Partners 91 Denis Caromel

GCM Scopes and Objectives: Grid Codes that Compose and Deploy No programming, No Scripting, … No Pain Innovation: Abstract Deployment Multi. Cast Composite Components Multicast and Gather. Cast