A Fuzzy Based Sensor Web for Adaptive Prediction Framework to Enhance the Availability of Web Service

Present day businesses revolve around internet applications (e.g., e-commerce, e-business, and internet banking) which are primarily supported by web services. The increasing consumer reliance on these internet-based applications causes dynamic variation in the number of requests received by web services and a slowdown in response time during peak load periods. To overcome this difficulty, in this paper, we propose a fuzzy logic (FL) based prediction and replication framework to replicate the web services over distributed servers and achieve timely responses. This framework senses the proximity of future interval response time against agreed service level agreement (SLA) time using sensor web called proximity sensor service. Also, it determines the replication requirement using FL and implements the FL decision using resource control algorithm to replicate the web service on another server before the SLA time is violated or to reclaim the excess resource. We conduct appropriate test scenarios in a dedicated test environment and compare the results with existing models. The results show that our framework replicates the web service at more appropriate times than the existing models and achieves 82% prediction accuracy. Thus, our framework significantly improves the availability of web services with minimal intervention from system administrators.


Introduction
Web services entail well-defined software components that support web based business applications and increase the efficiency of providing services by exchanging and aggregating data in a distributed environment [1]. Several techniques have been developed for web services [2][3][4] to enhance their availability. Because the rate of web service requests received from the clients varies, the quality of service (QoS), including the availability and performance, becomes unstable, leading to various uncertainty factors and potential web service failures or temporary interruptions. Hence, a QoS aspect such as the availability of web services has become an important research topic and has attracted a lot of attention in recent years.
In this paper, we propose a fuzzy logic based replication SMA framework, called "A Fuzzy Based Sensor Web for Adaptive Prediction Framework to Enhance the Availability of Web Service" (FAPFEA). The soft sensor or virtual sensor is defined as "A web service which contains an algorithm or simulation model could be a sensor in a sensor web as long as its interfaces and behaviors comply with the specifications" [5]. Sensor web is "web accessible sensor networks and archived sensor data that can be discovered and accessed using standard protocols and application programming interfaces" [6]. Our proposed framework uses virtual sensor (Proximity Sensor Service (PSS)) which is capable of reading from heterogeneous databases (MS/SQL, MySQL, etc.) to sense the proximity of the predicted future interval response time with SLA response time of specific web service (e.g., user status enquiry service ( 1 )) and determines the replication requirement. The soft sensors have an important role in sensor validation when performance declines or fault accumulation. The sensor web framework is constructed as per set of standards [6,7] laid down the Open Geospatial Consortium (OGC) to establish the "sensor web." The OGC SWE, Microsoft SenseWeb, and Oak Ridge National Lab Sensorpedia are the most common sensor web platforms providing sensor data service [8]. Our proposed framework follows the OGC's Sensor Web Enablement (SWE) which provides the service specifications for the enablement of sensor web. Figure 1 depicts the OGC SWE sensor web architecture of PSS, layers, and services of the OGC SWE. The detailed service specifications can be found in [6]. Using these specifications, PSS is developed to focus on predicting both arrival rate and response time and analyzing these two metrics using fuzzy logic (FL) to precisely sense the proximity between predicted future interval response time and expected SLA response time and to determine replication requirement. We use the Poisson Distribution (PD) to predict the future arrival rate and the Exponential Distribution (ED) to predict the future response time. Furthermore, a boolean decision based on sharp arrival rate or response time boundaries would lead to an inappropriate decision because the combination of these two metrics forms numerous vague situations. We thus use an intelligent approximation technique to deal with information that is partially true, uncertain, vague, or imprecise. "Fuzzy logic is a precise logic of imprecision and approximate reasoning" [9] and is therefore well suited to our problem. We input the predicted arrival rate and response time values into a fuzzy inference service and evaluate them based on various fuzzy rules (Table 3) for sensing the proximity of future interval response time against agreed SLA time and to determine the replication requirement using FL for efficient decision-making. Once the replication requirement decision is made, Resource Control Service (RCS) uses the resource control algorithm (RCA) to dynamically replicate the web service on another host before the response time violates the SLA. This framework is also designed to detect web service unavailability such as the web service being stopped, hung, or unresponsive for various reasons. Additionally, if the response time of any individual server is low and is approaching the threshold limit, the RCS removes the corresponding replica from the load balancer and replicates the web service on another host.

Related Work
Several techniques have been introduced in this domain. Self-management automation (SMA) system was introduced by IBM [10] to constantly monitor resource utilization and scale the capacity up or down. The SMA system becomes indispensable to monitor resource utilization constantly to scale up/down the resource capacity. So far, several attempts were made to develop SMA [11][12][13][14] in order to reduce administrator intervention in distributed resource management. However, this approach requires administrative responsibility to manage the system. The authors in [15] suggested architecture employing the enterprise-level gateway to improve web service availability. This technique continually monitors service availability and unfortunately leads to performance overhead for the gateway, thereby impacting client request and response processing.
A recent trend in web service availability is centered on the replication of web services [16][17][18][19]. The authors in [16] discussed different replication components and techniques, such as active, passive, and semiactive replication, as part of their proposed framework. The drawback of their proposed framework is that it uses a multicasting technique that increases the unnecessary load on the servers by processing the same request by multiple replicas. The authors in paper [20] also suggested an active replication for fast response. Also, authors stated that "a slow service is equivalent to unavailable service." In paper [18], the authors proposed system architecture to enhance the availability of web services by employing an enterprise service bus, replication of services, and multicasting. However, from the load balance perspective, multicasting and parallel invocation is ineffective [17], because it always increases the traffic and operating cost by propagating the same client requests to all of the servers. The work proposed in paper [19] designed a middleware component involving interactions with a java package to maintain the consistency of replica statuses.
The work proposed in paper [21] is a prediction framework to improve the availability of web services by predicting the future response time. The framework issues a replication decision on another server host when the predicted response time exceeds 90% of the SLA time without considering the arrival rate. The authors in [22] have suggested a framework for dynamic placement of service and service replication to improve the availability of services using a team formation algorithm. The framework concentrates on cost management, performance, and availability in the event of web service failover and does not consider the arrival rate and International Journal of Distributed Sensor Networks 3 response time while replicating the web service. In paper [23], the authors proposed an adaptive prediction framework to enhance web service availability using replication. In this research work, the authors suggested a linear regression method to predict the future load based on data from the past 15 days and replicated the web service for the current day according to these data. However, this approach may not help in dynamically varying loads because the replication is not predicted based on the current load.
All of the existing research works discussed above used different evaluation techniques and criteria for replication decisions. However, none of the above frameworks proposed to sense both the arrival rate and response time in future interval. Because the arrival rate and response time are interrelated parameters [24,25] and their combination forms numerous situations, it becomes necessary to consider all of the possible situations in determining the availability of web services and the replication decision. Ignoring either one of these metrics leads to inappropriate replication decisions. Therefore, we focus on predicting both the arrival rate and response time and analyze them using sensor web based FL to sense the proximity of future interval response time with agreed SLA time and to determine requirement of replication. Application server based sensor web architecture has been proposed by authors [7] to access the sensor data over the web. The author in paper [6] proposed architecture for Sensor Web Enablement for accessing sensor web from application interface. The authors in paper [8] proposed geosensor based efficient sensor data management methods and extended query processing system. But none of the works reported on sensor web based service replication. The objective of our proposed work is to achieve the availability of web services using heterogeneous sensor web according to the following aspects: (1) Availability in terms of response time: the web service should successfully respond to client requests within the specified SLA time.
(2) Availability in terms of web service up time: the web service should be available to process the requests at all times, providing uninterrupted availability.
The remainder of this paper is organized as follows. Section 3 provides an overview of the proposed adaptive replication framework and its components. Section 4 describes the prediction process, techniques, and algorithms. Section 5 details the test environment, the different test scenarios, and the test results. Finally, the conclusion and future work are summarized in Section 6.

Overview of Proposed Framework
The proposed framework FAPFEA is built with service gateway; any request from client always passes through the service gateway which has four major components, namely, Monitoring Service (MS), Load Balancing Service (LBS), Intelligent Resource Control Manager (IRCM), and Proximity Sensor Service (PSS). The components of FAPFEA framework are described below and shown in Figure 2.  Figure 2: Framework of FAPFEA.

Monitoring Service (MS).
The MS keep monitors the statuses of web service ( 1 ), servers ( 1 , 2 ⋅ ⋅ ⋅ ) and creates metrics for number of requests arrived, response time of each request, and number of requests processed by web service ( 1 ) during a specific interval.

Load Balancing Service (LBS)
. LBS receives requests from clients and distributes them to the pool of active replicated web services using round-robin technique. These replicated web services process the requests and send responses back to the clients.

Intelligent Resource Control Manager (IRCM).
The IRCM is a service component which manages and controls the web services replication to maintain the web services response time within the expected SLA time. It uses sensor web service called "Proximity Sensor Service (PSS)" that senses the proximity of the predicted future interval response time with SLA response time and determines the replication requirement using FL for efficient decision-making. IRCM also uses "Resource Control Service (RCS)" to implement the requirement of resources into system. IRCM acts as client to invoke the PSS at defined time interval to identify the availability of web services and requirement of new replica. Once IRCM receives the response from PSS, RCS further analyzes the PSS's response using RCA to implement the PSS response at appropriate time. RCS is a subservice component controlled by IRCM, which acts as actuator for PSS response. It analyzes the PSS response using resource control algorithm (RCA) and dynamically replicates the new replica or stops excessive replica at appropriate time.

Proximity Sensor Service (PSS)
. PSS adopts OGC SWE standards to provide the interoperable usage of sensor resources. It has been built upon the existing open source SOS implementation from the 52 North Sensor Web frameworks (http://52north.org/swe). The PSS is a web service which is constructed with two subservices, namely, future prediction service (FPS) and fuzzy inference service (FIS). The functional flow of PSS has been illustrated in Figure 3. The FPS reads metrics from MS data base for the arrival rate and response time of last interval time and predicts the future arrival rate and future response time using PD and ED, respectively. The FIS senses/observes the closeness or proximity or nearness between SLA response times and predicted future interval response time and determines the requirement of additional replication. It returns the flag of replication requirement "Y" or "N" or "S" to requested service (IRCM).

Processes and Techniques
The vision of sensor web is being pursued by the Sensor Web Enablement (SWE) working group of OGC. The PSS has been built with 52-degree North's SOS 2.0 specification, and the web architecture of PSS implementation is shown in Figure 1.
In the SWE architecture, application layer provides services to the clients to deliver processed data from service providers. Application layer can perform the functionality of centralized decision and control where an intelligent algorithm may run to evaluate the current state of the sensor networks and issue the autonomous control commands to the devices in the network. The IRCM resides on application layer which has service composition and execution logic to implement the web service replication intelligently. The IRCM has PSS client interface to configure the service level parameters (e.g., SLA time, execution interval time) for any specific web service ( 1 ) which has to respond to customer requests within agreed SLA time. Whenever the client (IRCM) requests for future interval availability of web service, the PSS can analyze the proximity and replication requirement of web service and returns the flag of replication requirement. Such a request from IRCM to PSS is processed by presentation layer and transmitted to service layer. The service layer has the details of service provider, service registry, information repository, and SWE's SOS client information. The information repository contains the sensor description model named SensorML through which sensor processes or sensor systems (PSS) can make themselves known and discoverable. With the help of this service level information, service layer forwards the request to middleware layer which is responsible [7] for the communication and interaction of service layer with

Future Prediction Service (FPS).
Upon the request from IRCM to PSS, the FPS reads the MS data base and observes last interval's rate of arrival and response time of web service 1 and predicts the future interval arrival rate (demand) and response time. The arrival rate is the mean number of requests ( ) that arrive per unit of time ( ). This can be parameterized with multiples of the monitoring pole interval. From the MS database, the FPS reads the number of requests that arrived ( ) to web service ( 1 ) at the end of every interval ( ) (e.g., 60 seconds). The average arrival rate of an individual server is calculated using = . (1) The variables used in this paper are listed in Nomenclatures.
When the system is running with multiple replica servers, the current arrival rate (CA) is calculated using From , it predicts the future arrival rate ( ) for the next interval using PD [26, page 168]: To find the future arrival rate, we use the mean of two probability confidences and V . The future arrival rates FA 1 and FA 2 are predicted at probabilities and V using (4) and (5), respectively [26, page 170]. Consider where V is a known value (e.g., 0.1). Hence, FA 2 is calculated using (5) The response time is the time taken by a web service to completely process one request. It can also be defined as the time difference between the time in which a request is submitted and the time in which the response is received [24]. From the MS database, the FPS reads the number of requests processed ( ) and response time of each request ( ) at the end of every interval ( ) (e.g., 60 seconds). The average response time ( ) (in milliseconds (ms)) from an individual server is calculated using (7). When system has multiple servers, the total average current response time (CR) is calculated using (8) and response rate is calculated using (9). Therefore, Current response rate = .
From , FPS predicts the future response time (FR) using ED [26, page 172] We use the mean of two probability confidences and to find the future response time. The CDF (cumulative distribution function) of the future response time (FR 1 ) is predicted for the probability confidence using (11), where is a known probability confidence value (e.g., 0.75). Hence, FR 1 is calculated using (11) to (11b) [26, page 172]. Consider  Similarly, the future response time (FR 2 ) is predicted at probability confidence (e.g., 0.25) using (12) to (12b) [26, page 172]. Consider The total future response time (FR) (in ms) is calculated using [26, page 222]

Fuzzy Inference Service (FIS).
The FIS analyzes the predicted arrival rate and response time and evaluates them against various fuzzy rules and a replication decision matrix. It maps these nonlinear input data (FA and FR) to a scalar output (the decision that replication is required or not) which is done using FL system. There are four key processes involved in a FL system [27] to determine the replication requirement decision: (1) fuzzifier, (2) fuzzy rules, (3) fuzzy inference engine, and (4) defuzzifier. In the fuzzy system, the concept of the linguistic variable is used to represent the input or output variable that carries the linguistic label [28]. The linguistic label is generally decayed into a set of linguistic terms. The linguistic variables of and are defined in Tables 1 and 2, respectively. The ranges of the fuzzy variables are determined using the triangular method [29]. The linguistic values of arrival rate are converted into triangular fuzzy numbers as shown in Figure 5 and Table 1, where " " is 50% of present processing capability ( ). is calculated as = * , where is number of servers and is number of requests that each server can process within SLA time (e.g., 2500 requests/min). Correspondingly, the linguistic values of response time are converted into triangular fuzzy numbers as shown in Figure 6 and Table 2. Here, " " is 50% of SLA response time (e.g., 650) [30]. The fuzzy rules are functions in the form of a series of "ifthen-else" statements. Each of the two fuzzy sets (arrival rate, response time) has seven membership functions. The arrival rate and response time are termed as conditional attributes and form 49 (7 2 ) fuzzy decisional matrix elements which    Table 3. The replication requirement is termed as the decision attribute. The decision attribute has three categorical values: "Y" (replication required), "N" (replication not required), and "S" (stop existing replica). These decision attributes are arrived at by the FL decisions illustrated in Table 3 that are stored in variable "FL flag" which will be used further by RCA. In our framework, we use the center of gravity method to defuzzify the strength of rule evaluation to identify the crisp output. This method is illustrated in

Resource Control Service and Its
Algorithm. The RCS acts as actuator and performs the following activities: (1) it incorporates the FL decision; (2) it performs health checks of servers and web services; (3) it creates new virtual machines (VM) similar to any replica and powers them on or off; (4) it adds or removes any server from the load balancer; and (5) it starts or stops any server or web service. To analyze the consistency of the system behavior, the RCS uses the four time parameters: (1) "adm STOP ," the administrator defined waiting time (for the RCS) after the FL decision is set to "S" (e.g., 900 seconds); (2) "adm REPL ," the administrator defined waiting time (for the RCS) after the FL decision is set to "Y" (e.g., 300 seconds in our tests); (3) "Y WAIT ," the waiting time of the system after the FL decision is set to "Y"; and (4) "S WAIT ," the waiting time of the system after the FL decision is set to "S." The "adm STOP " and "adm REPL " parameter values are set by an administrator. The FL decision and these time parameters are applied in the RCA (Pseudocode 1) to implement the FL decision. If the FL decision is "Y," it will check for ≥ 90% SLA; if true, it implements the replication immediately; otherwise, it continues for the next interval until Y WAIT ≥ adm REPL ; then, it implements the new replica ( ). Once the replication has been done, the RCS will add the new replica server into the load balancer to distribute the request to the new replica service. If the FL decision is "N," it will continue for the next interval analysis. If the FL decision is "S," it will continue with next interval until adm STOP ; then, it stops server ( ) which provides higher response time. Also, the RCS periodically pings the servers and checks services to determine the health status at every ℎ interval (e.g., 10 seconds). If any of the web services is found to be hanging, unresponsive, or stopped, it is restarted. If the restart fails, the RCS sets the flag "Service Status Abnormal" to "Yes" and stop sending the request to it and replicates new server. Also, RCS evaluates the performance of each server periodically; if any server's response time exceeds 90% of the SLA value, RCS replicates a new replica ( ) and stops sending the request to the lower performance replica ( ), and it removes the ( ) from the load balancer once all the existing requests are completed. Then, administrator can investigate the problem servers.

Evaluation and Discussion
Call function findserver greater resp time() (11) Call function stop replica service( , 1 ) (12) Else-If (13) [(FL flag = "Y")] (14) I f ≥ 90% SLA (15) S e tY WAIT = adm REPL Call function start replica service( , 1 ) (21) [(RST Th Exceed( , 1 ) = "Yes")] (22) Call function start replica service( , 1 ) (23) Call function stop replica service( , 1 ) (24) Else-if (25) [Service Status Abnormal( , 1 ) = "Yes"] (26) Call function start replica service( , 1 ) Call function stop replica service( , 1 ) (28) Else the results. The test environment was set up with virtual machines on Hyper-V with the Windows 2005 server platform with 4 GB RAM and MS-SQL Server 2005. The software tools "Applications Manager" from Manage Engine, SoapUI from SmartBear, and "ACE (Application Control Engine)" from Cisco were used for monitoring, testing, and load balancing purposes, respectively. Tomcat server and Eclipse were used for application development and implementation. We employed web service, namely, the customer status enquiry service ( 1 ) on each of the replication servers 1 ⋅ ⋅ ⋅ which were connected through a LAN (local area network) with a bandwidth of 100 mbps. This web service retrieves the status (e.g., active, closed, dormant, and inactive) of the customer. The SLA time defined for 1 is 1300 ms; concurrent HTTP requests were initiated from seven client machines with the frequency ranging from 1000 to 19,000 requests/minute using SoapUI. The number of concurrent HTTP requests is represented with threads every 60 seconds. A laptop with Core I-5 2.2 GHz 4 GB Ram was used as SOS Station which was connected with an access point to join the same network to the FAPFEA system. To enable Internet access, 3G modem was used via a USB interface. Several tests were carried out by turning on the system and starting operation. Testing the conventional system environment with overload condition to understand the behavior of the system before implementing the FAPFEA.

2
Testing FAPFEA for the reliability of sensing the proximity of future interval response time with defined SLA time and replicate the service dynamically. 3 Testing FAPFEA for the scalability to introduce the replica when required for the continuous overload.

4
Testing FAPFEA for the sustainability to maintain the response time for randomly varying (robust) load.

5
Testing FAPFEA with other models to compare the number of replicated web services provided by each model to process the same load.

Experiments.
The aim of these test scenarios is to evaluate the ability of our proposed framework to sense the proximity of future interval response time with agreed SLA and determine the replication requirement to automatically enhance web service availability through replication and reclamation of the resources based on demand with minimal intervention from the system administrator. Table 4 provides the overview of the test scenarios we conduct in this paper.

Conventional System
Test. This test has been conducted to understand the behavior and performance of the conventional system where there are no replication techniques facilitated. Here, two servers were engaged with web service 1 and the HTTP requests sent to web services, ranging from 1000 requests/minute to 8,000 requests/minute. The CA, CR data has been collected and shown in Table 5 and graphical representation of the test results is shown in Figure 7. It can be inferred from the data and graph that when the arrival rate is greater than 6000 requests/minute, the response time exceeds SLA time and the request failure rate increases too. Since there is no replication technique incorporated in the conventional system, it does not have the ability to replicate new web service automatically. Hence, it is found to be incapable of processing all the requests within expected SLA time. So the web service is considered as unavailable when web service response time exceeds SLA time.   )  7000  7880  880  978  5  4  1300  7000  7880  880  978  10  4  1300  7000  7880  880  978  15  4  1300  7500  8380  1004  1113  20  4  1300  7500  8380  1004  1113  25  5  1300  7500  8380  916  1018  30  5  1300  7500  8380  811  902  35  5  1300  8000  8970  870  967  40  5

Reliability Test for Dynamic Replication.
The aim of this test is to ascertain the reliability of the proposed framework for sensing the proximity of future interval response time with defined SLA time and replicate the service dynamically. To test this scenario, the HTTP requests were sent from client machines to 1 at frequencies ranging from 7000 to 10,000 requests/minute. The and data are collected and calculated from the MS metrics and and are calculated using (1) to (13). and are then evaluated against fuzzy rules and defuzzified using the center of gravity method in (14). These test results are summarized in Table 6 and shown in Figure 11. By virtue of the fuzzy decision output, the "FL flag" is set to "Y," "N," or "S" depending on the loads against the response time. As the FL decision varies with time, the RCS applies the FL decision in the RCA and implements the new replication or removes the replication as shown in Figure 11. For instance, here, the prediction processes, calculations, fuzzy decision, and algorithms used in our framework are explained for at 7500 requests/minute and at 1004. The FPS predicts the FA 1 using (4) with = 90%: From the above equations, FA 1 is derived by summing up ( ) until being greater than 0.90, where = 1 to ; hence, FA 1 is calculated as 8600 requests/minute.
The FR 1 is calculated using (11) to (11b) with = 75%: Similarly, the FR 2 is calculated using (12) to (12b) with = 25%: International Journal of Distributed Sensor Networks 9 The predicted FA is converted into fuzzy sets using triangular method as shown in Figure 8, and respective linguistic values are represented in Table 7. Similarly, FR is converted into fuzzy sets and represented in Figure 9 and respective linguistic values are shown in Table 8.
Evaluation of the rules is as follows: = 90 signifies that replication is required and the FL flag is set to "Y." The RCS analyzes the FL decision by applying RCA to determine the urgency of the replication. Since Y WAIT < adm REPL , it waits till Y WAIT ≥ adm REPL (i.e., 300 seconds); then, the RCA replicates the new server ( 5 ) with 1 . Thus, the load balancer starts distributing the load to the new replica. Similarly, when of 1 reaches 9,000 requests/minute and the future response time exceeds 90% of SLA, without waiting for adm REPL , the RCA immediately replicates the new server ( 6 ) with web service 1 . Thus, the response time of web service is maintained by our proposed framework even during heavy load periods by replicating new servers dynamically when required as shown in Figure 11.

Scalability Test for Continuous
Overload. This test is to ascertain the scalability of the proposed framework when the load on the web service increases continuously. In order to test this scenario, we activated four servers with web service 1 and HTTP requests were sent to 1 at frequencies ranging from 7000 to 12000 requests/minute. The and data are collected and calculated from the MS metrics and   and are calculated using (1) to (13) and evaluated against fuzzy rules and defuzzified using (14) as we described in Section 5.2.2. These test results are summarized in Table 9 and shown in Figure 12. By virtue of the fuzzy decision output, the "FL flag" is set to "Y," "N," or "S" depending on the loads against the response time. As the FL decision varies with time, the RCS applies the FL decision in the RCA and implements the new replication as shown in Figure 12. Thus, the future interval response time is sensed accurately and replicated a new replica when required to provide uninterrupted web service availability.

Sustainability Test for Randomly Varying Load Scenario.
The aim of this test is to ascertain the ability of the proposed framework to maintain the response time of web service within SLA time when the system is under circumstances where it receives the randomly varying load. To test this scenario, the HTTP requests were sent from client machines to 1 at frequencies ranging from 2000 to 19,000 requests/minute by randomly stepping the load up or down every minute and adm REPL are set to 0 seconds to replicate the new service immediately. In total, approximately 163,000 requests were generated and processed by 1 for this test. The and data are collected and calculated from the MS metrics and and are calculated using (1) to (13) and evaluated against fuzzy rules and defuzzified using (14) as described in Section 5.2.2. These test results are summarized in Table 10 and shown in Figure 13. By virtue of the fuzzy decision output, the "FL flag" is set to "Y," "N," or  "S" depending on the loads against the response time. As the FL decision varies with time, the RCS applies the FL decision in the RCA and implements the new replication or removes the replication as shown in Figure 13. For example, the system received a lower load and normal response time after the 14th min (19,000 requests/minute) and the RCS waits for the adm STOP period to stop the replica. Hence, after adm STOP (300 seconds) of continuous low load, the RCS stops one of the replicas. Thus, FAPFEA implements the new replication or reclaims the excessive servers when required to provide uninterrupted web service availability.

Comparison Test of Replication Timing.
To validate the efficiency of FAPFEA, we compare it with the linear regression model (LRM) suggested by [23] and Holt's linear exponential smoothing model (HLESM) suggested by [21]. The comparison test analyzes the number of replicated web services provided by each model to process the same load. The LRM predicts the future load based on data from the past 15 days and replicates the web service accordingly to serve for the 16th day. The HLESM approach computes the response time using the queuing network model, predicts the response time using HLESM, and replicates web services when the predicted response time exceeds 90% of SLA. The replication techniques of these two existing models are computed mathematically and compared with FAPFEA for various loads varying from 2000 requests/minute to 3500 requests/minute. The results are compared and shown in Figure 14. This indicates that the FAPFEA predicts the replication requirement accurately and at the most appropriate time compared with these two existing models. This entails lower maintenance requirements, less electric power consumption, and less operational cost with the use of our approach.

Prediction Error.
To evaluate the prediction accuracy of our framework, we used the common approaches of mean absolute error (MAE) and root mean squared error (RMSE) [31]. MAE is used to calculate the average magnitude of errors. The "RMSE is a quadratic scoring rule which is measuring average magnitude of the error" [32]. Both approaches can have values ranging from zero to ∞ (where lower values are better) [32]. The overall prediction error of FAPFEA is evaluated using The MAE and RMSE values are compared with those of HLESM and LRM. 500 request samples were collected and averaged to 10 samples which are presented in Figure 15. The results of the above tests signify that our proposed framework is efficient in dynamically replicating the web service on-demand, improving the availability of web services to respond to client requests within the defined SLA time for all constant, varied, and robust load conditions.

Conclusion and Future Work
In this paper, we present a sensor web based adaptive prediction framework for improving the availability of web services. Our approach uses the sensor web service PSS to sense the proximity of the predicted future interval response time with SLA response time of web service using PD and ED, respectively. FL is used to determine the replication requirement. IRCM passes the FL decision to RCS for implementing the FL decision that replicates the web service on another server host whenever the predicted response time violates the SLA or reclaims the existing excess resource. In addition, our framework detects the failure of any web service or server and attempts to restart it. In case of web service failure, it replicates the web service on another server. Also, if the response time of any individual server is approaching the threshold limit, it replicates the web service on another server and stops the replica with lower performance.
We conducted several testing scenarios, demonstrating that our framework replicates the web service and reclaims the unnecessary resources dynamically based on demand with 82% accuracy. The comparison results of two existing models (LRM and HLESM) show that FAPFEA predicts the replication requirement more accurately and at the most appropriate time. Thus, FAPFEA facilitates a high availability with minimal administrator intervention and less maintenance and operational cost. The advantages of our proposed framework include that it is proactive, dynamic, on-demand, and accurate. We thereby achieve web service availability by maintaining the response time within SLA and by maintaining the continuous (uninterrupted) availability of web services to provide uninterrupted responses, respectively. Because our framework meets basic attributes such as sustainability, scalability, and elasticity, it provides a better solution to the current internet business world.
Our future work will be directed towards implementing our framework on cloud computing web services and analyzing its performance for large scale applications. One limitation of FAPFEA is that it is capable of one replication for one interval time. If the system requires two or more replications, the other replication will occur after the adm REPL time. We will be addressing this issue in future papers.