Results

Figure5.11shows the complete target LQN model as a result of applying the rules explained in this chapter to the CoupoNet example. Notice that the load-balancing task has been

added to compensate for the delay introduced by the target platform load balancing and networking overhead.

To validate the model generated as valid LQN model. We used the W3C XML Schema (XSD) Validator1_{. W3C XML Schema (XSD) Validator can be used to validate an XML} file against a schema to check if it conforms to the schema semantics. The tool also checks the well-formedness of the XML file. Using the W3C XML Schema (XSD) Validator we were able to validate the syntactical correctness and the well-formedness of the generated LQN model.

The LQN Solver (LQNS) is used to solve the generated LQN models. Appendix B shows the LQNS output results of the CoupoNet example. Using the results, a system administrator can analyze the response time and throughput of the system. By varying the usage profiles (e.g., number of users) and the deployment configuration, the administrator can also analyze the system performance under different deployment configuration or target providers. They can also study the system bottleneck and adjust the configuration, or define adaptation rules to enact auto-scaling actions.

Figure 5.12: The Change in Fetch Coupon Response Time with User Population

Figure5.12shows the results of analyzing the system response time for the fetch coupons scenario as the population of the coupon users increases. Such analyses are used to evaluate

the system scalability (maximum users supported with a specified response time). Several other analysis techniques and algorithms can also be applied on the generated LQN models. The LQN community created algorithms to identify the location of the system bottlenecks and to tune the multiplicity and replication parameters of software threads and processors to improve the system performance [122]. However, the evaluation of these techniques is out of the scope of this work.

5.6

Summary

This chapter extends the StratusML language to facilitate annotating the cloud models with the runtime performance parameters and generating performance models from the cloud applications on the fly. The chapter argued that LQN models are one of the suitable candidates as a target performance analysis formalism to represent the performance of cloud applications.

The chapter makes the following contributions:

(a) Evaluating performance modeling requirements based on the existing cloud deployed artifacts.

(b) Extending our StratusML framework to capture the application runtime parameters to enable generating analytical performance models from the StratusML models. (c) Defining a set of transformation rules to automatically transform the StratusML models

into LQN formalism.

A case study has been presented to show, in a step by step manner how an annotated StratusML models with performance parameters and how to apply the proposed transfor- mation rules to generate LQN models by utilizing the cloud application service deployment and configuration artifacts.

The meta-models presented in this chapter sum the description of the concepts of the (5+1) view models presented in Chapter3. Moreover, this chapter completes the realization of the StarusML framework presented in Chapter 4. The next chapter focuses on the framework evolution support. A set of semi-automated techniques for mapping domain concepts will be presented to support the process of meta-model creation, evolution, and transformation.

Chapter 6

Liberate: A Schema Matching

Approach to Support Service

Migration in the Cloud

“These vendors will never agree on standardized schema, but they have agreed on how they describe their schema.” – Jamie Lewis, president of the Burton Group. Cloud providers impose using specific schemas to specify the application services for deployment and operation. However, mismatches between providers’ schemas hinder appli- cation portability and lead to vendor lock-in. To address this problem, this thesis follows a model driven approach that facilitates specifying the cloud service using provider-agnostic constructs, and uses transformation techniques to generate provider specific configuration. As shown in the previous chapters, such model driven approach, depends on the ability to find mappings between the concepts of providers schemas. This is a daunting, error prone and time consuming task that is usually performed by the domain experts manually. To alleviate the efforts needed in this manual process, this chapter adopts a semi-automated schema matching approach. Schema matching can be used to identify the correspondences between the different providers’ schemas. This is important for (i) creating domain refer- ence models (i) keeping the reference models up-to-date as new domain concepts evolve, and (iii) creating mappings between the different reference models, or between the reference models and the platform specific models.

Schema matching exploits structural and linguistic similarities between schemas to identify matchings. This is a well known practice for ontology alignment and database

migration [145] in many domains, e.g: linked-data, e-commerce, and bioinformatics [47]. However, it has been less frequently exploited in the cloud domain. This is because, not all cloud providers’ schemas follow the same structural conventions. Moreover, the terms in these schemas use industrial jargons that may not share linguistic similarities. In this chapter, Liberate: a novel semi-automated schema matching approach has been devised to deal with these challenges. Liberate applies a generic structural similarity based on a modified similarity-flooding algorithm [103], and utilizes web search results, and gloss- based semantic similarity to incorporate domain knowledge in element-based similarity evaluation.

The rest of this chapter is organized as follows: Section 6.1 illustrates why schema matching is required and how generic schema matching solutions may fail to address the mismatch problem in the cloud. Section6.2presents our proposed solution, and how it has been realized. Section6.3evaluates the different matchers proposed against public schemas of two major cloud providers (i.e., Windows Azure and Google App Engine) and private schemas of two reference cloud models (StratusML and TOSCA). Finally, an executive summary and suggestions for future work is presented in Section6.4.

6.1

Preliminaries

Several approaches could be used to address the vender lock-in problem in the cloud [68]. Most of these approaches are based on model driven engineering. Regardless of the ap- proach selected, finding alignments between the different providers’ schemas, standards and models is unavoidable for mismatch resolution. This section shows some examples of the mismatches between cloud providers’ schemas and highlights the challenges of automatic schema matching in the cloud domain.