Software architects plan, model, and analyze the high-level design of software systems. Today, these systems are often deployed in cloud computing environments as Software-as-a-Service (SaaS) applications. The scalability of these applications is crucially impacted by architects' early design decisions. Architects decide based on their experience and known architectural styles like a 3-tier architecture. In new application domains, however, architects lack the experience to determine whether their designs will result in scalable implementations. This lack leads to the high risk of unsatisfying scalability and expensive reimplementations. To tackle this problem, we propose initial ideas and concepts for architectural templates (ATs), de ned as a language to formalize architectural styles on component models. This formalization allows to enrich styles by quality annotations and completions for model-driven quality analyses. As we focus on SaaS applications, we exemplify this idea by enriching ATs by scalability annotations and completions allowing architects to analyze their applications' scalability. To illustrate such an analysis, we introduce and use a toy example. Based on this example, we derive initial working packages describing how we plan to realize and validate ATs.
In forward engineering, software architects plan, model, and analyze the
highlevel design of large software systems, i.e., their architecture. Today, these
software systems are often deployed as so-called Software-as-a-Service (SaaS)
applications [16] in cloud computing environments because of their advantageous
characteristics. Cloud computing is characterized by (a) elasticity, i.e., an access
to computing resources that can be provisioned and released on demand [16] and
(b) an accounting model in which only actually-demanded resources determine
costs (pay-per-use) [16]. These two characteristics induce a dependency between
costs and required computing resources. To minimize costs, a typical requirement
for SaaS applications is, therefore, that SaaS applications use as little additional
computing resources as possible when demand increases. This requirement
describes the scalability of a system, i.e., its ability \to sustain increasing workloads
by making use of additional resources" [11].
?? The research leading to these results has received funding from the EU Seventh
Framework Programme (FP7/2007-2013) under grant no 317704 (CloudScale).
For software architects, scalability induces the need of guidance toward its
achievement. For instance, an architect may require guidance when deciding
between a relational and a NoSQL [19] database as both promise di erent
scalability depending on stored data. Today, architects can be guided by (
To illustrate these ideas, we introduce an example scenario in Sec. 1.1. Afterwards, we discuss why neither architectural styles nor scalability analyses su ciently guide architects in designing scalable SaaS applications in Sec. 1.2. 1.1
As an example scenario, we consider a simpli ed book shop that shall be newly
designed for running in a cloud computing environment. In this scenario, an
enterprise assigns a software architect to design the book shop. The enterprise
has the following requirements for this shop:
R1: Functionality In the shop, customers can (
environment for the book shop changes over time. For example, it expects that books sell better around Christmas while they sell worse around the holiday season in summer. Therefore, the response times of the shop shall stay within 3 seconds even if the customer arrival rates in- or decrease by 1,000 customers per hour (at maximum).
R3: Linear Scalability The costs for operating the book shop are only allowed to increase (decrease) by $0.01 per hour when the number of customers using the shop increases (decreases) by 1. Costs per hour is a metric to measure the amount of additional resources (cf., the scalability de nition in Sec. 1). Requirements R2 and R3 are typical reasons to operate a system in an elastic cloud computing environment [11], i.e., an environment where application servers automatically provision the required amount of resources to cope with environmental changes. Therefore, the software architect will design the shop as an SaaS application operating in a rented cloud computing environment. 1.2
To provide a scalable SaaS application (R3), the architect considers using (
The rst option (architectural styles) requires that the architect is aware of appropriate cloud-based architectural styles as well as their application and assumptions. Currently, only a few architectural styles for SaaS applications in the cloud exist [8]. One example for such a style is SPOSAD [13].
SPOSAD suggests a 3-tier system with stateless middle tier, but leaves open the decision for a concrete database paradigm on the data tier [13]. Therefore, the architect may design the book shop as shown in Fig. 1: he assigns each of the three SPOSAD tiers (presentation, middle, data) to a component (Book Shop Frontend, Book Management, Book Database). The tiers of SPOSAD can be seen as SPOSAD's roles, i.e., as set of constraints for associated components.
Middle Tier Customer Legend:
Book Shop Frontend
Role Actor
Component
Book
Management Provided Interface Required Interface
Data Tier $DB Kind = NoSQL
Book Database Assembly Connector $Parameter For example, the data tier may only allow connections from the middle tier. As SPOSAD does not constrain the data tier further, the architect is unsure whether to design the system with a relational or a NoSQL database that both promise a di erent scalability. Because of this variability point, he needs further guidance; SPOSAD alone is not enough. For achieving particular scalability requirements, there is, hence, the need to re ne SPOSAD. Also the few other SaaS styles lack detailed suggestions for selecting an appropriate database paradigm.
The second option (scalability analyses) would allow the architect to model
both database alternatives and to compare their scalability (what-if analysis).
Scalability analyses require simulation or analytical models allowing architects
to predict an SaaS applications' scalability in cloud computing environments.
However, according to Becker et al. [2], current analysis models lack (
The lack of guidance (regarding styles and scalability analyses) for the architect leads to the high risk of realizing a cost-ine cient SaaS application and of an expensive re-implementation. For example, it may be expensive to refactor the book shop with an established but non-scalable relational database implementation to an implementation using a NoSQL database. This risk becomes even more severe in case the enterprise discovers scalability issues when high costs for hosting their application have already incurred, e.g., during system operation. 2
Related work tackling the engineering of scalable SaaS applications can be
classi ed into two areas: (
A generally rich set of literature provides, classi es, and surveys sets of architectural styles (e.g., [5], [20]). However, these styles lack an explicit consideration of cloud computing environments as well as a focus on scalability.
In the context of cloud computing, typical styles are REST [9] for HTTP
and SPIAR [17] for AJAX. Also Erl et al. [8] describe a set of cloud
computing styles that foster scalability (e.g., load balanced virtual server instances).
These styles have in common that they target the infrastructure in which SaaS
applications run. Third party cloud computing providers typically provide this
infrastructure by o ering (
The second area, performance engineering, o ers several approaches recently classi ed and surveyed by Koziolek [12]. These approaches allow for analyzing the performance (response time, throughput, utilization) of component-based systems as, for example, the PCM [3]. However, they lack support for cloud computing characteristics, e.g., an elastic provisioning of computing resources.
Becker et al. [2] survey model-driven performance engineering approaches that support elasticity via self-adaptation, e.g., the SimuLizar [1] approach that extends the PCM. They conclude that these approaches are still limited. For example, only two approaches target design-time models and realistic validations by case studies are missing. However, software architects require design-time approaches, and appropriate case studies are the means to systematically nd architectural styles for scalable SaaS applications. Especially the latter aspect, i.e., using model-driven performance engineering techniques to conduct scalability analyses, lacks investigation. Therefore, we plan to extend existing performance analysis approaches like SimuLizar and PCM to enable model-driven scalability analyses of SaaS applications. In particular, we want to conduct case studies to identify appropriate architectural styles for scalable SaaS applications. 3
To cope with the lack of guidance for software architects (cf., Sec. 1), we propose and introduce architectural templates (ATs). We de ne ATs as a language to formalize architectural styles on component models. This formalization allows to enrich styles by quality annotations and completions. Quality annotations characterize a concrete quality property of interest. Quality completions utilize these annotations to derive quality models analyzable by quality analysis tools. As we focus on SaaS applications, we enrich ATs by scalability annotations and completions allowing architects to analyze their applications' scalability.
Technically, we plan to apply ATs on systems modeled in the PCM [3]. For
this application, we will extend the PCM metamodel (i.e., PCM's model for
specifying component-based architectures) by ATs. For scalability analyses, we
will extend the SimuLizar [1] approach to take information of ATs into account.
(
Software architects can use our ATs to design systems as well as to analyze their scalability. AT engineers, on the other hand, enrich our ATs by annotations and completions. We guide through these processes of AT application (Sec. 3.1) and AT creation (Sec. 3.2) by using the book shop scenario of Sec. 1. 3.1
Software architects apply ATs to design SaaS applications and to analyze their scalability. Fig. 2 illustrates the process steps for applying ATs. In step 1, architects select an AT from a repository of ATs. For example, the architect of the book shop scenario selects a SPOSAD AT. Afterwards, the architect assigns all roles the AT requires to the components of his architecture (step 2).
As illustrated in Fig. 1, he may assign SPOSAD's presentation, application, and data tier roles to book shop components as well as connects these components appropriately. Firstly, the AT formalism assures that no constraints are violated, e.g., it forbids connecting presentation and data tier components. Secondly, the AT formalism allows architects to specify whether a data tier component corresponds to a relational or a NoSQL database (scalability annotation).
As this design is based on an AT, the architect can automatically run scalability analyses afterwards by using the analysis tool we will provide (step 3). The key idea is that the AT includes a scalability completion for this purpose. For the book shop, SPOSAD AT's scalability model ensures that the architect obtains results that accurately re ect the scalability of the selected database kind. Therefore, the SPOSAD AT allows the architect to analyze which kind of database better ts his scalability requirements at design time. 3.2
To create ATs, AT engineers apply the process illustrated in Fig. 3. In the rst step, they formalize AT roles (e.g., SPOSAD's data tier) based on architectural styles (e.g., known from architecture handbooks).
Besides formalizing architectural styles, AT engineers enrich the AT with
scalability annotations and completions to enable an automated scalability
analysis. For this automation, AT engineers rst have to identify scalability-relevant
parameters and quantify them (step 2). For example, the kind of database
(relational vs. NoSQL database) on the data tier could be a scalability-relevant
parameter because NoSQL databases are often designed for scaling horizontally.
(
(
Parameters
(
(
(
In case AT engineers successfully identi ed a scalability parameter, they specify a scalability model for this parameter (step 3). The AT engineer of the book shop has, e.g., to specify a scalability model for NoSQL databases. Because NoSQL databases can scale horizontally, an accurate scalability model may model this NoSQL database as a \simple database" component, attached to a \load balancer" component. As soon as load exceeds a certain threshold, an adaptation rule assures that another \simple database" is spawned and added to load balancing. To determine concrete thresholds of the load balancer as well as processing times of the \simple database", the AT engineer integrates the results of the regression analysis. This model can, nally, be analyzed by ordinary analysis tools supporting components annotated with processing times and adaptation rules, e.g., the PCM with SimuLizar extended by scalability metrics.
Next, AT engineers validate the scalability model (step 4). For this
validation, they use a set of case studies, like the book shop scenario, that include
identi ed scalability parameters. For each case study, AT engineers (
In the nal step of Fig. 3, AT engineers enrich the AT with scalability annotations and completions. The speci cation of a \NoSQL database" for the \kind of database" parameter corresponds to a scalability annotation. The transformation to a scalability model corresponds to a scalability completion. Therefore, analysis tools can analyze the scalability of a model speci ed by ATs.
We based the process of Fig. 3 on established processes in performance engineering [10]. The basic idea is that concepts for performance engineering (e.g., performance model speci cation) apply similarly on scalability as well. 4
In [4], we described an overall process for applying ATs (there, termed \patterns") to design scalable SaaS applications. In this context, we also showed how to reverse engineer PCM models from existing systems [7].
Furthermore, we extended the PCM to run automatically measurements based on Java SE and RMI [15]. We also conducted several measurements in a virtualized environment and showed PCM's suitability for these environments. In [14], we show how to support automatic measurements for di erent target platforms than Java SE. This additional support is especially useful when the targeted platform is a cloud computing platform, e.g., a PaaS environment. 5
Our main contribution will be the AT language and AT processes helping
software architects to design scalable SaaS applications. For the concrete realization,
we plan to contribute (
We plan to evaluate expected bene ts of ATs based on case studies. As case
studies, we will use (
Currently, we are in the planning phase of our work. The ideas presented in this
paper re ect the current status of our plans. Therefore, we introduce a set of ve
work packages (WPs) describing how we want to progress in actually realizing
ATs. We plan to provide rst results in every WP within one year. Afterwards,
we plan to re ne and extend them in a time frame over two more years.
WP1: Architectural Templates The goal of this WP is to formalize ATs by
extending the PCM metamodel as well as to provide an initial set of example
ATs. A minimal requirement is that at least SPOSAD is speci ed using ATs.
WP2: Scalability Formalization This WP targets to provide a quanti able
scalability formalization that architects can use to compare di erent designs
of systems. Therefore, we want to clarify two main questions: (