=Paper=
{{Paper
|id=Vol-1531/paper8
|storemode=property
|title=A Flexible Approach for Adding Middleware Completions to Software Performance Models
|pdfUrl=https://ceur-ws.org/Vol-1531/paper8.pdf
|volume=Vol-1531
|dblpUrl=https://dblp.org/rec/conf/models/Faisal15
}}
==A Flexible Approach for Adding Middleware Completions to Software Performance Models==
https://ceur-ws.org/Vol-1531/paper8.pdf
A Flexible Approach for Adding Middleware
Completions to Software Performance Models
Adnan Faisal
Department of Systems and Computer Engineering
Carleton University
Ottawa, Ontario, Canada
faisal@sce.carleton.ca
I. PROBLEM
II. RELATED WORK
Models used for software development represent mostly the
functional properties of the software, without modeling the Four lines of related research on performance completions
platforms on which the software will run. However, from a have been found. Wu et al. [8] propose a subsystem modeling
performance modeling perspective, the information about the approach in the context of LQN, which has variability only in
underlying platform infrastructure (e.g., middleware, operating parameters, but not in structure. Verdickt [9] in line two took
system, hardware, networks) on which the software will be the approach of manually modeling CORBA middleware in
deployed is essential for the analysis of software performance UML, weaving it to application software model, and then
(e.g., System response time, Throughput). This issue was manually transforming the middleware-aware software model
identified by Woodside et al. [1] and the authors called these from UML to LQN. This approach has automation only in one
added performance model elements performance completions. step (i.e., weaving middleware model to software model), and
A key completion for a distributed application is its even this is done only for CORBA (i.e., not middleware in
middleware [2, 3]. general). The third line of research is a component-based
Many previous studies have shown that platforms play a modeling approach in the context of Palladio Component
key role in software performance. Just to mention a few, in Model (PCM) [10]. Happe et. al. [11] proposed pattern-based
Juric et al. [5] and Gómez-Martínez et al. [6], the response time performance completions for Message Oriented Middleware
of message transmission is compared for various middleware (MOM); Becker [12] proposed coupled transformations to
(e.g., RMI, RMI-SSL, SOAP), and it is shown that the response compose completions into both generated code and a
times can vary as much as 14%, depending on the middleware performance model; Strittmatter et al. [13] used feature models
used. In Faisal et al. [4] the impact of network latency on the and completions to build a particular communication
performance of software deployed across multiple clouds is infrastructure from an abstract connector model; Kapova [14]
investigated, showing that deploying an application to a more introduced variability in the model transformation process
powerful cloud may cause performance degradation rather than (rather than just in the model instances). The fourth line of
gain if the communication overhead is too high. Therefore, it is research is based on Aspect Oriented Modeling (AOM). Alhaj
very important for the performance modelers to have a et al. [15] proposed an approach to transform platform
systematic method for building performance models for the independent-model to platform-dependent model in the context
platform infrastructure, and especially for the various features of a model transformation chain that generates queueing-based
presented within a middleware. This gives them the performance models from UML design models of service-
opportunity to rapidly build performance models for changing oriented applications. The Reusable Aspect Model (RAM)
circumstances and to reuse existing middleware models. proposed by Keinzle et al. [16] can be used to model
The objective of the proposed research is “to develop a middleware variability of functional requirements, whereas this
systematic, flexible framework that enables model research aims to model the variability of non-functional
completions for a wide range of middleware for software requirements for performance prediction.
performance models”. The goal of such modeling is to predict The present work is different in two important ways from
how an application software would do in terms of performance its predecessors. First, it considers pure performance model
if deployed to different middleware platforms with various completions, not completions as components as in the first and
features. The proposed framework is flexible because it offers a third research lines. A model completion is both more general
mechanism to model a wide range of middleware and their and simpler than a component or connector completion. The
features. Also, the size of the produced models are flexible as second difference is that (unlike the second, third and fourth
the framework allows the modeler to choose desired level of research lines) the completion is defined and composed at the
modeling details. performance model level, not in the software specification.
This is often simpler because the performance model is at a
more abstract level than a design model (e.g., PCM or UML).
These differences give two advantages. First, the resulting purpose of brevity, only two weather stations are shown in this
performance model is smaller and simpler. Second, design model.
details may be confidential or simply unavailable, and for such Each concurrent entity (called a task) is represented by two
cases a performance model may be constructed as a “black or more attached rectangles. The rightmost rectangle shows
box” for the middleware, then composed using the methods task name and a parameter for its thread-pool multiplicity (e.g.,
proposed here. {10}, default value = 1). It has attached rectangles to the left
that represent its operations, called entries and labeled with the
III. PROPOSED SOLUTION host (CPU) demand for one invocation of the entry (e.g.,
The various models that take part in the proposed [$msg*ws1]) and think time (e.g., (Z1)). Each task has a host
framework are shown in Figure 1. The Base Middleware processor drawn as an oval, with a multiplicity (e.g., {32},
Model (BMM) is the simplest possible middleware, which is in default value = 1) which can represent multiple cores. A call
reality a single call. The commonality and variability in from one entry to another is represented by an arrow labeled
different middleware features are identified and modeled as with the average number of calls (default value=1).
feature models. These feature models are realized in Feature
Realization Models (FRM). Which features to be composed to
the BMM are described in a Feature Composition Descriptor
(FCD) and given as input to the “Compose Feature” module of
the Middleware Composition Engine (MCE) to produce
feature-aware Specialized Middleware Model (SMM). The
SMM is calibrated to obtain its service time under various
workload.
The next step is to compose the SMM to an application Fig. 2. LQN model of WeatherApp
software model that does not contain a middleware model. This
IV. PRELIMINARY WORK
software model is called Base Software Model (BSM). The
“Compose Middleware” module of the MCE takes BSM, SMM By carefully observing the popular commercial middleware
and MCD (Middleware Composition Descriptor) as input to products (e.g., RMI, Servlet, SPRING, JMS, Web Services), it
produce middleware-aware Specialized Software Model can be seen that in every middleware the caller and callee must
(SSM). do some marshal/wrapper operation to send and receive
The performance models can come from any model- messages respectively. This can be seen as a Mandatory
creation process, but in this research they are assumed to come Feature for every middleware. But, there are many other
from a Domain Specific Language (DSL) targeted for operations (e.g., NameService, Encryption,
performance modeling called Layered Queuing Network ContainerOperations) that may or may not be present in a
(LQN) [7]. The LQN models can be executed (both middleware. We call such operations as Optional Features. A
analytically and by simulation) to obtain different performance minimum middleware is modeled using BMM, and its
metrics such as response time, throughput, utilization etc. mandatory and optional features are modeled using feature
models and their realizations.
A. Base Middleware Model (BMM)
The BMM contains the minimum number of (i.e., two)
tasks and hosts needed to carry out a call in distributed
communication. These two tasks represent the caller and the
callee. The double bar(||) before the name of a model element
tells that this element is a placeholder and it is going to be
replaced by the corresponding client or servant element in the
composed model. The BMM (and also the realization models
that are introduced later) have the following properties: mean
number of calls for each call, network latency, multiplicities of
tasks and hosts, and call-type (i.e., blocking or non-blocking).
Their default values are 1, 0, 1 and blocking respectively.
Fig. 1. Overview of the Proposed Framework These default values can be modified in the FCD.
The LQN models are capable of representing the software
components and their deployment, in order to capture inter-
component communications, and to analyze resource
interactions between layers of the application. Figure 2 shows
an LQN model for a distributed weather application
(WeatherApp). This is a two layer application where weather
stations located in various parts of the city send data to a Fig. 3. Base Middleware Model (BMM)
central weather center for data collection and analysis. For the
B. Feature Model element tells that this element is going to stay in the composed
The available roles of a middleware are represented using a model.
base feature model (whose root element is A feature can be implemented as either PMR, SMR or both
MiddlewareFeatures) and a number of sub-feature models. The and kept in the model library. The appropriate realization is
base feature model has one mandatory feature called Wrapper. invoked from the library as required by the performance
This feature essentially models the marshalling operation. All modeller.
other features (e.g., Compression, Encryption, Broker) are
optional features.
There are some features (e.g. Broker, ServiceManager) that
have their own sub-feature models. A feature with sub-features Fig. 6. Structure-modifying realization of encryption feature
is shown in thick borders in a feature diagram. A sub-feature
D. Realization Composition
can have further sub-features nested within one another. The
MiddlewareFeatures are shown in Figure 4. In Figure 5, Broker The BMM is specialized by composing the realizations of
and ServiceManager features are shown in thick border, the required features to it. For every feature, the following
indicating they may contain further sub-features. information needs to be provided for its realization
composition. (Note that, each of this information has an
associated switch to identify it in FCD. Below, the switches are
written in parentheses after the name of the information.)
Realization type (-t): can be either PMR or SMR.
Realization destination (-d): tells where a realization to
be composed. The destination can be either a call’s client,
call’s servant, both to call’s client and servant (which is
Fig 4. Base feature model default), or to a call itself where the feature (e.g. broker)
neither adds operations to the client nor to the servant.
Realization host (-h): can be either self, bound or single.
Self means the realization tasks are deployed at their own
separate hosts. Bound (which is the default value for SMR)
means the realization task is deployed to its destination
tasks host. Whereas, ‘single’ can be used only when the
realization destination is ‘both’ but both of the realization
Fig. 5. Sub-feature models of ServiceManager and Broker tasks share a single host. Note that, PMRs are always of
‘bound’ type.
C. Feature Realization
Realization properties (-p): These are optional list of
Since the BMM is modeled in LQN, the features have to be property parameters to be passed to customize the
also realized in LQN. A feature can be realized in two different realization. These properties include call-type (blocking or
ways: Property-Modifying Realization (PMR) and Structure- non-blocking), mean number of calls, multiplicity of
Modifying Realization (SMR). PMRs do not modify the realization task and its host etc. This point is not further
structure of the BMM, rather they only update model properties discussed here due to the lack of space.
(e.g., service demand, call-type etc.). PMRs keep the model Sometimes the order of realization composition to the
compact and are useful when the modeling the concurrency of BMM may affect the performance overhead. Therefore, a
a feature is not essential. For example, the PMR of encryption default “order value” is assigned to every realization,
feature is as follows: causing the realizations to have a “partial ordering” among
Encryption.demand = $ENCRYPT+$msg*$encrypt
themselves. Also, the ordering for the recipient of a call is
The service demand in a realization (as shown in the
reverse than the ordering for the source of a call. For
equation above and also in Figure 6) has two parts: a constant
example, compression realization has a lower order value
part represented in UPPERCASE letters (e.g., $ENCRYPT)
than encryption realization. Therefore, if a BMM is to be
and a variable part represented in camelCase letters (e.g.,
composed with both encryption and compression
$encrypt) multiplied by the message size ($msg).
realizations, then for the source of the call the Middleware
The other type of realization, namely SMR, carry more
Composition Engine (MCE) would compose the
information than PMR. SMRs increase the size of the model by
compression realization first, then encryption realization.
adding tasks and hosts, but they allow to model concurrency.
But for the recipient, the encryption realization would be
Figure 6 shows the SMR of encryption feature. SMRs of many
composed first, and then the compression realization. This
other features such as compression and wrapper would also
is logical because the recipient has to decrypt the message
take the same structure, but only the service demand
first before uncompressing it.
parameters would change (e.g., for compression it would be
Note that, one must use SMR if one is interested to
$compress and $COMPRESS instead of $encrypt and
keep the ordering of operation in one’s model, because
$ENCRYPT). The single bar(|) before the name of a model
PMRs do not preserve concurrency. Also note that the
default partial ordering can be overridden using realization described in a text file called Middleware Composition
properties. Descriptor (MCD). It is possible that many (or even all) of the
calls of a BSM use the same middleware. For all those calls,
E. Obtaining Specialized Middleware Model
the middleware of choice should be preferably mentioned only
The list of realizations to be applied to the BMM are once in the MCD. In order to achieve this advantage, the
described in a text file called Feature Composition Descriptor concept of callgroup is introduced, that simply identify a set of
(FCD). The MCE reads the FCD and composes the FRMs to calls by a single name.
the BMM, producing Specialized Middleware Model (SMM). The MCD file starts with the name of the BSM, followed by
The first line of the FCD contains the name of the base model the –o switch and the name of the SSM. The rest of the file can
(in this case BMM), followed by a colon (:) and source and be divided into two blocks: callgroup and middleware
destination entries (between a “greater than” sign) that form the descriptions. For example, consider the following MCD which
call to be updated. Then the type of the call is mentioned after – describes that the WeatherApp BSM presented in Figure 2
c switch. The subsequent lines of the FCD file describes the should be composed with the Specialized Middleware Model
features to be composed. Each of these lines begin with the SMM1 shown in Fig. 7.
name of the feature to be applied, followed by composition
information separated by switches. If the source model is weatherApp –o weatherAppSpecialized
BMM, then one of the features must be the Wrapper feature callgroup ws_wc
since it is a mandatory feature. The last line of the description WS1 > wCenter
block contains the –o switch followed by the name of the WS2 > wCenter
middleware
output model. Below is an example of an FCD
ws_wc SMM1 –s Servant_Encryption
BMM:c>s –c block
Wrapper –t struct –d both –h bound On the second line of this MCD, a callgroup named ws_wc is
Compression –t value –d both declared, which has two calls described in the next two lines.
Encryption –t struct –d both –h single Then the middleware section begins. Here only one
SMM –o “SMM1” middleware (SMM1) is applied to one callgroup (ws_wc). The
switch –s tells MCE that the task Servant_Encryption is a
When this FCD is given as input to the MCE, the SMM shared task, meaning it should be created only once and all the
shown in Figure 7 is produced. MCE carries out the calls in the group should share it. The resultant SSM is shown
composition process respecting the partial ordering of the in Figure 8.
features. The produced SMM is the model that is calibrated and
is going to be composed to the BSM.
A powerful property of FCD is that, the performance
modeler is not limited to apply features only to the BMM.
Rather, any SMR (such as broker) can be referred as the base
model in the FCD, and then the subfeatures of that feature can
be composed to obtain specialized submodels to be further
composed to the BMM.
Fig. 8. Specialized Software Model (weatherApp+SMM1)
Note that there is only one task (SMM1_Serv_En) that
handles encryptions at the server side instead of two tasks. This
happened due to the use of the –s switch in the MCD.
V. EXPECTED CONTRIBUTIONS
The main contribution of this research is a flexible, reusable
approach to represent the performance impact of a large range
Fig. 7. Specialized Middleware Model (SMM1). of middleware, including many optional features. This is
achieved through the following contributions to knowledge:
F. Obtaining Specialized Software Model Modeling the commonality and variability that is present
One or more SMMs are composed to the BMM to obtain a in various middleware. This is done by means of the
Specialized Software Model (SSM). The description of what following sub-contributions: a) proposing a BMM and
middleware to be composed at what calls of the BSM is
identifying its properties so that it can be adapted to a large supervisors, Prof. Murray Woodside and Prof. Dorina Petriu,
range of middleware, b) identifying and grouping the for their continuous support and invaluable feedback.
middleware features and presenting them in feature models
and sub-feature models. REFERENCES
Solving the frequently occurring modeling problem of [1] M. Woodside, D.B. Petriu, K. H. Siddiqui, “Performance-related
“state explosion” by proposing two kinds (SMR and PMR) Completions for Software Specifications”, Proc. 24th Int. Conf.
of realizations for a middleware feature. on Software Engineering , Orlando, May 2002.
Developing syntax for describing the choice of features [2] G. Coulouris, J. Dollimore, T. Kindberg, G. Blair, Distributed
and choice of middleware in the forms of FCD and MCD Systems Concepts and Design, 5th Edition, Pearson Ed. 2012.
[3] A. Faisal, D. C. Petriu, M. Woodside, “A Systematic Approach
respectively.
for Composing General Middleware Completions to
Describing a process to calibrate the SMM to obtain its Performance Models”, in Computer Performance Engineering
service time under various workload. (Proc. European Performance Engineering Workshop EPEW14,
Developing algorithms for MCE so that it can compose Florence Sept. 2014), LNCS vol. 8721, Springer, pp 30-44.
BMM with FRM to obtain SMM, and BSM with SMM to [4] A. Faisal, D. C. Petriu, M. Woodside, Network latency impact
obtain SSM. on performance of software deployed across multiple clouds,
This work also has the following practical contributions: Proc CASCON 2013, pp 216-229, Nov 2013.
Tool support for storing the BMM and FRMs in a model [5] M. B. Juric, I. Rozman, B. Brumen, M. Colnaric, M. Hericko,
library. “Comparison of performance of Web services, WS-Security,
Tool support to automatically obtain SMM and SSM from RMI, and RMI-SSL”, Journal of Systems and Software, n. 79,
the required input models. pp. 689-700, 2006
Calibrating SMMs, and validating the calibrations and the [6] E. Gómez-Martínez, J. Merseguer “Impact of SOAP
generated models by comparing their performance metrics Implementations on the Performance of a Web Service-Based
Application”, Proc ISPA Workshops, pp. 884-896, 2006.
with those of the software applications running on a test-
[7] G. Franks, T. Al-Omari, M. Woodside, O. Das, S. Derisavi,
bed.
“Enhanced Modeling and Solution of Layered Queueing
VI. PLAN FOR EVALUATION AND VALIDATION Networks”, IEEE Trans. on Software Eng. v. 35, n. 2, pp. 148-
161, 2009
The proposed framework is verified by observing whether [8] X. Wu., M. Woodside, “Performance Modeling for Software
the MCE can construct composed models with desired Components,” Proc. 4th Int. Workshop on Software and
properties and level of details. Validation is done in two Performance, Redwood Shores, Calif., Jan 2004, pp. 290-301.
phases. First, in order to validate that a large range of [9] T. Verdickt, Performance Analysis of Distributed Systems Based
middleware can be modeled, we will compose an application on Architectural System Models, PhD Thesis, Dept. of Inf.
software with various types of middleware (e.g., Web Technology, Universiteit Gent, Belgium, 2007.
Services, Servlet, Spring) and compare the performance [10] S. Becker, H. Koziolek, R. Reussner, “Model-based
metrics of the composed application with SSMs generated by Performance Prediction with the Palladio Component Model”,
our framework. Second, in order to validate the modeling of Proc. 6th Int. Workshop on Software and Performance, pp. 56–
various features, we will choose a middleware and calibrate 67, 2007.
(i.e., get service time) it under various workloads. Then an [11] J. Happe, H. Friedrich, S. Becker, R. H. Reussner,“A pattern-
application software will be composed with that middleware in based performance completion for Message-oriented
which different set of calls will use different features. The Middleware”, Proc. 7th Int. Workshop on Software and
SSM will be validated by comparing its performance metrics Performance, pp. 165-176, 2008.
with those of the actual system. [12] S. Becker, “Coupled model transformations”, Proc. 7th Int.
Workshop on Software and Performance, pp. 165-176, 2008.
VII. CURRENT STATUS [13] M. Strittmatter, L. Happe, “Compositional performance
abstractions of software connectors” Proc. 3rd International
The author has developed a framework to model the
Conf. on Performance Engineering, pp. 275-278, 2013.
performance completions of large array of middleware and [14] L. Kapova, Configurable Software Performance Completions
their features. At present, a tool is being developed in Java to through Higher-Order Model Transformations, PhD Thesis,
automate the entire process of LQN model composition. For Karlsruhe Institute of Technology, 2011.
the purpose validation, experiments are being run on a test-bed [15] M. Alhaj, D.C. Petriu, "Using Aspects for Platform-Independent
and compared to those generated by the models.. The author to Platform-Dependent Model Transformations", International
expects to complete this research in one year. Journal of Electrical and Computer Systems, Vol. 1, Issue 1,
pp.35-48, 2012.
ACKNOWLEDGMENT [16] J. Kienzle, W. A. Abed, F. Fleurey, J. Jézéquel, J. Klein,
This research was funded by the Natural Sciences and “Aspect-Oriented Design with Reusable Aspect Models”,
Engineering Research Council of Canada through its Strategic Transactions on Aspect-Oriented Software Development, vol. 7,
Network SAVI (Smart Applications on Virtual Infrastructure) pp. 279 – 327, 2010.
and its Discovery Grant programs. The author thanks his co-