SlideShare una empresa de Scribd logo

PhD Defense slides

•
•
Kiev Gama
Kiev Gama

The document summarizes a PhD thesis defense presented by Kiev Santos da Gama at the Université de Grenoble on October 6, 2011. The thesis addresses providing flexible mechanisms for executing untrustworthy components in a dynamic environment while minimizing risks to applications. It proposes dynamic isolation of components using isolation containers and runtime reconfigurable policies, as well as self-healing containers that provide continuous monitoring and automatic recovery from faults. The goal is to develop more dependable dynamic component-based applications that can still function despite failures through minimizing the impact of untrustworthy components.

TecnologíaEducación
1 de 78
Descargar para leer sin conexión
Towards Dependable Dynamic Component-Based Applications Kiev SANTOS DA GAMA Laboratoire d’Informatique de Grenoble Université de Grenoble Thèse soutenue publiquement le 6 Octobre 2011, devant le jury: Mme Claudia RONCANCIO Professeur, Ensimag - Grenoble INP, Président M Gilles MULLER Directeur de Recherche, INRIA, Rapporteur M Lionel SEINTURIER Professeur, Institut Univ. de France & Univ. de Lille, Rapporteur M Ivica CRNKOVIC Professor, Mälardalen University, Examinateur M Gaël THOMAS Maître de Conférences, Univ. Pierre et Marie Curie, Examinateur M Didier DONSEZ Professeur, Université Joseph Fourier, Directeur M Peter KRIENS Technical Director, OSGi Alliance, Invité
Extensible Applications Different elements (components) easily pluggable into the application exte nsions 6 000+ at firefox .org 06 October 2011 PhD Defense Kiev Gama 2
Components from Many Sources 06 October 2011 PhD Defense Kiev Gama 3
Components from Many Sources Crash 06 October 2011 PhD Defense Kiev Gama 4
Whose fault is it? Who is liable? User/Administrator? Plugin Provider? Platform (i.e. the browser)? What can be done about it? Should the whole application pay the price for someone else’s fault? 06 October 2011 PhD Defense Kiev Gama 5
“A chain is as strong as its “A component system is only as weakest link” strong as its weakest component” [Szyperski 2002] 06 October 2011 PhD Defense Kiev Gama 6
Main Question How to provide a flexible mechanism for untrustworthy components execution minimizing risks to the application? 06 October 2011 PhD Defense Kiev Gama 7
Back to the browsers: Isolation Trend Fault is contained. Browser remains intact 06 October 2011 PhD Defense Kiev Gama 8
Limitations No automatic recovery of faulty plugin No monitoring for diagnosing and fault avoidance OK for browsers. What about other contexts? 06 October 2011 PhD Defense Kiev Gama 9
Critical Applications Availability 99% Unavailability = losses (money, data, lives) Business-Critical: Banking eCommerce Non-stop systems Dynamic reconfigurations needed at runtime with minimal system disruption 06 October 2011 PhD Defense Kiev Gama 10
Dynamic Reconfiguration Potential source of faults Parts Repository (plugins, components, elements, etc) System 06 October 2011 PhD Defense Kiev Gama 11
Main Question How to provide a flexible mechanism for untrustworthy components execution minimizing risks to the application in a dynamic environment? 06 October 2011 PhD Defense Kiev Gama 12
STATE OF THE ART OBJECTIVES AND PROPOSITIONS IMPLEMENTATION VALIDATION CONCLUSIONS AND PERSPECTIVES 06 October 2011 PhD Defense Kiev Gama 13
STATE OF THE ART I. COMPONENTS II. DEPENDABILITY III. ISOLATION 06 October 2011 PhD Defense Kiev Gama 14
Components Software Component Component Platform Component Quality 06 October 2011 PhD Defense Kiev Gama 15
Software Component “A component is a static abstraction with plugs” [Nierstrasz 1995] “A software component is a unit of composition with contractually specified interfaces and explicit context dependencies only. A software component can be deployed independently and is subject to composition by third parties.” [Szyperski 2002] 06 October 2011 PhD Defense Kiev Gama 16
Component Platform “A platform is the substrate that allows for installation of components … such that these can be instantiated and activated.” [Szyperski 2002] 06 October 2011 PhD Defense Kiev Gama 17
Component Quality “ilities” (reliability, maintainability, usability, etc) Quality attributes difficult to evaluate Sometimes Subjective May involve many subcharacteristics Combined components ≠ Combined attributes Hard to predict or test all possible compositions Worse in dynamic platforms Need to execute untrustworthy components but still ensuring system dependability 06 October 2011 PhD Defense Kiev Gama 18
STATE OF THE ART I. COMPONENTS II. DEPENDABILITY III. ISOLATION 06 October 2011 PhD Defense Kiev Gama 19
Dependability “the ability to avoid service failures that are more frequent and more severe than is acceptable” [Avizienis 2004] Dependability involves other attributes (e.g., availability, reliability, maintainability) Dependability in a changing environment: Resilience Ability to recover/adjust from changes 06 October 2011 PhD Defense Kiev Gama 20
Fault Tolerance Typically implemented through redundancy techniques Fault containment as a means to reduce fault impact 06 October 2011 PhD Defense Kiev Gama 21
Types of Fault •  Deterministic –  Programming errors •  Abnormal behavior (intentional or not) –  Reproducible bugs •  Non-deterministic It may happen with –  Race conditions trustworthy code –  Hardware origin •  Electric noise •  Bit flips •  Cosmic rays 06 October 2011 PhD Defense Kiev Gama 22
Recovery Mechanisms Recovery-oriented Self-healing Computing Recovery Autonomic Computing Resilient Systems 06 October 2011 PhD Defense Kiev Gama 23
STATE OF THE ART I. COMPONENTS II. DEPENDABILITY III. ISOLATION 06 October 2011 PhD Defense Kiev Gama 24
Isolation Means of protection from other users (Humans, Systems, Components) Avoiding Harms Destroyed/Modified data Privacy Data read without permission Degraded service Fault containment 06 October 2011 PhD Defense Kiev Gama 25
Isolation Techniques Hardware-enforced Process-based Process Process Virtualization Domain Domain Software-based Process Application-level domains Security Managers , Policy Process 06 October 2011 PhD Defense Kiev Gama 26
Techniques Summary Privacy Fault Containment Process-based P P Virtualization P P Security Managers P O Application-level Domains P P 06 October 2011 PhD Defense Kiev Gama 27
Component Isolation •  Component Object Model –  In-process –  Out-of-process server •  .NET Platform –  Application Domains –  Security managers •  Java –  Security managers –  Class loaders –  Isolates 06 October 2011 PhD Defense Kiev Gama 28
Component Isolation Summary Privacy Fault Containment COM (In-process) P O COM (out-of-process) P P .NET Application Domains P P .NET Security Managers P O Java Security Managers P O Java Class loaders P O Java Isolates P P 06 October 2011 PhD Defense Kiev Gama 29
Limitations of Studied Approaches as Dependable Component Platforms Decision about isolation is made at design time Lack of fault monitoring mechanisms No automatic automatic recovery from faults 06 October 2011 PhD Defense Kiev Gama 30
STATE OF THE ART OBJECTIVES AND PROPOSITIONS IMPLEMENTATION VALIDATION CONCLUSIONS AND PERSPECTIVES 06 October 2011 PhD Defense Kiev Gama 31
Vision Still live with failure Minimize the impact of untrustworthy components More dependable dynamic component- based applications 06 October 2011 PhD Defense Kiev Gama 32
Objectives Flexible Isolation of Components Automatic Recovery from Faults 06 October 2011 PhD Defense Kiev Gama 33
Propositions Dynamic isolation of components I.  Component Isolation Containers II.  Runtime Reconfigurable Policy Self-healing Container I.  Continuous Monitoring II.  Automatic recovery 06 October 2011 PhD Defense Kiev Gama 34
Example Scenario Sensor Data Gathering Report Generator RFID Reader RFID Application 06 October 2011 PhD Defense Kiev Gama 35
PROPOSITIONS DYNAMIC ISOLATION OF COMPONENTS I. COMPONENT ISOLATION CONTAINERS II. RUNTIME RECONFIGURABLE POLICY SELF-HEALING CONTAINER I. CONTINUOUS MONITORING II. AUTOMATIC RECOVERY
Dynamic Isolation of Components I. Component Isolation Containers Component quarantine A “sandbox” approach Fault confinement II. Runtime Reconfigurable Policy Isolation at runtime (i.e. dynamic) Promotion of components 06 October 2011 PhD Defense Kiev Gama 37
Dynamic Isolation of Components I. Component Isolation Containers Communication Reader A Reader B Sensor X Sensor Y Data Gathering Report Generator 06 October 2011 PhD Defense Kiev Gama 38
Dynamic Isolation of Components The fault is contained Reader A Reader B Crash Sensor X Crash Sensor Y Data Gathering Report Generator 06 October 2011 PhD Defense Kiev Gama 39
Dynamic Isolation of Components II. Runtime Reconfigurable Policy New Reader Persistence Check Sensor X Sensor Y Reader A Reader B Data Gathering Report Generator 06 October 2011 PhD Defense Kiev Gama 40
Dynamic Isolation of Components II. Runtime Reconfigurable Policy Change Sensor X Sensor Y Reader A Reader B Apply changed policy Promoted component Data Gathering Report Generator 06 October 2011 PhD Defense Kiev Gama 41
How Many Sandboxes? N-sandboxes x One sandbox How to group components? Trustworthiness Different Levels Criteria Cohesion Same provider Similar functionality Coupling Dependencies Intensive communication 06 October 2011 PhD Defense Kiev Gama 42
PROPOSITIONS DYNAMIC ISOLATION OF COMPONENTS I. COMPONENT ISOLATION CONTAINERS II. RUNTIME RECONFIGURABLE POLICY SELF-HEALING CONTAINER I. CONTINUOUS MONITORING II. AUTOMATIC RECOVERY
Self-Healing Container I. Continuous monitoring Problem Diagnosis Observation for future promotion (quarantine period) II. Automatic Recovery Restablished execution 06 October 2011 PhD Defense Kiev Gama 44
Self-Healing Container I. Continuous Monitoring Reader A Reader B Sensor X Sensor Y Data Gathering Report Generator 06 October 2011 PhD Defense Kiev Gama 45
Self-Healing Container I. Continuous Monitoring Reader A Reader B Crash Crash Sensor X Sensor Y Data Gathering Report Generator 06 October 2011 PhD Defense Kiev Gama 46
Self-Healing Container II. Automatic Recovery Recovery Reader A Reader B Sensor X Sensor Y Data Gathering Report Generator 06 October 2011 PhD Defense Kiev Gama 47
Summary Propositions Dynamic Isolation of components I. Component isolation containers II. Runtime reconfigurable policy Self-healing container I. Continuous monitoring II. Automatic recovery Differences against other approaches Flexible isolation Self-healing isolation container 06 October 2011 PhD Defense Kiev Gama 48
STATE OF THE ART OBJECTIVES AND PROPOSITIONS IMPLEMENTATION VALIDATION CONCLUSIONS AND PERSPECTIVES 06 October 2011 PhD Defense Kiev Gama 49
IMPLEMENTATION COMPONENT ISOLATION I. TARGET COMPONENT PLATFORM II. ISOLATION APPROACH III. ISOLATION TECHNIQUES USED IV. RECONFIGURABLE POLICY SELF-HEALING SANDBOX I. AUTONOMIC MANAGER II. FAULT MODEL 06 October 2011 PhD Defense Kiev Gama 50
Target Component Platform (un)Installation of components at runtime Non-stop applications OSGi A module system for Java applications Used in industry and academia 06 October 2011 PhD Defense Kiev Gama 51
Isolation Approach Approach used for isolating components Two Component platforms: Trusted Trusted Platform Sandbox Platform Sandbox (Quarantine ) Replicated components (for type dependency purpose) Mutual exclusive states 06 October 2011 PhD Defense Kiev Gama 52
Isolation Approach: Mutual Exclusive States Trustworthy components are active execute on the trusted platform Untrustworthy components are active on the sandbox platform Fault Contained Environment Trusted Platform Sandbox Platform STARTED RESOLVED STARTED RESOLVED RESOLVED STARTED RESOLVED STARTED Bundle A Bundle B Bundle C Bundle D Bundle A Bundle B Bundle C Bundle D ? Actually two ? ? ? running platforms Main OSGi Sandbox OSGi Virtual Perspective STARTED STARTED STARTED STARTED Impression of having Bundle A Bundle B Bundle C Bundle D a single application Legend Trustworthy ? Untrustworthy OSGi 06 October 2011 PhD Defense Kiev Gama 53
Isolation Approach: Virtual Perspective Fault Contained Environment Trusted Platform Sandbox Platform STARTED RESOLVED STARTED RESOLVED RESOLVED STARTED RESOLVED STARTED Bundle A Bundle B Bundle C Bundle D Bundle A Bundle B Bundle C Bundle D ? Actually two ? ? ? running platforms Main OSGi Sandbox OSGi Virtual Perspective STARTED STARTED STARTED STARTED Impression of having Bundle A Bundle B Bundle C Bundle D a single application Legend Trustworthy ? Untrustworthy OSGi 06 October 2011 PhD Defense Kiev Gama 54
Isolation Techniques Used Domain-based (Java Isolates) strong isolation containers with fault containment Isolate Isolate Process (MVM) Process-based (Java Virtual Machine) Process Process (JVM) (JVM) 06 October 2011 PhD Defense Kiev Gama 55
Communication between Containers JVM Java Isolate Java Isolate (MVM) Bundle A Bundle B Bundle C Bundle D Bundle A Bundle B Bundle C Bundle D ? ? ? ? Communication via Main Sockets or Sandbox OSGi Link API OSGi (JSR-121) JVM JVM Bundle A Bundle B Bundle C Bundle D Bundle A Bundle B Bundle C Bundle D ? ? ? ? Communitation Main via Sandbox OSGi Sockets OSGi 06 October 2011 PhD Defense Kiev Gama 56
Reconfigurable Policy Isolation Policy Model 06 October 2011 PhD Defense Kiev Gama 57
IMPLEMENTATION COMPONENT ISOLATION I. TARGET COMPONENT PLATFORM II. ISOLATION APPROACH III. ISOLATION TECHNIQUES USED IV. RECONFIGURABLE POLICY SELF-HEALING SANDBOX I. AUTONOMIC MANAGER II. FAULT MODEL 06 October 2011 PhD Defense Kiev Gama 58
Self-healing Sandbox The sandbox with an automatic recovery mechanism An autonomic manager for the sandbox External application Control loop using a sense, analyze and react principle Fault detection and forecast Pragmatic approach based on a fault model 06 October 2011 PhD Defense Kiev Gama 59
Self-healing Sandbox Architecture Sandbox Platform use Trusted Platform Core use delegate delegate use use Core PlatformProxy Service PlatformProxy Registry use use delegate use delegate use use Monitoring EffectorMBean Isolation Service MBean Policy Eval. Registry delegate delegate use delegate HeartbeatProbe SensorProbe EffectorProbe Autonomic Manager delegate delegate delegate Monitor Policy Strategy Watchdog Evaluator Executor use use use use use use use use Script Knowledge Interpreter 06 October 2011 PhD Defense Kiev Gama 60
Self-healing Sandbox Control Loop Details Sys. Admin. Script Repository Autonomic Manager AP Policy Evaluator Monitor Analyze and Plan K Knowledge Execute M Watchdog Monitor E Strategy Executor Sensors Effectors 06 October 2011 Sandbox 61
Fault Model Hypotheses of faults General issues Resource Consumption (e.g. CPU, memory) Crashes (e.g., errors from wrapped native libraries) Specific dynamism mishandling issues Dangling objects (stale services) Excessive Faulty Thread CPU Resource Usage Behavior Allocation Denial of Crash Service Unresponsiveness Application Stale Service Memory Hang 06 October 2011 PhD Defense Kiev Gama 62
Separation of Concerns Dependability as crosscutting concerns Aspect-oriented Programming approach All dependability code in aspects Application code Aspect Weaver Aspects Woven code 06 October 2011 PhD Defense Kiev Gama 63
Implementation Summary Domain-based (Isolates) Process-based (Multiple JVMs) Dynamic Isolation of components I. Component isolation containers Propositions II. Runtime reconfigurable policy DSL Self-healing container I. Continuous monitoring II. Automatic recovery Autonomic Manager 06 October 2011 PhD Defense Kiev Gama 64
STATE OF THE ART OBJECTIVES AND PROPOSITIONS IMPLEMENTATION VALIDATION CONCLUSIONS AND PERSPECTIVES 06 October 2011 PhD Defense Kiev Gama 65
VALIDATION EXPERIMENTS USE CASE DOMAIN-BASED X PROCESS-BASED TEST PLATFORM SELF-HEALING CONTAINER VALIDATION 06 October 2011 PhD Defense Kiev Gama 66
Experiments Use Case Aspire RFID FP7 project RFID Network Non-stop servers collecting data Plug-and-play devices Native code for drivers puts stability in risk ONS Edge Edge RFID Readers + Sensors EPC IS EPC IS Premise Edge 06 October 2011 PhD Defense Kiev Gama 67
Experiments Use Case Sensor RFID Reader RFID Application ONS Edge Edge RFID Readers + Sensors EPC IS EPC IS Premise Edge 06 October 2011 PhD Defense Kiev Gama 68
Process-based x Domain-based Trusted Platform Sandbox Platform Criteria Memory footprint Isolate Isolate Application startup Sandbox reboot time MVM (Java 1.5) Trusted Platform Sandbox Platform JVM 1.5 JVM 1.5 Virtual Machines used Trusted Platform Sandbox Platform MVM (Java 1.5) Sun Oracle Hotspot JVM 1.5 Sun Oracle Hotspot JVM 1.6 JVM 1.6 JVM 1.6 06 October 2011 PhD Defense Kiev Gama 69
Results Single JVM (Domain-based) 90 Sandbox 80 Trusted platform 70 60 50 MB 40 Footprint of our solution using 30 process-based isolation is equivalent to domain-based isolation 20 10 0 MVM (2 Isolates) 2 x JVM 1.5 2 x JVM 1.6 Isolation Containers Application Startup Sandbox Crash Sandbox Reboot time (ms) detection time (ms) time (ms) MVM (Multi-Isolate) 3186 32 303 MVM 1.5 (Multi-JVM) JVM 1.5 3449 3945 697 660 3064 3047 Mean time to repair on sandbox is JVM 1.6 3859 658 2537 faster when using Isolates 06 October 2011 PhD Defense Kiev Gama 70
Generic Test Platform Fault deployment instead of fault injection –  Emulation of erroneous behavior based on our fault model –  Fault injection in the interface level does not represent actual application usage Management probes for triggering the faults JVM JVM RMI Connector Management and Monitoring Console MBeanServer (JConsole, VisualVM) Test Test Test Test Probe Probe Probe Probe Report Core Sensor Reader Reader Sensor X Sensor Y Generator Interfaces Aggregator Simulator A Simulator B Sandbox OSGi 06 October 2011 PhD Defense Kiev Gama 71
Self-healing Container Validation Fault detection –  Fault model Event causality –  Heuristic for events correlation –  Updates that trigger abnormal behavior –  Useful for finding faulty components Prediction of faults (e.g., Stale service retainers, Out of memory error) 06 October 2011 PhD Defense Kiev Gama 72
Results Correlation of events was possible Proper actions taken upon abnormal behavior 06 October 2011 PhD Defense Kiev Gama 73
STATE OF THE ART OBJECTIVES AND PROPOSITIONS IMPLEMENTATION VALIDATION CONCLUSIONS AND PERSPECTIVES 06 October 2011 PhD Defense Kiev Gama 74
Conclusions and Perspectives Dynamic Isolation of Components Component Isolation Containers (“sandboxes”) Runtime Reconfigurable Policy Self-healing Container Continuous Monitoring Automatic recovery 06 October 2011 PhD Defense Kiev Gama 75
Missing Characteristics Fine grained monitoring Automatic promotion of well-behaving components Automatic replacement of faulty components (e.g. taken from a repository) Open issue: How to automatically evaluate component trust ? 06 October 2011 PhD Defense Kiev Gama 76
Perspectives Resource monitoring at component level Automated Component Promotion Correlation of Historical Events Rating Component Trustworthiness Diversity of Isolation Environments Embedded Systems Cloud Computing 06 October 2011 PhD Defense Kiev Gama 77
[Thanks|Merci|Obrigado|Gracias] ?

Recomendados

CompatibleOne OpenStack Summit April11
CompatibleOne OpenStack Summit April11CompatibleOne OpenStack Summit April11
CompatibleOne OpenStack Summit April11CompatibleOne
 
CompatibleOne FISL Conference 2011 Brazil
CompatibleOne FISL Conference 2011 BrazilCompatibleOne FISL Conference 2011 Brazil
CompatibleOne FISL Conference 2011 BrazilCompatibleOne
 
Brian Simulator (a draft)
Brian Simulator (a draft)Brian Simulator (a draft)
Brian Simulator (a draft)Jimmy Lu
 
Systematic 6th Internal Convention, June 15, 2011, Paris
Systematic 6th Internal Convention, June 15, 2011, ParisSystematic 6th Internal Convention, June 15, 2011, Paris
Systematic 6th Internal Convention, June 15, 2011, ParisCompatibleOne
 
PhD defense
PhD defensePhD defense
PhD defenseJef Aernouts
 
Verteidigung
VerteidigungVerteidigung
VerteidigungHS Heilbronn
 
Thesis powerpoint
Thesis powerpointThesis powerpoint
Thesis powerpointMalissaHopeCollins
 
My Thesis Defense Presentation
My Thesis Defense PresentationMy Thesis Defense Presentation
My Thesis Defense PresentationDavid Onoue
 

Recomendados

CompatibleOne OpenStack Summit April11
CompatibleOne OpenStack Summit April11CompatibleOne OpenStack Summit April11
CompatibleOne OpenStack Summit April11CompatibleOne
 
CompatibleOne FISL Conference 2011 Brazil
CompatibleOne FISL Conference 2011 BrazilCompatibleOne FISL Conference 2011 Brazil
CompatibleOne FISL Conference 2011 BrazilCompatibleOne
 
Brian Simulator (a draft)
Brian Simulator (a draft)Brian Simulator (a draft)
Brian Simulator (a draft)Jimmy Lu
 
Systematic 6th Internal Convention, June 15, 2011, Paris
Systematic 6th Internal Convention, June 15, 2011, ParisSystematic 6th Internal Convention, June 15, 2011, Paris
Systematic 6th Internal Convention, June 15, 2011, ParisCompatibleOne
 
PhD defense
PhD defensePhD defense
PhD defenseJef Aernouts
 
Verteidigung
VerteidigungVerteidigung
VerteidigungHS Heilbronn
 
Thesis powerpoint
Thesis powerpointThesis powerpoint
Thesis powerpointMalissaHopeCollins
 
My Thesis Defense Presentation
My Thesis Defense PresentationMy Thesis Defense Presentation
My Thesis Defense PresentationDavid Onoue
 
Painel SBRC 2018 - Smart Cities: Tendências e Desafios
Painel SBRC 2018 - Smart Cities: Tendências e DesafiosPainel SBRC 2018 - Smart Cities: Tendências e Desafios
Painel SBRC 2018 - Smart Cities: Tendências e DesafiosKiev Gama
 
Aplicativos de transporte de pessoas e cidades inteligentes
Aplicativos de transporte de pessoas e cidades inteligentesAplicativos de transporte de pessoas e cidades inteligentes
Aplicativos de transporte de pessoas e cidades inteligentesKiev Gama
 
O computador para o século XXI
O computador para o século XXIO computador para o século XXI
O computador para o século XXIKiev Gama
 
The Importance of Open Source to the Cities
The Importance of Open Source to the CitiesThe Importance of Open Source to the Cities
The Importance of Open Source to the CitiesKiev Gama
 
Geração de Inovação para Cidades Inteligentes
Geração de Inovação para Cidades InteligentesGeração de Inovação para Cidades Inteligentes
Geração de Inovação para Cidades InteligentesKiev Gama
 
Oportunidades na Internet das Coisas
Oportunidades na Internet das CoisasOportunidades na Internet das Coisas
Oportunidades na Internet das CoisasKiev Gama
 
O uso de redes sociais no cotidiano das pessoas
O uso de redes sociais no cotidiano das pessoasO uso de redes sociais no cotidiano das pessoas
O uso de redes sociais no cotidiano das pessoasKiev Gama
 
CTIA 2015 - Internet das Coisas
CTIA 2015 - Internet das CoisasCTIA 2015 - Internet das Coisas
CTIA 2015 - Internet das CoisasKiev Gama
 
Sistemas Operacionais Urbanos
Sistemas Operacionais UrbanosSistemas Operacionais Urbanos
Sistemas Operacionais UrbanosKiev Gama
 
A Internet das Coisas
A Internet das CoisasA Internet das Coisas
A Internet das CoisasKiev Gama
 
Smart Cities e Big Data
Smart Cities e Big DataSmart Cities e Big Data
Smart Cities e Big DataKiev Gama
 
Mídias móveis na formação docente e no desenvolvimento profissional
Mídias móveis na formação docente e no desenvolvimento profissionalMídias móveis na formação docente e no desenvolvimento profissional
Mídias móveis na formação docente e no desenvolvimento profissionalKiev Gama
 
Monitorar/controlar ou empoderar cidadãos: duas estratégias para cidades inte...
Monitorar/controlar ou empoderar cidadãos: duas estratégias para cidades inte...Monitorar/controlar ou empoderar cidadãos: duas estratégias para cidades inte...
Monitorar/controlar ou empoderar cidadãos: duas estratégias para cidades inte...Kiev Gama
 
Hacker cidadão - divulgação
Hacker cidadão - divulgaçãoHacker cidadão - divulgação
Hacker cidadão - divulgaçãoKiev Gama
 
Cidades inteligentes e Internet das Coisas
Cidades inteligentes e Internet das CoisasCidades inteligentes e Internet das Coisas
Cidades inteligentes e Internet das CoisasKiev Gama
 
The Role of FIDO in a Cyber Secure Netherlands: FIDO Paris Seminar.pptx
The Role of FIDO in a Cyber Secure Netherlands: FIDO Paris Seminar.pptxThe Role of FIDO in a Cyber Secure Netherlands: FIDO Paris Seminar.pptx
The Role of FIDO in a Cyber Secure Netherlands: FIDO Paris Seminar.pptxLoriGlavin3
 
Nell’iperspazio con Rocket: il Framework Web di Rust!
Nell’iperspazio con Rocket: il Framework Web di Rust!Nell’iperspazio con Rocket: il Framework Web di Rust!
Nell’iperspazio con Rocket: il Framework Web di Rust!Commit University
 
How to write a Business Continuity Plan
How to write a Business Continuity PlanHow to write a Business Continuity Plan
How to write a Business Continuity PlanDatabarracks
 
Use of FIDO in the Payments and Identity Landscape: FIDO Paris Seminar.pptx
Use of FIDO in the Payments and Identity Landscape: FIDO Paris Seminar.pptxUse of FIDO in the Payments and Identity Landscape: FIDO Paris Seminar.pptx
Use of FIDO in the Payments and Identity Landscape: FIDO Paris Seminar.pptxLoriGlavin3
 
Advanced Computer Architecture – An Introduction
Advanced Computer Architecture – An IntroductionAdvanced Computer Architecture – An Introduction
Advanced Computer Architecture – An IntroductionDilum Bandara
 
The State of Passkeys with FIDO Alliance.pptx
The State of Passkeys with FIDO Alliance.pptxThe State of Passkeys with FIDO Alliance.pptx
The State of Passkeys with FIDO Alliance.pptxLoriGlavin3
 
Unraveling Multimodality with Large Language Models.pdf
Unraveling Multimodality with Large Language Models.pdfUnraveling Multimodality with Large Language Models.pdf
Unraveling Multimodality with Large Language Models.pdfAlex Barbosa Coqueiro
 

Más contenido relacionado

Más de Kiev Gama

Painel SBRC 2018 - Smart Cities: Tendências e Desafios
Painel SBRC 2018 - Smart Cities: Tendências e DesafiosPainel SBRC 2018 - Smart Cities: Tendências e Desafios
Painel SBRC 2018 - Smart Cities: Tendências e DesafiosKiev Gama
 
Aplicativos de transporte de pessoas e cidades inteligentes
Aplicativos de transporte de pessoas e cidades inteligentesAplicativos de transporte de pessoas e cidades inteligentes
Aplicativos de transporte de pessoas e cidades inteligentesKiev Gama
 
O computador para o século XXI
O computador para o século XXIO computador para o século XXI
O computador para o século XXIKiev Gama
 
The Importance of Open Source to the Cities
The Importance of Open Source to the CitiesThe Importance of Open Source to the Cities
The Importance of Open Source to the CitiesKiev Gama
 
Geração de Inovação para Cidades Inteligentes
Geração de Inovação para Cidades InteligentesGeração de Inovação para Cidades Inteligentes
Geração de Inovação para Cidades InteligentesKiev Gama
 
Oportunidades na Internet das Coisas
Oportunidades na Internet das CoisasOportunidades na Internet das Coisas
Oportunidades na Internet das CoisasKiev Gama
 
O uso de redes sociais no cotidiano das pessoas
O uso de redes sociais no cotidiano das pessoasO uso de redes sociais no cotidiano das pessoas
O uso de redes sociais no cotidiano das pessoasKiev Gama
 
CTIA 2015 - Internet das Coisas
CTIA 2015 - Internet das CoisasCTIA 2015 - Internet das Coisas
CTIA 2015 - Internet das CoisasKiev Gama
 
Sistemas Operacionais Urbanos
Sistemas Operacionais UrbanosSistemas Operacionais Urbanos
Sistemas Operacionais UrbanosKiev Gama
 
A Internet das Coisas
A Internet das CoisasA Internet das Coisas
A Internet das CoisasKiev Gama
 
Smart Cities e Big Data
Smart Cities e Big DataSmart Cities e Big Data
Smart Cities e Big DataKiev Gama
 
Mídias móveis na formação docente e no desenvolvimento profissional
Mídias móveis na formação docente e no desenvolvimento profissionalMídias móveis na formação docente e no desenvolvimento profissional
Mídias móveis na formação docente e no desenvolvimento profissionalKiev Gama
 
Monitorar/controlar ou empoderar cidadãos: duas estratégias para cidades inte...
Monitorar/controlar ou empoderar cidadãos: duas estratégias para cidades inte...Monitorar/controlar ou empoderar cidadãos: duas estratégias para cidades inte...
Monitorar/controlar ou empoderar cidadãos: duas estratégias para cidades inte...Kiev Gama
 
Hacker cidadão - divulgação
Hacker cidadão - divulgaçãoHacker cidadão - divulgação
Hacker cidadão - divulgaçãoKiev Gama
 
Cidades inteligentes e Internet das Coisas
Cidades inteligentes e Internet das CoisasCidades inteligentes e Internet das Coisas
Cidades inteligentes e Internet das CoisasKiev Gama
 

Más de Kiev Gama (15)

Painel SBRC 2018 - Smart Cities: Tendências e Desafios
Painel SBRC 2018 - Smart Cities: Tendências e DesafiosPainel SBRC 2018 - Smart Cities: Tendências e Desafios
Painel SBRC 2018 - Smart Cities: Tendências e Desafios
 
Aplicativos de transporte de pessoas e cidades inteligentes
Aplicativos de transporte de pessoas e cidades inteligentesAplicativos de transporte de pessoas e cidades inteligentes
Aplicativos de transporte de pessoas e cidades inteligentes
 
O computador para o século XXI
O computador para o século XXIO computador para o século XXI
O computador para o século XXI
 
The Importance of Open Source to the Cities
The Importance of Open Source to the CitiesThe Importance of Open Source to the Cities
The Importance of Open Source to the Cities
 
Geração de Inovação para Cidades Inteligentes
Geração de Inovação para Cidades InteligentesGeração de Inovação para Cidades Inteligentes
Geração de Inovação para Cidades Inteligentes
 
Oportunidades na Internet das Coisas
Oportunidades na Internet das CoisasOportunidades na Internet das Coisas
Oportunidades na Internet das Coisas
 
O uso de redes sociais no cotidiano das pessoas
O uso de redes sociais no cotidiano das pessoasO uso de redes sociais no cotidiano das pessoas
O uso de redes sociais no cotidiano das pessoas
 
CTIA 2015 - Internet das Coisas
CTIA 2015 - Internet das CoisasCTIA 2015 - Internet das Coisas
CTIA 2015 - Internet das Coisas
 
Sistemas Operacionais Urbanos
Sistemas Operacionais UrbanosSistemas Operacionais Urbanos
Sistemas Operacionais Urbanos
 
A Internet das Coisas
A Internet das CoisasA Internet das Coisas
A Internet das Coisas
 
Smart Cities e Big Data
Smart Cities e Big DataSmart Cities e Big Data
Smart Cities e Big Data
 
Mídias móveis na formação docente e no desenvolvimento profissional
Mídias móveis na formação docente e no desenvolvimento profissionalMídias móveis na formação docente e no desenvolvimento profissional
Mídias móveis na formação docente e no desenvolvimento profissional
 
Monitorar/controlar ou empoderar cidadãos: duas estratégias para cidades inte...
Monitorar/controlar ou empoderar cidadãos: duas estratégias para cidades inte...Monitorar/controlar ou empoderar cidadãos: duas estratégias para cidades inte...
Monitorar/controlar ou empoderar cidadãos: duas estratégias para cidades inte...
 
Hacker cidadão - divulgação
Hacker cidadão - divulgaçãoHacker cidadão - divulgação
Hacker cidadão - divulgação
 
Cidades inteligentes e Internet das Coisas
Cidades inteligentes e Internet das CoisasCidades inteligentes e Internet das Coisas
Cidades inteligentes e Internet das Coisas
 

Último

The Role of FIDO in a Cyber Secure Netherlands: FIDO Paris Seminar.pptx
The Role of FIDO in a Cyber Secure Netherlands: FIDO Paris Seminar.pptxThe Role of FIDO in a Cyber Secure Netherlands: FIDO Paris Seminar.pptx
The Role of FIDO in a Cyber Secure Netherlands: FIDO Paris Seminar.pptxLoriGlavin3
 
Nell’iperspazio con Rocket: il Framework Web di Rust!
Nell’iperspazio con Rocket: il Framework Web di Rust!Nell’iperspazio con Rocket: il Framework Web di Rust!
Nell’iperspazio con Rocket: il Framework Web di Rust!Commit University
 
How to write a Business Continuity Plan
How to write a Business Continuity PlanHow to write a Business Continuity Plan
How to write a Business Continuity PlanDatabarracks
 
Use of FIDO in the Payments and Identity Landscape: FIDO Paris Seminar.pptx
Use of FIDO in the Payments and Identity Landscape: FIDO Paris Seminar.pptxUse of FIDO in the Payments and Identity Landscape: FIDO Paris Seminar.pptx
Use of FIDO in the Payments and Identity Landscape: FIDO Paris Seminar.pptxLoriGlavin3
 
Advanced Computer Architecture – An Introduction
Advanced Computer Architecture – An IntroductionAdvanced Computer Architecture – An Introduction
Advanced Computer Architecture – An IntroductionDilum Bandara
 
The State of Passkeys with FIDO Alliance.pptx
The State of Passkeys with FIDO Alliance.pptxThe State of Passkeys with FIDO Alliance.pptx
The State of Passkeys with FIDO Alliance.pptxLoriGlavin3
 
Unraveling Multimodality with Large Language Models.pdf
Unraveling Multimodality with Large Language Models.pdfUnraveling Multimodality with Large Language Models.pdf
Unraveling Multimodality with Large Language Models.pdfAlex Barbosa Coqueiro
 
What's New in Teams Calling, Meetings and Devices March 2024
What's New in Teams Calling, Meetings and Devices March 2024What's New in Teams Calling, Meetings and Devices March 2024
What's New in Teams Calling, Meetings and Devices March 2024Stephanie Beckett
 
From Family Reminiscence to Scholarly Archive .
From Family Reminiscence to Scholarly Archive .From Family Reminiscence to Scholarly Archive .
From Family Reminiscence to Scholarly Archive .Alan Dix
 
Connect Wave/ connectwave Pitch Deck Presentation
Connect Wave/ connectwave Pitch Deck PresentationConnect Wave/ connectwave Pitch Deck Presentation
Connect Wave/ connectwave Pitch Deck PresentationSlibray Presentation
 
DevEX - reference for building teams, processes, and platforms
DevEX - reference for building teams, processes, and platformsDevEX - reference for building teams, processes, and platforms
DevEX - reference for building teams, processes, and platformsSergiu Bodiu
 
"ML in Production",Oleksandr Bagan
"ML in Production",Oleksandr Bagan"ML in Production",Oleksandr Bagan
"ML in Production",Oleksandr BaganFwdays
 
Digital Identity is Under Attack: FIDO Paris Seminar.pptx
Digital Identity is Under Attack: FIDO Paris Seminar.pptxDigital Identity is Under Attack: FIDO Paris Seminar.pptx
Digital Identity is Under Attack: FIDO Paris Seminar.pptxLoriGlavin3
 
SALESFORCE EDUCATION CLOUD | FEXLE SERVICES
SALESFORCE EDUCATION CLOUD | FEXLE SERVICESSALESFORCE EDUCATION CLOUD | FEXLE SERVICES
SALESFORCE EDUCATION CLOUD | FEXLE SERVICESmohitsingh558521
 
Are Multi-Cloud and Serverless Good or Bad?
Are Multi-Cloud and Serverless Good or Bad?Are Multi-Cloud and Serverless Good or Bad?
Are Multi-Cloud and Serverless Good or Bad?Mattias Andersson
 
Moving Beyond Passwords: FIDO Paris Seminar.pdf
Moving Beyond Passwords: FIDO Paris Seminar.pdfMoving Beyond Passwords: FIDO Paris Seminar.pdf
Moving Beyond Passwords: FIDO Paris Seminar.pdfLoriGlavin3
 
The Fit for Passkeys for Employee and Consumer Sign-ins: FIDO Paris Seminar.pptx
The Fit for Passkeys for Employee and Consumer Sign-ins: FIDO Paris Seminar.pptxThe Fit for Passkeys for Employee and Consumer Sign-ins: FIDO Paris Seminar.pptx
The Fit for Passkeys for Employee and Consumer Sign-ins: FIDO Paris Seminar.pptxLoriGlavin3
 
Transcript: New from BookNet Canada for 2024: BNC CataList - Tech Forum 2024
Transcript: New from BookNet Canada for 2024: BNC CataList - Tech Forum 2024Transcript: New from BookNet Canada for 2024: BNC CataList - Tech Forum 2024
Transcript: New from BookNet Canada for 2024: BNC CataList - Tech Forum 2024BookNet Canada
 
Take control of your SAP testing with UiPath Test Suite
Take control of your SAP testing with UiPath Test SuiteTake control of your SAP testing with UiPath Test Suite
Take control of your SAP testing with UiPath Test SuiteDianaGray10
 

Último (20)

The Role of FIDO in a Cyber Secure Netherlands: FIDO Paris Seminar.pptx
The Role of FIDO in a Cyber Secure Netherlands: FIDO Paris Seminar.pptxThe Role of FIDO in a Cyber Secure Netherlands: FIDO Paris Seminar.pptx
The Role of FIDO in a Cyber Secure Netherlands: FIDO Paris Seminar.pptx
 
Nell’iperspazio con Rocket: il Framework Web di Rust!
Nell’iperspazio con Rocket: il Framework Web di Rust!Nell’iperspazio con Rocket: il Framework Web di Rust!
Nell’iperspazio con Rocket: il Framework Web di Rust!
 
How to write a Business Continuity Plan
How to write a Business Continuity PlanHow to write a Business Continuity Plan
How to write a Business Continuity Plan
 
Use of FIDO in the Payments and Identity Landscape: FIDO Paris Seminar.pptx
Use of FIDO in the Payments and Identity Landscape: FIDO Paris Seminar.pptxUse of FIDO in the Payments and Identity Landscape: FIDO Paris Seminar.pptx
Use of FIDO in the Payments and Identity Landscape: FIDO Paris Seminar.pptx
 
Advanced Computer Architecture – An Introduction
Advanced Computer Architecture – An IntroductionAdvanced Computer Architecture – An Introduction
Advanced Computer Architecture – An Introduction
 
The State of Passkeys with FIDO Alliance.pptx
The State of Passkeys with FIDO Alliance.pptxThe State of Passkeys with FIDO Alliance.pptx
The State of Passkeys with FIDO Alliance.pptx
 
Unraveling Multimodality with Large Language Models.pdf
Unraveling Multimodality with Large Language Models.pdfUnraveling Multimodality with Large Language Models.pdf
Unraveling Multimodality with Large Language Models.pdf
 
What's New in Teams Calling, Meetings and Devices March 2024
What's New in Teams Calling, Meetings and Devices March 2024What's New in Teams Calling, Meetings and Devices March 2024
What's New in Teams Calling, Meetings and Devices March 2024
 
From Family Reminiscence to Scholarly Archive .
From Family Reminiscence to Scholarly Archive .From Family Reminiscence to Scholarly Archive .
From Family Reminiscence to Scholarly Archive .
 
Connect Wave/ connectwave Pitch Deck Presentation
Connect Wave/ connectwave Pitch Deck PresentationConnect Wave/ connectwave Pitch Deck Presentation
Connect Wave/ connectwave Pitch Deck Presentation
 
DevEX - reference for building teams, processes, and platforms
DevEX - reference for building teams, processes, and platformsDevEX - reference for building teams, processes, and platforms
DevEX - reference for building teams, processes, and platforms
 
DMCC Future of Trade Web3 - Special Edition
DMCC Future of Trade Web3 - Special EditionDMCC Future of Trade Web3 - Special Edition
DMCC Future of Trade Web3 - Special Edition
 
"ML in Production",Oleksandr Bagan
"ML in Production",Oleksandr Bagan"ML in Production",Oleksandr Bagan
"ML in Production",Oleksandr Bagan
 
Digital Identity is Under Attack: FIDO Paris Seminar.pptx
Digital Identity is Under Attack: FIDO Paris Seminar.pptxDigital Identity is Under Attack: FIDO Paris Seminar.pptx
Digital Identity is Under Attack: FIDO Paris Seminar.pptx
 
SALESFORCE EDUCATION CLOUD | FEXLE SERVICES
SALESFORCE EDUCATION CLOUD | FEXLE SERVICESSALESFORCE EDUCATION CLOUD | FEXLE SERVICES
SALESFORCE EDUCATION CLOUD | FEXLE SERVICES
 
Are Multi-Cloud and Serverless Good or Bad?
Are Multi-Cloud and Serverless Good or Bad?Are Multi-Cloud and Serverless Good or Bad?
Are Multi-Cloud and Serverless Good or Bad?
 
Moving Beyond Passwords: FIDO Paris Seminar.pdf
Moving Beyond Passwords: FIDO Paris Seminar.pdfMoving Beyond Passwords: FIDO Paris Seminar.pdf
Moving Beyond Passwords: FIDO Paris Seminar.pdf
 
The Fit for Passkeys for Employee and Consumer Sign-ins: FIDO Paris Seminar.pptx
The Fit for Passkeys for Employee and Consumer Sign-ins: FIDO Paris Seminar.pptxThe Fit for Passkeys for Employee and Consumer Sign-ins: FIDO Paris Seminar.pptx
The Fit for Passkeys for Employee and Consumer Sign-ins: FIDO Paris Seminar.pptx
 
Transcript: New from BookNet Canada for 2024: BNC CataList - Tech Forum 2024
Transcript: New from BookNet Canada for 2024: BNC CataList - Tech Forum 2024Transcript: New from BookNet Canada for 2024: BNC CataList - Tech Forum 2024
Transcript: New from BookNet Canada for 2024: BNC CataList - Tech Forum 2024
 
Take control of your SAP testing with UiPath Test Suite
Take control of your SAP testing with UiPath Test SuiteTake control of your SAP testing with UiPath Test Suite
Take control of your SAP testing with UiPath Test Suite
 

PhD Defense slides

  • 1. Towards Dependable Dynamic Component-Based Applications Kiev SANTOS DA GAMA Laboratoire d’Informatique de Grenoble Université de Grenoble Thèse soutenue publiquement le 6 Octobre 2011, devant le jury: Mme Claudia RONCANCIO Professeur, Ensimag - Grenoble INP, Président M Gilles MULLER Directeur de Recherche, INRIA, Rapporteur M Lionel SEINTURIER Professeur, Institut Univ. de France & Univ. de Lille, Rapporteur M Ivica CRNKOVIC Professor, Mälardalen University, Examinateur M Gaël THOMAS Maître de Conférences, Univ. Pierre et Marie Curie, Examinateur M Didier DONSEZ Professeur, Université Joseph Fourier, Directeur M Peter KRIENS Technical Director, OSGi Alliance, Invité
  • 2. Extensible Applications Different elements (components) easily pluggable into the application exte nsions 6 000+ at firefox .org 06 October 2011 PhD Defense Kiev Gama 2
  • 3. Components from Many Sources 06 October 2011 PhD Defense Kiev Gama 3
  • 4. Components from Many Sources Crash 06 October 2011 PhD Defense Kiev Gama 4
  • 5. Whose fault is it? Who is liable? User/Administrator? Plugin Provider? Platform (i.e. the browser)? What can be done about it? Should the whole application pay the price for someone else’s fault? 06 October 2011 PhD Defense Kiev Gama 5
  • 6. “A chain is as strong as its “A component system is only as weakest link” strong as its weakest component” [Szyperski 2002] 06 October 2011 PhD Defense Kiev Gama 6
  • 7. Main Question How to provide a flexible mechanism for untrustworthy components execution minimizing risks to the application? 06 October 2011 PhD Defense Kiev Gama 7
  • 8. Back to the browsers: Isolation Trend Fault is contained. Browser remains intact 06 October 2011 PhD Defense Kiev Gama 8
  • 9. Limitations No automatic recovery of faulty plugin No monitoring for diagnosing and fault avoidance OK for browsers. What about other contexts? 06 October 2011 PhD Defense Kiev Gama 9
  • 10. Critical Applications Availability 99% Unavailability = losses (money, data, lives) Business-Critical: Banking eCommerce Non-stop systems Dynamic reconfigurations needed at runtime with minimal system disruption 06 October 2011 PhD Defense Kiev Gama 10
  • 11. Dynamic Reconfiguration Potential source of faults Parts Repository (plugins, components, elements, etc) System 06 October 2011 PhD Defense Kiev Gama 11
  • 12. Main Question How to provide a flexible mechanism for untrustworthy components execution minimizing risks to the application in a dynamic environment? 06 October 2011 PhD Defense Kiev Gama 12
  • 13. STATE OF THE ART OBJECTIVES AND PROPOSITIONS IMPLEMENTATION VALIDATION CONCLUSIONS AND PERSPECTIVES 06 October 2011 PhD Defense Kiev Gama 13
  • 14. STATE OF THE ART I. COMPONENTS II. DEPENDABILITY III. ISOLATION 06 October 2011 PhD Defense Kiev Gama 14
  • 15. Components Software Component Component Platform Component Quality 06 October 2011 PhD Defense Kiev Gama 15
  • 16. Software Component “A component is a static abstraction with plugs” [Nierstrasz 1995] “A software component is a unit of composition with contractually specified interfaces and explicit context dependencies only. A software component can be deployed independently and is subject to composition by third parties.” [Szyperski 2002] 06 October 2011 PhD Defense Kiev Gama 16
  • 17. Component Platform “A platform is the substrate that allows for installation of components … such that these can be instantiated and activated.” [Szyperski 2002] 06 October 2011 PhD Defense Kiev Gama 17
  • 18. Component Quality “ilities” (reliability, maintainability, usability, etc) Quality attributes difficult to evaluate Sometimes Subjective May involve many subcharacteristics Combined components ≠ Combined attributes Hard to predict or test all possible compositions Worse in dynamic platforms Need to execute untrustworthy components but still ensuring system dependability 06 October 2011 PhD Defense Kiev Gama 18
  • 19. STATE OF THE ART I. COMPONENTS II. DEPENDABILITY III. ISOLATION 06 October 2011 PhD Defense Kiev Gama 19
  • 20. Dependability “the ability to avoid service failures that are more frequent and more severe than is acceptable” [Avizienis 2004] Dependability involves other attributes (e.g., availability, reliability, maintainability) Dependability in a changing environment: Resilience Ability to recover/adjust from changes 06 October 2011 PhD Defense Kiev Gama 20
  • 21. Fault Tolerance Typically implemented through redundancy techniques Fault containment as a means to reduce fault impact 06 October 2011 PhD Defense Kiev Gama 21
  • 22. Types of Fault •  Deterministic –  Programming errors •  Abnormal behavior (intentional or not) –  Reproducible bugs •  Non-deterministic It may happen with –  Race conditions trustworthy code –  Hardware origin •  Electric noise •  Bit flips •  Cosmic rays 06 October 2011 PhD Defense Kiev Gama 22
  • 23. Recovery Mechanisms Recovery-oriented Self-healing Computing Recovery Autonomic Computing Resilient Systems 06 October 2011 PhD Defense Kiev Gama 23
  • 24. STATE OF THE ART I. COMPONENTS II. DEPENDABILITY III. ISOLATION 06 October 2011 PhD Defense Kiev Gama 24
  • 25. Isolation Means of protection from other users (Humans, Systems, Components) Avoiding Harms Destroyed/Modified data Privacy Data read without permission Degraded service Fault containment 06 October 2011 PhD Defense Kiev Gama 25
  • 26. Isolation Techniques Hardware-enforced Process-based Process Process Virtualization Domain Domain Software-based Process Application-level domains Security Managers , Policy Process 06 October 2011 PhD Defense Kiev Gama 26
  • 27. Techniques Summary Privacy Fault Containment Process-based P P Virtualization P P Security Managers P O Application-level Domains P P 06 October 2011 PhD Defense Kiev Gama 27
  • 28. Component Isolation •  Component Object Model –  In-process –  Out-of-process server •  .NET Platform –  Application Domains –  Security managers •  Java –  Security managers –  Class loaders –  Isolates 06 October 2011 PhD Defense Kiev Gama 28
  • 29. Component Isolation Summary Privacy Fault Containment COM (In-process) P O COM (out-of-process) P P .NET Application Domains P P .NET Security Managers P O Java Security Managers P O Java Class loaders P O Java Isolates P P 06 October 2011 PhD Defense Kiev Gama 29
  • 30. Limitations of Studied Approaches as Dependable Component Platforms Decision about isolation is made at design time Lack of fault monitoring mechanisms No automatic automatic recovery from faults 06 October 2011 PhD Defense Kiev Gama 30
  • 31. STATE OF THE ART OBJECTIVES AND PROPOSITIONS IMPLEMENTATION VALIDATION CONCLUSIONS AND PERSPECTIVES 06 October 2011 PhD Defense Kiev Gama 31
  • 32. Vision Still live with failure Minimize the impact of untrustworthy components More dependable dynamic component- based applications 06 October 2011 PhD Defense Kiev Gama 32
  • 33. Objectives Flexible Isolation of Components Automatic Recovery from Faults 06 October 2011 PhD Defense Kiev Gama 33
  • 34. Propositions Dynamic isolation of components I.  Component Isolation Containers II.  Runtime Reconfigurable Policy Self-healing Container I.  Continuous Monitoring II.  Automatic recovery 06 October 2011 PhD Defense Kiev Gama 34
  • 35. Example Scenario Sensor Data Gathering Report Generator RFID Reader RFID Application 06 October 2011 PhD Defense Kiev Gama 35
  • 36. PROPOSITIONS DYNAMIC ISOLATION OF COMPONENTS I. COMPONENT ISOLATION CONTAINERS II. RUNTIME RECONFIGURABLE POLICY SELF-HEALING CONTAINER I. CONTINUOUS MONITORING II. AUTOMATIC RECOVERY
  • 37. Dynamic Isolation of Components I. Component Isolation Containers Component quarantine A “sandbox” approach Fault confinement II. Runtime Reconfigurable Policy Isolation at runtime (i.e. dynamic) Promotion of components 06 October 2011 PhD Defense Kiev Gama 37
  • 38. Dynamic Isolation of Components I. Component Isolation Containers Communication Reader A Reader B Sensor X Sensor Y Data Gathering Report Generator 06 October 2011 PhD Defense Kiev Gama 38
  • 39. Dynamic Isolation of Components The fault is contained Reader A Reader B Crash Sensor X Crash Sensor Y Data Gathering Report Generator 06 October 2011 PhD Defense Kiev Gama 39
  • 40. Dynamic Isolation of Components II. Runtime Reconfigurable Policy New Reader Persistence Check Sensor X Sensor Y Reader A Reader B Data Gathering Report Generator 06 October 2011 PhD Defense Kiev Gama 40
  • 41. Dynamic Isolation of Components II. Runtime Reconfigurable Policy Change Sensor X Sensor Y Reader A Reader B Apply changed policy Promoted component Data Gathering Report Generator 06 October 2011 PhD Defense Kiev Gama 41
  • 42. How Many Sandboxes? N-sandboxes x One sandbox How to group components? Trustworthiness Different Levels Criteria Cohesion Same provider Similar functionality Coupling Dependencies Intensive communication 06 October 2011 PhD Defense Kiev Gama 42
  • 43. PROPOSITIONS DYNAMIC ISOLATION OF COMPONENTS I. COMPONENT ISOLATION CONTAINERS II. RUNTIME RECONFIGURABLE POLICY SELF-HEALING CONTAINER I. CONTINUOUS MONITORING II. AUTOMATIC RECOVERY
  • 44. Self-Healing Container I. Continuous monitoring Problem Diagnosis Observation for future promotion (quarantine period) II. Automatic Recovery Restablished execution 06 October 2011 PhD Defense Kiev Gama 44
  • 45. Self-Healing Container I. Continuous Monitoring Reader A Reader B Sensor X Sensor Y Data Gathering Report Generator 06 October 2011 PhD Defense Kiev Gama 45
  • 46. Self-Healing Container I. Continuous Monitoring Reader A Reader B Crash Crash Sensor X Sensor Y Data Gathering Report Generator 06 October 2011 PhD Defense Kiev Gama 46
  • 47. Self-Healing Container II. Automatic Recovery Recovery Reader A Reader B Sensor X Sensor Y Data Gathering Report Generator 06 October 2011 PhD Defense Kiev Gama 47
  • 48. Summary Propositions Dynamic Isolation of components I. Component isolation containers II. Runtime reconfigurable policy Self-healing container I. Continuous monitoring II. Automatic recovery Differences against other approaches Flexible isolation Self-healing isolation container 06 October 2011 PhD Defense Kiev Gama 48
  • 49. STATE OF THE ART OBJECTIVES AND PROPOSITIONS IMPLEMENTATION VALIDATION CONCLUSIONS AND PERSPECTIVES 06 October 2011 PhD Defense Kiev Gama 49
  • 50. IMPLEMENTATION COMPONENT ISOLATION I. TARGET COMPONENT PLATFORM II. ISOLATION APPROACH III. ISOLATION TECHNIQUES USED IV. RECONFIGURABLE POLICY SELF-HEALING SANDBOX I. AUTONOMIC MANAGER II. FAULT MODEL 06 October 2011 PhD Defense Kiev Gama 50
  • 51. Target Component Platform (un)Installation of components at runtime Non-stop applications OSGi A module system for Java applications Used in industry and academia 06 October 2011 PhD Defense Kiev Gama 51
  • 52. Isolation Approach Approach used for isolating components Two Component platforms: Trusted Trusted Platform Sandbox Platform Sandbox (Quarantine ) Replicated components (for type dependency purpose) Mutual exclusive states 06 October 2011 PhD Defense Kiev Gama 52
  • 53. Isolation Approach: Mutual Exclusive States Trustworthy components are active execute on the trusted platform Untrustworthy components are active on the sandbox platform Fault Contained Environment Trusted Platform Sandbox Platform STARTED RESOLVED STARTED RESOLVED RESOLVED STARTED RESOLVED STARTED Bundle A Bundle B Bundle C Bundle D Bundle A Bundle B Bundle C Bundle D ? Actually two ? ? ? running platforms Main OSGi Sandbox OSGi Virtual Perspective STARTED STARTED STARTED STARTED Impression of having Bundle A Bundle B Bundle C Bundle D a single application Legend Trustworthy ? Untrustworthy OSGi 06 October 2011 PhD Defense Kiev Gama 53
  • 54. Isolation Approach: Virtual Perspective Fault Contained Environment Trusted Platform Sandbox Platform STARTED RESOLVED STARTED RESOLVED RESOLVED STARTED RESOLVED STARTED Bundle A Bundle B Bundle C Bundle D Bundle A Bundle B Bundle C Bundle D ? Actually two ? ? ? running platforms Main OSGi Sandbox OSGi Virtual Perspective STARTED STARTED STARTED STARTED Impression of having Bundle A Bundle B Bundle C Bundle D a single application Legend Trustworthy ? Untrustworthy OSGi 06 October 2011 PhD Defense Kiev Gama 54
  • 55. Isolation Techniques Used Domain-based (Java Isolates) strong isolation containers with fault containment Isolate Isolate Process (MVM) Process-based (Java Virtual Machine) Process Process (JVM) (JVM) 06 October 2011 PhD Defense Kiev Gama 55
  • 56. Communication between Containers JVM Java Isolate Java Isolate (MVM) Bundle A Bundle B Bundle C Bundle D Bundle A Bundle B Bundle C Bundle D ? ? ? ? Communication via Main Sockets or Sandbox OSGi Link API OSGi (JSR-121) JVM JVM Bundle A Bundle B Bundle C Bundle D Bundle A Bundle B Bundle C Bundle D ? ? ? ? Communitation Main via Sandbox OSGi Sockets OSGi 06 October 2011 PhD Defense Kiev Gama 56
  • 57. Reconfigurable Policy Isolation Policy Model 06 October 2011 PhD Defense Kiev Gama 57
  • 58. IMPLEMENTATION COMPONENT ISOLATION I. TARGET COMPONENT PLATFORM II. ISOLATION APPROACH III. ISOLATION TECHNIQUES USED IV. RECONFIGURABLE POLICY SELF-HEALING SANDBOX I. AUTONOMIC MANAGER II. FAULT MODEL 06 October 2011 PhD Defense Kiev Gama 58
  • 59. Self-healing Sandbox The sandbox with an automatic recovery mechanism An autonomic manager for the sandbox External application Control loop using a sense, analyze and react principle Fault detection and forecast Pragmatic approach based on a fault model 06 October 2011 PhD Defense Kiev Gama 59
  • 60. Self-healing Sandbox Architecture Sandbox Platform use Trusted Platform Core use delegate delegate use use Core PlatformProxy Service PlatformProxy Registry use use delegate use delegate use use Monitoring EffectorMBean Isolation Service MBean Policy Eval. Registry delegate delegate use delegate HeartbeatProbe SensorProbe EffectorProbe Autonomic Manager delegate delegate delegate Monitor Policy Strategy Watchdog Evaluator Executor use use use use use use use use Script Knowledge Interpreter 06 October 2011 PhD Defense Kiev Gama 60
  • 61. Self-healing Sandbox Control Loop Details Sys. Admin. Script Repository Autonomic Manager AP Policy Evaluator Monitor Analyze and Plan K Knowledge Execute M Watchdog Monitor E Strategy Executor Sensors Effectors 06 October 2011 Sandbox 61
  • 62. Fault Model Hypotheses of faults General issues Resource Consumption (e.g. CPU, memory) Crashes (e.g., errors from wrapped native libraries) Specific dynamism mishandling issues Dangling objects (stale services) Excessive Faulty Thread CPU Resource Usage Behavior Allocation Denial of Crash Service Unresponsiveness Application Stale Service Memory Hang 06 October 2011 PhD Defense Kiev Gama 62
  • 63. Separation of Concerns Dependability as crosscutting concerns Aspect-oriented Programming approach All dependability code in aspects Application code Aspect Weaver Aspects Woven code 06 October 2011 PhD Defense Kiev Gama 63
  • 64. Implementation Summary Domain-based (Isolates) Process-based (Multiple JVMs) Dynamic Isolation of components I. Component isolation containers Propositions II. Runtime reconfigurable policy DSL Self-healing container I. Continuous monitoring II. Automatic recovery Autonomic Manager 06 October 2011 PhD Defense Kiev Gama 64
  • 65. STATE OF THE ART OBJECTIVES AND PROPOSITIONS IMPLEMENTATION VALIDATION CONCLUSIONS AND PERSPECTIVES 06 October 2011 PhD Defense Kiev Gama 65
  • 66. VALIDATION EXPERIMENTS USE CASE DOMAIN-BASED X PROCESS-BASED TEST PLATFORM SELF-HEALING CONTAINER VALIDATION 06 October 2011 PhD Defense Kiev Gama 66
  • 67. Experiments Use Case Aspire RFID FP7 project RFID Network Non-stop servers collecting data Plug-and-play devices Native code for drivers puts stability in risk ONS Edge Edge RFID Readers + Sensors EPC IS EPC IS Premise Edge 06 October 2011 PhD Defense Kiev Gama 67
  • 68. Experiments Use Case Sensor RFID Reader RFID Application ONS Edge Edge RFID Readers + Sensors EPC IS EPC IS Premise Edge 06 October 2011 PhD Defense Kiev Gama 68
  • 69. Process-based x Domain-based Trusted Platform Sandbox Platform Criteria Memory footprint Isolate Isolate Application startup Sandbox reboot time MVM (Java 1.5) Trusted Platform Sandbox Platform JVM 1.5 JVM 1.5 Virtual Machines used Trusted Platform Sandbox Platform MVM (Java 1.5) Sun Oracle Hotspot JVM 1.5 Sun Oracle Hotspot JVM 1.6 JVM 1.6 JVM 1.6 06 October 2011 PhD Defense Kiev Gama 69
  • 70. Results Single JVM (Domain-based) 90 Sandbox 80 Trusted platform 70 60 50 MB 40 Footprint of our solution using 30 process-based isolation is equivalent to domain-based isolation 20 10 0 MVM (2 Isolates) 2 x JVM 1.5 2 x JVM 1.6 Isolation Containers Application Startup Sandbox Crash Sandbox Reboot time (ms) detection time (ms) time (ms) MVM (Multi-Isolate) 3186 32 303 MVM 1.5 (Multi-JVM) JVM 1.5 3449 3945 697 660 3064 3047 Mean time to repair on sandbox is JVM 1.6 3859 658 2537 faster when using Isolates 06 October 2011 PhD Defense Kiev Gama 70
  • 71. Generic Test Platform Fault deployment instead of fault injection –  Emulation of erroneous behavior based on our fault model –  Fault injection in the interface level does not represent actual application usage Management probes for triggering the faults JVM JVM RMI Connector Management and Monitoring Console MBeanServer (JConsole, VisualVM) Test Test Test Test Probe Probe Probe Probe Report Core Sensor Reader Reader Sensor X Sensor Y Generator Interfaces Aggregator Simulator A Simulator B Sandbox OSGi 06 October 2011 PhD Defense Kiev Gama 71
  • 72. Self-healing Container Validation Fault detection –  Fault model Event causality –  Heuristic for events correlation –  Updates that trigger abnormal behavior –  Useful for finding faulty components Prediction of faults (e.g., Stale service retainers, Out of memory error) 06 October 2011 PhD Defense Kiev Gama 72
  • 73. Results Correlation of events was possible Proper actions taken upon abnormal behavior 06 October 2011 PhD Defense Kiev Gama 73
  • 74. STATE OF THE ART OBJECTIVES AND PROPOSITIONS IMPLEMENTATION VALIDATION CONCLUSIONS AND PERSPECTIVES 06 October 2011 PhD Defense Kiev Gama 74
  • 75. Conclusions and Perspectives Dynamic Isolation of Components Component Isolation Containers (“sandboxes”) Runtime Reconfigurable Policy Self-healing Container Continuous Monitoring Automatic recovery 06 October 2011 PhD Defense Kiev Gama 75
  • 76. Missing Characteristics Fine grained monitoring Automatic promotion of well-behaving components Automatic replacement of faulty components (e.g. taken from a repository) Open issue: How to automatically evaluate component trust ? 06 October 2011 PhD Defense Kiev Gama 76
  • 77. Perspectives Resource monitoring at component level Automated Component Promotion Correlation of Historical Events Rating Component Trustworthiness Diversity of Isolation Environments Embedded Systems Cloud Computing 06 October 2011 PhD Defense Kiev Gama 77

Notas del editor

  1. We enumerate here the topics to be explored in this part of the talk.
  2. System quality attributes concern non functional properties, often called “ilities” (reliability, maintainability, usability, etc). Some of these attributes are hard to be evaluated, especially those that can be observed only during runtime such as reliability and performance. In the context of component-based development, when composing components together one should not consider the quality of the final composition as simply an addition of the attribute value of the involved components. If a reliable component A is composed with another reliable component B it does not necessarily means that the resulting composition will be reliable as well.Functional testing is based on system requirements in order to verify if a component produces the expected outputs, but it is difficult to test it against all possible compositions with other components.It may be necessary to execute untrustworthy components which are not necessarily malicious. For instance a device driver that contains unstable code.However it is still necessary to ensuresystem dependability. The untrustworthy component should not compromise the rest of the application.
  3. The general goal of this thesis is to provide mechanisms that can make dynamic componentbasedapplications more dependable. We want to minimize some of the impacts that runtime updatesmay introduce, especially those related to executing untrustworthy components. We propose distinctapproaches that combined together can lead us towards the construction of more dependableapplications in dynamic component-based platforms: