Runtime Software Architectural Models for Adaptation, Recovery and Evolution Hassan Gomaa Emad Albassam Daniel A. Menascé Dept. of Computer Science Dept. of Computer Science Dept. of Computer Science George Mason University George Mason University George Mason University Fairfax, Virginia, USA Fairfax, Virginia, USA Fairfax, Virginia, USA hgomaa@gmu.edu ealbassa@gmu.edu menasce@gmu.edu Abstract—This paper describes approaches for dynamic University, in particular the research directions taken and software adaptation using runtime models of the software why they were taken, the software engineering concepts architecture. Software adaptation patterns consist of and technology that the research is based on, the main interaction models and state machine models that are used results of the research, and directions for future research. during dynamic software adaptation. Software adaptation Section II considers dynamic software adaptation from and recovery concerns are off-loaded from components by incorporating them into connectors, which are responsible different perspectives before addressing adaption of for dynamically adapting and recovering components. Both software architectures in Section III, comparing in Section centralized and decentralized approaches to adaptation and IV adaption without knowledge of the software recovery are considered. Two approaches to dynamic application with adaptation in which the application’s software product lines are described, a dynamic software software architectural patterns are known. From these adaptation approach for service-oriented product lines and patterns, software adaptation patterns are developed the design of variable adaptation and recovery connectors. consisting of interaction models and state machine models that are used during dynamic software adaptation, as Keywords—dynamic software adaptation; autonomic described in Section V. computing; dynamic software product lines; runtime models; recovery and adaptation connectors. Next, in Section VI, the paper describes how software adaptation concerns can be separated from component development concerns by incorporating adaptation I. INTRODUCTION concerns into adaptation connectors. The paper then describes in Sections VII and VIII how adaptation A software architectural model describes the design of the connectors can be extended to address recovery in a software system in terms of components and connectors. decentralized autonomic MAPE-K approach for self- Architectural models are frequently developed at design healing and self-adaptation. time before the implementation of the software system. However, architectural models can also be used at The paper goes on to describe in Section IX, two runtime to enable architecture recovery and architecture approaches to dynamic software product lines (SPL). The adaptation. Runtime architectural models are software first approach is a dynamic software adaptation approach models that coexist with the executing software system, for service-oriented product lines. The second approach is such that runtime decisions about dynamic changes to the the design of variable adaptation and recovery connectors executing system are made by analyzing the architectural used in the software adaptation of dynamic software model and then applied to the executing system. product lines (DSPL). In Section X, the paper discusses related work and future directions for dynamic software This paper describes approaches for dynamic software adaptation. adaptation using runtime models of the software architecture for both planned and unplanned adaptation. II. DYNAMIC SOFTWARE ADAPTATION Planned adaptation is proactive in which manual or automated decisions are made to dynamically change the Software adaptation addresses software systems that need software system at runtime. Unplanned adaptation is to change their behavior during execution. In self- triggered by unexpected events, such as node failure, managed and self-healing systems, systems need to which necessitate reactive decisions to dynamically monitor the environment and adapt their behavior in recover the software system from failure. response to changes in the environment [3]. Garlan and Schmerl [1] have proposed an adaptation framework for This paper describes and discusses the research conducted self-healing systems, which consists of monitoring, in dynamic software adaptation at George Mason analysis/resolution, and adaptation. Kramer and Magee [2] have described how in an adaptive system, a the software architecture in terms of components and component needs to transition from an active (operational connectors, and (b) the mapping of the software state) to a quiescent (idle) state before it can be removed components and connectors to the hardware from a configuration. Kramer and Magee have also configuration, in particular the computer nodes to which advocated an architectural approach to self-managed they are deployed. systems [5]. Autonomic systems address software adaptation by following the MAPE-K model that consists If the dynamic adaptation involves a change to the of four activities (monitoring, analysis, planning, and software architecture, then (a) the runtime PIM is used to execution) that operate on a knowledge-base of the determine what components need to be added, removed, system [3]. or replaced in the architecture – this corresponds to architectural adaptation in section II (b) the runtime PSM Software adaptation can take many forms. It is possible to is used to determine the nodes that are affected. If the have a self-managed system that adapts the algorithm it adaptation does not involve a change in the software executes based on changes it detects in the external architecture but involves a change to the software environment. If these algorithms are pre-defined, then the configuration (e.g., after a node failure, one or more system is adaptive but the software structure and components need to be recovered and relocated to architecture is fixed. The situation is more complex if the different nodes), then the runtime PSM is used to adaptation necessitates changes to the software structure determine how to reconfigure the system. This or architecture. In order to differentiate between these corresponds to configuration adaptation in section II. different types of adaptation, adaptations can be classified as follows within the context of distributed component- IV. DYNAMIC CHANGE MANAGEMENT OF SOFTWARE based software architectures: ARCHITECTURES a) Algorithmic adaptation. The system dynamically changes its behavior within its existing structure. There is Kramer and Magee [2][5] investigated how dynamic no change to the system structure or architecture. adaptation (also called dynamic reconfiguration) could be carried out at the software architecture level. The software b) Configuration adaptation. Dynamic adaptation involves architecture consists of distributed components deployed dynamically relocating components of the architecture to to a distributed configuration. They described how a different nodes of a distributed configuration, for example component must transition to a quiescent state before it if a node fails. The dynamic replacement of a failed can be removed or replaced in a dynamic software component with a replacement component has to be configuration. However, each component of the software performed while the system is executing. architecture is treated as a black box with no knowledge c) Architectural adaptation. The software architecture has of the executing software application. to be modified as a result of the dynamic adaptation. Old component(s), which may not provide the same interface, A change management model [5] defines the precise steps must be dynamically replaced by new component(s) while involved in dynamic reconfiguration to transition from the the system is executing. In this situation, in addition to current software run-time configuration to the new run- architectural changes, there are also likely to be time configuration. Thus, a component that needs to be configuration changes as old components are removed replaced has to stop being active and become quiescent, and new components are instantiated on new or existing the components that it communicates with need to stop nodes. communicating with it; the component then needs to be unlinked, removed, and potentially replaced by one or III. MODEL-DRIVEN SOFTWARE ARCHITECTURE FOR more new components, after which the configuration DYNAMIC SOFTWARE ADAPTATION needs to be relinked and the affected components restarted. In model-driven software architecture, models of the software architecture are developed prior to In order to drive a target component to quiescence, it is implementation. An architecture model can be a platform- frequently necessary to also drive neighboring independent model (PIM), which is a precise model of the components to quiescence. However, if the application software architecture before commitment to a given behavior of the neighboring components is known, it is platform, or a platform-specific model (PSM), where the possible to drive these components to partial quiescence architecture is deployed to a distributed hardware so that they cease to communicate with the target configuration [4]. Both PIM and PSM models can be used component but continue communicating with other in runtime adaptation of software systems. In dynamic components, thereby providing less disruption to the architecture-based software adaptation, it is necessary to runtime software system as described next. have runtime knowledge before and after adaptation of (a) V. SOFTWARE ADAPTATION PATTERNS AND CONNECTORS component. If the component is idle, it transitions directly to the Quiescent state. However, if the component is busy participating in a transaction, it transitions to the Passive The Kramer/Magee approach to software adaptation state. When the transaction is completed, it then assumes no knowledge of the executing application. If the transitions to the Quiescent state. software application is known, then knowledge of the patterns of behavior in the software architecture can be taken advantage of during software adaptation. A software architecture is composed of distributed software architectural patterns, such as client/server, master/slave, and distributed control patterns, which describe the software components that constitute the pattern and their interconnections [4, 6]. For each of these architectural patterns, there is a corresponding software adaptation pattern, which models how the software Fig. 1. Basic adaptation state machine components and interconnections can be changed under predefined circumstances, such as replacing one client In early research on software adaptation patterns [8], the with another in a client/server pattern, inserting a control state machine for each component was modeled using two component between two other control components in a orthogonal state machines, an operational state machine distributed control pattern, etc. (modeling normal component operation) and an adaptation (also referred to as reconfiguration) state A software adaptation pattern defines how a set of machine (Fig. 1). However, for more complicated components that make up an architectural pattern adaptation patterns, there is often some interaction dynamically cooperate to change the software between the two state machines, which complicates the configuration to a new configuration [9]. A software adaptation process. adaptation pattern requires state- and scenario-based reconfiguration behavior models to provide for a In later research on service-oriented systems [9, 10], the systematic design approach. The adaptation patterns are operational state machine was separated from the described by adaptation interaction models (using adaptation state machine. This is done by moving the communication or sequence diagrams) and adaptation adaptation state machine from the component and state machine models [9]. Several adaptation patterns encapsulating it in the connector. This separation of have been developed including the Master-Slave adaptation concerns from application concerns ensures Adaptation Pattern, Centralized Control Adaptation that the adaptation patterns, as well as the corresponding Pattern, Decentralized Control Adaptation Pattern [8], and code that realizes each pattern, are more reusable. service-oriented architectural patterns [9]. VI. SOFTWARE ADAPTATION CONNECTORS A. Software Adaptation State Machines Connectors in component-based software architectures An adaptation state machine defines the sequence of (CBSA) are objects that interconnect components and states a component goes through from a normal encapsulate a communication protocol [4]. Connectors operational state to a quiescent state [9]. A component is encapsulate frequently used communication patterns such in the Active state when it is engaged in its normal as asynchronous communication and synchronous application computations. A component is in the Passive communication with reply. For software adaptation, a state when it is not currently engaged in a transaction it connector is enhanced to also address adaptation concerns initiated, and will not initiate new transactions. A of the component it is connected to. As long as the component transitions to the Quiescent state when it is no connector receives all incoming messages to the longer operational and its neighboring components no component and all responses from that component, it can longer communicate with it. Once quiescent, the track the behavior of the component in terms of messages component is idle and can be removed from the received and responses sent, steer t h e component to a configuration, so that it can be replaced with a different quiescent state [6], and thereby carry out the adaptation version of the component. Fig. 1 shows the basic of the component. adaptation state machine model for a component as it transitions from Active state to Quiescent state. The adaptation framework sends a Passivate command to the Fig. 2. SOA architectural pattern The SASSY framework [7, 9, 10, 17, 20] provides two investigated by the RASS project [15, 16] are to (a) different types of adaptation connector, coordinator dynamically discover a software architecture at run-time connector and service connector, as shown in Fig. 2. A [14] (b) investigate connectors that address software service adaptation connector behaves as a proxy for a recovery in addition to software adaptation and (c) to service, such that its clients can interact with the investigate a decentralized autonomic MAPE-K approach connector as if it was the service. The goal of an to self-healing and self-configuration. adaptation connector is to separate the concerns of an individual service from dynamic adaptation, i.e., the RASS [15] introduced the following concepts: adaptation connector implements the adaptation mechanism for its corresponding service, including the A recovery pattern defines how components in an interaction with the change management service [9] and architectural pattern can be dynamically relocated and tracking the operational states of the service. The recovered to a consistent state after a component has adaptation state machine for a given adaptation pattern is failed. encapsulated in the corresponding adaptation connector. A Recovery and Adaptation Connector (RAC) that is used Each adaptation connector encapsulates a state machine to separate adaptation and recovery concerns from that has the states depicted in Fig. 1. However, the events component concerns so that a component can be and actions of the state machine depend on the dynamically adapted and recovered from failures. characteristics of the component that the connector communicates with. For example, in Fig. 2, a service A RAC (fig. 2) behaves as a proxy for a component or connector that interacts with a service behaves differently service by receiving requests from clients and then from a connector that interacts with a coordinator. forwarding these requests to the service. The RAC also receives responses from the service, which are then SASSY uses an adaptive Change Management Model [9] forwarded to requesting clients. To ensure safe adaptation to establish a region of quiescence [2] that allows at run-time and recoverability of service failures, the RAC dynamic adaptation of the component(s) to take place. For must keep track of the transactions that the service is each adaptation pattern, the change management model currently engaged in and must maintain messages (i.e., controls and sequences the steps in which the requests and responses) that pass through it so that these configuration of components in the pattern is changed messages can be held during adaptation and can be from the old configuration to the new configuration. In recovered when the service fails. Fig. 2, a service could be dynamically replaced by a newer version of the service. However, to dynamically The reason why the RAC is able to address both planned add a new service to the SOA would also necessitate a adaptation and unplanned adaptation (i.e., recovery) is dynamic change of the coordinator to a newer version that that in both cases, the messages that constitute each is capable of interacting with the new service. transaction need to be stored in the connector until the transaction has completed and manipulated during VII. RECOVERY AND ADAPTATION CONNECTORS adaptation if required. However, the state machines and algorithms for planned and unplanned adaptation are As a sequel to the SASSY project, we started work on the different, as described next. Resilient Autonomic Software Systems (RASS) project. After the SASSY research demonstrated that software VIII. DISTRIBUTED ADAPTATION AND FAILURE adaptation concerns could be separated from component application concerns, the runtime modeling problems RECOVERY Based on the concept of RACs, we designed and patterns between components. DeSARM’s decentralized implemented DARE (Distributed Adaptation and architecture discovery mechanism is based on selective Recovery), a decentralized, integrated adaptation and gossiping techniques [21] and message tracing. recovery framework [16] for providing both self-healing DeSARM notifies the Configuration Maintenance Layer and self-adaptation properties to complex and highly when it suspects a node failure due to absence of gossip dynamic CBSAs. DARE is based on a decentralized messages from that node. version of the MAPE-K model. Every node in the The Application Recovery Layer (ARL) consists of the system hosts an identical instance of the DARE Recovery and Adaptation Manager (RAM) that is middleware whose architecture is shown in Fig 3. responsible for overseeing dynamic adaptation and recovery of the CBSA. When a node fails, the ARL ensures that the software system recovers to a consistent configuration in which every failed component is relocated and instantiated on a healthy node, and that the connections between a recovered component and its neighbor components are re-established. The RAM interacts with the appropriate RAC for each component to be adapted or recovered. The RAC ensures that (1) any transactions that were interrupted due to a run-time failure are recovered and restarted at the recovered component and (2) a component is only adapted after it has become quiescent [2]. IX. DYNAMIC SPL RUN-TIME ARCHITECTURE Software product line (SPL) engineering [18] provides a means for systematic planning and design for dynamic software adaptation. With a conventional SPL approach, Fig. 3. The DARE architecture at each node such as the PLUS method [19, 22], a family of software architectures, consisting of common and variant The Configuration Maintenance Layer (CML) tracks components, is built at design time in advance of mapping of components to nodes and provides services deployment and is managed using a feature model. By to higher layers for retrieving and modifying this means of application feature selection, a given member of map. The Configuration Manager (CM) is responsible the SPL is derived and then deployed. However, with for maintaining the current configuration map of the dynamic software adaptation, a member of the SPL can, software system, which is stored in a distributed hash after deployment, be dynamically adapted at run-time to a table that supports replication of its entries [23] in order different member of the SPL. to tolerate failures and enable distribution of the map. The table contains entries that map the IP address of a Dynamic software product lines (DSPL) [24] are needed node to the set of identifiers of components and RACs when SPL members need to adapt after deployment while hosted by the node with this IP address. the system is operational. Dynamic software adaptation for SPLs is the process of changing the SPL member at The recovery of a failed component must be handled by run-time to a different SPL member. In other words, exactly one Recovery and Adaptation Manager at one dynamic software adaptation is concerned with changing node. To ensure consistent recovery, our approach the application configuration at runtime after it has been involves electing the node with the lowest IP address deployed and is needed for SPLs that have to dynamically to become the recovery coordination node for adapt after original deployment. To address dynamic coordinating recovery of other failed nodes. The adaptation, the SPL life cycle for the PLUS method [19] Failure Analysis Manager (FAM) in the recovery node is extended as shown in Fig. 4. PLUS consists of two is the only FAM that proceeds with the recovery by phases: 1) Product Line (Domain) Engineering and 2) analyzing the failure. Application Engineering. For dynamic adaptation, a third The Architecture Discovery Layer (ADL) consists of phase is required: 3) Target System Reconfiguration. DeSARM [14], a decentralized architecture discovery During this third phase, the executable target system is mechanism, which is responsible for automatically dynamically changed from the target system run-time discovering at runtime the current architecture of the configuration for one product line member to a new target software system, in particular components and connectors system run-time configuration for a different SPL as well as synchronous and asynchronous communication member [25]. Fig. 4. Software life cycle for dynamic SPL Using feature modeling, the SPL feature model has to adaptation and recovery using partial knowledge of the capture all features of the SPL corresponding to the system [12]. Schneider et al. [13] concluded in their different application run-time architectures. The run-time survey on self-healing frameworks that the systematic feature model captures the features of the currently integration of the self-* properties is one of the main executing target system and is initially deployed at challenges in this area. This paper has described how the application derivation time. Furthermore, this feature above challenges have been systematically addressed. The model can change at run-time by deactivating those SASSY and DARE approaches have progressively features no longer required and dynamically replacing addressed the issues of decentralizing approaches to them with new features (from the original SPL feature dynamic adaptation and recovery; DARE has addressed model) that are required. In order to dynamically adapt the integration of self-healing and self-adaptation the software architecture in response to these feature properties. changes, it is necessary to have a feature/component table that relates each feature to the components that realize the Two other areas investigated by one of the authors are feature. evolutionary software architectures [27] and designing reusable secure connectors [28]. The evolutionary Dynamic SPL concepts have been used in SASSY for software development approach uses SPL and feature dynamic software adaptation of service-oriented modeling concepts for evolving multi-version systems. architectures [25]. RASS [26] investigated the design of The multi-version systems constitute a family of systems variable adaptation and recovery connectors used in the with some common functionality and some variable software adaptation of dynamic software product lines. functionality. The goal is to model all versions of the The approach integrates software product line and feature system, including previously deployed systems as a modelling concepts with autonomic properties of self- software product line. The addition of optional and healing and self-adaptation. alternative features necessitates the adaptation of the original software architecture by designing optional and X. DISCUSSION variant components to realize these features. Although there is a large body of literature in the area of autonomic and self-adaptive systems, most of them use Secure connectors [28] are designed separately from a centralized approach [11]. The main challenge with application components by reusing the appropriate decentralized approaches is carrying out dynamic communication pattern between components as well as the security services required by these components. Each components from failure. The paper has considered both secure connector is designed as a composite component centralized and decentralized approaches to adaptation that encapsulates both security service components and and recovery. The paper also described two approaches communication pattern components. Integration of to dynamic software product lines, a dynamic software security services and communication patterns within a adaptation approach for service-oriented product lines and secure connector is provided by a security coordinator. design of variable adaptation and recovery connectors The main advantage is that secure connectors can be used in the software adaptation of dynamic SPL. reused in different secure applications. For future work, the DSPL approach could be further Dynamic SPL and dynamic software adaptation enhanced by addressing software evolution and approaches could be enhanced by incorporating both the incorporating security patterns into recovery and above approaches. Thus a dynamic adaptive SPL [25] adaptation connectors. could also evolve after initial deployment by allowing new features and components to be added to address ACKNOWLEDGEMENTS evolving requirements. Dynamic and variable recovery and adaption connectors [26] could be further enhanced This work is partially supported by the AFOSR award by incorporating security patterns. Thus variable FA9550-16-1-0030. The authors thank Koji Hashimoto connectors could be evolved and adapted at run-time to and Mohamed Hussein for their contributions to this incorporate different recovery, adaptation, and/or security research. patterns. XI. CONCLUSIONS R EFERENCES This paper has described and discussed the research [1] D. Garlan and B. Schmerl, “Model-based Adaptation for Self- conducted in dynamic software adaptation at George Healing Systems”, Proc. Workshop on Self-Healing Systems, Mason University, including the research directions taken ACM Press, Charleston, SC, 2002. and why they were taken, the software engineering [2] J. Kramer and J. Magee, “The evolving philosophers problem: concepts and technology that the research is based on, the Dynamic change management,” IEEE Tr. Software Engineering, main results of the research and directions for future vol. 16, no. 11, pp. 1293–1306, 1990. research. In particular, the research has been [3] J. O. Kephart and D. M. Chess, “The vision of autonomic progressively addressing more challenging problems, computing,” Computer, vol. 36, no. 1, pp. 41–50, 2003. building on dynamic software architecture models and [4] H. Gomaa, Software modeling and design: UML, use cases, patterns, and software architectures. Cambridge University software product line models, progressing from software Press, 2011 architectural patterns to software adaptation and software [5] J. Kramer and J. Magee, “Self-managed systems: an architectural recovery patterns, separating adaptation concerns from challenge,” in Future of Software Engineering, 2007. FOSE’07. application concerns, decentralizing software adaptation IEEE, 2007, pp. 259–268. planning and decision making, and addressing both [6] H. Gomaa, “A Software Modeling Odyssey: Designing Evolutionary planned and unplanned adaptation using a decentralized Architecture-centric Real-Time Systems and Product Lines”, autonomic MAPE-K model. If a system failure occurs Keynote paper, Proc. 9th International Conference on Model- during adaptation planning, the planning needs to be Driven Engineering, Languages, and Systems, Genova, Italy, October 2006. aborted and restarted. However, if a system failure occurs [7] D. Menascé, H. Gomaa, S. Malek, J. Sousa, “SASSY: A Framework during adaptation execution, both the adaptation planning for Self-Architecting Service-Oriented Systems”, IEEE Software, and execution need to be aborted and restarted. Vol. 28, No. 6, pp. 78-85, November/December 2011. This paper has described approaches for dynamic [8] H. Gomaa and M. Hussein, “Software reconfiguration patterns for Dynamic Evolution of Software Architectures”, Proc. Fourth software adaptation using runtime models of the software Working IEEE/IFIP Conference on Software Architecture, Oslo, architecture, comparing adaptation with no knowledge of Norway, June, 2004. the software application with adaptation in which the [9] H. Gomaa, K. Hashimoto, M. Kim, S. Malek, and D. A. application’s software architectural patterns are known. Menascé, “Software adaptation patterns for service-oriented From architectural patterns, software adaptation patterns architectures,” in Proc. 2010 ACM Symp. Applied Computing. were developed consisting of interaction models and state ACM, 2010, pp. 462– 469. machine models that are used during dynamic software [10] H. Gomaa and K. Hashimoto, “Dynamic self-adaptation for distributed service-oriented transactions,” in Proc. 7th Intl. adaptation. Symp. Software Engi- neering for Adaptive and Self-Managing Systems. IEEE Press, 2012, pp. 11–20. The paper then described how software adaptation and [11] D. Weyns, B. Schmerl, V. Grassi, S. Malek, R. Mirandola, C. recovery concerns could be off-loaded from components Prehofer, J. Wuttke, J. Andersson, H. Giese, and K. M. Göschka, by separating these concerns and incorporating them into “On patterns for decentralized control in self-adaptive systems,” in adaptation and recovery connectors, which are Software Engineering for Self-Adaptive Systems II. Springer, responsible for dynamically adapting and recovering 2013, pp. 76–107. [12] C. Krupitzer, F. M. Roth, S. VanSyckel, G. Schiele, and C. Becker, “A survey on engineering approaches for self-adaptive systems,” Pervasive and Mobile Computing, vol. 17, pp. 184– 206, 2015. [13] C. Schneider, A. Barker, and S. Dobson, “A survey of self-healing systems frameworks,” Software: Practice and Experience, vol. 45, no. 10, pp. 1375–1398, 2015. [14] J. Porter, H. Gomaa, and D. Menascé, “DESARM: A decentralized mechanism for discovering software architecture models at runtime in distributed systems,” in 11th Intl. Workshop on Models@run.time, 2016 [15] E. Albassam, H. Gomaa, and D. Menascé, “Model-based Recovery Connectors for Self-adaptation and Self-healing: Design and Experimentation,” in Software Technologies, Revised Selected Papers from the 11th International Joint Conference, ICSOFT 2016, Lisbon, Portugal, July, 2016; Published by Springer, CCIS 743 pp. 108-131, 2017. [16] E. Albassam, J. Porter, H. Gomaa, & D. Menascé, "DARE: A Distributed Adaptation and Recovery Failure Recovery Framework for Software Systems", Proc International Conf. on Autonomic Computing (ICAC), 2017. [17] H. Gomaa and K. Hashimoto, “Model-based Run-Time Software Adaptation for Distributed Hierarchical Service Coordination”, Proc. Sixth International Conference on Adaptive and Self- Adaptive Systems and Applications, Venice, May 2014. [18] P. Clements & L. Northrop, Software Product Lines: Practices and Patterns, Boston: Addison-Wesley, 2001. [19] Gomaa, H., “Designing Software Product Lines with UML: From Use Cases to Pattern-based Software Architectures”, Addison- Wesley, 2005. [20] D. A. Menascé, J. P. Sousa, S. Malek, and H. Gomaa, “QoS Architectural Patterns for Self-Architecting Software Systems”, 7th IEEE Intl. Conf. on Autonomic Computing and Communication, Washington, DC, June, 2010. [21] A.-M. Kermarrec and M. Van Steen, “Gossiping in distributed systems,” ACM SIGOPS Operating Systems Review, vol. 41, no. 5, pp. 2–7, 2007. [22] M. Abu-Matar and H. Gomaa, "Variability Modeling for Service Oriented Product Line Architectures", Proc. International Software Product Line Conference, Munich, Germany, August 2011. [23] I. Stoica, R. Morris, D. Karger, M. F. Kaashoek, and H. Balakrishnan, “Chord: A scalable peer-to-peer lookup service for internet applications,” ACM SIGCOMM Computer Communication Review, vol. 31, no. 4, pp. 149–160, 2001. [24] M. Hinchey, S. Park, and K. Schmid, “Building Dynamic Software Product Lines,” Computer, vol. 45, no. 10, pp. 22–26, Oct. 2012. [25] H. Gomaa & K. Hashimoto, “Dynamic Software Adaptation for Service-oriented Product Lines,” Proc. Intl. Software Product Line Conf., Volume 2, New York, USA, 2011. [26] E. Albassam, H. Gomaa, and D. Menascé, “Variable Recovery and Adaptation Connectors for Dynamic Software Product Lines”, Proc. Tenth International Workshop on Dynamic Software Product Lines, SPLC Conference, Sevilla, Spain, September 2017. [27] H. Gomaa, “Towards Feature-Based Evolutionary Software Modeling”, Proc. International Workshop on Models and Evolution, MODELS Conference, Wellington, New Zealand, October 2011. [28] M. Shin, H. Gomaa, and D. Pathirage, “Reusable Secure Connectors for Secure Software Architectures”, Proc. 15th International Conference on Software Reuse, Limassol, Cyprus, June 2016.