1 / 17

Towards Preserving Correctness in Self-Managed Software Systems

Towards Preserving Correctness in Self-Managed Software Systems. Lieven Desmet – Nico Janssens – Sam Michiels Frank Piessens – Wouter Joosen – Pierre Verbaeten DistriNet Research Group, Katholieke Universiteit Leuven, Belgium Lieven.Desmet@cs.kuleuven.ac.be. Overview. Assumptions

barto
Télécharger la présentation

Towards Preserving Correctness in Self-Managed Software Systems

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Towards Preserving Correctness in Self-Managed Software Systems Lieven Desmet – Nico Janssens – Sam Michiels Frank Piessens – Wouter Joosen – Pierre Verbaeten DistriNet Research Group, Katholieke Universiteit Leuven, Belgium Lieven.Desmet@cs.kuleuven.ac.be

  2. Overview • Assumptions • Motivation • Research goals • Approaches • Open questions

  3. Assumptions • Adaptive, dynamic software system, with adaptation management within software system • Adaptivity by typical feedback control loop: • sensors • gathering data • making adaptation decision • planning adaptation • executing adaptation

  4. DiPS + • Component based, rapid prototyping framework for protocol stacks in highly dynamic network environments DiPS+ Functional Layer open framework PhD Sam Michiels DMonA Self-Management Agents Network Management CuPS Run-time replacement WOSS'02 & WICSA'04 MsC Thesisses WCOP'02 & ICSM'04

  5. Focus • DiPS+ self-management: • external self-management: add-ons to open framework • centralized (decision) and distributed (activation) • domain specific: flow-based architecture, service based architecture • level of adaptation: component/service within a composition, concurrency model • how to get it right: MAIN ISSUE • application domain: system software (protocol stacks) and distributed applications

  6. Motivation • Some observations: • Shift towards component based software design and service oriented software architectures • compositions of highly decoupled, reusable, distributed software entities • Need for evolvability and manageability • both at deploy-time and run-time • Lot of mission critical software systems • high availability (24/7) • predictable behavior/correctness

  7. Examples • Implicit dependencies between components • e.g. data-centered systems: • Central data repository • Components can read and write data to the repository • Components share data through the shared data repository comp comp comp shared data repository comp comp comp

  8. Examples • Composing a data-centered application: • Introduces dataflow dependencies between components implicit dependency comp comp repository

  9. Examples • Replacing a component by a bug-fixed version with additional non-functional support • interfaces are stable • partially completed transactions

  10. Examples • Replacing components or services by a faster version • interfaces are not stable anymore • components are not backward compatible node 1 node 2 node 1 node 2

  11. Research goals • Consistent software compositions • loosely coupled components and services at design-time • correctly deployed in different compositions • Dynamic consistency • software consistency before, during and after adaptations for • isolated software adaptations • distributed software adaptations

  12. Approaches • Consistent composition • ADL's and analysis/verification tools • difficult to cover all dependencies/assumptions • Support for dataflow dependencies in data centered software systems • specific point solution • ArchJava bridges gap between ADL and implementation • no composition-time information (constraints, dependencies, assumptions) can be used [Desmet, WADS 2004] [PhD Aldrich, 2003]

  13. Approaches • Dynamic consistency: Isolated adaptations • Achieving a quiesence state in order to have safe software configurations • Adding consistency recovery support to capture and reinstate application-state • Coexistence of old and new components until converging output (SIMPLEX and HERCULES) [Magee and Kramer, IEEE Trans. on SE 1990] [Phd Hofmeister, 1990] [Cook and Dage, ICSE 99] [Rivera et al, TR SEI 96]

  14. Approaches • Dynamic consistency: distributed adaptations • Consistency preserving distributed adaptations at runtime: Cactus, Ensemble • however very specific to a particular application domain and environment • NeCoMan • encapsulates dynamic consistency in generic and reflective middleware platform • only applicable in flow-based architectures • Lasagne • collaborations are composed on a per-request base by selecting appropriate wrappers [Chen et al., ICDCS 02] [van Renesse et al., Software – Practice & Experience 1998] [Janssens, RM 2004] [PhD Truyen, 2004]

  15. Open questions • Which kind of software systems can benefit of self-managed behavior? • Is there any need for mission critical, self-managed software systems? • Can the presented correctness be relaxed in some situations? • Is fault tolerance complementary to this approach?

  16. Open questions (2) • What is the unit of adaptation? • Are adaptations localized or distributed? • Are adaptations anticipated or unanticipated? • What is the right balance between formal description/analysis and usability? • Can tool support completely bridge this gap?

  17. Questions ? ? ? ? ? Lieven Desmet – Nico Janssens – Sam Michiels Frank Piessens – Wouter Joosen – Pierre Verbaeten DistriNet Research Group, Katholieke Universiteit Leuven, Belgium Lieven.Desmet@cs.kuleuven.ac.be

More Related