From CloudScale
Revision as of 16:55, 5 August 2013 by Sebastian.lehrig (Talk | contribs)

Jump to: navigation, search



"An actor specifies a role played by a user or any other system that interacts with the subject." [1]

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

Architectural Templates (ATs) are a method to formalise architectural styles on component models. This formalization is annotated with quality models for model-driven analyses. An example of such an annotation are CloudScale Architectural Templates.

CloudScale Architectural Templates

CloudScale Architectural Templates (CATs) are a refinement of Architectural Templates (ATs). While ATs allow arbitrary quality models to be annotated, CATs annotate only CloudScale's scalability model. This annotation allows architects to analyse the scalability of their SaaS applications.


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 [3])


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" [4]. 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.


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." [5]


In computer science, a "resource, or system resource, is any physical or virtual component of limited availability within a computer system." [6] In economics, resources (or 'factors of production') "are the inputs to the production process." [7] Furthermore, resources "are any commodities or services used to produce goods or services" [7]. 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.

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.


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)." [8]


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."[8]


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 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.)
  • Add references for load, work, and workload (Bolch/Jane?). Also, think about splitting work into "work model" and "work specification".
  • Define ontologies


  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. 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.
  4. 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.
  5.; last accessed: 2013/08/05
  6.; last accessed: 2013/08/05
  7. 7.0 7.1; last accessed: 2013/08/05
  8. 8.0 8.1; last accessed: 2013/08/05