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

More documents

Recommendations

Info

2. Fundamentals through the network. However, security and confidentiality are the main constraints when moving private data to a shared public infrastructure. Figure 2.1.: New market opened by lower cost of SaaS [CC06] In the Figure 2.1 the economics of scaling up to a high number of customers while reducing the software price is analyzed. Cloud providers have reached a new market formed by small or medium businesses without enough budget for building an on-premise IT infrastructure. Multi-tenancy refers to the sharing of the whole technological stack (hardware, operating system, middleware, and application instances) at the same time by different tenants and their corresponding users [SAS + 12]. Andrikopoulos et al. identify two fundamental aspects in multi-tenant awareness: communication, and administration and management [ABLS13]. The former involves isolated message exchanges between tenants and the latter allows tenants individual configuration and management of their communication endpoints. Utilizing an ESB as the central piece of communication middleware between applications in a PaaS environment forces it to ensure multi-tenancy at both communication, and administration and management, as mentioned before. The multi-tenancy support modifications made in the open-source ServiceMix 4.3 are the results of [Ess11], [Muh12], and [Sá12]. In this diploma thesis we reuse and extend those results in oder to provide multi-tenant transparent Cloud data access in the Cloud through the ESB, when the application’s data is migrated and accessed through the ESB in a Cloud infrastructure. The migration of an application’s stack to the Cloud can be done at different levels of the application’s stack: Presentation Layer, Business Layer, and Data Access Layer. The Replacements of Components with Cloud offerings migration type is the least invasive type of migration [ABLS13]. In this diploma thesis we focus on this type of migration, concretely when the used Cloud offering is the database system. Migration of the data can be either seen as the migration of the Data Layer (Data Access Layer and Database Layer) or of the whole application [ABLS13]. Migration of the Data Layer to the Cloud means migrating the both data management and data access to the Cloud, while maintaining its transparency to the application’s Business Layer. In a Cloud infrastructure where Cloud storage is offered, Feresten identifies four main tenant requirements: security, performance, data protection and availability, and data management [Fer10]. Multi-tenancy in a storage system can be achieved by aggregating tenant-aware 12
2.4. Java Business Integration meta-data to the tenant’s data (see Figure 2.2), or by physical storage partitioning, but this is not sufficient when fulfilling the data management, and the flexibility requirement. Tenants must have independent access and management, as if they accessed their own data storage systems. For this purpose, storage vendors have introduced the concept of virtual storage container, a tenant-aware management domain which grants all (or most of) the database management operations over the storage container, as described in Figure 2.2. Figure 2.2.: Attributes of a Virtual Storage Container [Fer10] In this diploma thesis we must take into account the different approaches that most of the Cloud storage vendors have taken into account, in order to provide the tenant transparent access through the ESB to his virtual storage container in one or more Cloud infrastructures. 2.4. Java Business Integration The interaction between enterprises’ applications has suffered in the past from lack of standardized technologies, leading each of the enterprises to develop their own or acquiring vendor-specific integration technology. Java Business Integration (JBI) is defined by the Java Community as an integration technology which maximizes the decoupling between components and defines an interoperation semantic founded on standards-based messaging. This allows different vendor-specific components to interoperate in a multivendor "echosystem" [JBI05]. The key which leads to the integration of different components relies on a unique message format in the JBI environment which different plugged-in components use to communicate within the environment. External components are not directly connected, but through a mediator. The communication mediator between components in a JBI environment is the Normalized Message Router (NMR). Its main functionality is the routing of the internal standardized Normalized Message (NM) between the components. However, it can perform additional processing during the message exchange. The NMR fields are defined as an eXtensible Markup Language (XML) document format payload, metadata conforming the header and a non XML document format attachment referenced by the payload. 13
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 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 46 and 47: 3. Related Works store may contain
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

You also want an ePaper? Increase the reach of your titles

Delete template?

Save as template?