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

More documents

Recommendations

Info

5. Design stores have two main storage structures: database and table. Inside the table we find a second storage structure, rows and columns. The NoSQL databases are divided into different families, and for each family we find between the different vendors different namings which refer to the same storage structure. However, they all have in common the support of a main, and secondary storage structures. The data source entity stores the necessary information for providing access in the system, and for accessing the target databases in the target data sources. The configuration information is provided either by the tenant, or by the Cloud Data Migration Application, during and/or after the data migration process to the Cloud. We provide isolation in the registration of sensible information, e.g. access credentials, by indexing the table with the tenant and user Universally Unique Identifier (UUID). Whether transformation operations are required is detected by analyzing the value contained in the dsType attribute. The format of its value must comply the following standard: family-mainInfoStructure-secInfoStructure-version, e.g. sqldatabase-table-mysql5.1.2 for a MySQL database system, or nosqlKeyValue-bucket-object-1.0 for a bucket in Google Cloud Storage [Ora13], [Gooc]. The main information structure entity persists the data related to the database’s main storage structure, e.g. table in MySQL databases, and table, bucket, or domain in NoSQL databases. These storage structures are identified by its name in the backend data store. The locationid attribute in this entity categorizes one main information structure as source or target main information structure. A composite key formed by the name, locationid, and tenantid, is not possible in this entity. One tenant id may have the same name to identify two main information structure which are of a different database type, e.g. one SQL table, and one NoSQL bucket with the same name. Therefore, the entries in this entity are identified by a incremental id. The secondary information structure is used in our system only to persist meta-data for NoSQL databases. The knowledge level in the system of tenant’s migrated SQL databases lowers to the table storage structure, and one database is uniquely associated with one tenant, user, and endpoint in the target database system, e.g in Amazon RDS one database is accessed by the database instance identifier, and the host name [Amac]. However, different main storage structures can be accessed in NoSQL databases through the same user’s endpoint. Therefore, we need to persist one or more main storage structures per database system endpoint, and provide a second level, the secondary information structure, to register a tenant’s NoSQL database meta-data. For example, one tenant can create one or more buckets in the Google Cloud Storage system, and access them through the same endpoint [Gooc]. Buckets store one or more objects, which are identified by their name. We must then associate a tenant’s NoSQL data store with one or more buckets, and these with one or more objects. A composite key formed by the name, tenantid, and locationid, is not possible, for the same reason discussed previously. One tenant id may have the same name to identify two secondary information structure which are of a different NoSQL database type, e.g. one document, and one object with the same name. Therefore, the entries in this entity are identified by a incremental id. As the relationships between secondary and main information structure, main information structure and data source, and between data sources (source and target) are a one to one relation, we avoid with the cascade option deleting information which might be 50
5.1. Service Registry related with multiple entities, e.g. one target data source which is associated with two source data sources. The entities related to the upper entities, e.g. a second information structure related to a main information structure, and this to a data source, and to a service assembly, are set with the Java persistence property Cascade. The service assembly is the upper entity which defines the connection between one source, and multiple target data sources. The undeployment of a service assembly involves the deletion of the data sources which are related to the service assembly, and the main and secondary information structures. 51
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 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 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?