A Model-Driven Deployment Approach for Scaling
Distributed Software Architectures on a Cloud
Computing Platform
Jeisson Vergara-Vargas and Henry Umaña-Acosta
Departamento de Ingeniería de Sistemas e Industrial
Universidad Nacional de Colombia
Bogotá, D.C., Colombia
{javergarav & hrumana}@unal.edu.co
Abstract—Software architecture aims to satisfy the software
requirements from different points of view. It is represented by
models which are the reference for understanding the structure
and behavior of the software. In this way, one of the biggest
challenges is to ensure that a software system can improve its
performance through the use of scalability tactics, especially to
support larger number of concurrent users. This paper presents a
model-driven deployment approach to design models of
distributed software architectures. In particular, models for web-
based software systems in order to support its automatic
implementation and its dynamic deployment on a cloud computing
platform, using the horizontal scaling tactic. In addition, we design
and propose Sarch to build the models, a domain-specific language
based on the specification of a set of architectural styles and its
representation as architectural views.
Keywords—Software Architecture, Performance, Scalability,
Model-Driven Deployment, Domain-Specific Language, Architec-
tural Style, Architectural View, Cloud Computing.
I. INTRODUCTION
Taylor et al. in [1] describe the Software Architecture (SA)
as the set of principal design decisions made about a software
system. Likewise, Rozanski et al. in [2] describe the SA as the
structure of structures of the system, which comprise software
elements, relations among them, and properties of both. In
general, SA is the design of the highest abstract level of the
structure of a software system. A SA is selected and designed
based on functional and nonfunctional requirements, and many
challenges of designing a SA are related to the ever increasing
complexity of the software. However, the way of building
software architectures is not unique, all of design decisions
possibilities establish a common objective that allows to define
a specialization of elements, relations and properties of software
systems. Each one of these specializations is known as an
Architectural Style [1], [3]. In this way, these styles abstract
design solutions at a high level.
On the other hand, one of the most important quality
attributes that must be guaranteed by the SA is the Scalability,
i.e., the ability of a software system to handle the increased
workload, which may be due to an increase in the number of
978-1-5386-0497-7/17/$31.00 ©2017 IEEE
99
requests or transactions [2]. In this way, improving the
performance of the system. Thereby, the key premise in this
paper is that a set of styles can be considered as the basis of a
language adjusted to a particular domain and providing notations
close to it [4], i.e., a Domain-Specific Language (DSL) focused
on SA modeling. In this context, we propose Sarch, a DSL aimed
to the design of software architectures from the definition of the
Data Model, Component-and-Connector (C&C), Layered and
Deployment Architectural Views, representations of a set of
architectural styles presented by Clements et al. in the Views and
Beyond (V&B) catalog [3].
Sarch is proposed from two approaches: support the software
implementation and the software deployment. The first approach
is done through a Model-Driven Development (MDD)
paradigm, which improve the software implementation process
based on models supported by powerful tools and processes [5].
In the same way, the second approach is done through a Model-
Driven Deployment (MDDep) approach, which is a proposed
paradigm that uses models, as in MDD, but using them to
automate the software deployment. Hence, Sarch is used as the
metamodel of MDDep and MDD processes, where a Sarch
instance represents a SA model. This model allows to generate
the source code of a Java web-based software system with a
Distributed Software Architecture, a SA composes of a set of
autonomous components that work together. Likewise, the
model allows to deploy the system on a Cloud Computing
platform from the definition of a Horizontal Scaling (HS)
schema for each one of the components that are part of the SA.
HS describe the ability to have more than one instance of the
component, through the addition of extra nodes to the system.
This method allows to improve the performance of the system
and support an increase in the number of concurrent users
supported [2].
The remainder of the paper is organized as follows. Section
II describes the related works focused on the use of DSLs in SA
and the automation of software deployments. Section III
introduces Sarch. Section IV describes the associated
transformation and generation processes. Section V shows a
conceptual and practical evaluation of the approach. Finally, in
Section VI conclusions and future work are presented.
 II. RELATED WORK
One of the first works is the definition of Architecture
Description Languages (ADLs). An ADL is a DSL designed to
model the architecture of a software system [6]. The main
advantage is that an ADL describes the software and the
hardware of a software system, from the definition of different
types of features, components, and processes. The most popular
ADLs are [7]: ACME, AADL and Darwin. A second work is the
definition of the architectural styles/views defined in the V&B
catalog as DSLs [2]. This approach is used to generate automatic
SA documentation through a MDD process [8], [9], [10]. On the
other hand, many works have been proposed to support the
development process, aimed at generating source code
automatically. A remarkable work is WebDSL, a DSL designed
to support the implementation of dynamic web applications [11].
Nevertheless, there are few works that use a DSL based on the
specification of software architecture styles. One of these works
is proposed by Cavalcante et al. [12], who introduce the
implementation of a MDD process in which, from the π-ADL
architectural description [13], it is possible the semiautomatic
source code generation in Go programming language. Likewise,
Aldrich et al. propose ArchJava [14], a Java extension that
unifies SA with implementation, ensuring that the
implementation conforms to architectural constraints; in this
case, it is important to note that the extension is made based on
the C&C style [3]. In addition, it is important to highlight some
works to support the deployment process [15], as a remarkable
work, Lascu et al. present an automatic deployment approach of
component-based applications [16]. Specifically connecting a
large number of heterogeneous software components through
the use of complex algorithms designed. Finally, there are some
works related with the automatic deployment but in a cloud
platform, e.g., a set of frameworks for the automatic deployment
of component-based applications in different kind of cloud
providers [17], [18].
III. SARCH LANGUAGE
Sarch is a DSL designed to allow the design of SA. This
design can be done from a set of architectural styles that cover
the necessary elements to support the implementation and
deployment of a software system based on distributed
architectures. Thus, the way as Sarch allows the use of these
styles is by mean of their associated architectural views,
presented in the (V&B) catalog [3]. Data Model Style/View
describes the static information structure of a software system.
Layered Style/View describes a division of the software into
units and each unit represents a group of modules that offers a
cohesive set of services. Component-and-Connector (C&C)
Style/View describes the way how a software system works.
Specifically, it is a style which abstracts a set of traditional styles
defined from components and connectors like Client-Server,
Peer-to-Peer, Event-Based, Service-Oriented Architecture
(SOA) and Microservices Architecture (MSA). Deployment
Style/View describes the way how the C&C elements are
allocated to the hardware of a computing platform on which the
100
software executes [3]. The grammar of Sarch is defined using
Xtext, an open-source framework for the development of
programming languages and DSLs. Xtext has its own
infrastructure which comprises an Extended Backus–Naur Form
(EBNF) grammar language, a parser, a linker, a typechecker, a
compiler and a textual editor for Eclipse [19]. A general instance
in Sarch language consists of the definition of a set of views
described above. Grammar of the four views are defined
similarly: a terminal that defines the view name and a list of
elements and relations that the view may have: Data Model
(element: data entity; relations: one-to-one, one-to-many),
Layered (element: layer; relation: allowed-to-use), C&C
(elements: components, connectors; relation: attachment),
Deployment (elements: software element, environmental
element; relation: deployed-in). The general schema of the
architecture and a view (C&C) of the Sarch grammar is shown
in Figure 1 as Xtext representation, and in Figure 2 as a Concrete
Syntax Tree (CST).
Figure 1. Grammar for Sarch: general schema of the architecture and C&C
view.
Architecture
architecture name=ID { Views }
DataModelView LayeredView ComponentAndConnectorView DeploymentView
… … …
component-and-connector-view :: Elements Relations ::
elements { … } relations { … }
… …
Figure 2. CST for Sarch: general schema of the architecture and C&C view.
IV. TRANSFORMATION AND GENERATION PROCESSES
A MDD methodology highlights two relevant aspects: the
definition of a set of metamodels and the definition of a set of
transformations [5]. Thus, MDD allows the creation of different
instances of the metamodels, called models, which are the basis
for the definition of a set of transformations that permit de
automatic code generation. In the same way, we propose
MDDep, based on the MDD paradigm, where the metamodels
and models have the same role, but the transformations are
focused on the automatic deployment generation. MDDep is
proposed as a new approach of Model-Driven Engineering
(MDE) which is defined as a methodology for applying the
advantages of modeling to software engineering activities [5], as
is MDD. To carry out the MD* process in this approach, it is
necessary to make a reference implementation. This
implementation consists of the construction of a software system
in the Java programming language, with a defined distributed
software architecture. Thus, the reference implementation
allows to map the software system elements with the
architectural styles/views elements in order to define the
adequate transformations.
A. Target Architecture
In order to define an adequate distributed architecture, we
selected a MSA. It is a recent architectural style and pattern,
which defines a set of components called microservices (MS)
that expose a small functionality to other MS and works with
them collaboratively [20]. The defined architecture is shown in
Figure 3 and described as follows. A set of Data Models in which
each one has at least one data entity and a set of relations
between the entities presented. A set of components of type:
databases (DB) to handle the information, MS to handle the
business logic, web applications (WA) to handle the user
interaction and load balancers (LB) to redirect requests to WA.
All MS have a unique associated DB. Moreover, a set of
connectors that can be JDBC (Java Database Connectivity) type
for connecting MS and DB, REST (REpresentational State
Transfer) type for connecting WA and MS, or HTTP
(HyperText Transfer Protocol) type for connecting LB and WA.
A Layered Architecture for representing the division of MS and
WA components into units. A Deployment Architecture for
deploying all components. It is defined from the main elements
of the Docker Project. Docker is a software platform that allows
the deployment of different kind of software artifacts in elements
called Containers [21]. A container wraps a piece of software in
a complete file system that contains everything needed to run. In
this way, each one of the components is deployed in a individual
container which has an execution environment and a specific
port. The execution environment can be GlassFish as application
server for MS and WA, MySQL as database server for DB, or
HAProxy as server for LB. Each component can have more than
one instance, i.e., it can be scaled horizontally.
LB_1:1
HTTP
WA_1:1 WA_1:2
REST
MS_1:1 MS_1:2 MS_2:1 MS_2:2
JDBC
DB_1:1
Figure 3. Target architecture from the point of view of the C&C style in a
semiformal representation. Notation: {DB, MS, WA, LB}_{identi-
fier}:{instance}. In this case, there is a LB with one instance, there is a WA
with two instances, there are two MS with two instances each one, and there is
a DB with one instance.
B. Transformations
The transformations are defined using Xtend, a dialect of
Java [22] that has as one of its main features the support for code
generation. Thus, the mapping between a distributed software
101
architecture designed in Sarch and a web-based software system
is described as follows:
1) MDD Process: In this process we focused on the
construction of Java project for MS and WA components
defined in the C&C view. A MS is built from the data models
defined in the data-model view, creating its respective entity
classes and a service which expose a set of CRUD (Create,
Read, Update, Delete) operations, in an API REST form.
Likewise, a WA is built from the defined services in the MS,
creating a set of web pages and its respective Java classes to
consume the APIs REST of the MS. The layered view define
the layers and its relations for MS (back-end in Sarch) and WA
(front-end in Sarch).
2) MDDep Process: This process is manly based on the
deployment view defined in Sarch. The main characteristic of
this view is the capacity to define important information about
the way of how the software will be deployed. Sarch requires
three kind of information: information about the software
elements to be deployed C&C elements, information about the
environmental elements where the software elements will be
deployed, and information about the way in which software
elements and environmental elements are related. It is necessary
to emphasize in the environmental elements because they are
the basis for the MDDep approach. Sarch defines two types of
environmental elements: server node and containers. The server
node must be unique and it describes the information of a server
allocated on the cloud which have control over all nodes where
the software system can be deployed. This server must be
configured previously, using Rancher, a container management
platform [23]. Basically, Rancher permits to add a set of nodes
(virtual servers) from different cloud providers. For this case,
we use an Amazon Web Services (AWS) infrastructure [24].
Once the server node is ready (with nodes added), Sarch can
generate the deployment schema defined in the architecture
created. Sarch generates a Docker schema for DB, MS, WA and
LB, by means of three generated files: a "Dockerfile" that
defines the information about the execution environment to be
created, a "docker-compose" that allows the creation of the
environment in the Dockerfile (container name and port where
it must be deployed), a "rancher-compose" that defines the
scaling value, i.e., the number of times the component will be
scaled in its deployment (number of instances to be created),
and a "deploy-cloud" that defines the server node information,
in order to deploy the respective component on the cloud (url,
access key and secret key: information provided by the Rancher
API in the server node). In this way, each component is
deployed in a set of containers, depending of the scale value in
Sarch. In addition, Sarch generates a set of stress test plans for
the POST (Create) operations of the MS. These plans allows the
automatic execution of stress tests in order to know the
maximum performance of the system in different scenarios of
concurrent users. Finally, it is important to highlight that for this
first work using Sarch language, the scale value for DB and LB
is restricted to 1, while the scale value for MS and WA is
restricted to n - 1, where n is the maximum number of nodes was previously configured in an AWS server. Likewise, a set of
added on the server node. four nodes with the same hardware specifications was
configured: Amazon EC2, t2.large, Ubuntu 16.04.1 as OS, 2x2.4
V. EVALUATION GHz, memory: 8 GiB, storage: 16 GiB. In the same way, Figure
5 shows the architecture visualization from Rancher server for
A. Conceptual Analysis the case study after the transformations.

It is important to highlight some important aspects about the

five approaches presented in the related work and the approach
presented with Sarch, in order to compare its scope and its
advantages with respect to others. Due to the characteristics of
software architecture, it is necessary to check how the main
aspects abstracted of the five approaches are covered by Sarch
(show Table I). The approaches analyzed are: 1st: ADLs [6], [7];
2nd: DSL for documenting SA [8], [9], [10]; 3rd: support the
development process [11], [12], [13], [14]; 4th: support the posts_lb
HTTP
posts_wa
REST
posts_ms
JDBC
posts_db

deployment process [15], [16]; and 5th: deployment in a cloud

platform [17], [18]. In the same way, the characteristics analyzed node1 node2

are: A: use of styles/views, B: SA description, C: use of DSLs, posts_lb-1

deployed_in
posts_lb
«container»

HAProxy:80

D: use of Model-Driven *, E: automatic source code generation, posts_db-1

deployed_in
posts_db
«container»

MySQL:3306
posts_ms
«container»

GlassFish:4000

F: automatic deployment, and G: cloud support. In this way, rancher_server posts_ms-2

deployed_in

posts_ms-1

Sarch uses a notation defined from a set of architectural IP:8080

node4
deployed_in

node3

styles/views to describe and model the relevant elements of an posts_wa-1

deployed_in
posts_wa
«container»

GlassFish:8080
posts_ms
«container»

GlassFish:4000

architectural design. In addition, the Sarch grammar and its posts_ms-3

deployed_in
posts_ms
«container»

GlassFish:4000

textual representation allow an automatic software architecture

documentation. Moreover, Sarch addresses the software
development process with the automatic code generation from a Figure 4. Deployment and C&C view for the Posts system in Sarch.
set of defined functionalities and a MDD process. In addition, it Scenario: posts_ms scaled 3 times and posts_wa, posts_lb and posts_db scaled
is important to mention that the main advantages of the Sarch once.
approach is its support for the automatic software deployment in
a cloud platform. This allows the ability to take architectural
decisions from the model in order to applying the performance
and scalability perspective through a dynamic scaling of
components.

TABLE I. APPROACHES VS. MAIN ASPECTS

A B C D E F G
1st Approach X X X Figure 5. Rancher server environment with 4-nodes infrastructure on the
2nd Approach X X X X cloud.
3rd Approach X X X X
4th Approach X
5th Approach X X
Sarch Approach X X X X X X X For the analysis, a set of test cases was selected to analyze
the performance of the system when changes are made to the
scale value in Sarch (for MS and WA components), i.e., when
B. Practical Analysis there are different scenarios for the horizontal scaling tactic. In
the same way, each scenario was tested from the generated stress
A case study is presented as part of the approach evaluation. test plan for the "create posts" functionality in the system, and
In this way, an architecture has been designed in Sarch, in order with different number of concurrent users (requests). The results
to analyze the results of the software system implementation and of this analysis is shown in Table II, where the numeric values
deployment. The case study consists on a web application to represent the average Response Time (RT), i.e., the length of
handle Posts. In particular, the application allows to perform the time the system takes to give an answer to a request (time in
four CRUD operations for the posts, which have two attributes: milliseconds) [2], and the Throughput (T), i.e., the amount of
title and content. A graphic representation of this case study, as workload the system is capable of handling in a unit time period
well as the representation in Sarch language are shown in Figure (transactions/minute) [2]. In addition, a graphical representation
4. Emphasis is placed on Deployment and C&C styles because of the system performance in each of the scenarios is shown in
they are the basis for the MDDep approach. However, Data Figure 6, where it is also possible to see the knee for each of the
Model and Layered styles are the basis for the implementation curves, that is, the point at which the system reaches its
of the components designed for the case study. The server node

102
maximum responsiveness (peak load behavior) [2]. For modeling, e.g., with the approach proposed in this work to take
conducting the tests was used JMeter, an Apache tool that allows architectural decisions focused on the performance and
the execution of different types of software testing, specially scalability. As a future work, we will define a greater scope for
load tests [25]. In this case, JMeter allowed the execution of each Sarch, in which there is a greater collaboration of architectural
scenario with the different alternatives in the number of styles and their views, in order to allow the modeling of other
concurrent users, from the stress test plans generated by Sarch. types of software systems, of high and low complexity. In the
same way, strengthen the theoretical bases of MDDep to
TABLE II. STRESS TEST RESULTS introduce new ways of dealing with other software quality
attributes such as high availability.
Scenario 1 Scenario 2 Scenario 3
Users MS: 1, WA: 1 MS: 2, WA: 1 MS: 3, WA: 1
RT T RT T RT T REFERENCES
0 0 0.0 0 0.0 0 0.0
1 210 49.6 199 50.0 194 50.3 [1] R. N. Taylor, N. Medvidovic, and E. M. Dashofy, Software Architecture
5 218 246.3 203 294.4 200 250.0 - Foundations, Theory, and Practice. 2010.
50 310 2290.1 223 2453.0 235 2429.1 [2] N. Rozanski and E. Woods, Software Systems Architecture, 2nd ed. 2011.
100 503 3992.0 491 4024.1 484 4043.1 [3] P. Clements, F. Bachmann, L. Bass, D. Garlan, J. Ivers, R. Little, P.
200 1185 5492.0 1067 5805.5 1061 5822.4 Merson, R. Nord, and J. Stafford, Documenting Software Architectures:
250 1599 5771.5 1319 6468.3 1228 6732.5 Views and Beyond. 2011.
300 - - 1794 6442.4 1603 6915.1 [4] I. Damyanov and M. Sukalinska, “Domain Specific Languages in
310 - - 2010 7948.7 1682 6935.1 Practice,” Int. J. Comput. Appl., vol. 115, no. 2, pp. 42–45, 2015.
[5] M. Brambilla, J. Cabot, and M. Wimmer, Model-Driven Software
360 - - - - 2404 8299.2
Engineering in Practice, 1st ed., vol. 1. 2012.
400 - - - - - -
[6] N. Medvidovic and R. N. Taylor, “A Classification and Comparison
Framework for Software Architecture Description Languages,” Softw.
Eng. IEEE Trans., vol. 26, no. 1, pp. 70–93, 2000.
[7] S. Björnander, “Architecture Description Languages,” Mrtc.Mdh.Se,
2011.
[8] E. Demirli and T. Bedir, “Software Language Engineering of
Architectural Viewpoints,” Softw. Lang. Eng., no. December, pp. 311–
331, 2013.
[9] E. Demirli and B. Tekinerdogan, “SAVE: Software Architecture
Environment for Modeling Views,” 2011 Ninth Work. IEEE/IFIP Conf.
Softw. Archit., pp. 355–358, 2011.
[10] E. Demirli, “Model-Driven Engineering of Software Architecture
Viewpoints,” Bilkent University, 2012.
[11] “WebDSL.” [Online]. Available: http://webdsl.org/.
[12] E. Cavalcante, F. Oquendo, and T. Batista, “Architecture-Based Code
Figure 6. Performance curves with knee in each scenario. Generation: From π-ADL Architecture Descriptions to Implementations
in the Go Language,” Softw. Archit. 8th Eur. Conf. ECSA, pp. 130–145,
Based on the above, it can be evidenced that when horizontal 2014.
scaling is applying, the response times decrease and the [13] F. Oquendo, “pi-ADL: an Architecture Description Language based on
the higher-order typed pi-calculus for specifying dynamic and mobile
throughput increases. This implied that the scalability objective software architectures,” ACM SIGSOFT Softw. Eng. Notes, vol. 29, no.
is satisfied correctly and the design initially done with Sarch is 5, p. 1, 2004.
validated. [14] J. Aldrich, C. Chambers, and D. Notkin, “ArchJava: Connecting Software
Architecture to Implementation,” Proc. 24th Int. Conf. Softw. Eng. - ICSE
’02, p. 187, 2002.
VI. CONCLUSIONS AND FUTURE WORK [15] J. P. Arcangeli, R. Boujbel, and S. Leriche, “Automatic deployment of
distributed software systems: Definitions and state of the art,” J. Syst.
Based on the related work with SA and software automation, Softw., vol. 103, pp. 198–218, 2015.
[16] T. A. Lascu, J. Mauro, and G. Zavattaro, “Automatic deployment of
new approaches in the SA modeling have been proposed. In the component-based applications,” Sci. Comput. Program., vol. 113, pp.
first place, Sarch offers a set of complete options to model SA, 261–284, 2015.
which helps to have a greater consistency between the design, [17] J. Cala and P. Watson, “Automatic Software Deployment in the Azure
implementation and deployment of distributed software Cloud,” Computing, no. June, pp. 155–168, 2010.
[18] R. Di Cosmo, A. Eiche, J. Mauro3, S. Zacchiroli, G. Zavattaro, and J.
systems. Sarch can be seen as a first approximation to a new Zwolakowski, “Automatic Deployment of Services in the Cloud with
ADL, considering that it covers a wider scope than traditional Aeolus Blender,” vol. 3, pp. 397–411, 1973.
ADLs that are primarily focused on architectural [19] “Xtext.” [Online]. Available: http://www.eclipse.org/Xtext/.
documentation and a few to the automatic code generation. On [20] S. Newman, Building Microservices: Designing Fine-Grained Systems.
2015.
the other hand, MDDep is proposed as a new approach which [21] “Docker.” [Online]. Available: https://www.docker.com/.
can be considered as a variant of MDD. However, we [22] “Xtend.” [Online]. Available: https://eclipse.org/xtend/.
emphasize that the approach is based entirely on an [23] “Rancher.” [Online]. Available: http://rancher.com/.
architectural design based on the conception of quality [24] “Getting Started with AWS: Computing Basics for Linux.” p. 60, 2014.
[25] “Apache JMeter.” [Online]. Available: http://jmeter.apache.org/.
attributes of the software and how they can be solved from its

103