Diploma Thesis Santiago GÃ³mez SÃ¡ez - IAAS

More documents

Recommendations

Info

3. Related Works store may contain one or more users. In our prototype we ensure tenant and user isolation at both communication, and administration and management levels. Over the past decades, caching has become the key technology in bridging the performance gap across memory hierarchies via temporal or spatial localities; in particular, the effect is prominent in disk storage systems [HLS + 12]. Han et al. investigate how cost efficiency in a Cloud environment can be achieved, specially in applications which require a high I/O activities number, and present a CaaS (cache-as-a-service) model. Cloud providers offering data storage solutions present pricing models based on the storage size, usage per time, or number of requests. Amazon RDS costs $0.025 per hour for a Micro DB Instance usage [Amac], while Amazon DynamoDB $0.01 per hour for every 50 units of read capacity [Amaa], and Google Cloud Storage $0.01 per 1000 PUT, POST, GET requests per month [Gooc]. An I/O-intensive application whose database is hosted in the Cloud may produce a significant economic cost. The cost of continuously retrieving data from the Cloud data store, when existing temporal proximity between the data accessed, can be considered unnecessary, and reducible. Furthermore, the application’s overall performance can be reduced due to the network latency and, in the scope of this work, the use of an ESB to access the Cloud data store. In this diploma thesis we do not provide cashing as a service, but include cashing support to the sharded-based router pattern described in [SAB + 12]. Uralov enhaces ServiceMix-mt with cashing support for dynamic discovery and selection of Cloud data hosting solutions [Ura12]. However, we must adapt and extend it due to the lack of support of functionalities we require and the lack of full OSGi compliance. 3.1. SQL Approaches In this section we discuss about the different approaches ESB vendors take into account when accessing or storing data in SQL database systems, and compare it to the support we provide in this work. Most of the ESB vendors provide support for data persistency in RDBMS. However, it is restricted to output connections to DBMS. Fuse ESB provides JDBC data source support, enabling users to connect to a database and make SQL based queries and updates [Fus11]. This connection can be established during routing, when receiving a JMS or HTTP message in a consumer endpoint, etc. However, they do not provide support for native database communication protocol incoming messages, e.g. MySQL or PostgreSQL communication protocol. Thus, data consumer endpoints supporting native database protocols are not deployable. The same limited support is provided in the integration framework Camel, in its component Camel-jdbc [Thec]. JBoss presents its Enterprise Data Service Platform containing data services with SOA support, and an ESB [Red11]. Any organization currently using an ESB can interoperate their Data Services Platform through open standards [Red11]. Accessing the database layer using methods which implement the SOA, e.g. Web services, requires the application to support such methods. One of the main goals in this diploma thesis is to minimize the adaptations in the DAL when migrating the data to the Cloud. Furthermore, as we can see in Figure 3.2, connection utilizing native database protocol is established directly from the business 32
3.2. NoSQL Approaches Figure 3.2.: JBoss Enterprise Data Services Platform [Red11] application logic to the data service. In our approach we propose a native database connection through the ESB to the data service. 3.2. NoSQL Approaches In this section we discuss the different supports for accessing NoSQL databases of the main Cloud data stores vendors in the market, emphasizing on the communication protocols supported, the interfaces provided, and the Cloud storage standard CDMI. Schilling provides an overview on the different supported communication protocols, API, Command-line Interface (CLI), and message payload formats in Cloud providers offering NoSQL storage solutions. Amazon NoSQL provides two main supports for accessing and modifying data in their data stores: AWS SDK for Java, or a REST API. The former requires the installation and the adaptation of the DAL to the set of functionalities provided by their JAVA SDK [Amaa]. Therefore, due to our main goal of minimizing changes in the on-premise application, we discard this approach, and do not provide further information. The latter consists in a set of functions accessible through HTTP messages and supporting a JSON payload format. Google Cloud Storage provides a REST API where XML payload is supported as default, and JSON in an experimental phase [Gooc]. MongoDB provides both a Java API and a REST API for accessing the databases [10G]. In the first place, we note that most of the NoSQL database providers offer their own API developed in different languages for accessing their data stores. However, as discussed before, the installation of an external API forces to make a considerable number of modifications. Most of the Cloud data store providers support for REST operations. The CDMI standard defines a Cloud data access standardized protocol JSON over HTTP and provides a set of operations on the stored data [Sto12]. Therefore, we consider this as the standardized access method and provide support for it in our prototype. 33
Page 1: Institute of Architecture of Applic
Page 5 and 6: Contents 1. Introduction 1 1.1. Pro
Page 7 and 8: Contents 7.3.3. Evaluation Analysis
Page 9 and 10: List of Figures 1.1. Migration Scen
Page 11 and 12: List of Tables 4.1. Description of
Page 13: List of Listings 5.1. Tenant-aware
Page 16 and 17: 1. Introduction and multi-protocol
Page 18 and 19: 1. Introduction Definitions List of
Page 20 and 21: 1. Introduction • Implementation,
Page 22 and 23: 2. Fundamentals usage of it. PaaS p
Page 24 and 25: 2. Fundamentals 2.2.1. Enterprise S
Page 26 and 27: 2. Fundamentals through the network
Page 28 and 29: Management Framework Component Fram
Page 30 and 31: 2. Fundamentals corresponding works
Page 32 and 33: 2. Fundamentals the tenant level, b
Page 34 and 35: 2. Fundamentals 2.9. Structured Que
Page 36 and 37: 2. Fundamentals 2.9.2. PostgreSQL D
Page 38 and 39: 2. Fundamentals 2.10.1. Key-value D
Page 40 and 41: 2. Fundamentals User Interface Web
Page 42 and 43: 28 2. Fundamentals
Page 44 and 45: 3. Related Works and balancing the
Page 48 and 49: 3. Related Works In the second plac
Page 50 and 51: 4. Concept and Specification VM0 or
Page 52 and 53: 4. Concept and Specification then f
Page 54 and 55: 4. Concept and Specification 4.3. D
Page 56 and 57: 4. Concept and Specification 4.6. U
Page 58 and 59: 4. Concept and Specification Name G
Page 60 and 61: 4. Concept and Specification Name G
Page 62 and 63: 4. Concept and Specification 4.8.3.
Page 64 and 65: 5. Design stores have two main stor
Page 66 and 67: 5. Design userId serviceName XMLNam
Page 68 and 69: 5. Design received in the vendor’
Page 70 and 71: 5. Design JBI SA into an OSGi conta
Page 72 and 73: 5. Design Apache Camel provides a s
Page 74 and 75: 5. Design External Application Lege
Page 76 and 77: 5. Design External Application Exte
Page 78 and 79: 6. Implementation the bundle activa
Page 80 and 81: 6. Implementation each of the queri
Page 82 and 83: 6. Implementation multi-tenancy awa
Page 84 and 85: 6. Implementation The HTTP endpoint
Page 86 and 87: 6. Implementation stored. Both auth
Page 88 and 89: 74 6. Implementation
Page 90 and 91: 7. Validation and Evaluation We mus
Page 92 and 93: 7. Validation and Evaluation When t
Page 94 and 95: 7. Validation and Evaluation in the
Page 96 and 97:
1. Introduction 1. Introduction 7.
Page 98 and 99:
7. Validation and Evaluation proble
Page 100 and 101:
7. Validation and Evaluation access
Page 102 and 103:
8. Outcome and Future Work The func
Page 104 and 105:
90 8. Outcome and Future Work
Page 106 and 107:
Appendix A. Components A.2. CDASMix
Page 108 and 109:
94 Appendix A. Components
Page 110 and 111:
Appendix B. Messages 20 - target da
Page 112 and 113:
Appendix B. Messages 110 111 - OK r
Page 114 and 115:
Appendix B. Messages 1 interface: l
Page 116 and 117:
102 Appendix B. Messages
Page 118 and 119:
Bibliography [CC06] F. Chong and G.
Page 120 and 121:
Bibliography [SAS + 12] [SBK + 12]
Page 122 and 123:
Acknowledgement I am heartily thank
show all

Diploma Thesis Santiago GÃ³mez SÃ¡ez - IAAS

Create successful ePaper yourself

Delete template?

Save as template?