From CloudScale
Revision as of 16:18, 25 September 2013 by Sebastian.lehrig (Talk | contribs)

Jump to: navigation, search




Architectural Styles

Architectural styles are Conceptual solution structures applied continuously and widely without exceptions on one element of an architecture (based on [2]). Examples are the 3-Tier style, Pipes&Filters, and SPOSAD.

Architectural Templates

The Architectural Template (AT) language is a language to formalize architectural styles on component models. In particular, this formalization allows to enrich styles by quality annotations and completions for model-driven quality analyses. Quality annotations characterize a concrete quality property of interest. Quality completions utilize these annotations to derive quality models that can be used as input to quality analysis tools. The language is formalized as "ScaleDL Architectural Template".

Whenever we refer to "an Architectural Template (AT)", we talk about a concrete architectural style formalized by the AT language. Accordingly, the plural form, Architectural Templates (ATs), refers to a set of these formalizations.

CloudScale Architectural Templates

CloudScale Architectural Templates (CATs) are the set of architectural templates (ATs) we evaluated for CloudScale. This set of ATs (1) representing best practices for designing SaaS applications and (2) allows to analyse the scalability of SaaS applications.

CloudScale Environment

CloudScale's Eclipse application. It is a front end to all CloudScale tools.


Costs are the valuated consumption of resources necessary to provide a certain service (per time unit). (Our definition is based on two German statements: "Kosten bezeichnen in der Regel den mit Marktpreisen bewerteten Einsatz von Produktionsfaktoren bei der Herstellung von Gütern und Dienstleistungen" [3] and "Kosten stehen betriebswirtschaftlich gesehen für den bewerteten Verbrauch an Produktionsfaktoren in Geldeinheiten (GE), welche zur Erstellung der betrieblichen Leistung in einer Abrechnungsperiode notwendig sind" [3].) Typically, this valuation is monetary. Also see economic costs [4] and operating cost [5].


An actor consuming services of a service provider. The term "service customer" can synonymously be used. Refinements of a "service customer" include "SaaS customer", "PaaS customer", and "IaaS customer". Other typical synonyms are "user" and "consumer", however, these synonyms should be avoided for clarity.


An actor making a layer's services ready to use, potentially by releasing a software system on top of lower-layer services. The term "service deployer" can synonymously be used. Refinements of a "service deployer" include "SaaS deployer", "PaaS deployer", and "IaaS deployer".


For an as-a-Service layer, elasticity is the degree to which the layer is able to adapt to workload changes by (de)provisioning services of its underlying layers in an autonomic manner such that at each point in time the utilised services fulfill the SLOs of the layer as closely as possible. (based on [6])


Load is the characterisation of the quantity of customer's service requests at a given time, e.g., by characterising the request rate.


A metric is a "precisely defined method which is used to associate an element of an (ordered) set V to a system S" [7]. Typically, we use metrics to determine a quantity (V is the set of natural or real numbers). An example SaaS quantity metric is the sum of consumed IaaS and PaaS services. Example IaaS quantity metrics include the number of consumed CPU services, the number of consumed CPU Minutes, and the number of CPU invocations by customers.


"In computer science and information science, an ontology formally represents knowledge as a set of concepts within a domain, and the relationships between pairs of concepts. It can be used to model a domain and support reasoning about concepts." [8] We use directed graphs to represent ontologies where nodes represent concepts and edges represent relationships. An example for reasoning is the identification of transitive relationships. Nodes can represent types as well as instances. "OWL is a language for making ontological statements, developed as a follow-on from RDF and RDFS" [8]. Furthermore, OWL ontologies can be queried by SPARQL. The most popular OWL reasoner is Pellet.


The Palladio Component Model (PCM) is a component-based architecture description language, with a focus on performance properties (response time, throughput, utilization).


The price is the valuation for a quantity of a certain service, typically realised in monetary units. (Based on the following German statement: "Der Preis [..] ist der üblicherweise in Geldeinheiten realisierte Wert eines Gutes oder einer Dienstleistung." [9])

Price Model

A price model is the concrete specification of prices for consuming services. For example, the service provider Amazon provides its price model for the EC2 IaaS solution on its web page [10]. A typical synonym is "cost model", however, this synonym should be avoided as we want to strictly distinguish between costs and prices.


An actor offering services. The term "service provider" can synonymously be used. Refinements of a "service provider" include "SaaS provider", "PaaS provider", and "IaaS provider".


"Quantity is a property that can exist as a magnitude or multitude." [11]


In computer science, a "resource, or system resource, is any physical or virtual component of limited availability within a computer system." [12] In economics, resources (or 'factors of production') "are the inputs to the production process." [13] Furthermore, resources "are any commodities or services used to produce goods or services" [13]. We use the economical definition for resources because it better fits to our service models.


For an as-a-Service layer, scalability is the ability of the layer to sustain increasing workloads while fulfilling its SLA, potentially by consuming a higher quantity of lower layer services. (based on [6])

For the SaaS layer, scalability is the ability of the software to sustain increasing workloads while fulfilling its SLA, potentially by consuming a higher quantity of PaaS or IaaS services.


The Scalability Description Language (ScaleDL) is a language to characterize cloud-based systems, with a focus on scalability properties. ScaleDL includes three sublanguages: ScaleDL Usage Evolution, ScaleDL Architectural Template, and ScaleDL Overview.

ScaleDL Architectural Template

ScaleDL Architectural Template the formalization of the Architectural Template (AT) language. ScaleDL is realized via an EMF metamodel. Its syntax and semantics are described in deliverable D1.1.


Software deployed by the deployer, i.e., software running on a layer waiting for requests (by service customers) to be executed. Typically, this execution is charged by service providers. Because services can be consumed by service customers, they are a special kind of a resource. The term "software service" can synonymously be used.

Service Description

The characterization of a service, e.g., by operation interfaces, their protocols, or by an SLA.


"A service-level agreement (SLA) is a contractual agreement outlining a specific service commitment made between contract parties -- a service provider and its customer. The SLA includes language describing the overall service, financial aspects of service delivery, including fees, penalties, bonuses, contract terms and conditions, and specific performance metrics governing compliant service delivery. These individual performance metrics are called service-level objectives (SLOs)." [14]


Service-level objectives (SLOs) are "[...] performance metrics governing compliant service delivery. [...] Each SLO corresponds with a single performance characteristic relevant to the delivery of an overall service. Some examples of SLOs would include: system availability, help desk incident resolution time and application response time." [14]


Stakeholders are actors who have roles associated that are specific for a concrete as-a-Service (XaaS) layer. Typical XaaS stakeholders are XaaS customers, XaaS providers, XaaS architects, XaaS developers, XaaS deployers, and XaaS maintainers.


Work is the characterisation of the data to be processed by a certain layer.


Workload is the combined characterisation of work and load.

Future Work

  • Add references for load, work, and workload (Bolch/Jane?). Also, think about splitting work into "work model" and "work specification".
  • Check SLA/SLO definition.
  • Add references for ATs and CATs once published.
  • Define method vs. approach vs. procedure vs. technique.
  • Define more on the software side (V or W-Model for services/clouds, roles, architectural terms, etc.).
  • Include time, e.g., for costs.
  • Define layer and exemplify it with Saas-PaaS-IaaS.
  • Discuss performance: performance vs. scalability engineering? Associated roles? Management vs. engineering?
  • Discuss whether "scaling down" should be part of the scalability definition
  • Define what an Operation is
  • Discuss: AT & AT Application vs. AT Type & AT Instance


  1. (OMG), Object Management Group. OMG Unified Modeling Language (OMG UML), Superstructure Specification (Version 2.4.1). Object Management Group, August 2011.
  2. Baier, Achim, Steffen Becker, Martin Jung, Klaus Krogmann, Carsten Röttgers, Niels Streekmann, Karsten Thoms, and Steffen Zschaler. Handbuch Der Software-Architektur. Edited by Ralf H. Reussner and Wilhelm Hasselbring. 2nd ed. dPunkt.verlag Heidelberg, 2008.
  3. 3.0 3.1; last accessed: 2013/08/05
  4.; last accessed: 2013/08/05
  5.; last accessed: 2013/08/05
  6. 6.0 6.1 Herbst, Nikolas Roman, Samuel Kounev, and Ralf Reussner. “Elasticity in Cloud Computing: What It Is, and What It Is Not.” In Proceedings of the 10th International Conference on Autonomic Computing (ICAC 2013), San Jose, CA, June 24–28. usenix, 2013.
  7. Eusgeld, Irene, Felix C. Freiling, and Ralf Reussner, eds. Dependability Metrics: Advanced Lectures [result from a Dagstuhl Seminar, October 30 - November 1, 2005]. Vol. 4909. Lecture Notes in Computer Science. Springer, 2008.
  8. 8.0 8.1; last accessed: 2013/08/07
  9.; last accessed: 2013/08/05
  10.; last accessed: 2013/08/05
  11.; last accessed: 2013/08/05
  12.; last accessed: 2013/08/05
  13. 13.0 13.1; last accessed: 2013/08/05
  14. 14.0 14.1; last accessed: 2013/08/05