A robust reconfiguration protocol for the dynamic update of component‐based software systems

Abstract

This paper focuses on the dynamic reconfiguration of component-based software systems. From a structural point of view, such systems are made of components linked together through their provided and required services, the code of components being defined by modules (e.g., jar files). Today, the ability to reconfigure component-based systems at runtime faces limitations. Some component frameworks allow to dynamically reconfigure components -starting or stopping them, or changing how they are wired together for instancebut forbid any dynamic evolution of the modules defining their code. Other frameworks allow to dynamically update modules but at the cost of loosing control on component wires, preventing software architects or tools alike to decide how components are wired together. In this paper, we propose a component framework that addresses these limitations through a unified approach for the management of components and modules. Our approach uniquely enables to reconfigure both components and modules at runtime, without restrictions. We prototyped the proposed framework in Java and exercised various dynamic reconfigurations of componentbased systems. Furthermore, we formalized this framework and proved the correctness of its reconfiguration protocol with the Coq proof assistant.files defined in M 1 by those defined in M 2 . Such reconfigurations are complementary to components reconfigurations that allow to manipulate components without changing their code (e.g., starting or stopping components, replacing a component by a newly started one instanciated from the same module). Module reconfigurations are useful to upgrade components to new versions or to adapt the code of components, for load management reasons, for instance. However, existing component frameworks do not fully support module reconfigurations at runtime.Several Java-based component frameworks [7][8][9] imply to shutdown and restart the entire system to manage module reconfigurations, mainly because modules are simply managed through setting up the classpath of the Java Runtime Environment. With the recent Tapestry industrial Java-based component framework [10], some component classes may be dynamically updated but only at the condition component interfaces do not evolve.Alternate approaches [11, 12] propose to use dynamic software updating (DSU) techniques [13] to allow updating the code of a component without any shutdown-restart. Despite being useful, such techniques face restrictions and are not guaranteed to succeed, which makes them suited to use at debug time but unreliable to use at production time.Other component frameworks, either industrial [2][3][4]14] or academic [15,16], leverage a module platform such as OSGi [17] or the NetBean Platform Module System [18] to manage the dynamic update of Java modules. Module platforms manage module updates through micro-rebooting the necessary components only, avoiding the global downtime imposed by a global shutdown-restart approach. However, such platforms autonomously decide how modules are link...

Dynamic software updating: a systematic mapping study

“…Moreover, number of studies have demonstrated further application domains including the Internet of Things [38, 54, 58, 60, 81, 82, 84, 106, 136 ], cloud computing [84, 88, 136 ], air traffic control systems [78–80, 123, 127, 134 ], component‐based systems [53, 58–60, 63, 71 ], mobile applications [3, 38, 98 ], production plant [61, 120 ], text editors [39, 87 ], robot systems [64, 122 ], games and multimedia [6, 91 ], and financial transaction processors [80, 127 ].…”

“…For DSU time metrics, number of studies have presented various metrics including compile‐time [41, 44, 46, 54, 96 ], load time [41, 45, 60, 133 ], waiting time [51, 73, 76, 83 ], reconfiguration time [59, 60, 62 ], rollback time [51, 101 ], quiescence time [3, 58 ], timeout [9, 111 ], debug time [60 ], disruption time [4 ], down‐time [56 ], garbage collection time [44 ], interrupt time [38 ], synchronisation time [93 ], pausing time [42 ], restart time [60 ], and reconfiguration period [67 ], and warm‐up time [56 ].…”

“…Also, number of authors have highlighted additional DSU approaches including dynamic replacement [22, 54, 66, 75, 86, 92, 93 ], dynamic instrumentation [52, 59, 60, 74, 84, 94 ], dynamic linking [37, 39, 53, 75, 83, 85 ], lust‐in‐time compilation [30, 44, 55, 58, 76, 95 ], wrapper [4, 40, 42, 44, 52 ], dynamic aspect‐oriented [35, 41, 50, 96, 97 ], extension of features [98, 99 ], dynamic adaptation [43, 59 ], rolling update [84 ], object transformer [49 ], data‐driven programming [92 ], distributed DSU [38 ], dynamic core library update [56 ], using run time to support DSU [92 ], procedure‐oriented [30 ], micro‐language‐based [100 ], and dynamic rebinding [5 ].…”

“…On the other hand, update points facets are less discussed facets in the domain.In this study, we have identified a list of 27 models for DSU. Based on the number of primary studies for each model, we list the top five most cited models in Table 11. Furthermore, the result shows other models including binary rewriting [53, 74 ], labelled transition systems [9, 69 ], incremental [83, 102 ], instantaneous [83, 102 ], mix objects object [42, 44 ], dynamic loading [97, 133 ], stack mapping [105 ], adaptation [64 ], aspect‐based [96 ], class‐loading [45 ], dynamic linking [53 ], relocatable code [53 ], event‐based [9 ], multiple consistency [44 ], object space [56 ], dynamic rebinding [5 ], representation consistency [77 ], shared library [53 ], stack reconstruction [74 ], strict consistency [87 ], V‐shape protocol [60 ], state machine [89 ], and component model [70 ]. RQ 3: What programming languages and algorithms employed in dynamic software updating?…”

“…For the states transformations, a group of studies have highlighted state transformation techniques in DSU including state mapping [9, 16, 43, 51, 52, 60, 94, 101, 104, 115, 122, 128 ], transformation function [9, 36, 37, 41, 43, 83, 91, 95, 131 ], state migration [52, 55, 105, 114 ], targeted object synthesis [9, 35, 36 ], relinking [29, 117 ], primitive support [39, 116 ], synchronisation [93, 116 ], and dynamic loading [86, 91 ].…”