QoS Architectural Patterns for Self-Architecting Software Systems Daniel A. Menascé, João P. Sousa, Sam Malek, and Hassan Gomaa Department of Computer Science George Mason University Fairfax, VA 22030, USA {menasce,jpsousa,smalek,hgomaa}@gmu.edu ABSTRACT systems, where the architectural decisions made to optimize This paper discusses the automated application of architec- certain features may cause adverse effects in other parts of tural patterns for tuning the quality of service of service- the system. oriented software. The paper first presents an overview of Situated systems present an additional challenge since both prior work in self-architecting, SASSY, and a motivating the specific quality goals and the available means, such as example in the emergency response domain. After sum- service providers, may only become known on the spot, when marizing the heuristic used for self-architecting, the paper the system is needed to address a specific situation. For ex- discusses a number of architectural patterns and the cor- ample, in the emergency response domain, different means responding quantitative models for two concrete aspects of may be employed or given different priorities, e.g., to fight quality of service: availability and response time. A case a threat vs. to evacuate the affected area, depending on the study illustrates the role of patterns in the application of kind of threat and on the number of potential victims. the self-architecting heuristic to the motivating example. Automation is a promising approach to help architects address such challenges. In service-oriented systems, auto- matic service discovery brings scalability and effectiveness Categories and Subject Descriptors to the process of selecting the set of service providers that C.4 [Modeling Techniques]: Experimentation; D.2.11 [Soft- will deliver the preferred Quality of Service (QoS) to the sys- ware Architectures]: Patterns; D.4.8 [Performance]: Sto- tem. Furthermore, once service discovery is automated, it chastic analysis; G.1.6 [Optimization]: Global optimiza- can be supported by a run-time infrastructure thus making tion self-healing and self-adaptation possible [1, 9, 25]. Further improvements to QoS may be achieved by leveraging the automatic generation of service coordinators based on high- General Terms level descriptions of service flow. For example, JOpera au- Performance, Experimentation tomatically tunes coordination parameters, such as thread replication, taking into account system characteristics and Keywords load [23]. Although steps in the right direction, the mechanisms Service-Oriented Architecture, software architectures, auto- above fall short of providing the kinds of QoS improvements nomic computing, quality of service, software optimization, that expert application of architectural patterns can deliver. architecture patterns Work on architectural patterns is well-know in the art [8]. However, this paper is about automated techniques for ap- 1. INTRODUCTION plying QoS architectural patterns. Tuning the architecture of software systems is hard. Once Recent work in self-architecting attempts to bridge that an application’s logic is defined, an architect is concerned gap by automating the application of architectural patterns [5, with choosing architectural styles and patterns that promote 18]. This paper extends prior work in SASSY (Self-Archi- desired system qualities. Unfortunately, choosing a pattern tecting Software SYstems), where the automatic applica- that promotes certain aspects of quality normally has a neg- tion of patterns is informed by QoS goals defined by system ative effect on some other aspects of quality [4, 14]. The task stakeholders [18]. SASSY uses efficient and scalable search of an architect is to make tradeoffs that reflect the priorities heuristics to identify the optimal patterns, making it possi- of stakeholders. This task is especially complex for large ble to perform self-architecting both at system deployment and at run time for purposes of self-adaptation [20]. The contributions of this paper are, first, the analysis of a number of patterns suitable for self-architecting, and second, Permission to make digital or hard copies of all or part of this work for quantitative models to derive the overall QoS of a system personal or classroom use is granted without fee provided that copies are after the application of several such patterns. not made or distributed for profit or commercial advantage and that copies In the remainder of this paper, Sections 2 and 3 respec- bear this notice and the full citation on the first page. To copy otherwise, to tively present an overview of SASSY and a motivating ex- republish, to post on servers or to redistribute to lists, requires prior specific ample in the emergency response domain. Section 4 summa- permission and/or a fee. ICAC’10, June 7–11, 2010, Washington, DC, USA. rizes the self-architecting heuristic, and Section 5 presents Copyright 2010 ACM 978-1-4503-0074-2/10/06 ...$10.00. 195 the patterns currently supported in SASSY and their cor- ity functions and their composition are defined by domain responding QoS models. Section 5 also illustrates the ap- experts in consultation with the system stakeholders. plication of such patterns with a case study, and Section 6 SASSY uses analytical models to derive the end-to-end compares with related work. Finally, Section 7 summarizes QoS attributes, and hence the utility of the system, as func- the main points of this paper. tions expressed in terms of the QoS provided by each service along each SSS (more in Section 5.6). These analytical mod- 2. OVERVIEW OF SASSY els play a key role in the self-architecting process. The self-architecting and re-architecting component auto- SASSY takes optimization of QoS to a level beyond the matically generates a near-optimal System Service Architec- optimal selection of service providers by automatically gen- ture, and maintains that optimality in the face of changes erating a number of candidate architectural patterns to re- detected by the Monitoring Support—self-healing and adap- place each service and searching for the pattern that best tation—and in the face of changes made by users in the SAS serves user-defined QoS goals. and SSS—system evolution. For that, it focuses on a set Broadly, SASSY provides a framework and infrastructure of SSS with greater room for improving their contribution for self-adaptation, self-healing, self-optimization and evolu- to the overall utility. Then it generates variations to the tion of service-oriented software systems. system architecture by replacing each service along an SSS Figure 1 shows the relationships between the top-level with candidate architectural patterns that are functionally components and models used in the SASSY framework. This equivalent but improve some aspect of QoS. Prior work has framework is consistent with the classical monitoring and evaluated the effectiveness and scalability of several heuris- feedback control loop for software self-management (e.g., [17]) tics for generating candidate replacements and searching for and builds on prior work by the authors and others [13, 19]. the optimal architecture [20]. Specifically, starting at the bottom left, the Monitoring Sup- This paper describes the progress made to further improve port component leverages probes on the SOA implementa- the self-architecting process by leveraging knowledge about tion stack and transforms those observations into measures which architectural patterns promote or detract which QoS of QoS at system level via monitoring and gage services. attributes. Observations of service failure and QoS are reflected on the System Service Architecture, at the center, thus keeping the latter consistent with the status of the running system. The Adaptation Support component, at the bottom right, 3. MOTIVATING EXAMPLE manages the operational aspects of effecting changes to the For illustrating our research, we rely on an emergency re- running system based on architectural descriptions of those sponse system intended for use by government agencies to changes. automatically detect, respond, and manage various crises. What is distinctive about SASSY is the self-architecting The system targets SOA enabled smart spaces, which are and re-architecting component and associated models, at the comprised of various types of sensors, such as smoke detec- top of the figure. Service Activity Schemas (SAS) describe tors, fire sprinklers, and cameras. Each sensor exposes its the features and logic of the application and are written by functionality via a discoverable web service, which complies domain experts in a graphical notation similar to Business to the specification of the service type from the domain on- Process Modeling Notation (BPMN) [2] (more in Section 3). tology. The emergency response crew is also equipped with BPMN is too loosely defined and does not have the tight a variety of SOA enabled devices (e.g., PDAs) and plat- semantics and the QoS annotation capabilities as SAS [7]. forms (e.g., fire engines), which allow the crew to communi- In contrast to BPMN, SAS can be annotated with QoS cate their status, coordinate activities, and operate remote goals expressed in the form of utility functions. Utility func- sensors. A system such as this is innately dynamic and in- tions originate in economics and have been extensively used tended to deal with a variety of emergency scenarios. The in autonomic computing to assign a value to the usefulness SAS language provides a suitable method of specifying the of a system based on its attributes (e.g., [1, 25]). For exam- system’s requirements under different emergency conditions ple, a utility function associated with system availability, a (e.g., fire, earthquake, hurricane). SASSY in turn selects might be: the appropriate SAS model based on the situation at hand. Below we describe a SAS model constructed for a fire emer- 0 a < 0.9 gency at a smart building, which is further used in this paper 8 to illustrate self-architecting and QoS analysis in SASSY. UAvailability(a) = < 0.5 0.9 ≤ a < 0.95 (1) 1 0.95 ≤ a < 1 Figure 2a shows a subset of the modeling constructs avail- : able in the SAS language.