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

More documents

Recommendations

Info

4. Concept and Specification 4.3. Dynamic Transparent Routing Data access and modification from different back-end data stores must be supported in a transparent way between the tenants. We divide this requirement into two sub-requirements we consider our system must fulfill: Transparency, and Dynamic Routing. 4.3.1. Transparency Giving a single logical view on a distributed database system abstracts the tenant from knowing the physical location of his data. The system must provide a single access endpoint for accessing and modifying data previously migrated to the Cloud. We must perform internally the necessary search operations in the registry containing the back-end data stores information, and the necessary mapping operations with the meta-data included in the tenants’ requests. After those operations, our system must forward the requests to the back-end data stores and forward the responses to the tenants’ requests. 4.3.2. Dynamic Routing Providing transparency by exposing a single endpoint to retrieve data from different back-end data stores requires the system to support dynamism in its routing mechanisms. One tenant may migrate one database to the Cloud, or shard a database between different databases in the Cloud, or different Cloud providers. This fact forces us to support connections to the back-end data stores dynamically rather than statically. Furthermore, when query and data transformation is required due to version or schema direct incompatibility between the tenant’s requests and the back-end data store support, transformation mechanisms must ensure transformation of queries and data in order to provide a full transparent access. When transformations are not needed, the message should not be routed through a transformer component. In the prototype developed in this diploma thesis query and data transformations are out of scope. When sharding a database, the tenant can split the data between two or more databases, or database systems. In order to minimize the changes in the application’s DAL, we must support a single physical frontend endpoint while processing the tenant’s request through one or more physical back-end endpoints. Special cases such as queries containing JOIN operations in between tables stored in different back-end SQL databases are not supported. However, the system should support the execution of multiple SQL queries in one request, which is known as multiple-queries. 4.4. Cache Cashing mechanisms in applications with high number of I/O operations benefits the application’s performance, as described in Chapter 3. The prototype developed in this diploma 40
4.5. Integration Requirements thesis provides support for application’s I/O operations. Therefore, cashing is one of the main components which can drive to a better system performance. In our system the cache must be shared between the tenants using it. Hence, data cashed must be previously enriched with tenant and user context information. Operations in our system which require data from local or remote databases, e.g. authentication operations or data retrieval operations, should utilize the cashing mechanism to reduce the response time of the system. Tenant operations which perform changes in their data stored in the Cloud may lead to inconsistencies between the data persisted in the cache and the updated data in the Cloud. Freshness of data in the cashing system must be ensured. 4.5. Integration Requirements Apache ServiceMix 4.x versions are built on an OSGi-based runtime kernel, Apache Karaf [ASM], [APA11b]. However, they provide JBI support for users migrating to newer versions. For new users it is recommended to consider JBI deprecated, and build the components and expose the services in OSGi bundles. We consider that developing our components as OSGi bundles eases the compliance with newer versions in ServiceMix, and enables loose coupling between components. When a component is modified, the components in the OSGi container which used the services of the modified component must not be redeployed. However, we find that the ServiceMix-mt component are JBI compliant. We must then provide integration support between the JBI components and the OSGi bundles. The NMR in ServiceMix eases the integration of the JBI and OSGi providing an API for accessing the NMR and creating message exchanges. However, the messages routed in ServiceMix-mt are in a NMF, which is a completely different format with the message formats supported in the MySQL, or JSON over HTTP communication protocols. The system must ensure the appropriate conversion and mapping operations for marshaling and demarshaling incoming and outgoing messages. As described in previous sections, tenant’s requests can be routed in ServiceMix-mt directly between one consumer and one provider tenant-aware endpoint when no query or data transformation is required. When transformation is required, we must design our components to be easily integrated with a future transformer component as an intermediary in the route between endpoints. JBIMulti2 is the application built on top on ServiceMix-mt to enable administration and managements operations on the ESB. Therefore, the deployment of tenant-aware endpoint configurations can be only done through JBIMulti2. The Cloud Data Migration Application lacks of connection and access to the registries where the tenants’ configuration data is stored. In order to avoid a database connection from the migration application, which may be hosted in an external server, to the registries which contain the tenant meta-data, we must provide an interface to allow either the tenant or the migration application to register the data store meta-data. 41
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 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 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?