Configurations Setting

This section describes the implementation of detailed configurations setting including database configuration, SQL inputs, and expected results.

While Cloud data store services have to be accessed remotely through Internet, within this systems a database configuration has been implemented explicitly. All required data service configuration are stored in allocated database configuration file calleddbconfig.xmlwith XML data format. Listing 7.4 shows an example database configurations for a few Cloud data store services, where the configurations are designed explicitly for every individual data store services.

In every configuration setting, it is considered including both Cloud service connection information as well as the specific data store service configuration. However, it is investigated that some of the Cloud data store services are feasible accessing directly through public URL. In this case the Cloud service connections information fields are holding null value, but the data store services configuration fields are stored with necessary values. For example, the database host would be the public URL of data store service. Furthermore, it is also realized that some for the data store services have to be accessed implementing with a public key authentication. In this case the application creates SSH tunneling session with specific database port forwarding and then access Cloud data through forwarded port. Implementing XML DOM parsing thegetDatabaseConfiguration()method inDatabaseConfiguration class, the system retrieves that necessary data store service configuration for a specific data service provider.

In addition, the database configuration can be updated in system running time. Once the database configuration is updated the system will automatically notify about the update and will use the updated configuration for the further data access. Nevertheless, for every data service provider the database configuration file has designed with fixed number of elements item. If it is required to change the structure of database configuration, then also

7. Implementation

1 <?xml version="1.0" encoding="UTF-8"?> 2 <dbconf>

3

4 <defaultmysql id="0" name="defaultmysqldb">

5 <cloudurl>NULL</cloudurl> 6 <clouduser>NULL</clouduser> 7 <dburl>jdbc:mysql://localhost:3306/</dburl> 8 <dbname>dbName</dbname> 9 <dbusername>dbUser</dbusername> 10 <dbpassword>dbPass</dbpassword> 11 </defaultmysql> 12

13 <ec2postgresql id="1" name="ec2postgresqldb">

14 <cloudurl>ec2-xxx-xxx-xxx-xxx.eu-west-1.compute.amazonaws.com</cloudurl> 15 <clouduser>ec2-user</clouduser> 16 <dburl>jdbc:postgresql://localhost:5432/</dburl> 17 <dbname>dbName</dbname> 18 <dbusername>dbUser</dbusername> 19 <dbpassword>dbPass</dbpassword> 20 </ec2postgresql> 21

22 <rdsoracle id="2" name="rdsoracledb">

23 <cloudurl>NULL</cloudurl> 24 <clouduser>NULL</clouduser> 25 <dburl>jdbc:oracle:thin:@dbName.ctdc03yqnvpy.us-east-1.rds.amazonaws.com:1521:</dburl> 26 <dbname>dbName</dbname> 27 <dbusername>dbUser</dbusername> 28 <dbpassword>dbPass</dbpassword> 29 </rdsoracle> 30 31 </dbconf>

Listing 7.4:A part of data store service configurationdbconfg.xmlfor enable accessing both traditional as well as the Cloud data.

it is necessary to update the data retrieving method in the system level accordingly, as currently thegetDatabaseConfiguration()method is implemented to get the fixed number of configuration elements.

As we consider evaluating Cloud relational data store services, a set of SQL statement inputs have been designed based on SQL standard 2003. In order to evaluate the adaptation of data access layer, the same SQL statements are to be executed in different data store services. Moreover, a set of corresponding expected SQL results are defined to the system for comparing with actual SQL statement execution results. The expected results are prepared based on traditional database server. The Table 7.1 shows a part of usages important SQL statements inputs and corresponding expected results.

7.1. Software Tool Implementation

Table 7.1.:A part of usages important SQL statements inputs and corresponding expected results.

SQL Statement Expected Result

SELECT object_id, access_level_browse FROM oocke1_- account account/CRX/Mohsin/admin-Mohsin 3 account/CRX/Standard/admin-Standard 3 account/CRX/Standard/admin-Standard Private 3 account/CRX/Standard/guest Private 3 account/CRX/Standard/NI7XwEIBEd29BeMf4vj8cA 3 SELECT object_id, access_level_browse

FROM oocke1_account WHERE object_- id=’account/CRX/Standard/admin-Standard’

account/CRX/Standard/admin-Standard 3 SELECT object_id, AVG (access_level_browse * access_-

level_delete) FROM oocke1_calendar GROUP BY ob- ject_id calendar/CRX/Mohsin/9LPADU3ML74YP2C3LAQ 7XUCUX 3.0000 calendar/CRX/Standard/DefaultBusinessCalendar 6.0000 calendar/CRX/Standard/e5uf4EIBEd29BeMf4vj8cA 6.0000

SELECT access_level_browse, full_name FROM oocke1_account INNER JOIN oocke1_account_ ON (oocke1_account.object_id=oocke1_account_.object_id) WHERE (oocke1_account_.idx=1) ORDER BY oocke1_- account.full_name 3 admin-Mohsin, 3 admin-Standard, 3 admin-Standard Private 3 Guest, 3 guest Private SELECT access_level_browse, full_name FROM oocke1_-

account LEFT JOIN oocke1_account_ ON (oocke1_- account.object_id=oocke1_account_.object_id) WHERE (oocke1_account_.idx=2) 3 admin-Mohsin, 3 admin-Standard, 3 admin-Standard Private 3 guest Private 3 Guest, SELECT persons.LastName, persons.FirstName, or-

ders.OrderNo FROM persons FULL JOIN orders ON per- sons.P_Id=orders.P_Id ORDER BY persons.LastName

Hansen Ola 22456 Hansen Ola 24562 Pettersen Kari 77895 Pettersen Kari 44678 Svendson Tove null null null 34764