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

More documents

Recommendations

Info

4. Concept and Specification 4.8.3. Performance As discussed in previous sections, different performance indexes usually drive down in a system which relies on a high I/O operations number. Therefore, we must integrate additional mechanisms, e.g. cashing, in order to alleviate the performance fall. We mention in Chapter 3 not only performance benefits in terms of system efficiency when cashing, but also an economic efficiency when access to data involves an economic cost. 4.8.4. Scalability and Extensibility The system should offer clustering functionality and scale appropriately in a Cloud infrastructure. JBIMulti2 enables administration and management of more than one instance of ServiceMix [Muh12]. The horizontal scalability is out of the scope of this diploma thesis. This feature is contained in the diploma thesis "Extending an Open Source Enterprise Service Bus for Horizontal Scalability Support" [Fes12]. The integrated prototype should be upgradable and for this goal the decoupling of components have to facilitate changes in functionality. 4.8.5. Maintainability and Documentation The source code provided in this diploma thesis should be well commented and documented. The needed documentation should be shipped in the system’s package in order to provide the necessary steps and tips to lead to a running system and possible future extensions. Furthermore, a test suite containing the main operations and data needed to run on the Web service interface to configure the system must be provided for future automation purposes. 48
5. Design In this chapter we present the architectural solution taken into account to build the system which fulfills the requirements specified in Chapter 4. Due to the required communication support for SQL and NoSQL databases, we separate the architectural approaches and provide them separately. JBIMulti2 and ServiceMix-mt are the subsystems we must reengineer in order to aggregate transparent and dynamic routing functionalities. Therefore, we also provide in this chapter the needed extensions in the components conforming the system, e.g. service registry in JBIMulti2, and NMF in ServiceMix-mt. 5.1. Service Registry The service registry developed in Muhler’s approach [Muh12], and extended in Uralov’s work [Ura12], contains information related to the services, and policies which can be dynamically retrieved by the tenants. The services contains a WSDL file and implements an interface for its access. Furthermore, policies are attached to it in order to provide a dynamic discovery of services based on a set of rules. In this diploma thesis, we do not focus on service registering or service discovery, but on the endpoint configurations which are deployed by the tenants. These are stored in the service assembly entity, where the deployed SAs are persisted with tenant context information. A SA contains the SUs where the endpoint configuration is described. Therefore, we consider the service assembly entity as the start point of our extension in the service registry schema. We use the data sources name to refer to the user’s data sources, and categorize them as source or target data sources in the dsLocationId attribute. The data source name in source data source registrations must equal to the database name the user includes in his request to CDASMix. Source data sources are the ones the tenant physically accesses in our system, while the target data sources are the ones that the tenant logically accesses, but the system physically accesses. Physical location of the target data sources are described in the dsEndpointURL, and define the database endpoint’s host, port, and database name (an example is provided in Listing 7.1). A SA contains the routing information configuration for routing operations between endpoints. Hence, one service assembly identifies the tenant’s user source data sources. The source datasource can be connected to one or more target data sources, as shown in Figure 5.1. The self-referencing relation in the TenantBackendDS entity allows to reference one source data source with n target data sources. As discussed in Chapter 3, providing support for two different databases models, and for its different families (e.g. in NoSQL databases) forces us to dissect their storage structures, and provide a generic and extensible model in order to store its meta-data. The SQL data 49
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 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?