Robusta: an Approach to Building Dynamic Applications Walter Rudametkin
Total Page:16
File Type:pdf, Size:1020Kb
Robusta: An approach to building dynamic applications Walter Rudametkin To cite this version: Walter Rudametkin. Robusta: An approach to building dynamic applications. Software Engineering [cs.SE]. Université de Grenoble, 2013. English. tel-00948174 HAL Id: tel-00948174 https://tel.archives-ouvertes.fr/tel-00948174 Submitted on 17 Feb 2014 HAL is a multi-disciplinary open access L’archive ouverte pluridisciplinaire HAL, est archive for the deposit and dissemination of sci- destinée au dépôt et à la diffusion de documents entific research documents, whether they are pub- scientifiques de niveau recherche, publiés ou non, lished or not. The documents may come from émanant des établissements d’enseignement et de teaching and research institutions in France or recherche français ou étrangers, des laboratoires abroad, or from public or private research centers. publics ou privés. THÈSE Pour obtenir le grade de DOCTEUR DE L’UNIVERSITÉ DE GRENOBLE Spécialité : Informatique Arrêté ministériel : 7 août 2006 Présentée par Walter Andrew RUDAMETKIN IVEY Thèse dirigée par Jacky ESTUBLIER préparée au sein du Laboratoire d’Informatique de Grenoble dans L’École Doctorale Mathématiques, Sciences et Technologies de l’Information, Informatique Robusta : Une approche pour la construction d’applications dynamiques Thèse soutenue publiquement le 21/02/2013, devant le jury composé de : M. Noel DE PALMA Professeur à l’Université Joseph Fourier, Président M. Benoit BAUDRY Chargé de Recherche, INRIA Rennes, Rapporteur M. Luciano BARESI Professeur au Politecnico di Milano, Rapporteur M. Eric GRESSIER-SOUDAN Professeur au CNAM, Examinateur M. François EXERTIER Responsable de l’équipe JOnAS à Bull S.A.S., Examinateur M. Jacky ESTUBLIER Directeur de Recherche au CNRS, Directeur de thèse 1 Dedication I dedicate this dissertation to my loving family and my beautiful wife. Acknowledgements Thank you everybody! You know who you are. You know how you helped. There are so many people. Thank you for everything. I couldn’t have done it without you. Each and every one of you. I sincerely thank you. Robusta: An approach to building dynamic applications Abstract Current areas of research, such as ubiquitous and cloud computing, consider execution environments to be in a constant state of change. Dynamic applications—where components can be added, removed and substituted during execution—allow software to adapt and adjust to changing environments, and to accommodate evolving features. Unfortunately, dynamic applications raise design and development issues that have yet to be fully addressed. In this dissertation we show that dynamism is a crosscutting concern that breaks many of the assumptions that developers are otherwise allowed to make in classic applications. Dynamism deeply impacts software design and development. If not handled correctly, dynamism can silently corrupt the application. Furthermore, writing dynamic applications is complex and error-prone, and given the level of complexity and the impact dynamism has on the development process, software cannot become dynamic without (extensive) modification and dynamism cannot be entirely transparent (although much of it may often be externalized or automated). This work focuses on giving the software architect control over the level, the nature and the granularity of dynamism that is required in dynamic applications. This allows architects and developers to choose where the efforts of programming dynamic components are best spent, avoiding the cost and complexity of making all components dynamic. The idea is to allow architects to determine the balance between the efforts spent and the level of dynamism required for the application’s needs. At design-time we perform an impact analysis using the architect’s requirements for dynamism. This serves to identify components that can be corrupted by dynamism and to—at the architect’s disposition—render selected components resilient to dynamism. The application becomes a well-defined mix of dynamic areas, where components are expected to change at runtime, and static areas that are protected from dynamism and where programming is simpler and less restrictive. At runtime, our framework ensures the application remains consistent—even after unexpected dynamic events—by computing and removing potentially corrupt components. The framework attempts to recover quickly from dynamism and to minimize the impact of dynamism on the application. Our work builds on recent Software Engineering and Middleware technologies—namely, OSGi, iPOJO and APAM—that provide basic mechanisms to handle dynamism, such as dependency injection, late-binding, service availability notifications, deployment, lifecycle and dependency management. Our approach, implemented in the Robusta prototype, extends and complements these technologies by providing design and development-time support, and enforcing application execution consistency in the face of dynamism. i Table of Contents Part I: Introduction .............................................................................................. 1 Chapter 1 Introduction............................................................................................................. 1 1.1 Motivations and Overview .................................................................................................... 1 1.2 Dissertation Structure ............................................................................................................ 5 Part II: State of the Art ........................................................................................ 7 Chapter 2 Background .............................................................................................................. 9 2.1 Introduction ........................................................................................................................... 9 2.2 Software Architecture .......................................................................................................... 10 2.2.1 Definitions for Software Architecture.............................................................................................................. 11 2.3 Component-Based Software Engineering ........................................................................... 14 2.3.1 A little bit of history ............................................................................................................................................... 14 2.3.2 Component ............................................................................................................................................................... 15 2.3.3 Connector .................................................................................................................................................................. 17 2.3.4 Composite component.......................................................................................................................................... 18 2.3.5 Configuration .......................................................................................................................................................... 19 2.3.6 Ports ............................................................................................................................................................................ 19 2.3.7 Bindings..................................................................................................................................................................... 20 2.3.8 Component framework ........................................................................................................................................ 20 2.3.9 Other concepts......................................................................................................................................................... 20 2.3.9.1 Deployment...................................................................................................................................................... 21 2.3.9.2 Architecture Description Languages ....................................................................................................... 21 2.3.10 Modules vs. Components.................................................................................................................................. 23 2.4 Service Oriented Computing ............................................................................................... 25 2.5 Service-Oriented Components............................................................................................. 26 2.5.1 Abstraction levels ................................................................................................................................................... 27 2.5.2 Mapping components to objects........................................................................................................................ 28 2.5.3 Dependencies ........................................................................................................................................................... 29 2.5.4 Dependency types.................................................................................................................................................. 30 2.6 Conclusion ........................................................................................................................... 30 Chapter 3 Software Evolution .............................................................................................