Specification and Verification for distributed applications running on heterogeneous infrastructures E. Madelaine Oasis team INRIA -- CNRS - I3S -- Univ. of Nice Sophia-Antipolis ECNU Dept of Software Engineering October 2010 Eric MADELAINE ---- OASIS 1
Motivations … Specification and Verification for distributed applications Components Grids Interfaces Distributed Systems Clouds Services MultiCores Message passing Adaptation Self Healing Reconfiguration Load Balancing Self Optimizing Eric MADELAINE ---- OASIS 2
Motivations… (2) Components Grids Interfaces Clouds Distributed Systems Services MultiCores Message passing Adaptation Self Healing Reconfiguration Load Balancing Self Optimizing - Hard to program ? - Correct Behaviour ? - Correct Assembly ? Eric MADELAINE ---- OASIS 3
Do we need formal methods for developing component-based software ? A B ??? C A B C2 C Safe COTS-based development Safe management for complex => systems Behaviour Specifications (e.g. replacement at runtime) Eric MADELAINE ---- OASIS 4
Is it more difficult for distributed, asynchronous, evolving components ? Yes ! Asynchrony creates race-conditions, dead-locks, etc. Dynamicity creates new challenges: Correct (DYNAMIC) Adaptation, quiescent states, … Eric MADELAINE ---- OASIS 5
Motivations … (3) Heterogeneous Resources for Distributed Applications P2P LAN network Windows PacaGrid cluster CCS Cluster Cloud Cluster 47+ linux nodes 2-proc/4-core GPUs Mobile Storage terminals Server Eric MADELAINE ---- OASIS 6
Heterogeneous Resources for Distributed Applications P2P LAN - Heterogeneity: OS/processor/architecture/communications network - High performance / Dynamicity / Mobility / Safety / Security… Windows PacaGrid cluster = � ProActive = seamless programming, deployment, scheduling, and CCS Cluster execution middelware, strong semantic guaranties Cloud Cluster 47+ linux nodes The Challenge: 2-proc/4-core - Provide optimisations that depends on the underlying platform, and GPUs Mobile may evolve dynamically, while keeping simplicity and correctness Storage terminals Server Eric MADELAINE ---- OASIS 7
Agenda • Motivation • Building safe applications • Heterogeneous Infrastructures: Multi-Cores, P2P, Grids, Clouds • Context • Oasis team, ,MCorePhP collaborative project • Active Objects, Distributed Components • Safe Distributed Components • Behavioural Semantics • Model generation • Checking Properties • Specification and Verification Tools, Case Study • VerCors platform • Case-Study • Conclusion & Perspectives Eric MADELAINE ---- OASIS 8
The OASIS team: Propose fundamental principles, techniques and tools for design, development, analysis, and verification of reliable distributed systems ASP Calculus P Properties L A T F O ProActive R Model- M Components Checking S Challenges : � Guarantee safety and security for software systems � Develop and master future infrastructures of networks and services Eric MADELAINE ---- OASIS 9
MCorePhP: A collaborative project building the basis for safe programming of heterogeneous applications ANR (french ministry of research) International “Blanc” project. • Partners: University of Tsinghua, Beijing (Pr. Yongwei Wu) INRIA Oasis team (Pr. Denis Caromel, Dr. Eric Madelaine) • Research Tasks: Programming Model for Multi-Core Infrastructure with ChinaGrid and CGSP Application and User Case in Bioinformatics Eric MADELAINE ---- OASIS 10
MCorePhP: Task 1: Programming Model for Multi-Core 1.1 New Basic Programming Model for Multi-Core Extensions of the Active Object programming model: - Sharing memory (efficiently) between activities - Multi-active (multi-threaded) activities 1.2 Legacy Support and Integration 1.3 Safe Code Generation: From model-level specification and analysis of properties, to “correct by construction” executable code. This presentation 1.4 Monitoring Eric MADELAINE ---- OASIS 11
Asynchronous and Deterministic Objects [Denis Caromel – Ludovic Henrio] ASP (Asynchronous Sequential Processes) = • Distributed Active Objects • Asynchronous method calls • Futures and Wait-by-necessity Determinism/Confluence properties Programming abstractions Formal Basis for Verification Eric MADELAINE ---- OASIS 12
Active Objects (very short…) - Runnable (mono-threaded) objects - Communicating by remote method call - Asynchronous computation - Request queues (user-definable policy) - No shared memory Server obj. Client obj. - Futures B A Eric MADELAINE ---- OASIS 13
ProActive Parallel Suite Public domain library Object Web Consortium Spin-off company 2007 : Eric MADELAINE ---- OASIS 14
Fractal hierarchical model : Attribute Lifecycle Binding Content Controller Controller Controller Controller • Provided/Required Controller / membrane Interfaces • Hierarchy • Separation of concern: functional / non-functional • ADL • Extensible Content composites encapsulate primitives, which encapsulates code Eric MADELAINE ---- OASIS 15
Grid Component Model (GCM): Grid aware extension to Fractal Targetting GRIDS requires to handle: • Scalability => hierarchy, parallelism • Volatility, heterogeneity => adaptation, dynamicity, autonomicity… Collective interfaces • Multicast, gathercast, gather-multicast, MxN parallel communications Opportunity to use GCM for parallel computing Component non-functional concerns (membrane) as a Fractal system • Controllers as objects or Fractal/GCM components • Fractal extension for properly exposing the non-functional part, including non- functional client interfaces • Non-functional ADL and associated APIs Opportunity to use GCM for autonomic computing Eric MADELAINE ---- OASIS 16
GCM Scopes and Objectives: Grid Codes that Compose and Deploy MultiCast GatherCast MultiCast GatherCast No programming, No Scripting, … No Pain Eric MADELAINE ---- OASIS
Opportunity to use GCM for autonomic computing Dynamic to Autonomic component based system reconfiguration • Architecture of GCM membranes • How to plug autonomous strategies to drive all non- functional concerns EU BIONETS IP project, P. Naoumenko BDO PACA ½ funded PhD: • A GCM-based framework for autonomic and evolvable service compositions along bio-inspired strategies • Distributed and reconfigurable service compositions Eric MADELAINE ---- OASIS 18
Agenda • Motivation • Building safe applications • Heterogeneous Infrastructures: Multi-Cores, P2P, Grids, Clouds • Context • MCorePhP collaborative project • Active Objects, Distributed Components • Safe Distributed Components • Behavioural Semantics • Model generation • Checking Properties • Specification and Verification Tools, Case Study • VerCors platform • Case-Study • Conclusion & Perspectives Eric MADELAINE ---- OASIS 19
Behaviour specification and Safe composition Aim : Build reliable components from the composition of smaller pieces, using their formal specification. Component paradigm : only observe activity at interfaces. Behavioural properties: Deadlock freeness, progress/termination, safety and liveness. Applications : • Check behavioural compatibility between sub-components • Check correctness of component deployment • Check correctness of the transformation inside a running application. Eric MADELAINE ---- OASIS 20
pNets : Hierarchical and Parameterized LTSs [Arnold, Nivat 92] Synchronization networks [Lin 92] symbolic graphs with assignments [Lakas 96] semantics of Lotos open expressions • Value-passing, Dynamic architectures, etc. • But close to code structure • Instantiation to finite structures (through abstract interpretation) [Forte’04: T. Barros, R. Boulifa, E. Madelaine] [Annals of Telecomunications’08: T. Barros, A. Cansado, L. Henrio, E. Madelaine ] Eric MADELAINE ---- OASIS 21
pNets : generalized parallel operator PhiloNET Fork[k] Philo[k] TakeL Take Think TakeR Eat DropR Drop DropL PhiloNET : < Philo[k], Fork[k] > k ∈ [1:n] A g = { Think(k), TakeL(k), … } with synchronisation vectors : <Think(k), Think Philo[k] > <TakeL(k), TakeL Philo[k] , Take Fork[k-1] > Eric MADELAINE ---- OASIS Eric MADELAINE 22 22
Building Behavioural Models : Principles For a given language/framework, define an operational semantics that builds pNets from the program structure. For Fractal or GCM components: • Reason separately at each composition level Primitive components : functional behaviour is known • Given by the user (specification language) • Obtained by static analysis (primitive components, e.g. ProActive active objects) Composites : • Computed from lower level • Structure and NF behaviour automatically added from the component’s ADL Eric MADELAINE ---- OASIS 23
Recommend
More recommend
