An Integrated Architecture For Secured Cloud Data Transactions With Consistency Enhancements
J.Antony John Prabu1, Dr.S Britto Ramesh Kumar2
1Research Scholar and Assistant Professor,Department of Computer Science St. Joseph’s College, Trichy, Tamilnadu, India- 620 002
2Assistant Professor,Department of Computer Science St. Joseph’s College, Trichy, Tamilnadu, India- 620 002
Abstract:
Cloud computing is promising machinery that provides services hosted on the Internet. The amount of data delivered by various applications increases tremendously and many companies have moved their data to cloud servers. Because the cloud server providing scalable, reliable and highly accessible services to the users. One of the major issues in the environment of cloud data transaction management is how to gain secured data and achieve consistency enhancements during the transaction. This paper, proposed a integrated architecture for cloud data transaction to improve security and consistency. the proposed integrated framework using ASPNet was installed and developed as a cloud data exchange service. It has been used successfully in Azure operating system of cloud.
The AAA Server, CSC Server, CDL Server, D1 FTBC Server, Cloud DB and cloud storage server utilized to ensure the security and stability of data transactions in the cloud environment. finally, the performance of the proposed integrated system is analyzed , from which the proposed integrated configuration guaranteed efficient operation with improved performance.
Keywords: Cloud Architecture, Cloud Computing, Database Consistency, Data Transaction, Cloud DTM, 2- Phase Commit Protocol, Cloud Security, Cloud Controller, D1FTBC and Cloud Data Locker.
I. Introduction:
Cloud computing is a technology that is being utilized as an essential resource in IT industries for contributing different services to cloud vendors and clients. Cloud offers many services, such as platform as a service (PaaS), software as a service (SaaS), Infrastructure as a Service (IaaS) and Database as a Service. The cloud provides platform to maintains high level of data without worrying about hardware structure and maintenance. The combination of Saas , PaaS, Iaas and Daas are used in most of the cloud applications to provide reliable service. Data transaction system is considered to be a complicated system in cloud computing. In cloud computing, mostly data is stored and maintained by third party environment, so security is a main issue and also meet consistency problems when executing cloud data transactions. Therefore, it must maintain the guarantee of consistency to enable trustworthy data transactions. In this chapter, integrated architecture is proposed through Security and Consistency Frameworks for secured cloud data transactions. It portrays different security levels and guarantees of consistency for cloud data transactions. Finally, this chapter provides comprehensive research on proposed an integrated architecture to providing security and improving the consistency of data transactions in the cloud environment.
II. Review of Literature:
Antony and Britto [1] discussed the issues and challenges that occurred during the data transmission in cloud environment. This paper explained the necessity of ACID properties, advantages and boundaries of cloud database. In addition, the problems which faced in transferring data and data processing in the environment of cloud were described in detail. Also, the challenges of cloud processing system were listed and explained. Finally, A thorough study of the transaction processing system, Cloud Database as a Service (DBaaS), Cloud RDBMS Database and cloud data storage based on the new configuration for cloud databases with support traditional ACID properties. Yaser Mansouri et al., [2] proposed a work to explain the storage management of data in cloud environment. This paper discussed the key benefits and troubles of data drastic domains were within cloud based data stores. In the next, the authors offered a broad taxonomy that includes the key features of data storage in cloud that are data modeling, data scattering, data stability, data
Robson A. Campêlo et al., [3] reviewed the key features that related to consistent problems in cloud - data storage systems. in the first , this work presented the basic concepts of database management in cloud environment. Moreover, Existing models of distributed core stability storage systems were discussed. After that, a comprehensive taxonomy was proposed to classify the most important stability patterns which found in the literature, and then presented overview key approaches to implementing them. This survey offered a collective discussion that emphasizes key features of the methods. Finally, concluded the work by providing key issues and some final feedback. Islam Elgedawy [4] proposed a quota based method to running data ambiguity in the clouds that ensures global data validity without global locking. The proposed approach used a new operating service i.e DCaaS to prevent service developers from managing data uncertainty. This service ensured the SaaS service like performed as an adapter of cloud among SaaS service cases. From the Experimental results, the proposed method perceived by the DCaaS gives the best reaction time compared to classical locking and blocking methods. Zohra and Nadia [5] presented a work to discuss the consistency issues in cloud based DBMS. The uniqueness of cloud computing were described and database models for cloud were presented. The consistency concepts and the delimma caused by the CAP theorem were explained. In addition, various stages and models of consistency discussed. Moreover , some popular cloud systems were projected and described the models of to implement the data and maintain stability. Sruti and prasant [6] proposed a model to maintaining consistency data intensive cloud based context. The propsed technique gave a model to maintain consistency in cloud computing context. The experiment set up was conducted to the replica server only. In this work, certain amount of replicas concentrated but more replica servers may be included. Bugga and Kumar [7] proposed a structure to make sure the protection of distributed transactions in the cloud computing context. In this paper , two phase commit protocol was introduces in the proposed algorithm to give a secure transmissions. This was done by achieving ACID properties. Jeevarani and Chitra [8] proposed a model to enhance the consistency problem on the cloud computing DBMS. This work This work recommended using the “Prioritized Operation Manager (POM)” to get the preferred read-write mechanism for consistency and reliability. But the proposed model does not reduce response time while the amount of requests from clients increases.
Radi [9] Proposed a model for enhancing the spread of updates on cloud data storage. Th author introduced the technique of maintaining the stability of the duplicate server. This technique can achieve both stability and reliability with excellent performance. Nesrine et al.,[10] explored and investigated the transaction management approaches currently in use. This work proposed a model in which transaction management can be portrayed and maintained. In addition , the author presented forward serious efforts to reduce data management gaps. Finally, categorized all schemes into 12 types and expected that the type will be able to improve the present transaction aspects in the cloud.
III. Proposed Integrated Architecture
Components of Proposed Integrated Architecture
The Cloud environments are integrated in nature, it is designed to incorporate clients, internet service providers, applications, systems, services and infrastructures for various aspects. Across the ever-changing cloud environment, achieving integration for security and consistency is still a significant challenge. The IT sectors are trying to integrate the data transaction services with critical integration cloud platforms. Hence, this research proposes an integrated architecture through security and consistency frameworks for secured data transactions with enhanced consistency in cloud environment. The components of an integrated architecture are illustrated in Figure 3.1. The integrated architecture consists of Public Network, Internet Service Providers, Firewall, Application Gateway, Cloud Vendors or Enterprise Network, Routers, Security & Consistency Infrastructure and Cloud Service Providers. In this, security is provided for multi-level and consistency enhancements for data transaction. The proposed integrated architecture is categorized into Public Network, Cloud Vendors, Security & Consistency Infrastructure and Cloud Service Providers.
A. Public Network
Users:
The users can access cloud data transaction services on the enterprise service network using browsers and mobile native applications. The users could be a transaction end customer or enterprise line cloud vendor.
Internet Service Provider
The users can choose any kind of internet service provider (ISP) to access the cloud services. An ISP is an organization to provide services to accessing internet. It connects the customers, cloud vendors and cloud service providers with browsers, APIs, application gateways to the Internet.
Firewall:
The firewall is a system placed between Internet service providers and application gateway to access various transactional services like mobile banking, online shopping and online reservations etc.,
Figure. 3.1. An Integrated Architecture for Secured Cloud Data Transactions
The firewall is designed to control the communication access to and from the system. It restricts unnecessary traffic to access transactional services and permit only users with acceptable policies.
Application Gateway:
Application gateway enables on the firewall system between two types of networks. It is an application program enables when client access the transactional service. Hence, all data transaction communications are established through application gateway to protect the system. It is a highly secure method to protect cloud data transactions.
B. Cloud Vendors
The vendors that move their business process management system and enterprise data to cloud environment is called Cloud Vendors. Cloud vendors incorporate with Cloud Service Providers to manage hardware and software infrastructures. The Cloud vendor offers data transaction services to their clients. In this proposed integrated architecture cloud vendors enables the consistency and security infrastructure for cloud data transactions.
C. Security and Consistency Infrastructure for CDT
Security and Consistency are the two important factors in the performance of cloud data transactions. The architecture integrates security framework and consistency framework to offer a security and consistency infrastructure for cloud data transactions. Figure 3.2 shows the Security and Consistency Infrastructure for CDT.
Figure. 3.2. Security and Consistency Infrastructure for CDT 1) MLS for CDT:
In this research work, the multi-layered security framework was proposed at various levels. It was developed successfully for secured transaction in cloud environment. The proposed framework experimented through user authentication, service authentication and data security. The components of the proposed security framework are explained in chapter 3.3. This framework will lead to the strengthening of data transaction services in the cloud environment.
2) Consistency for CDT:
The most important task which is faced in software industry is maintaining the higher consistency state while data transaction on cloud environment. Most approaches are created to achieve the better consistency state in data transaction but still enhancement is needed. So the integrated architecture, proposes a framework named as D1FTBC with 3PSTBC protocol to improve the consistency rate in data transaction on cloud environment.
D. Cloud Service Providers
Cloud service providers are companies which are offer network services, platform service, infrastructure service, database service and business applications in cloud. Cloud Service Providers offer data transactional services like Cloud Banking Services, Cloud Shopping Services and Cloud Reservation Services. The offered cloud transactional services are hosted in the cloud data centers that can be accessed by companies or individual end user through the network connectivity of proposed integrated architecture.
IV. Performance Analysis A. Experimental Setup
The experiment setup has been established for the proposed integrated architecture using ASP.NET and developed as a cloud data transactional service. It is successfully deployed in the Azure platform in cloud. The AAA server, CSC server, CDL server, D1FTBC server, cloud DB and Cloud Storage server are tested to ensure the Security and Consistency of the data transaction in a cloud environment. The performance analysis on the implemented system ensures guarantees that the proposed integrated architecture works efficiently with the enhanced performance. The experimental setup involves Hardware and Software to analyze the performance of proposed
architecture. It is explained subsequently in the test bed environment. Figure. 4.1 depicts the experimental environment and test bed established to study the performance.
Figure 4.1 Test Bed Environments B. Hardware Requirements
The test bed of the proposed architecture has seven entities. They are AAA server, Cloud Service Controller (CSC) server, D1FTBC server, Cloud Data Locker (CDL) server, Cloud Database (CDB), Crypto Engine (CE) and Cloud Storage (CS). The proposed architecture deployed in Microsoft Azure that is cloud computing service created by Microsoft Corporation. The test bed for proposed architecture is successfully built, deployed and tested in Azure platform for various performance analyses. The virtual machines (VM) are created in the Cloud distributed environment for AAA server – (VM1), Cloud Service Controller (CSC) server - (VM2), D1FTBC server (VM3), Cloud Data Locker (CDL) server - (VM4), Cloud Database (CDB) - (VM5), Crypto Engine (CE)- (VM6) and Cloud Storage (CS) - (VM7) with CPU machines that has 40 GB disk space and 8 GB RAM.
C. Software Requirements:
The software of the proposed architecture are located in Azure. Visual Studio 2012 Asp.NET is used for designing web pages with User Interaction available in the Dot NET framework and SQL Azure Database is used to maintain cloud data storage for online transactions. The overall web service is published using SQL Database in the Azure platform. The azure account is created and configured the web application name with necessary resource group. After selecting the application service plan, the SQL server instance is created. The SQL database is used for maintaining cloud databases. Code First migration in Azure is used to update code changes frequently. The Steam application logs are used to manage deployed web applications in Azure and also used to process the performance analysis in various aspects.
D. Performance Analysis on User Authentication
The authentication protocols at various levels are managed with IASCDTCE setup and validate the user identities in local as well as remote levels. The AAA server effectively communicates the user to strengthen the user level security.
Processing Time for User Credential Data:
The processing time of the user credential data is part of the AAA server to strengthen the user and device level security. The table 4.1 shows the response time to Retrieve Encrypted User Credentials, Decrypt the User Credentials and Encrypt the User Credentials versus different level of service requests.
Table: 4.1. Response Time for User Credential Data
Test
No of
Service Request
Retrieve Encrypted User
Credentials (Ms)
Decrypt the User
Credentials (Ms)
Encrypt the User
Credentials (Ms)
1 50 32.8389 21.1258 16.2342
2 100 34.4389 22.4843 16.8334
3 150 35.3849 24.9584 17.2429
4 200 36.3887 25.9587 18.3873
5 250 38.4849 27.4983 19.2767
6 300 40.5984 28.9493 21.0484
7 350 41.4398 29.8958 22.1339
8 400 42.7983 32.5893 22.3859
9 450 43.9936 33.5983 23.4855
10 500 45.3956 36.4945 25.9467
Figure 4.2. Performance Analysis on Processing the User Credential Data
Figure 5.25. shows the graph for the performance of accessing User Credential Data through AAA server. The plot exhibits between the processing times versus number of requests. On the significant of the scale 50 to 500 number of request, the processing time of Retrieve Encrypted User Credentials slightly higher than Decrypt and Encrypt of the User Credentials. Accessing encrypted data in cloud is a typical task to retrieve data without the loss of any information. All the Retrieve, Decrypt and Encrypt processing times are grow linearly according to the number of service request.
Hence the system shows the better performance results for AAA server for user authentication.
E. Performance Analysis on Service Authentication
Service Authentication Performance for Increasing Number of Service Request:
The performance of the service authentication is analyzed through the CSC server to ensure service policy verification and working ability of the VM of the offered services. Table 4.2 shows the processing time of various components of CSC server that is Service Policy Verification, Decrypt SSRS DB, Response from VM Instrospector and Response from VMM Profiler against number of service requests per minute.
Table: 4.2. Processing Time for Service Authentication for Increasing Service Request No of
Service Request
Service Policy Verifier (Ms)
Decrypt SSRS DB (Ms)
Response from VM
Instrospector (Ms)
Response from VMM Profiler (Ms)
100 17.8637 24.8265 19.4892 13.3648
200 18.8943 26.8213 20.8563 13.9376
300 20.9483 27.5893 22.3867 14.4993
400 21.4902 29.4789 23.0963 15.4803
500 22.493 30.4984 24.3973 16.2879
600 23.9588 33.8321 25.9832 16.7292
700 24.2821 35.289 26.0937 17.3873
800 24.3899 36.4921 27.3439 18.0941
900 25.9387 38.329 28.9482 19.3829
1000 26.9048 39.09793 29.3902 21.9475
Figure 4.3 shows the performance of CSC server and the plot placed between processing time versus number of service request. On the significant of the scale 600 to 1000 number of request, the system exhibits a linearly growing of processing time compared to scale 100 to 500 number of request. The comparison of component performances Decrypt SSRS DB shows maximum processing time 39.09793 ms and VMM Profiler shows minimum processing time 21.9475 ms for 1000 service request.
Figure 4.3. Performance Analysis on Service Authentication for Increasing Service Request F. Performance Analysis on D1FTBC Approach
Performance Analysis on combined Requests:
Table 4.3 shows the execution time for different consistency approaches to increasing the arrival rate of combined service request. The arrival rate of combined transaction increases from 100 to 800 service requests per minute. Figure 4.4 shows performance analysis of proposed D1FTBC consistency approach against increasing arrival rate.
Table: 4.3. Response time for Combined Request
Tes t
Executio n Time in
D1FTB C (Ms)
Executio n Time in
TBC (Ms)
Executio n Time in
Quorum (Ms)
Executio n Time in
Classic (Ms)
No. of Read Transactio ns
per Minute
No. of Write Transactio ns
per Minute
Total Number of
Combine d
Request per Minute
No. of Replic a Serve rs
1 34.163 37.839 44.877 41.148 50 50 100 5
2 36.145 40.938 45.996 42.129 100 100 200 5
3 38.392 44.038 46.778 48.392 150 150 300 5
4 42.898 47.484 52.973 53.893 200 200 400 5
5 45.619 50.588 55.984 52.395 250 250 500 5
6 47.715 53.838 58.388 56.702 300 300 600 5
7 49.158 56.854 64.583 59.883 350 350 700 5
8 52.382 60.994 68.774 62.139 400 400 800 5
Figure. 4.4. Performance Analysis on Combined Request
The plot is positioned between execution time versus number of Combined transaction per minute.
In the execution of Combined transactions, Quorum approach increases from 44.877 ms for 100 requests to 68.774 ms for 800 requests. Classic approach increases from 41.148 ms for 100 requests to 62.139 ms for 800 requests. TBC approach increases from 37.839 ms for 100 requests to 60.994 ms for 800 requests, while the proposed D1FTBC approach varies little from 34.163 ms for 100 requests to 52.382 ms for 800 requests. The effect of both higher and lower number of arrival rate on D1FTBC approach for Combined (Read/Write) transactions, the execution is small that means it shows the better performance result for combined transactions than the existing TBC, Quorum and Classic consistency approaches.
G. Performance Analysis of D1FTBC Components
Table 4.4 shows the execution time for various components of D1FTBC approach against increasing arrival rate of the service request. The arrival rate is increasing from 50 to 500 service requests per minute.
Table: 4.4. Execution Time for D1FTBC Components Test
No of
Service Request
Query Analyzer (Ms)
Fix
Transaction Tree
(Ms)
Transaction Execution (Ms)
Data Update (Ms)
1 50 12.4309 14.1947 18.2872 13.4785
2 100 12.7329 14.3574 18.8737 13.6382
3 150 13.0946 15.6328 18.9376 14.2437
4 200 13.9387 16.8637 19.2648 14.9438
5 250 14.1823 17.2944 19.5036 15.3904
6 300 15.3062 17.8894 20.8219 16.6392
7 350 15.7984 19.6928 21.3924 17.8382
8 400 16.6498 19.8348 21.8893 18.4092
9 450 16.9412 20.9326 22.8349 19.6389
10 500 17.2947 22.2874 23.6894 20.2236
Figure 4.5 shows performance analysis on the components of proposed D1FTBC consistency approach against increasing arrival rate. The plot is denoted between execution time versus number of service requests per minute. In the execution of D1FTBC Approach, On the significant scale of 50 to 500 number of service request, the components of proposed system seems to exhibits a linear growing of execution time. The transaction execution component shows the higher response, which is major work to implement commit protocol for every transaction. The Fix Transaction Tree and Data Update components show the average level execution time between Transaction Execution and Query Analyzer components.
Figure. 4.5 Execution Time for D1FTBC Components
The Query Analyzer shows smaller execution time than the other components of D1FTBC. Figure 4.5 shows the execution time depends on the nature of workload of each component and the system components growing linearly in the plot that ensures better performance of D1FTBC approach.
H. Performance Analysis on Data level security
Table 4.5 represents the execution time for various components of CDL server against increasing arrival rate.
Table: 4.5 Execution time for CDL server No of
Service Request
Client
Authentication through OTP (Ms)
Service Provider Verification through DSN (Ms)
Retrieve Encrypted Data from Cloud DB (Ms)
Decrypt the Data from Cloud DB (Ms)
50 15.8367 14.2873 38.1298 21.4872
100 15.8931 14.4912 38.3981 21.5238
150 16.9237 14.5219 38.6218 21.7233
200 17.3839 14.6389 38.7219 21.9301
250 17.5179 14.8341 38.9437 22.3016
300 18.6253 15.2128 39.2849 22.5293
350 19.8248 15.3895 39.4938 22.7382
400 19.9236 15.5902 39.5382 22.9378
450 20.2843 15.7129 39.7198 23.2783
500 21.4278 15.9346 39.8392 23.4292
Figure 4.6 shows performance analysis on the components of proposed CDL server increasing arrival rate. The plot is denoted between execution time versus number of service requests per minute. In the execution of CDL, On the significant scale of 50 to 500 number of service request, the components of proposed system seems to exhibit a linear growing of execution time. The CDL component shows the higher response, which is major work to implement three stage verification to access data and adopt a cryptography mechanism to handle transactional data. Retrieval of encrypted data from cloud DB take more response time, because of strengthening three stage verification processes. Decrypt the cloud data through crypto engine also takes reasonable time in the benchmark. The OTP verification is a client authentication processes to wait responses from every client enter transaction. It shows better response time than Retrieve encrypted data and Decrypt data process. The service provider verification is a machine to machine interaction that shows smaller response time than other components in CDL server. Figure 4.6 shows the execution time depended on the nature of workload of each component and the system components growing linearly in the plot that ensures better performance of CDL server.
I. Performance Analysis of System Throughput
The performance analysis is carried out to measure the system throughput of proposed system. The amount of data that the client obtains service response from the web server at any given time is measured as system throughput. These automated performance tests and measures are useful through the deployment of the system as commercial product. Table 4.6 represents the number of requests chosen for the test and A summary of the test results is shown in Table 4.7. The concurrent execution of AAA server, CSC server, D1FTBC server and CDL server as well and mean response time of the individual servers are noted and reported. The need of this task is to identify, if the system performance differ when increasing the concurrent users. The performance test is conducted to find out the response time with 1,5,10,20,30,40,50,60,70,80,90 and 100 concurrent requests. The response time of each request is measured and reported separately. For the test scenario 100 users are chosen as the maximum number. The performance test analyses whether the load of web server is low with less number of concurrent service requests. Meanwhile, the observation noted is that the web server load was high with more number of concurrent service request. The performance of the mean response time of the system is based on the transaction processing system performed by the number of simultaneous users. The throughput of the system relies on number requests per second towards the number of simultaneous clients.
Table: 4.6 Number of Requests Chosen for the Test
Test No. of Users No. of Concurrent
Requests
1 1 1
2 5 5
3 10 10
4 20 20
5 30 30
6 40 40
7 50 50
8 60 60
9 70 70
10 80 80
11 90 90
12 100 100
Table: 4.7 Summary of Test Results
Test Mean Response Time (Sec.)
Standard Deviation (Sec.)
Throughput No of Requests / (Sec.)
1 113.57 28.70971 1
2 120.2 35.30073 5
3 123.67 30.64626 10
4 123.97 32.00014 20
5 124.16 31.45358 30
6 129.62 35.73522 40
7 129.91 30.52507 53
8 129.99 33.10787 65
9 137.36 38.74379 75
10 145.09 38.68236 88
11 166.16 40.77202 94
12 221.16 54.26138 89
Figure: 4.6. Performance Results For Mean Response time
The graphs are presented for mean response time and system throughput in Figure 4.6 and Figure 4.7 based on the test results presented in Table 4.6 and 4.7. Figure 4.6 shows performance results in terms of mean response times. The plot is denoted between Number of users versus Average Response Time. On the significant scale of 1 to 90 transaction clients, the transaction payment system seems to exhibit a linearly growing mean response time. The slope of the curve is starting to steepen between 90 and 100 simultaneous users. This is quite natural that every system reaches the level of load where the performance observed by a single user starts to degrade dramatically. Figure 4.7 shows the performance results based concurrent request to determine the throughput of the proposed system. From the observation of the graph the system throughput increases gradually up to 10 service requests and keep on increasing till 90 simultaneous service requests.
Since the highest throughput of the web server is 94 due to the maximum load capacity of the web server and the throughput declines thereafter. In view of the information that the graph does not produce a straight line and it is observed that the throughput of the proposed system is nonlinear.
Conclusion:
The experimental study for the proposed system is validated in terms of User Authentication of AAA server, Service Authentication of CSC server, Read / Write Ratio Test and Transaction Performance on D1FTBC Approach, Performance Analysis of 3PSTBC Protocol, Performance Analysis of Data Level Security of CDL server, Secure Communication Analysis between servers, Latency Analysis of the servers and System Throughput on the Proposed Architecture are explored sincerely with necessary tables, graphs with implemented screen shot.
References:
[1] Prabu, J. Antony John, and Dr S. Britto Ramesh Kumar. "Issues and Challenges of Data Transaction Management in Cloud Environment." International Research Journal of Engineering and Technology (IRJET) 2, no. 4 (2015): 123-128.
[2] Mansouri, Yaser, Adel Nadjaran Toosi, and Rajkumar Buyya. "Data storage management in cloud environments: Taxonomy, survey, and future directions." ACM Computing Surveys (CSUR) 50, no. 6 (2017): 1-51.
[3] Campêlo, Robson A., Marco A. Casanova, Dorgival O. Guedes, and Alberto HF Laender.
"A brief survey on replica consistency in cloud environments." Journal of Internet Services and Applications 11, no. 1 (2020): 1-13.
[4] Elgedawy, Islam. "DCaaS: Data consistency as a service for managing data uncertainty on the clouds." arXiv preprint arXiv:1306.0441 (2013).
[5] Mahfoud, Zohra, and Nadia Nouali-Taboudjemat. "Consistency in Cloud-based database systems." Informatica 43, no. 3 (2019).
[6] Basu, Sruti, and Prasant Kumar Pattnaik. "Maintaining Consistency in Data-intensive Cloud Computing Environment." In Progress in Computing, Analytics and Networking, pp. 257- 264. Springer, Singapore, 2018.
[7] Bugga, N., Kumar, A.S.: A New Framework and Algorithms for secure cloud Transactions.
International Journal of Computer Science and Mobile Computing (IJCSMC) Vol 5, Issue 6, (2016) 87–94
[8] Jeevarani, B., Chitra, K.: Improved Consistency Model in Cloud Computing Databases.
IEEE International Conference on Computational Intelligence and Computing Research (2014)
[9] Radi, M.: Improved Aggressive Update Propagation Technique in Cloud Data Storage.
International Journal of Emerging Trends & Technology in Computer Science (IJETTCS) (2014) 102–105
[10] Tan, Da-Peng, Lin Li, Yin-Long Zhu, Shuai Zheng, Huan-Jie Ruan, and Xiao-Yu Jiang.
"An embedded cloud database service method for distributed industry monitoring." IEEE Transactions on Industrial Informatics 14, no. 7 (2017): 2881-2893.
