Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

PhD Defense slides

1,162 views

Published on

Software is moving towards evolutionary architectures that are able to easily accommodate changes and integrate new functionality. This is important in a wide range of applications, from plugin-based end user applications to critical applications with high availability requirements.
Dynamic component-based platforms allow software to evolve at runtime, by allowing components to be loaded, and executed without forcing applications to be restarted. However, the flexibility of such mechanism demands applications to cope with errors due to inconsistencies in the update process, or due to faulty behavior from components introduced during execution. This is mainly true when dealing with third-party components, making it harder to predict the impacts (e.g., runtime
incompatibilities, application crashes) and to maintain application dependability when integrating such third-party code into the application. Components whose origin or quality attributes are unknown could be considered as untrustworthy since they can potentially introduce faults to applications when combined with other components, even if unintentionally. The quality of components is harder to evaluate when components are combined together, especially if it happens
on-the-fly. We are interested in reducing the impact that can be brought by untrustworthy
components deployed at runtime and that would potentially compromise application dependability.
This thesis focuses on applying techniques for moving a step forward towards dependable
dynamic component-based applications by addressing different dependability attributes namely reliability, maintainability and availability. We propose the utilization of strong component isolation boundaries, by providing a fault-contained environment for separately running untrustworthy components. Our solution combines three approaches: (i) the dynamic isolation of components, governed by a runtime reconfigurable policy; (ii) a self-healing component isolation container; and (iii) the usage of aspects for separating dependability concerns from functional code.

Published in: Technology, Education
  • Be the first to comment

  • Be the first to like this

PhD Defense slides

  1. 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. 2. Extensible ApplicationsDifferent elements (components) easily pluggable into the application exte nsions 6 000+ at firefox .org 06 October 2011 PhD Defense Kiev Gama 2
  3. 3. Components from Many Sources06 October 2011 PhD Defense Kiev Gama 3
  4. 4. Components from Many Sources Crash06 October 2011 PhD Defense Kiev Gama 4
  5. 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 forsomeone else’s fault? 06 October 2011 PhD Defense Kiev Gama 5
  6. 6. “A chain is as strong as its “A component system is only asweakest link” strong as its weakest component” [Szyperski 2002] 06 October 2011 PhD Defense Kiev Gama 6
  7. 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. 8. Back to the browsers: Isolation TrendFault is contained. Browser remains intact 06 October 2011 PhD Defense Kiev Gama 8
  9. 9. LimitationsNo 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. 10. Critical ApplicationsAvailability 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. 11. Dynamic Reconfiguration Potential source of faults Parts Repository (plugins, components, elements, etc) System 06 October 2011 PhD Defense Kiev Gama 11
  12. 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. 13. STATE OF THE ARTOBJECTIVES AND PROPOSITIONSIMPLEMENTATIONVALIDATIONCONCLUSIONS AND PERSPECTIVES06 October 2011 PhD Defense Kiev Gama 13
  14. 14. STATE OF THE ART I. COMPONENTS II. DEPENDABILITY III. ISOLATION06 October 2011 PhD Defense Kiev Gama 14
  15. 15. ComponentsSoftware Component Component Platform Component Quality 06 October 2011 PhD Defense Kiev Gama 15
  16. 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. 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. 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. 19. STATE OF THE ART I. COMPONENTS II. DEPENDABILITY III. ISOLATION06 October 2011 PhD Defense Kiev Gama 19
  20. 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. 21. Fault ToleranceTypically implemented through redundancy techniques Fault containment as a means to reduce fault impact 06 October 2011 PhD Defense Kiev Gama 21
  22. 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. 23. Recovery Mechanisms Recovery-oriented Self-healing Computing Recovery Autonomic Computing Resilient Systems 06 October 2011 PhD Defense Kiev Gama 23
  24. 24. STATE OF THE ART I. COMPONENTS II. DEPENDABILITY III. ISOLATION06 October 2011 PhD Defense Kiev Gama 24
  25. 25. IsolationMeans 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. 26. Isolation TechniquesHardware-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. 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. 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. 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. 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. 31. STATE OF THE ARTOBJECTIVES AND PROPOSITIONSIMPLEMENTATIONVALIDATIONCONCLUSIONS AND PERSPECTIVES06 October 2011 PhD Defense Kiev Gama 31
  32. 32. VisionStill live with failure Minimize the impact of untrustworthycomponents More dependable dynamic component-based applications 06 October 2011 PhD Defense Kiev Gama 32
  33. 33. Objectives Flexible Isolation of Components Automatic Recovery from Faults 06 October 2011 PhD Defense Kiev Gama 33
  34. 34. PropositionsDynamic 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. 35. Example Scenario Sensor Data Gathering Report Generator RFID Reader RFID Application 06 October 2011 PhD Defense Kiev Gama 35
  36. 36. PROPOSITIONS DYNAMIC ISOLATION OF COMPONENTS I. COMPONENT ISOLATION CONTAINERS II. RUNTIME RECONFIGURABLE POLICY SELF-HEALING CONTAINER I. CONTINUOUS MONITORING II. AUTOMATIC RECOVERY
  37. 37. Dynamic Isolation of ComponentsI. 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. 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. 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. 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. 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. 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. 43. PROPOSITIONS DYNAMIC ISOLATION OF COMPONENTS I. COMPONENT ISOLATION CONTAINERS II. RUNTIME RECONFIGURABLE POLICY SELF-HEALING CONTAINER I. CONTINUOUS MONITORING II. AUTOMATIC RECOVERY
  44. 44. Self-Healing ContainerI. Continuous monitoring Problem Diagnosis Observation for future promotion (quarantine period) II. Automatic Recovery Restablished execution 06 October 2011 PhD Defense Kiev Gama 44
  45. 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. 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. 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. 48. SummaryPropositions 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. 49. STATE OF THE ARTOBJECTIVES AND PROPOSITIONSIMPLEMENTATIONVALIDATIONCONCLUSIONS AND PERSPECTIVES06 October 2011 PhD Defense Kiev Gama 49
  50. 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 MODEL06 October 2011 PhD Defense Kiev Gama 50
  51. 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. 52. Isolation ApproachApproach 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. 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. 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. 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. 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 OSGi06 October 2011 PhD Defense Kiev Gama 56
  57. 57. Reconfigurable Policy Isolation Policy Model 06 October 2011 PhD Defense Kiev Gama 57
  58. 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 MODEL06 October 2011 PhD Defense Kiev Gama 58
  59. 59. Self-healing SandboxThe 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. 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. 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. 62. Fault ModelHypotheses 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 Hang06 October 2011 PhD Defense Kiev Gama 62
  63. 63. Separation of ConcernsDependability as crosscutting concerns Aspect-oriented Programming approach All dependability code in aspects Application code Aspect Weaver Aspects Woven code06 October 2011 PhD Defense Kiev Gama 63
  64. 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. 65. STATE OF THE ARTOBJECTIVES AND PROPOSITIONSIMPLEMENTATIONVALIDATIONCONCLUSIONS AND PERSPECTIVES06 October 2011 PhD Defense Kiev Gama 65
  66. 66. VALIDATION EXPERIMENTS USE CASE DOMAIN-BASED X PROCESS-BASED TEST PLATFORM SELF-HEALING CONTAINER VALIDATION06 October 2011 PhD Defense Kiev Gama 66
  67. 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 Edge06 October 2011 PhD Defense Kiev Gama 67
  68. 68. Experiments Use Case Sensor RFID Reader RFID Application ONS Edge Edge RFID Readers + Sensors EPC IS EPC IS Premise Edge06 October 2011 PhD Defense Kiev Gama 68
  69. 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. 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 303MVM 1.5 (Multi-JVM)JVM 1.5 3449 3945 697 660 3064 3047 Mean time to repair on sandbox isJVM 1.6 3859 658 2537 faster when using Isolates 06 October 2011 PhD Defense Kiev Gama 70
  71. 71. Generic Test PlatformFault 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 OSGi06 October 2011 PhD Defense Kiev Gama 71
  72. 72. Self-healing Container ValidationFault 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. 73. Results Correlation of events was possible Proper actions taken upon abnormal behavior 06 October 2011 PhD Defense Kiev Gama 73
  74. 74. STATE OF THE ARTOBJECTIVES AND PROPOSITIONSIMPLEMENTATIONVALIDATIONCONCLUSIONS AND PERSPECTIVES06 October 2011 PhD Defense Kiev Gama 74
  75. 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. 76. Missing CharacteristicsFine grained monitoring Automatic promotion of well-behaving components Automatic replacement of faulty components (e.g. taken from arepository) Open issue: How to automatically evaluate component trust ? 06 October 2011 PhD Defense Kiev Gama 76
  77. 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
  78. 78. [Thanks|Merci|Obrigado|Gracias] ?

×