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

Authors: Sundharam Ramalingam; Lakshmi Mohandas
Journal: International Journal of Distributed Sensor Networks
 (2016)

---

## Abstract

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.


---

## Body

## 1. 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–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 (C1)) 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. Figure1 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.Figure 1
OGC SWE sensor web architecture of PSS.


## 2. 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–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–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 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.


## 3. 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 Figure2.Figure 2
Framework of FAPFEA.


### 3.1. Monitoring Service (MS)

The MS keep monitors the statuses of web service (C1), servers (R1,R2⋯Rn) and creates metrics for number of requests arrived, response time of each request, and number of requests processed by web service (C1) during a specific interval.


### 3.2. 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.


### 3.3. 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.


### 3.4. 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).Figure 3
PSS functional flow diagram.


## 3.1. Monitoring Service (MS)

The MS keep monitors the statuses of web service (C1), servers (R1,R2⋯Rn) and creates metrics for number of requests arrived, response time of each request, and number of requests processed by web service (C1) during a specific interval.


## 3.2. 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.


## 3.3. 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.


## 3.4. 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).Figure 3
PSS functional flow diagram.


## 4. 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 Figure1. 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 (C1) 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 physical sensors/sensor services (PSS) and collects the sensed data from the sensors. Thus, PSS received the request from middleware and processes the request to sense the proximity of future interval response time of specific web services with the help of FPS and it determines the replication requirement with the help of FIS. The PSS’s outcome is responded back to middleware in turn to reach IRCM. IRCM further analyzes the PSS’s response with the help of RCS and RCA for the implementation of replication. The processes and techniques used in FPS, FIS, and RCS are explained below in detail and flow diagram is illustrated in Figure 4.Figure 4
FAPFEA flow diagram.


### 4.1. 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 serviceC1 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 (Ti). This can be parameterized with multiples of the monitoring pole interval. From the MS database, the FPS reads the number of requests that arrived (nqs) to web service (C1) at the end of every interval (Ti) (e.g., 60 seconds). The average arrival rate of an individual server is calculated using (1)λcs=nqsTi.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 (2)CA=λc=∑s=1nλcsns.From λc, it predicts the future arrival rate (λf) for the next interval using PD [26, page 168]:(3)λf=Px=λcx⊗e-λcx!.To find the future arrival rate, we use the mean of two probability confidences σu and σv. The future arrival rates FA1 and FA2 are predicted at probabilities σu and σv using (4) and (5), respectively [26, page 170]. Consider(4)FA1=Fx=∑i=0xe-λc⊗λcii!≥σu,where σu is a known value (e.g., 0.9). Hence, FA1 is calculated using (4) [26, page 170]. Similarly, (5)FA2=Fx=∑i=0xe-λc⊗λcii!≥σv,where σv is a known value (e.g., 0.1). Hence, FA2 is calculated using (5) [26, page 170].The total future arrival rate (FA) is calculated using (6) [26, page 222]:(6)λf=FA=FA1⊗σu⊕FA2⊗σv.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 (nq) and response time of each request (Tcq) at the end of every interval (Ti) (e.g., 60 seconds). The average response time (Tcs) (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 μc is calculated using (9). Therefore, (7)Tcs=∑q=1nTcqnq,(8)CR=Tc=∑s=1nTcsns,(9)Current  response  rateμc=TiTc.From Tc, FPS predicts the future response time (FR) using ED [26, page 172](10)Px=Tc⊗e-Tc⊗x.We use the mean of two probability confidences θJ and θK to find the future response time. The CDF (cumulative distribution function) of the future response time (FR1) is predicted for the probability confidence θJ using (11), where θJ is a known probability confidence value (e.g., 0.75). Hence, FR1 is calculated using (11) to 11b [26, page 172]. Consider(11)PX=x=∑x=1nTc⊗e-Tc⊗x≥θJ,11aFx=∫0xTc⊗e-Tc⊗xdt=1-e-Tc⊗x≤θJ,11bFR1=x=-Tcln⁡1-θJ.Similarly, the future response time (FR2) is predicted at probability confidence θK (e.g., 0.25) using (12) to 12b [26, page 172]. Consider (12)PX=x=∑x=1nTc⊗e-Tc⊗x≥θK,12aFx=∫0xTc⊗e-Tc⊗xdt=1-e-Tc⊗x≤θK,12bFR2=x=-Tcln⁡1-θK.The total future response time (FR) (in ms) is calculated using [26, page 222](13)FR=Tf=FR1⊗θJ⊕FR2⊗θK.


### 4.2. 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 λf and Tf are defined in Tables 1 and 2, respectively.Table 1
Linguistic variables for FA.
Fuzzy set
Crisp input range
Linguistic variable
α
1
0 toω-(ω∗0.6)
Very Very Low (VVL)
α
2
ω
-
(
ω
∗
0.8
) to ω-(ω∗0.4)
Very Low (VL)
α
3
ω
-
(
ω
∗
0.6
) to ω
Low (LW)
α
4
ω
-
(
ω
∗
0.4
) to ω+(ω∗0.4)
Normal (NR)
α
5
ω  to ω+(ω∗0.6)
High (HG)
α
6
ω
+
(
ω
∗
0.4
) to ω+(ω∗0.8)
Very High (VH)
α
7
ω
+
(
ω
∗
0.6
) to 0
Very Very High (VVH)Table 2
Linguistic variables for FR.
SL
Crisp input range
Linguistic variable
β
1
0 toψ-(ψ∗0.6)
Very Very Fast (VVF)
β
2
ψ
-
(
ψ
∗
0.8
) to ψ-(ψ∗0.4)
Very Fast (VF)
β
3
ψ
-
(
ψ
∗
0.6
) to  ψ
Fast (FS)
β
4
ψ
-
(
ψ
∗
0.4
) to ψ+(ψ∗0.4)
Normal (NR)
β
5
ψ  to ψ+(ψ∗0.6)
Slow (SL)
β
6
ψ
+
(
ψ
∗
0.4
) to ψ+(ψ∗0.8)
Very Slow (VS)
β
7
ψ
+
(
ψ
∗
0.6
) to 0
Very Very Slow (VVS)Table 3
Replication matrix.
FR
FA
VVH
VH
HG
NR
LW
VL
VVL
VVS
Y
Y
Y
Y
N
N
N
VS
Y
Y
Y
N
N
N
N
SL
Y
Y
Y
N
N
N
N
NR
Y
N
N
N
N
N
S
FS
N
N
N
N
S
S
S
VF
N
N
N
N
S
S
S
VVF
N
N
N
S
S
S
SThe 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 ρ=ns∗Np, where ns is number of servers and Np 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 “if-then-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 (72) fuzzy decisional matrix elements which are summarized in 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 (14)δ=∑i=1nmi∗wi∑i=1nmi.Figure 5
Fuzzy sets (α) for future arrival rate.Figure 6
Fuzzy sets (β) for future response time.


### 4.3. 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_TSTOP,” the administrator defined waiting time (for the RCS) after the FL decision is set to “S” (e.g., 900 seconds); (2) “adm_TREPL,” 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_TWAIT,” the waiting time of the system after the FL decision is set to “Y”; and (4) “S_TWAIT,” the waiting time of the system after the FL decision is set to “S.” The “adm_TSTOP” and “adm_TREPL” 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 Tf≥ 90% SLA; if true, it implements the replication immediately; otherwise, it continues for the next interval until Y_TWAIT≥ adm_TREPL; then, it implements the new replica (Ry). 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_TSTOP; then, it stops server (Rx) which provides higher response time. Also, the RCS periodically pings the servers and checks services to determine the health status at every Th 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 (Ry) and stops sending the request to the lower performance replica (Rx), and it removes the (Rx) from the load balancer once all the existing requests are completed. Then, administrator can investigate the problem servers.Pseudocode 1:Pseudocode of RCA.
(1) /∗⁢IRCM-Execution Flow⁢∗/
(2) Read_interval = current_time -Tpr
(3) If Read_interval >Ti
(4) Set  Tpr =  current_time
(5) Call function PSS()
(6) Call function RCS()
(7) /∗⁢RCS-Flow⁢∗/
(8) If [(FL_flag  = “S”) AND
(9)  (S_TWAIT ≥ adm_TSTOP)]
(10)  Call function findserver_greater_resp_time()
(11)  Call function stop_replica_service(Rx, C1)
(12) Else-If
(13)  [(FL_flag = “Y”)]
(14)   If  Tf ≥ 90% SLA
(15)    Set  Y_TWAIT = adm_TREPL
(16)   End-if
(17)   If(Y_TWAIT ≥ adm_TREPL)
(18)    Call function start_replica_service(Ry, C1)
(19)   End-if
(20) Else-if
(21)   [(RST_Th_Exceed(Rx, C1) = “Yes”)]
(22)    Call function start_replica_service(Ry, C1)
(23)    Call function stop_replica_service(Rx,  C1)
(24) Else-if
(25)   [Service_Status_Abnormal(Rx, C1) = “Yes”]
(26)    Call function start_replica_service(Ry, C1)
(27)    Call function stop_replica_service(Rx, C1)
(28) Else
(29)   Continue
(30) End-if
(31) End-if.


## 4.1. 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 serviceC1 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 (Ti). This can be parameterized with multiples of the monitoring pole interval. From the MS database, the FPS reads the number of requests that arrived (nqs) to web service (C1) at the end of every interval (Ti) (e.g., 60 seconds). The average arrival rate of an individual server is calculated using (1)λcs=nqsTi.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 (2)CA=λc=∑s=1nλcsns.From λc, it predicts the future arrival rate (λf) for the next interval using PD [26, page 168]:(3)λf=Px=λcx⊗e-λcx!.To find the future arrival rate, we use the mean of two probability confidences σu and σv. The future arrival rates FA1 and FA2 are predicted at probabilities σu and σv using (4) and (5), respectively [26, page 170]. Consider(4)FA1=Fx=∑i=0xe-λc⊗λcii!≥σu,where σu is a known value (e.g., 0.9). Hence, FA1 is calculated using (4) [26, page 170]. Similarly, (5)FA2=Fx=∑i=0xe-λc⊗λcii!≥σv,where σv is a known value (e.g., 0.1). Hence, FA2 is calculated using (5) [26, page 170].The total future arrival rate (FA) is calculated using (6) [26, page 222]:(6)λf=FA=FA1⊗σu⊕FA2⊗σv.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 (nq) and response time of each request (Tcq) at the end of every interval (Ti) (e.g., 60 seconds). The average response time (Tcs) (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 μc is calculated using (9). Therefore, (7)Tcs=∑q=1nTcqnq,(8)CR=Tc=∑s=1nTcsns,(9)Current  response  rateμc=TiTc.From Tc, FPS predicts the future response time (FR) using ED [26, page 172](10)Px=Tc⊗e-Tc⊗x.We use the mean of two probability confidences θJ and θK to find the future response time. The CDF (cumulative distribution function) of the future response time (FR1) is predicted for the probability confidence θJ using (11), where θJ is a known probability confidence value (e.g., 0.75). Hence, FR1 is calculated using (11) to 11b [26, page 172]. Consider(11)PX=x=∑x=1nTc⊗e-Tc⊗x≥θJ,11aFx=∫0xTc⊗e-Tc⊗xdt=1-e-Tc⊗x≤θJ,11bFR1=x=-Tcln⁡1-θJ.Similarly, the future response time (FR2) is predicted at probability confidence θK (e.g., 0.25) using (12) to 12b [26, page 172]. Consider (12)PX=x=∑x=1nTc⊗e-Tc⊗x≥θK,12aFx=∫0xTc⊗e-Tc⊗xdt=1-e-Tc⊗x≤θK,12bFR2=x=-Tcln⁡1-θK.The total future response time (FR) (in ms) is calculated using [26, page 222](13)FR=Tf=FR1⊗θJ⊕FR2⊗θK.


## 4.2. 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 λf and Tf are defined in Tables 1 and 2, respectively.Table 1
Linguistic variables for FA.
Fuzzy set
Crisp input range
Linguistic variable
α
1
0 toω-(ω∗0.6)
Very Very Low (VVL)
α
2
ω
-
(
ω
∗
0.8
) to ω-(ω∗0.4)
Very Low (VL)
α
3
ω
-
(
ω
∗
0.6
) to ω
Low (LW)
α
4
ω
-
(
ω
∗
0.4
) to ω+(ω∗0.4)
Normal (NR)
α
5
ω  to ω+(ω∗0.6)
High (HG)
α
6
ω
+
(
ω
∗
0.4
) to ω+(ω∗0.8)
Very High (VH)
α
7
ω
+
(
ω
∗
0.6
) to 0
Very Very High (VVH)Table 2
Linguistic variables for FR.
SL
Crisp input range
Linguistic variable
β
1
0 toψ-(ψ∗0.6)
Very Very Fast (VVF)
β
2
ψ
-
(
ψ
∗
0.8
) to ψ-(ψ∗0.4)
Very Fast (VF)
β
3
ψ
-
(
ψ
∗
0.6
) to  ψ
Fast (FS)
β
4
ψ
-
(
ψ
∗
0.4
) to ψ+(ψ∗0.4)
Normal (NR)
β
5
ψ  to ψ+(ψ∗0.6)
Slow (SL)
β
6
ψ
+
(
ψ
∗
0.4
) to ψ+(ψ∗0.8)
Very Slow (VS)
β
7
ψ
+
(
ψ
∗
0.6
) to 0
Very Very Slow (VVS)Table 3
Replication matrix.
FR
FA
VVH
VH
HG
NR
LW
VL
VVL
VVS
Y
Y
Y
Y
N
N
N
VS
Y
Y
Y
N
N
N
N
SL
Y
Y
Y
N
N
N
N
NR
Y
N
N
N
N
N
S
FS
N
N
N
N
S
S
S
VF
N
N
N
N
S
S
S
VVF
N
N
N
S
S
S
SThe 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 ρ=ns∗Np, where ns is number of servers and Np 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 “if-then-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 (72) fuzzy decisional matrix elements which are summarized in 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 (14)δ=∑i=1nmi∗wi∑i=1nmi.Figure 5
Fuzzy sets (α) for future arrival rate.Figure 6
Fuzzy sets (β) for future response time.


## 4.3. 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_TSTOP,” the administrator defined waiting time (for the RCS) after the FL decision is set to “S” (e.g., 900 seconds); (2) “adm_TREPL,” 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_TWAIT,” the waiting time of the system after the FL decision is set to “Y”; and (4) “S_TWAIT,” the waiting time of the system after the FL decision is set to “S.” The “adm_TSTOP” and “adm_TREPL” 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 Tf≥ 90% SLA; if true, it implements the replication immediately; otherwise, it continues for the next interval until Y_TWAIT≥ adm_TREPL; then, it implements the new replica (Ry). 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_TSTOP; then, it stops server (Rx) which provides higher response time. Also, the RCS periodically pings the servers and checks services to determine the health status at every Th 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 (Ry) and stops sending the request to the lower performance replica (Rx), and it removes the (Rx) from the load balancer once all the existing requests are completed. Then, administrator can investigate the problem servers.Pseudocode 1:Pseudocode of RCA.
(1) /∗⁢IRCM-Execution Flow⁢∗/
(2) Read_interval = current_time -Tpr
(3) If Read_interval >Ti
(4) Set  Tpr =  current_time
(5) Call function PSS()
(6) Call function RCS()
(7) /∗⁢RCS-Flow⁢∗/
(8) If [(FL_flag  = “S”) AND
(9)  (S_TWAIT ≥ adm_TSTOP)]
(10)  Call function findserver_greater_resp_time()
(11)  Call function stop_replica_service(Rx, C1)
(12) Else-If
(13)  [(FL_flag = “Y”)]
(14)   If  Tf ≥ 90% SLA
(15)    Set  Y_TWAIT = adm_TREPL
(16)   End-if
(17)   If(Y_TWAIT ≥ adm_TREPL)
(18)    Call function start_replica_service(Ry, C1)
(19)   End-if
(20) Else-if
(21)   [(RST_Th_Exceed(Rx, C1) = “Yes”)]
(22)    Call function start_replica_service(Ry, C1)
(23)    Call function stop_replica_service(Rx,  C1)
(24) Else-if
(25)   [Service_Status_Abnormal(Rx, C1) = “Yes”]
(26)    Call function start_replica_service(Ry, C1)
(27)    Call function stop_replica_service(Rx, C1)
(28) Else
(29)   Continue
(30) End-if
(31) End-if.


## 5. Evaluation and Discussion

### 5.1. Environment

This section explains the test environment to evaluate the performance of FAPFEA and analyze 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 (C1) on each of the replication servers R1⋯Rn 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 C1 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.


### 5.2. 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. Table4 provides the overview of the test scenarios we conduct in this paper.Table 4
Overview of experimental scenarios.
SL
Scenario
1
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.


#### 5.2.1. 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 serviceC1 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.Table 5
Experimental results of conventional system.
CA
CR
SLA
1000
203
1300
2000
316
1300
3000
502
1300
4000
724
1300
5000
968
1300
6000
1339
1300
7000
1774
1300
8000
2358
1300Figure 7
Conventional system test.


#### 5.2.2. 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 toC1 at frequencies ranging from 7000 to 10,000 requests/minute. The λc and Tc data are collected and calculated from the MS metrics and λf and Tf are calculated using (1) to (13). λf and Tf 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 λc at 7500 requests/minute and Tc at 1004.Table 6
Experimental results of reliability test.
CA (in Nos.)
FA (in Nos.)
CR (in ms)
FR (in ms)
Time (in min)
Servers (in Nos.)
SLA (in ms)
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
1300
8000
8970
870
967
45
5
1300
8000
8970
870
967
50
5
1300
9000
9960
1071
1184
55
5
1300
9000
9960
893
1004
60
6
1300
9000
9960
840
934
65
6
1300
10000
11040
967
1079
70
6
1300
10000
11040
978
1087
75
7
1300
10000
11040
896
996
80
7
1300The FPS predicts the FA1 using (4) with σu = 90%:(15)FA1=Fx=∑i=0ne-λc⊗λcii!≥0.90,Fx=PX=1+PX=2+PX=3+⋯≥0.90.From the above equations, FA1 is derived by summing up P(X) until being greater than 0.90, where x=1 to n; hence, FA1 is calculated as 8600 requests/minute.Similarly, FA2 is calculated using (5) with σv = 10%:(16)FA2=Fx=∑i=0ne-λc⊗λcii!≥0.10,where FA2 = 6400 requests/minute.The total future arrival rate is calculated using (6):(17)FA=8600∗0.9+6400∗0.10=7740+640=8380requests/minute.The FR1 is calculated using (11) to 11b with θJ = 75%:(18)FR1=-Tc⊗ln⁡1-σj,FR1=-1004⊗ln⁡1-0.75=1391.8395ms.Similarly, the FR2 is calculated using (12) to 12b with θK = 25%: (19)FR2=288.8328ms.The total future response time (FR) is calculated using (13):(20)FR=Tf=1391.8395∗0.75+288.8328∗0.25=1043.8796+72.2082=1116.0878ms.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.Table 7
Linguistic variable of FA.
SN
Fuzzy sets
Input
Output set
Output
α
1
VVL
0
1000
0
α
2
VL
0
2000
0
α
3
LW
0
3000
0
α
4
NR
0
5000
0
α
5
HG
0
7000
0
α
6
VH
0.62
8000
4960
α
7
VVH
0.38
9000
3420
8380Table 8
Linguistic variable of FR.
SN
Fuzzy sets
Input
Output set
Output
β
1
VVF
0
130
β
2
VF
0
260
0
β
3
FS
0
390
0
β
4
NR
0
650
0
β
5
SL
0
910
0
β
6
VS
0.39
1040
408.72
β
7
VVS
0.61
1170
707.85
1116.6Figure 8
Fuzzy sets representation of FA.Figure 9
Fuzzy sets representation of FR.Evaluation of the rules is as follows:(21)γ1=Max⁡0.39,0.61,0,0=0.61,γ2=Max⁡0,0,0,0,0,0,0=0,γ3=Max⁡0,0,0,0=0.Using (14), the fuzzified values are defuzzified and illustrated in Figure 10:(22)δ=450∗0.615∗0.61=274.53.05=90.δ = 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_TWAIT < adm_TREPL, it waits till Y_TWAIT≥ adm_TREPL (i.e., 300 seconds); then, the RCA replicates the new server (R5) with C1. Thus, the load balancer starts distributing the load to the new replica. Similarly, when λc of C1 reaches 9,000 requests/minute and the future response time exceeds 90% of SLA, without waiting for adm_TREPL, the RCA immediately replicates the new server (R6) with web service C1. 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.Figure 10
Crisp output of defuzzification.Figure 11
Reliability test for dynamic replication.


#### 5.2.3. 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 serviceC1 and HTTP requests were sent to C1 at frequencies ranging from 7000 to 12000 requests/minute. The λc and Tc data are collected and calculated from the MS metrics and λf and Tf 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.Table 9
Experimental results of scalability test.
CA (in Nos.)
FA (in Nos.)
CR (in ms)
FR (in ms)
Time (in min.)
Servers (in Nos.)
SLA (in ms)
7000
7880
880
978
5
4
1300
7500
8380
1004
1113
10
5
1300
8000
8970
870
967
15
5
1300
8500
9500
946
1046
20
5
1300
9000
10000
1021
1121
25
5
1300
9500
10500
1101
1184
30
6
1300
10000
11000
893
993
35
6
1300
10500
11500
967
1067
40
6
1300
11000
12000
1052
1152
45
6
1300
11500
12500
1171
1271
50
7
1300
12000
13000
896
996
55
7
1300Figure 12
Scalability test for continuous over load.


#### 5.2.4. 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 toC1 at frequencies ranging from 2000 to 19,000 requests/minute by randomly stepping the load up or down every minute and adm_TREPL are set to 0 seconds to replicate the new service immediately. In total, approximately 163,000 requests were generated and processed by C1 for this test. The λc and Tc data are collected and calculated from the MS metrics and λf and Tf 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_TSTOP period to stop the replica. Hence, after adm_TSTOP (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.Table 10
Experimental results of sustainability test.
CA (in Nos.)
FA (in Nos.)
CR (in ms)
FR (in ms)
Time (in min.)
Servers (in Nos.)
SLA (in ms)
2000
2480
652
730
1
2
1300
4000
4640
978
1087
2
3
1300
6000
6800
935
1039
3
3
1300
3000
3560
640
711
4
3
1300
2000
2480
465
516
5
3
1300
7000
7880
913
1014
6
4
1300
14000
16160
998
1109
7
5
1300
10000
11040
836
929
8
5
1300
18000
19920
993
1103
9
6
1300
8000
8970
690
767
10
6
1300
7000
7880
576
640
11
6
1300
10000
11040
827
943
12
6
1300
16000
18010
921
1011
13
6
1300
19000
20990
1034
1197
14
7
1300
13000
15080
729
823
15
7
1300
12000
13130
581
645
16
7
1300
12000
13130
569
631
17
7
1300
8000
8790
453
525
18
7
1300
4000
4640
314
411
19
6
1300
6000
6800
643
719
20
6
1300Figure 13
Sustainability test for randomly varying load.


#### 5.2.5. 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.Figure 14
Experimental results of comparison.


### 5.3. 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 (23)MAE=∑i=1nPi-Pi^N,RMSE=∑i=1nPi-Pi^2N.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 graph shows that the RMSE value for FAPFEA reached a maximum of 18% for sample 10 and the MAE value reached a maximum of 17% at sample 6. By comparison, the maximum RMSE and MAE values for HLESM were 23% at sample 6 and 20% at sample 8, respectively. The maximum RMSE and MAE values for LRM were 25% at sample 10 and 22% maximum at sample 7, respectively. Thus, the FAPFEA prediction accuracy is demonstrated to be more reliable than the existing methods.Figure 15
Prediction error comparison.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.


## 5.1. Environment

This section explains the test environment to evaluate the performance of FAPFEA and analyze 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 (C1) on each of the replication servers R1⋯Rn 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 C1 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.


## 5.2. 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. Table4 provides the overview of the test scenarios we conduct in this paper.Table 4
Overview of experimental scenarios.
SL
Scenario
1
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.


### 5.2.1. 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 serviceC1 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.Table 5
Experimental results of conventional system.
CA
CR
SLA
1000
203
1300
2000
316
1300
3000
502
1300
4000
724
1300
5000
968
1300
6000
1339
1300
7000
1774
1300
8000
2358
1300Figure 7
Conventional system test.


### 5.2.2. 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 toC1 at frequencies ranging from 7000 to 10,000 requests/minute. The λc and Tc data are collected and calculated from the MS metrics and λf and Tf are calculated using (1) to (13). λf and Tf 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 λc at 7500 requests/minute and Tc at 1004.Table 6
Experimental results of reliability test.
CA (in Nos.)
FA (in Nos.)
CR (in ms)
FR (in ms)
Time (in min)
Servers (in Nos.)
SLA (in ms)
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
1300
8000
8970
870
967
45
5
1300
8000
8970
870
967
50
5
1300
9000
9960
1071
1184
55
5
1300
9000
9960
893
1004
60
6
1300
9000
9960
840
934
65
6
1300
10000
11040
967
1079
70
6
1300
10000
11040
978
1087
75
7
1300
10000
11040
896
996
80
7
1300The FPS predicts the FA1 using (4) with σu = 90%:(15)FA1=Fx=∑i=0ne-λc⊗λcii!≥0.90,Fx=PX=1+PX=2+PX=3+⋯≥0.90.From the above equations, FA1 is derived by summing up P(X) until being greater than 0.90, where x=1 to n; hence, FA1 is calculated as 8600 requests/minute.Similarly, FA2 is calculated using (5) with σv = 10%:(16)FA2=Fx=∑i=0ne-λc⊗λcii!≥0.10,where FA2 = 6400 requests/minute.The total future arrival rate is calculated using (6):(17)FA=8600∗0.9+6400∗0.10=7740+640=8380requests/minute.The FR1 is calculated using (11) to 11b with θJ = 75%:(18)FR1=-Tc⊗ln⁡1-σj,FR1=-1004⊗ln⁡1-0.75=1391.8395ms.Similarly, the FR2 is calculated using (12) to 12b with θK = 25%: (19)FR2=288.8328ms.The total future response time (FR) is calculated using (13):(20)FR=Tf=1391.8395∗0.75+288.8328∗0.25=1043.8796+72.2082=1116.0878ms.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.Table 7
Linguistic variable of FA.
SN
Fuzzy sets
Input
Output set
Output
α
1
VVL
0
1000
0
α
2
VL
0
2000
0
α
3
LW
0
3000
0
α
4
NR
0
5000
0
α
5
HG
0
7000
0
α
6
VH
0.62
8000
4960
α
7
VVH
0.38
9000
3420
8380Table 8
Linguistic variable of FR.
SN
Fuzzy sets
Input
Output set
Output
β
1
VVF
0
130
β
2
VF
0
260
0
β
3
FS
0
390
0
β
4
NR
0
650
0
β
5
SL
0
910
0
β
6
VS
0.39
1040
408.72
β
7
VVS
0.61
1170
707.85
1116.6Figure 8
Fuzzy sets representation of FA.Figure 9
Fuzzy sets representation of FR.Evaluation of the rules is as follows:(21)γ1=Max⁡0.39,0.61,0,0=0.61,γ2=Max⁡0,0,0,0,0,0,0=0,γ3=Max⁡0,0,0,0=0.Using (14), the fuzzified values are defuzzified and illustrated in Figure 10:(22)δ=450∗0.615∗0.61=274.53.05=90.δ = 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_TWAIT < adm_TREPL, it waits till Y_TWAIT≥ adm_TREPL (i.e., 300 seconds); then, the RCA replicates the new server (R5) with C1. Thus, the load balancer starts distributing the load to the new replica. Similarly, when λc of C1 reaches 9,000 requests/minute and the future response time exceeds 90% of SLA, without waiting for adm_TREPL, the RCA immediately replicates the new server (R6) with web service C1. 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.Figure 10
Crisp output of defuzzification.Figure 11
Reliability test for dynamic replication.


### 5.2.3. 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 serviceC1 and HTTP requests were sent to C1 at frequencies ranging from 7000 to 12000 requests/minute. The λc and Tc data are collected and calculated from the MS metrics and λf and Tf 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.Table 9
Experimental results of scalability test.
CA (in Nos.)
FA (in Nos.)
CR (in ms)
FR (in ms)
Time (in min.)
Servers (in Nos.)
SLA (in ms)
7000
7880
880
978
5
4
1300
7500
8380
1004
1113
10
5
1300
8000
8970
870
967
15
5
1300
8500
9500
946
1046
20
5
1300
9000
10000
1021
1121
25
5
1300
9500
10500
1101
1184
30
6
1300
10000
11000
893
993
35
6
1300
10500
11500
967
1067
40
6
1300
11000
12000
1052
1152
45
6
1300
11500
12500
1171
1271
50
7
1300
12000
13000
896
996
55
7
1300Figure 12
Scalability test for continuous over load.


### 5.2.4. 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 toC1 at frequencies ranging from 2000 to 19,000 requests/minute by randomly stepping the load up or down every minute and adm_TREPL are set to 0 seconds to replicate the new service immediately. In total, approximately 163,000 requests were generated and processed by C1 for this test. The λc and Tc data are collected and calculated from the MS metrics and λf and Tf 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_TSTOP period to stop the replica. Hence, after adm_TSTOP (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.Table 10
Experimental results of sustainability test.
CA (in Nos.)
FA (in Nos.)
CR (in ms)
FR (in ms)
Time (in min.)
Servers (in Nos.)
SLA (in ms)
2000
2480
652
730
1
2
1300
4000
4640
978
1087
2
3
1300
6000
6800
935
1039
3
3
1300
3000
3560
640
711
4
3
1300
2000
2480
465
516
5
3
1300
7000
7880
913
1014
6
4
1300
14000
16160
998
1109
7
5
1300
10000
11040
836
929
8
5
1300
18000
19920
993
1103
9
6
1300
8000
8970
690
767
10
6
1300
7000
7880
576
640
11
6
1300
10000
11040
827
943
12
6
1300
16000
18010
921
1011
13
6
1300
19000
20990
1034
1197
14
7
1300
13000
15080
729
823
15
7
1300
12000
13130
581
645
16
7
1300
12000
13130
569
631
17
7
1300
8000
8790
453
525
18
7
1300
4000
4640
314
411
19
6
1300
6000
6800
643
719
20
6
1300Figure 13
Sustainability test for randomly varying load.


### 5.2.5. 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.Figure 14
Experimental results of comparison.


## 5.2.1. 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 serviceC1 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.Table 5
Experimental results of conventional system.
CA
CR
SLA
1000
203
1300
2000
316
1300
3000
502
1300
4000
724
1300
5000
968
1300
6000
1339
1300
7000
1774
1300
8000
2358
1300Figure 7
Conventional system test.


## 5.2.2. 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 toC1 at frequencies ranging from 7000 to 10,000 requests/minute. The λc and Tc data are collected and calculated from the MS metrics and λf and Tf are calculated using (1) to (13). λf and Tf 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 λc at 7500 requests/minute and Tc at 1004.Table 6
Experimental results of reliability test.
CA (in Nos.)
FA (in Nos.)
CR (in ms)
FR (in ms)
Time (in min)
Servers (in Nos.)
SLA (in ms)
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
1300
8000
8970
870
967
45
5
1300
8000
8970
870
967
50
5
1300
9000
9960
1071
1184
55
5
1300
9000
9960
893
1004
60
6
1300
9000
9960
840
934
65
6
1300
10000
11040
967
1079
70
6
1300
10000
11040
978
1087
75
7
1300
10000
11040
896
996
80
7
1300The FPS predicts the FA1 using (4) with σu = 90%:(15)FA1=Fx=∑i=0ne-λc⊗λcii!≥0.90,Fx=PX=1+PX=2+PX=3+⋯≥0.90.From the above equations, FA1 is derived by summing up P(X) until being greater than 0.90, where x=1 to n; hence, FA1 is calculated as 8600 requests/minute.Similarly, FA2 is calculated using (5) with σv = 10%:(16)FA2=Fx=∑i=0ne-λc⊗λcii!≥0.10,where FA2 = 6400 requests/minute.The total future arrival rate is calculated using (6):(17)FA=8600∗0.9+6400∗0.10=7740+640=8380requests/minute.The FR1 is calculated using (11) to 11b with θJ = 75%:(18)FR1=-Tc⊗ln⁡1-σj,FR1=-1004⊗ln⁡1-0.75=1391.8395ms.Similarly, the FR2 is calculated using (12) to 12b with θK = 25%: (19)FR2=288.8328ms.The total future response time (FR) is calculated using (13):(20)FR=Tf=1391.8395∗0.75+288.8328∗0.25=1043.8796+72.2082=1116.0878ms.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.Table 7
Linguistic variable of FA.
SN
Fuzzy sets
Input
Output set
Output
α
1
VVL
0
1000
0
α
2
VL
0
2000
0
α
3
LW
0
3000
0
α
4
NR
0
5000
0
α
5
HG
0
7000
0
α
6
VH
0.62
8000
4960
α
7
VVH
0.38
9000
3420
8380Table 8
Linguistic variable of FR.
SN
Fuzzy sets
Input
Output set
Output
β
1
VVF
0
130
β
2
VF
0
260
0
β
3
FS
0
390
0
β
4
NR
0
650
0
β
5
SL
0
910
0
β
6
VS
0.39
1040
408.72
β
7
VVS
0.61
1170
707.85
1116.6Figure 8
Fuzzy sets representation of FA.Figure 9
Fuzzy sets representation of FR.Evaluation of the rules is as follows:(21)γ1=Max⁡0.39,0.61,0,0=0.61,γ2=Max⁡0,0,0,0,0,0,0=0,γ3=Max⁡0,0,0,0=0.Using (14), the fuzzified values are defuzzified and illustrated in Figure 10:(22)δ=450∗0.615∗0.61=274.53.05=90.δ = 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_TWAIT < adm_TREPL, it waits till Y_TWAIT≥ adm_TREPL (i.e., 300 seconds); then, the RCA replicates the new server (R5) with C1. Thus, the load balancer starts distributing the load to the new replica. Similarly, when λc of C1 reaches 9,000 requests/minute and the future response time exceeds 90% of SLA, without waiting for adm_TREPL, the RCA immediately replicates the new server (R6) with web service C1. 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.Figure 10
Crisp output of defuzzification.Figure 11
Reliability test for dynamic replication.


## 5.2.3. 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 serviceC1 and HTTP requests were sent to C1 at frequencies ranging from 7000 to 12000 requests/minute. The λc and Tc data are collected and calculated from the MS metrics and λf and Tf 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.Table 9
Experimental results of scalability test.
CA (in Nos.)
FA (in Nos.)
CR (in ms)
FR (in ms)
Time (in min.)
Servers (in Nos.)
SLA (in ms)
7000
7880
880
978
5
4
1300
7500
8380
1004
1113
10
5
1300
8000
8970
870
967
15
5
1300
8500
9500
946
1046
20
5
1300
9000
10000
1021
1121
25
5
1300
9500
10500
1101
1184
30
6
1300
10000
11000
893
993
35
6
1300
10500
11500
967
1067
40
6
1300
11000
12000
1052
1152
45
6
1300
11500
12500
1171
1271
50
7
1300
12000
13000
896
996
55
7
1300Figure 12
Scalability test for continuous over load.


## 5.2.4. 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 toC1 at frequencies ranging from 2000 to 19,000 requests/minute by randomly stepping the load up or down every minute and adm_TREPL are set to 0 seconds to replicate the new service immediately. In total, approximately 163,000 requests were generated and processed by C1 for this test. The λc and Tc data are collected and calculated from the MS metrics and λf and Tf 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_TSTOP period to stop the replica. Hence, after adm_TSTOP (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.Table 10
Experimental results of sustainability test.
CA (in Nos.)
FA (in Nos.)
CR (in ms)
FR (in ms)
Time (in min.)
Servers (in Nos.)
SLA (in ms)
2000
2480
652
730
1
2
1300
4000
4640
978
1087
2
3
1300
6000
6800
935
1039
3
3
1300
3000
3560
640
711
4
3
1300
2000
2480
465
516
5
3
1300
7000
7880
913
1014
6
4
1300
14000
16160
998
1109
7
5
1300
10000
11040
836
929
8
5
1300
18000
19920
993
1103
9
6
1300
8000
8970
690
767
10
6
1300
7000
7880
576
640
11
6
1300
10000
11040
827
943
12
6
1300
16000
18010
921
1011
13
6
1300
19000
20990
1034
1197
14
7
1300
13000
15080
729
823
15
7
1300
12000
13130
581
645
16
7
1300
12000
13130
569
631
17
7
1300
8000
8790
453
525
18
7
1300
4000
4640
314
411
19
6
1300
6000
6800
643
719
20
6
1300Figure 13
Sustainability test for randomly varying load.


## 5.2.5. 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.Figure 14
Experimental results of comparison.


## 5.3. 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 (23)MAE=∑i=1nPi-Pi^N,RMSE=∑i=1nPi-Pi^2N.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 graph shows that the RMSE value for FAPFEA reached a maximum of 18% for sample 10 and the MAE value reached a maximum of 17% at sample 6. By comparison, the maximum RMSE and MAE values for HLESM were 23% at sample 6 and 20% at sample 8, respectively. The maximum RMSE and MAE values for LRM were 25% at sample 10 and 22% maximum at sample 7, respectively. Thus, the FAPFEA prediction accuracy is demonstrated to be more reliable than the existing methods.Figure 15
Prediction error comparison.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.


## 6. 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_TREPL time. We will be addressing this issue in future papers.



---

*Source: 4972061-2016-02-14.xml*