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

More documents

Recommendations

Info

6. Implementation each of the queries a set of meta-data for the request is created, as one query may contain different meta data from another one (e.g. tables which are located in different backend Cloud data stores). The operations on the MySQL packages are included in the commons.mysql package. This contains the MySQLPacket class, which provides a set of I/O operations for reading and writing on TCP streams, and specifically adapted to the MySQL packet format, e.g. read byte, read integer, read long, read string, write byte, write string, write long, etc. The MySQLPacket class provides a Java based representation of the MySQL packet. The processing of binary content in the SQL queries requires a special transformation in the scope of the system. For integration purposes with querying transformation component, we must send the query as a string which can be parsed prior to the transformation. Therefore, we encode the binary data contained in the MySQL request into base64, and inject it in the string representation of the query. Binary data in a received MySQL request is identified by the prefix binary. In the backend Cloud data store the binary data is stored in base64 format, but this transformation must be transparent to the user. Hence, the class provides decoding support when the component receives from the backend data store a previously stored base64 format, and sends it to the client as binary data. The MySQLConstants class included in this packet contains the protocol constants. The integration with the JBI framework of ServiceMix-mt is provided by the mysql.jbi package, where marshaling and demarshaling of the requests and responses to and from the NMF occurs. The detailed content of the marshalled incoming requests and responses is described in Appendix B.1. As the MySQL requests and responses differ, in Chapter 5 we design two different contents. The data retrieval operation responses to the MySQL client must be sent as java.sql.ResultSet objects, which are contained in the java.sql.Statement. This fact forces us to implement such objects, and its methods, as the response from the CDASMixjdbc component stores the retrieved data in a java.util.ArrayList. The demarshaler in this package creates the java.sql.ResultSet and the java.sql.Statement, and populates it with the retrieved data in the java.util.ArrayList. Furthermore, the marshaler creates the java.sql.ResultSetMetadata with the meta-data retrieved from the backend database server. The meta-data contained in this object does not refer to connection or tenant-aware meta-data, but the meta-data of the table, rows, and columns of the backend database where the query is executed. The NMConstants class contains the standardized naming we define of the properties and attachments in the NMF. The MessageExchangeHandler class implements the operations which directly invoke the routing operations in the NMR API. The target JBI endpoint URI is dynamically created from the tenant and user UUID retrieved from the cache, or the service registry, and inserted in the MessageExchange target endpoint URI. After the creation of the MessageExchange, the synchronous sendsync operation of the NMR API is invoked, the message is routed, and the thread waits until the reception of the message from the JBI endpoint. As described before, the CDASMix MySQL proxy component interacts with two main components to retrieve tenant’s information: Registry Cache, and the Service Registry. The former is provided by the OSGi bundle jbi.servicemix.registry, while the latter is connected through a set of methods provided in the mysqlproxy.registry package in the CDASMix MySQL proxy component. The cashing interface provided by the jbi.servicemix.registry implement the put 66
6.1. SQL Support Implementation and get operations, where the cashing key, and the data to store are provided. The mysqlproxy.registry accesses the cache through this interface, but dynamically creates the cashing key for the object it stores, following the format described in Listing 6.2. Three different types of information identified by a unique tag are stored in the cache: tenant authentication, tenant backend data source properties, and query results. 1 CACHE_TENANT_INFO_ID_TAG + "#" + tenantId + "#" + userId + "#" + srcdb + "#" + srcTable; 2 CACHE_TENANT_AUTHENTICATION_TAG + "#" + tenantId + "#" + userId + "#" + srcdb; 3 CACHE_QUERY_RESULT_TAG + "#" + tenantId + "#" + userId + "#" + targetdb + "#" + query; Listing 6.2: Dynamic creation of cache keys to store the different types of data and metadata. When the information is not located in the cache, the service registry is queried, and its result cashed. The CDASMix MySQL proxy establishes a database connection with the PostgreSQL database server where the service registry is hosted when the component is deployed. A dedicated connection for this component reduces the latency of creating a database connection per received MySQL request. 6.1.2. Multi-tenant ServiceMix Camel Service Engine The ServiceMix-camel-mt JBI SE provides integration support between the Camel router, and the JBI environment. This SE includes in its package the camel-core libraries, in order to interact with the camel endpoints which are by default included in it, e.g. camel-email, camel-jms, camel-http, camel-ftp, etc. Muhler extends in his work this SE in order to include multi-tenancy awareness [Muh12]. In this subsection we describe the modifications he makes, and the extensions we develop to make it compatible with the requirements of our system. The Camel router provides support for describing its routes in two styles: POJO, and Spring. The former allow programmers to describe the camel routes in a Java class which extends camel’s RouteBuilder class, while the latter allows the route description in XML format. Files which describe the routes are packed in SUs, and these in a SA. The CamelSpringDeployer class in ServiceMix-camel-mt implement the necessary methods for extracting the routes for deployment. Muhler extends this class in CamelSpringDeployerMT, and includes tenant-aware operations for injecting tenant-aware information in the service and endpoint URIs. However, the tenant-aware information is not enough in our system, due to requirements specified in Chapter 4. Therefore, we extend his work by adding the tenant’s user information in the multi-tenant information injected in the URIs. A Camel JBI endpoint is identified by the prefix jbi:, and the endpoints are classified into two types: consumer, and provider. Consumer endpoints receive message exchanges from endpoints exposed in the NMR, while providers forward the message exchanges to JBI endpoints exposed in the NMR, or to external services. The CamelConsumerEndpoint and CamelProviderEndpoint classes include the endpoint configuration, and the necessary methods for creating and accepting message exchanges. Hence, we modified them and included 67
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 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 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?