Mastère RSD - TC4 2005/20061 Distributed JAVA Aims and Principles The ProActive library Models of behaviours Generation of finite (parameterized) models.

Slides:



Advertisements
Similar presentations
Elton Mathias and Jean Michael Legait 1 Elton Mathias, Jean Michael Legait, Denis Caromel, et al. OASIS Team INRIA -- CNRS - I3S -- Univ. of Nice Sophia-Antipolis,
Advertisements

COS 461 Fall 1997 Network Objects u first good implementation: DEC SRC Network Objects for Modula-3 u recent implementation: Java RMI (Remote Method Invocation)
Programming Languages and Paradigms
PROTOCOL VERIFICATION & PROTOCOL VALIDATION. Protocol Verification Communication Protocols should be checked for correctness, robustness and performance,
Concurrency Important and difficult (Ada slides copied from Ed Schonberg)
European Commission Directorate-General Information Society Unit F2 – Grid Technologies INSERT PROJECT ACRONYM HERE BY EDITING THE MASTER SLIDE (VIEW.
©2009 Operačné systémy Procesy. 3.2 ©2009 Operačné systémy Process in Memory.
Denis Caromel1 Joint work with Ludovic Henrio – Eric Madelaine et. OASIS members OASIS Team INRIA -- CNRS - I3S – Univ. of Nice Sophia-Antipolis, IUF.
Fabrice Huet Mobility of Active Objects Fabrice Huet INRIA-I3S-CNRS.
Eric MADELAINE1 E. Madelaine, Antonio Cansado, Emil Salageanu OASIS Team, INRIA -- CNRS - I3S -- Univ. of Nice Sophia-Antipolis OSCAR meeting, Valparaiso,
1 Ludovic Henrio Paris, An Open Source Middleware for the Grid Programming Wrapping Composing Deploying.
Introduction in algorithms and applications Introduction in algorithms and applications Parallel machines and architectures Parallel machines and architectures.
Remote Method Invocation Chin-Chih Chang. Java Remote Object Invocation In Java, the object is serialized before being passed as a parameter to an RMI.
1/30/2004CSCI 315 Operating Systems Design1 Processes Notice: The slides for this lecture have been largely based on those accompanying the textbook Operating.
02/02/2004CSCI 315 Operating Systems Design1 Interprocesses Communication Notice: The slides for this lecture have been largely based on those accompanying.
Communication in Distributed Systems –Part 2
02/01/2010CSCI 315 Operating Systems Design1 Interprocess Communication Notice: The slides for this lecture have been largely based on those accompanying.
1/26/2007CSCI 315 Operating Systems Design1 Processes Notice: The slides for this lecture have been largely based on those accompanying the textbook Operating.
Concurrency - 1 Tasking Concurrent Programming Declaration, creation, activation, termination Synchronization and communication Time and delays conditional.
1 Threads Chapter 4 Reading: 4.1,4.4, Process Characteristics l Unit of resource ownership - process is allocated: n a virtual address space to.
System/Software Testing
INRIA Sophia-Antipolis, Oasis team INRIA Rhône-Alpes, Vasy team Feria–IRIT/LAAS, SVF team Toulouse GET - ENST Paris, LTCI team FIACRE Models and Tools.
Oct Multi-threaded Active Objects Ludovic Henrio, Fabrice Huet, Zsolt Istvàn June 2013 –
Programming in Java Unit 2. Class and variable declaration A class is best thought of as a template from which objects are created. You can create many.
1 Update Strategies for First Class Futures Khan Muhammad, Ludovic Henrio INRIA, Univ. Nice Sophia Antipolis,CNRS.
Formalism and Platform for Autonomous Distributed Components Bio-inspired Networks and Services A Distributed Component Model Formalisation in Isabelle.
Eric Madelaine FORTE ’04 -- Madrid sept /25 Parameterized Models for Distributed Java Objects Eric Madelaine work with Tomás Barros, Rabéa Boulifa.
Eric MadelaineOSMOSE -- WP2 -- Prague June 2004 Models for the Verification of Distributed Java Objects Eric Madelaine work with Tomás Barros, Rabéa Boulifa,
Denis Caromel1 Troisieme partie Cours EJC 2003, AUSSOIS, Denis Caromel OASIS Team INRIA -- CNRS - I3S -- Univ. of Nice Sophia-Antipolis.
Spring/2002 Distributed Software Engineering C:\unocourses\4350\slides\DefiningThreads 1 RMI.
ABSTRACT The real world is concurrent. Several things may happen at the same time. Computer systems must increasingly contend with concurrent applications.
Eric MADELAINE1 T. Barros, L. Henrio, E. Madelaine OASIS Team, INRIA -- CNRS - I3S -- Univ. of Nice Sophia-Antipolis (FACS’05), Fractal workshop, Grenoble.
1 Lecture 5 (part2) : “Interprocess communication” n reasons for process cooperation n types of message passing n direct and indirect message passing n.
3.1 Silberschatz, Galvin and Gagne ©2013 Operating System Concepts Essentials – 9 th Edition Interprocess Communication Processes within a system may be.
1 Qualitative Reasoning of Distributed Object Design Nima Kaveh & Wolfgang Emmerich Software Systems Engineering Dept. Computer Science University College.
1 Romain Quilici ObjectWeb Architecture meeting July 2nd 2003 ProActive Architecture of an Open Middleware for the Grid.
Denis Caromel1 Institut universitaire de France (IUF) INRIA Sophia-Antipolis – CNRS – I3S – Université de Nice Luis Mateu DCC – Universidad de Chile Eric.
Emil Salageanu ProActive Parallel Suite ActiveEon March 2008 ActiveEon Hands On Programming.
Grid programming with components: an advanced COMPonent platform for an effective invisible grid © GridCOMP Grids Programming with components.
Information System Design (IT60105) Lecture 26 Object-Oriented System Testing.
1. 2 Objects to Distributed Components (1) Typed Group Java or Active Object ComponentIdentity Cpt = newActiveComponent (params); A a = Cpt ….getFcInterface.
ICS 313: Programming Language Theory Chapter 13: Concurrency.
Denis Caromel 1 Denis Caromel, et al. OASIS Team INRIA -- CNRS - I3S -- Univ. of Nice Sophia-Antipolis, IUF Strong Programming.
Mastère RSD - TC4 2005/20061 Distributed Components –ProActive-Fractal : main concepts –Behaviour models for components –Deployment, management, transformations.
Parameterized Models for Distributed Java Objects Tomás Barros & Rabéa Boulifa OASIS Project INRIA Sophia Antipolis April 2004.
Server-Side Java Mapping Copyright © ZeroC, Inc. Ice Programming with Java 6. Server-Side Java Mapping.
ProActive components and legacy code Matthieu MOREL.
Eric MadelaineOSCAR Workshop -- Santiago Nov Verification of Distributed Applications Eric Madelaine work with Isabelle Attali, Tomás Barros, Rabéa.
Parameterized models for distributed objects Eric Madelaine, Rabéa Boulifa, Tomás Barros OASIS INRIA Sophia-Antipolis, I3S, UNSA
 In the java programming language, a keyword is one of 50 reserved words which have a predefined meaning in the language; because of this,
A visualisation and debugging tool for multi-active objects Ludovic Henrio, Justine Rochas LAMHA, Nov 2015.
Transparent First-class Futures and Distributed Components Introduction: components, futures, and challenges Statically Representing Futures An Example.
Denis Caromel1 Denis Caromel, et al. OASIS Team INRIA -- CNRS - I3S -- Univ. of Nice Sophia-Antipolis, IUF October
Eric MADELAINE ---- OASIS1 E. Madelaine Oasis team INRIA -- CNRS - I3S -- Univ. of Nice Sophia-Antipolis RESECO ’08 Santiago – Nov. 24, 2008 Specification.
Eric MADELAINE1 A. Cansado, L. Henrio, E. Madelaine OASIS Team, INRIA -- CNRS - I3S -- Univ. of Nice Sophia-Antipolis Fractal workshop, Nantes, 3 july.
RESECO - Montevideo - 22 nov 2007Reseco, Montevideo, 22 nov 2007 Eric Madelaine - OASIS Team1 Specifying and Generating Safe GCM Components INRIA – Sophia.
 Process Concept  Process Scheduling  Operations on Processes  Cooperating Processes  Interprocess Communication  Communication in Client-Server.
Tomás BarrosMonday, April 18, 2005FIACRE Toulouse p. 1 Behavioural Models for Hierarchical Components Tomás Barros, Ludovic Henrio and Eric Madelaine.
Distributed Components and Futures: Models and Challenges A Distributed Component Model Distributed Reconfiguration Calculi for Components and Futures.
A Theory of Distributed Objects Toward a Foundation for Component Grid Platforms Ludovic HENRIO l A Theory of Distributed Objects l Components l Perspectives.
Eric MADELAINE1 T. Barros, L. Henrio, E. Madelaine OASIS Team, INRIA -- CNRS - I3S -- Univ. of Nice Sophia-Antipolis DCC, University.
1 Romain Quilici OASIS Team INRIA -- CNRS - I3S -- Univ. of Nice Sophia-Antipolis, IUF July 2nd 2003 ProActive Architecture.
2. CALCULUS: A S P. A Theory of Distributed Objects D. Caromel, L. Henrio, Springer 2005, Monograph A Calculus: ASP: Asynchronous Sequential Processes.
Model Generation for Distributed Java Programs Rabéa Boulifa Eric Madelaine Oasis Team INRIA, Sophia-Antipolis France, I3S, UNSA Luxembourg, November 28,
Eric MADELAINE1 T. Barros, L. Henrio, E. Madelaine OASIS Team, INRIA -- CNRS - I3S -- Univ. of Nice Sophia-Antipolis (FACS’05), Fractal workshop, Grenoble.
ASYNCHRONOUS AND DETERMINISTIC OBJECTS ASP: Asynchronous Sequential Processes l Distributed objects l Asynchronous method calls l Futures and Wait-by-necessity.
Behavioural Models for Distributed Hierarchical Components
Formal Specification and Verification of Distributed Component Systems
Semantic Formalisms 3: Distributed Applications
ProActive Architecture of an Open Middleware for the Grid
Presentation transcript:

Mastère RSD - TC4 2005/20061 Distributed JAVA Aims and Principles The ProActive library Models of behaviours Generation of finite (parameterized) models Eric Madelaine INRIA Sophia-Antipolis, Oasis team

Mastère RSD - TC4 2005/20062 Distributed JAVA : ProActive Aims: Ease the development of distributed applications, with mobility and security features. Distributed = Network + many machines (Grids, WANs, LANs, P2P, PDAs,...) Library for distributed JAVA active objects –Communication : Asynchronous remote methods calls Non blocking futures (return values) –Control : Explicit programming of object activities Transparent distribution / migration

Mastère RSD - TC4 2005/20063 ProActive PDC Most of the time, activities and distribution are not known at the beginning, and change over time Seamless implies reuse, smooth and incremental transitions SequentialMultithreadedDistributed Seamless

Mastère RSD - TC4 2005/20064 ProActive : model Active objects : coarse-grained structuring entities (subsystems) Each active object: - possibly owns many passive objects - has exactly one thread. No shared passive objects -- Parameters are passed by deep-copy Asynchronous Communication between active objects Future objects and wait-by-necessity. Full control to serve incoming requests

Mastère RSD - TC4 2005/20065 Call between Objects b->foo(x) ba x Copy

Mastère RSD - TC4 2005/20066 ProActive : Active object 3 Proxy Body Object Active object Objet Standard object An active object is composed of several objects : The object itself (1) The body: handles synchronization and the service of requests (2) The queue of pending requests (3) 2 1 1

Mastère RSD - TC4 2005/20067 An object created with A a = new A (obj, 7); can be turned into an active and remote object: –Instantiation-based: A a = (A)newActive(«A», params, node); The most general case. –Class-based: a static method as a factory To get a non-FIFO behavior : class pA extends A implements RunActive { … } –Object-based: A a = new A (obj, 7);... a = (A)turnActive (a, node); ProActive : Creating active objects

Mastère RSD - TC4 2005/20068 ProActive : Reuse and seamless Polymorphism between standard and active objects –Type compatibility for classes (and not only interfaces) –Needed and done for the future objects also –Dynamic mechanism (dynamically achieved if needed) Wait-by-necessity: inter-object synchronization –Systematic, implicit and transparent futures Ease the programming of synchronizations, and the reuse of routines "A" "pA" a p_a foo (A a) { a.g (...); v = a.f (...);... v.bar (...); }

Mastère RSD - TC4 2005/20069 ProActive : Reuse and seamless Polymorphism between standard and active objects –Type compatibility for classes (and not only interfaces) –Needed and done for the future objects also –Dynamic mechanism (dynamically achieved if needed) Wait-by-necessity: inter-object synchronization –Systematic, implicit and transparent futures Ease the programming of synchronizations, and the reuse of routines "A" "pA" a p_a foo (A a) { a.g (...); v = a.f (...);... v.bar (...); } O.foo(a) : a.g() and a.f() are « local » O.foo(p_a): a.g() and a.f()are «remote + Async.»

Mastère RSD - TC4 2005/ ProActive : Intra-object synchronization Explicit control: Library of service routines: –Non-blocking services,... serveOldest (); serveOldest (f); –Blocking services, timed, etc. serveOldestBl (); serveOldestTm (ms); –Waiting primitives waitARequest(); etc. class BoundedBuffer extends FixedBuffer implements Active { void runActivity (Body myBody) { while (...) { if (this.isFull()) myBody.serveOldest("get"); else if (this.isEmpty()) myBody.serveOldest ("put"); else myBody.serveOldest (); // Non-active wait myBody.waitARequest (); }}} Implicit (declarative) control: library classes e.g. : myBody.forbid ("put", "isFull");

Mastère RSD - TC4 2005/ Example: Dining Philosophers Very classical toy example for distributed system analysis: Both Philosophers and Forks are here implemented as distributed active objects, synchronised by ProActive messages (remote method calls).

Mastère RSD - TC4 2005/ public class Philosopher implements Active { protected int id; protected int rightForkIndex; protected int State; protected Forks Fork[]; public Philosopher (int id, Forks forks[]) { this.id = id; this.Fork=forks; this.State=0; if (id + 1 ==5) rightForkIndex = 0; else rightForkIndex = id + 1; }../.. Philosopher.java

Mastère RSD - TC4 2005/ public void runActivity (Body myBody) { while (true) { switch (State) { case 0: think(); break; case 1: getForks(); break; case 2: eat(); break; case 3: putForks(); break; } } public void getForks() { ProActive.waitFor(Fork[rightForkIndex].take()); ProActive.waitFor(Fork[leftForkIndex].take()); State=2; }../.. Philosopher.java (cont.)

Mastère RSD - TC4 2005/ public class Forks implements Active { protected int id; protected boolean FreeFork; protected int State; public void ProActive. runActivity(Body myBody){ while(true){ switch (State){ case 0: myBody.getService().serveOldestWithoutBlocking("take"); break; case 1:myBody.getService().serveOldestWithoutBlocking("leave"); break; }}}../.. Fork.java

Mastère RSD - TC4 2005/ // Creates the fork active objects Fks= new Forks[5]; Params = new Object[1];// holds the fork ID for (int n = 0; n < 5; n++) { Params[0] = new Integer(n);// parameters are Objects try { if (url == null) Fks[n] = (Forks) newActive (“Fork”, Params, null); else Fks[n] = (Forks) newActive (“Fork”, Params, NodeFactory.getNode(url)); } catch (Exception e) { e.printStackTrace(); }}../.. Philosophers.java : initialization

Mastère RSD - TC4 2005/ Distributed JAVA Aims and Principles The ProActive library Models of behaviours Generation of finite (parameterized) models Eric Madelaine INRIA Sophia-Antipolis, Oasis team

Mastère RSD - TC4 2005/ Principles (1) Objectives: Behavioural model (Labelled Transition Systems), built in a compositional (structural) manner : One LTS per active object. Synchronisation based on ProActive semantics Usable for Model-checking => finite / small Java / ProActive code Abstract ProActive code Network of Parameterized LTSs Network of finite LTSs Data abstraction Behavioural semantics Finite instanciation

Mastère RSD - TC4 2005/ Principles (2) Define a behavioural model : networks of parameterized LTSs Implement using : abstraction of source code (slicing, data abstraction), analysis of method call graphs. Build parameterized models, then instantiate to obtain a finite structure. Build compositional models, use minimisation by bisimulation. Use equivalence-checker to prove equivalence of a component with its specification, model-checker to prove satisfiability of temporal logic formulas.

Mastère RSD - TC4 2005/ Communication model Active objects communicate through by Remote Method Invocation (requests, responses). Each active object: has a Request queue (always accepting incoming requests) has a body specifying its behaviour (local state and computation, service of requests, submission of requests) manages the « wait by necessity » of responses (futures)

Mastère RSD - TC4 2005/ A Remote requests Proxy Java Object A ag = newActive (“A”, […], VirtualNode) V v1 = ag.foo (param); V v2 = ag.bar (param);... v1.bar(); //Wait-By-Necessity V Wait-By-Necessity is a Dataflow Synchronization A Active Object Future Object Request Req. Queue Thread v1 v2 ag WBN!

Mastère RSD - TC4 2005/ Serv_Q(A) request served (executed and removed) response received Serv_Q(A) Method Calls : informal modelisation method call Local objectRemote object request arriving in the queue !ro.Q_m(f,args) ?Q_m(f,args) !lo.R_m(f,val) ?R_m(f,val) !ro.Q_m(f,args) ?Q_m(f,args) !lo.R_m(f,val) response received ?R_m(f,val)

Mastère RSD - TC4 2005/ Example (cont.) Philo Fork !ReqTake D !ReqTake G ?RepTake D ?RepTake G !ReqDrop D !ReqDrop G ?ReqTake !RepTake?ReqDrop (1) Build the network topology: Static code analysis for identification of: ProActive API primitives References to remote objects Variables carrying future values public void runActivity (Body myBody) { while (true) { switch (State) { case 0: think(); break; case 1: getForks(); break; case 2: eat(); break; case 3: putForks(); break; } } public void getForks() { ProActive.waitFor(Fork[rightForkIndex].take()); ProActive.waitFor(Fork[leftForkIndex].take()); State=2; }

Mastère RSD - TC4 2005/ Example (cont.) Philo(n) Fork(m) !F(n+1).Q_Take(f_i) ?R_Take(f_i) !F(n+1).Q_Drop() ?Q_Take(f_i) !P(m).R_Take(f_i) ?Q_Drop() Or better : using parameterized networks and actions: !F(n).Q_Take(f_j) ?R_Take(f_j) !F(n).Q_Drop() Eat(n)

Mastère RSD - TC4 2005/ public class Philosopher implements Active { protected int id; … public void runActivity (Body myBody) { while (true) { switch (State) { case 0: think(); break; case 1: getForks(); break; case 2: eat(); break; case 3: putForks(); break; } } public void getForks() { ProActive.waitFor(Fork[rightForkIndex].take()); ProActive.waitFor(Fork[leftForkIndex].take()); State=2; }../.. Exercice: Draw the (body) Behaviour of a philosopher, using a parameterized LTS

Mastère RSD - TC4 2005/ Exercice: Same exercice for the Fork !

Mastère RSD - TC4 2005/ Server Side : models for the queues General case : – Infinite structure (unbounded queue) – In practice the implementation uses bounded data structures – Approximation : (small) bounded queues – Operations : Add, Remove, Choose (filter on method name and args) Generic Queue model Optimisation : – Most programs filter on method names : partition the queue. – Use specific properties to find a bound to the queue length

Mastère RSD - TC4 2005/ Example (cont.) Fork: A queue for Take requests Fork: body LTSs public void ProActive. runActivity(Body myBody){ while(true){ switch (State){ case 0: myBody.getService().serveOldestWithoutBlocking("take"); break; case 1: myBody.getService().serveOldestWithoutBlocking(“drop"); break; }}}

Mastère RSD - TC4 2005/ Active object model: Full structure Body Proxy Queue !A2.Q_m(args) !A2.Q_m(f,args) A1 A2 Serve_m (f,args) !f.R_m(val) Use_m(val)

Mastère RSD - TC4 2005/ Verification : Properties 1) Deadlock – it is well-known that this system can deadlock. How do the tools express the deadlock property ? – Trace of actions : sequence of (visible) transitions of the global system, from the initial state to the deadlock state. Decomposition of the actions (and states) on the components. – Correction of the philosopher problem: Left as an exercise.

Mastère RSD - TC4 2005/ Next courses 3) Distributed Components –Fractive : main concepts –Black-box reasoning –Deployment, management, transformations www-sop.inria.fr/oasis/Eric.Madelaine/Teaching