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-