Sage Journals: Discover world-class research

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.

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 ( $C_{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.

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 Figure 2.

Figure 2

Framework of FAPFEA.

3.1. Monitoring Service (MS)

The MS keep monitors the statuses of web service ( $C_{1}$ ), servers ( $R_{1}, R_{2} \dots R_{n}$ ) and creates metrics for number of requests arrived, response time of each request, and number of requests processed by web service ( $C_{1}$ ) 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 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 ( $C_{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 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 service $C_{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 ( $T_{i}$ ). This can be parameterized with multiples of the monitoring pole interval. From the MS database, the FPS reads the number of requests that arrived ( $n_{q}^{s}$ ) to web service ( $C_{1}$ ) at the end of every interval ( $T_{i}$ ) (e.g., 60 seconds). The average arrival rate of an individual server is calculated using

\begin{matrix} λ_{c}^{s} = \frac{n_{q}^{s}}{T_{i}} . \end{matrix}

(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

\begin{matrix} C A = λ_{c} = \frac{\sum_{s = 1}^{n} λ_{c}^{s}}{n_{s}} . \end{matrix}

(2)

From

λ_{c}

, it predicts the future arrival rate (

λ_{f}

) for the next interval using PD [26, page 168]:

\begin{matrix} λ_{f} = P (x) = \frac{{λ_{c}}^{x} \otimes e^{- λ_{c}}}{x!} . \end{matrix}

(3)

To find the future arrival rate, we use the mean of two probability confidences

σ_{u}

and

σ_{v}

. The future arrival rates FA₁ and FA₂ are predicted at probabilities

σ_{u}

and

σ_{v}

using (4) and (5), respectively [26, page 170]. Consider

\begin{matrix} F A_{1} = F (x) = \sum_{i = 0}^{x} \frac{e^{- λ_{c}} \otimes {λ_{c}}^{i}}{i!} \geq σ_{u}, \end{matrix}

(4)

where

σ_{u}

is a known value (e.g., 0.9). Hence, FA₁ is calculated using (4) [26, page 170]. Similarly,

\begin{matrix} F A_{2} = F (x) = \sum_{i = 0}^{x} \frac{e^{- λ_{c}} \otimes {λ_{c}}^{i}}{i!} \geq σ_{v}, \end{matrix}

(5)

where

σ_{v}

is a known value (e.g., 0.1). Hence, FA₂ is calculated using (5) [26, page 170].

The total future arrival rate (FA) is calculated using (6) [26, page 222]:

\begin{matrix} λ_{f} = F A = \{[F A_{1} \otimes σ_{u}] \oplus [F A_{2} \otimes σ_{v}]\} . \end{matrix}

(6)

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 (

n_{q}

) and response time of each request (

T_{c}^{q}

) at the end of every interval (

T_{i}

) (e.g., 60 seconds). The average response time (

T_{c}^{s}

) (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,

\begin{matrix} T_{c}^{s} = \frac{\sum_{q = 1}^{n} T_{c}^{q}}{n_{q}}, \end{matrix}

(7)

\begin{matrix} C R = T_{c} = \frac{\sum_{s = 1}^{n} T_{c}^{s}}{n_{s}}, \end{matrix}

(8)

\begin{matrix} Current  response  rate μ_{c} = \frac{T_{i}}{T_{c}} . \end{matrix}

(9)

From

T_{c}

, FPS predicts the future response time (FR) using ED [26, page 172]

\begin{matrix} P (x) = \{T_{c} \otimes e^{- T_{c} \otimes x}\} . \end{matrix}

(10)

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 (FR₁) is predicted for the probability confidence

θ_{J}

using (11), where

θ_{J}

is a known probability confidence value (e.g., 0.75). Hence, FR₁ is calculated using (11) to 11 b [26, page 172]. Consider

\begin{matrix} P (X = x) = \sum_{x = 1}^{n} \{T_{c} \otimes e^{- T_{c} \otimes x}\} \geq θ_{J}, \end{matrix}

(11)

\begin{matrix} F (x) = \{\int_{0}^{x} T_{c} \otimes e^{- T_{c} \otimes x} d t\} = 1 - e^{- T_{c} \otimes x} \leq θ_{J}, \end{matrix}

(11a)

\begin{matrix} F R_{1} = x = [- T_{c} \ln [1 - θ_{J}]] . \end{matrix}

(11b)

Similarly, the future response time (FR₂) is predicted at probability confidence

θ_{K}

(e.g., 0.25) using (12) to 12 b [26, page 172]. Consider

\begin{matrix} P (X = x) = \sum_{x = 1}^{n} \{T_{c} \otimes e^{- T_{c} \otimes x}\} \geq θ_{K}, \end{matrix}

(12)

\begin{matrix} F (x) = \{\int_{0}^{x} T_{c} \otimes e^{- T_{c} \otimes x} d t\} = 1 - e^{- T_{c} \otimes x} \leq θ_{K}, \end{matrix}

(12a)

\begin{matrix} F R_{2} = x = [- T_{c} \ln [1 - θ_{K}]] . \end{matrix}

(12b)

The total future response time (FR) (in ms) is calculated using [26, page 222]

\begin{matrix} F R = (T_{f}) = \{[F R_{1} \otimes θ_{J}] \oplus [F R_{2} \otimes θ_{K}]\} . \end{matrix}

(13)

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 $T_{f}$ 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
FR	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	S

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 $ρ = n_{s} * N_{p}$ , where $n_{s}$ is number of servers and $N_{p}$ 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 (7²) 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

\begin{matrix} δ = \frac{\sum_{i = 1}^{n} m^{i} * w_{i}}{\sum_{i = 1}^{n} m^{i}} . \end{matrix}

(14)

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_ $T_{S T O P}$ ,” the administrator defined waiting time (for the RCS) after the FL decision is set to “S” (e.g., 900 seconds); (2) “adm_ $T_{R E P L}$ ,” 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_ $T_{W A I T}$ ,” the waiting time of the system after the FL decision is set to “Y”; and (4) “S_ $T_{W A I T}$ ,” the waiting time of the system after the FL decision is set to “S.” The “adm_ $T_{S T O P}$ ” and “adm_ $T_{R E P L}$ ” 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 $T_{f}$ ≥ 90% SLA; if true, it implements the replication immediately; otherwise, it continues for the next interval until Y_ $T_{W A I T}$ ≥ adm_ $T_{R E P L}$ ; then, it implements the new replica ( $R_{y}$ ). 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_ $T_{S T O P}$ ; then, it stops server ( $R_{x}$ ) which provides higher response time. Also, the RCS periodically pings the servers and checks services to determine the health status at every $T_{h}$ 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 ( $R_{y}$ ) and stops sending the request to the lower performance replica ( $R_{x}$ ), and it removes the ( $R_{x}$ ) 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 - $T_{p r}$

( $3$ ) If Read_interval > $T_{i}$

( $4$ ) Set $T_{p r}$ = current_time

( $5$ ) Call function PSS()

( $6$ ) Call function RCS()

( $7$ ) $/^{*}$ ⁢RCS-Flow⁢ $^{*} /$

( $8$ ) If [(FL_flag = “S”) AND

( $9$ ) (S_ $T_{W A I T}$ ≥ adm_ $T_{S T O P}$ )]

( $10$ ) Call function findserver_greater_resp_time()

( $11$ ) Call function stop_replica_service( $R_{x}$ , $C_{1}$ )

( $12$ ) Else-If

( $13$ ) [(FL_flag = “Y”)]

( $14$ ) If $T_{f}$ ≥ 90% SLA

( $15$ ) Set Y_ $T_{W A I T}$ = adm_ $T_{R E P L}$

( $16$ ) End-if

( $17$ ) If (Y_ $T_{W A I T}$ ≥ adm_ $T_{R E P L}$ )

( $18$ ) Call function start_replica_service( $R_{y}$ , $C_{1}$ )

( $19$ ) End-if

( $20$ ) Else-if

( $21$ ) [(RST_Th_Exceed( $R_{x}$ , $C_{1}$ ) = “Yes”)]

( $22$ ) Call function start_replica_service( $R_{y}$ , $C_{1}$ )

( $23$ ) Call function stop_replica_service( $R_{x}$ , $C_{1}$ )

( $24$ ) Else-if

( $25$ ) [Service_Status_Abnormal( $R_{x}$ , $C_{1}$ ) = “Yes”]

( $26$ ) Call function start_replica_service( $R_{y}$ , $C_{1}$ )

( $27$ ) Call function stop_replica_service( $R_{x}$ , $C_{1}$ )

( $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 ( $C_{1}$ ) on each of the replication servers $R_{1} \dots R_{n}$ 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 $C_{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.

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. Table 4 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 service $C_{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.

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	1300

Figure 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 to $C_{1}$ at frequencies ranging from 7000 to 10,000 requests/minute. The $λ_{c}$ and $T_{c}$ data are collected and calculated from the MS metrics and $λ_{f}$ and $T_{f}$ are calculated using (1) to (13). $λ_{f}$ and $T_{f}$ 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 $T_{c}$ 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	1300

The FPS predicts the FA₁ using (4) with $σ_{u}$ = 90%:

\begin{matrix} F A_{1} = F (x) = \sum_{i = 0}^{n} \frac{e^{- λ_{c}} \otimes {λ_{c}}^{i}}{i!} \geq 0.90, \\ F (x) = [P (X = 1) + P (X = 2) + P (X = 3) + \dots] \geq 0.90 . \end{matrix}

(15)

From the above equations, FA₁ is derived by summing up

P (X)

until being greater than 0.90, where

x = 1

to n; hence, FA₁ is calculated as 8600 requests/minute.

Similarly, FA₂ is calculated using (5) with $σ_{v}$ = 10%:

\begin{matrix} F A_{2} = F (x) = \sum_{i = 0}^{n} \frac{e^{- λ_{c}} \otimes {λ_{c}}^{i}}{i!} \geq 0.10, \end{matrix}

(16)

where FA₂ = 6400 requests/minute.

The total future arrival rate is calculated using (6):

\begin{matrix} F A = 8600 * 0.9 + 6400 * 0.10 = 7740 + 640 = 8380 requests / minute . \end{matrix}

(17)

The FR₁ is calculated using (11) to 11 b with

θ_{J}

= 75%:

\begin{matrix} F R_{1} = [- T_{c} \otimes \ln [1 - σ_{j}]], \\ F R_{1} = [- 1004 \otimes (\ln [1 - 0.75])] = 1391.8395 m s . \end{matrix}

(18)

Similarly, the FR₂ is calculated using (12) to 12 b with

θ_{K}

= 25%:

\begin{matrix} F R_{2} = 288.8328 m s . \end{matrix}

(19)

The total future response time (FR) is calculated using (13):

\begin{matrix} F R = T_{f} = 1391.8395 * 0.75 + 288.8328 * 0.25 = 1043.8796 + 72.2082 = 1116.0878 m s . \end{matrix}

(20)

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
				8380

Table 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.6

Figure 8

Fuzzy sets representation of FA.

Figure 9

Fuzzy sets representation of FR.

Evaluation of the rules is as follows:

\begin{matrix} γ_{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 . \end{matrix}

(21)

Using (14), the fuzzified values are defuzzified and illustrated in Figure 10:

\begin{matrix} δ = \frac{450 * 0.61}{5 * 0.61} = \frac{274.5}{3.05} = 90 . \end{matrix}

(22)

δ = 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_

T_{W A I T}

< adm_

T_{R E P L}

, it waits till Y_

T_{W A I T}

≥ adm_

T_{R E P L}

(i.e., 300 seconds); then, the RCA replicates the new server (

R_{5}

) with

C_{1}

. Thus, the load balancer starts distributing the load to the new replica. Similarly, when

λ_{c}

C_{1}

reaches 9,000 requests/minute and the future response time exceeds 90% of SLA, without waiting for adm_

T_{R E P L}

, the RCA immediately replicates the new server (

R_{6}

) with web service

C_{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.

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 service $C_{1}$ and HTTP requests were sent to $C_{1}$ at frequencies ranging from 7000 to 12000 requests/minute. The $λ_{c}$ and $T_{c}$ data are collected and calculated from the MS metrics and $λ_{f}$ and $T_{f}$ 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	1300

Figure 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 to $C_{1}$ at frequencies ranging from 2000 to 19,000 requests/minute by randomly stepping the load up or down every minute and adm_ $T_{R E P L}$ are set to 0 seconds to replicate the new service immediately. In total, approximately 163,000 requests were generated and processed by $C_{1}$ for this test. The $λ_{c}$ and $T_{c}$ data are collected and calculated from the MS metrics and $λ_{f}$ and $T_{f}$ 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_ $T_{S T O P}$ period to stop the replica. Hence, after adm_ $T_{S T O P}$ (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	1300

Figure 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

\begin{matrix} M A E = \frac{\sum_{i = 1}^{n} |P_{i} - \hat{P_{i}}|}{N}, \\ R M S E = \sqrt{\frac{\sum_{i = 1}^{n} {(P_{i} - \hat{P_{i}})}^{2}}{N}} . \end{matrix}

(23)

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_ $T_{R E P L}$ time. We will be addressing this issue in future papers.

Footnotes

Nomenclature

Conflict of Interests

The authors declare that there is no conflict of interests regarding the publication of this paper.

References

Benatallah

Sheng

Q. Z.

Dumas

The self-serv environment for web services composition

IEEE Internet Computing 2003 7 1 40 48

10.1109/MIC.2003.1167338

2-s2.0-0037251267

Abd-El-Barr

Design and Analysis of Reliable a Fault-tolerant Computer Systems 2007

London, UK

Imperial College Press

Birman

Van Renesse

Vogels

Adding high availability and autonomic behavior to web services

Proceedings of the 26th IEEE International Conference on Software Engineering (ICSE ′04)

May 2004

Edinburgh, UK

17 26

10.1109/ICSE.2004.1317410

Sheng

Q. Z.

Maamar

Robust web services provisioning through on-demand replication

Information Systems: Modeling, Development, and Integration 2009 20

Berlin, Germany

Springer

4 16 Lecture Notes in Business Information Processing

10.1007/978-3-642-01112-2_3

Geospatial sensor web and Self-adaptive Earth Predictive Systems (SEPS)

Proceedings of the Earth Science Technology Office(ESTO)/Advanced Information System Technology (AIST) Sensor Web Principal Investigator (PI) Meeting

2007

San Diego, Calif, USA

1 4

Botts

Percivall

Reed

Davidson

OGC^® sensor web enablement: overview and high level architecture

GeoSensor Networks 2008 4540

Berlin, Germany

Springer

175 190 Lecture Notes in Computer Science

10.1007/978-3-540-79996-2_10

Khan

M. S.

Kim

Enhanced service-oriented open sensor web architecture with application server based mashup

International Journal of Distributed Sensor Networks 2014 2014 10

313981

10.1155/2014/313981

2-s2.0-84904093892

Kim

M. S.

Lee

C. H.

Jang

I. S.

K.-J.

GeosensorBase: integrating and managing huge number of heterogeneous sensors using sensor adaptors and extended SQL querying

Web and Wireless Geographical Information Systems: 13th International Symposium, W2GIS 2014, Seoul, South Korea, May 29-30, 2014. Proceedings 2014 8470

Berlin, Germany

Springer

100 114 Lecture Notes in Computer Science

10.1007/978-3-642-55334-9_7

Zadeh

L. A.

Fuzzy logic and approximate reasoning

Synthesis 1975 30 3 407 428

10.1007/bf00485052

10.

Horn

Autonomic computing: IBM's perspective on the state of information technology

2001

IBM Corporation

11.

Agarwal

Bhat

Liu

Matossian

Putty

Schmidt

Zhang

Zhen

Parashar

Khargharia

Hariri

AutoMate: enabling autonomic applications on the grid

Proceedings of the Autonomic Computing Workshop

June 2003

Seattle, Wash, USA

IEEE

48 57

10.1109/ACW.2003.1210204

12.

Folino

Spezzano

An autonomic tool for building self-organizing Grid-enabled applications

Future Generation Computer Systems 2007 23 5 671 679

10.1016/j.future.2006.11.003

2-s2.0-33947125992

13.

Ganek

A. G.

Corbi

T. A.

The dawning of the autonomic computing era

IBM Systems Journal 2003 42 1 5 18

10.1147/sj.421.0005

14.

Kounev

Nou

Torres

Autonomic QoS-aware resource management in grid computing using online performance models

Proceedings of the 2nd International Conference on Performance Evaluation Methodologies and Tools & Workshops (ValueTools ′07)

October 2007

Nantes, France

ICST (Institute for Computer Sciences, Social-Informatics and Telecommunications Engineering)

15.

Abraham

Thomas

Enhancing web services availability

Proceedings of the 26th IEEE International Conference on e-Business Engineering (ICEBE ′05)

October 2005

Beijing, China

352 355

10.1109/ICEBE.2005.62

16.

Salas

Perez-Sorrosal

Patiño-Martínez

Jiménez-Peris

WS-replication: a framework for highly available web services

Proceedings of the 15th International Conference on World Wide Web (WWW ′06)

May 2006

Edinburgh, UK

ACM

357 366

10.1145/1135777.1135831

17.

Mendonça

N. C.

Silva

J. A. F.

Anido

R. O.

Client-side selection of replicated web services: an empirical assessment

Journal of Systems and Software 2008 81 8 1346 1363

10.1016/j.jss.2007.11.002

2-s2.0-50049119660

18.

Sundharam

Lakshmi

Abarajithan

Enhancing the availability of web services for mission critical applications

Proceedings of the Trendz in Information Sciences & Computing (TISC ′10)

December 2010

Chennai, India

IEEE

149 151

10.1109/tisc.2010.5714627

2-s2.0-79952782818

19.

Shen

A middleware for replicated web services

Proceedings of the IEEE International Conference on Web Services (ICWS ′05)

July 2005

IEEE

631 638

10.1109/icws.2005.8

2-s2.0-33749060860

20.

Liu

Cai

A dynamic fault tolerant algorithm based on active replication

Proceedings of the 7th International Conference on Grid and Cooperative Computing (GCC ′08)

October 2008

Shenzhen, China

557 562

10.1109/gcc.2008.59

2-s2.0-57949088153

21.

Hussein

M. K.

Mousa

M. H.

A framework for adaptive Qos of web services using replication

International Journal of Computer Science and Communication Networks 2012 2 2 288 294

22.

Ooi

B.-Y.

Chan

H.-Y.

Cheah

Y.-N.

Dynamic service placement and replication framework to enhance service availability using team formation algorithm

The Journal of Systems and Software 2012 85 9 2048 2062

10.1016/j.jss.2012.02.010

2-s2.0-84863084823

23.

Mohamed

M. F.

ElYamany

H. F.

Nassar

H. M.

A study of an adaptive replication framework for orchestrated composite web services

SpringerPlus 2013 2 1 511

10.1186/2193-1801-2-511

2-s2.0-84887296171

24.

Hwang

S.-Y.

Wang

Tang

Srivastava

A probabilistic approach to modeling and estimating the QoS of web-services-based workflows

Information Sciences 2007 177 23 5484 5503

10.1016/j.ins.2007.07.011

2-s2.0-34548649823

25.

Conti

Kumar

Das

S. K.

Shirazi

B. A.

Quality of service issues in internet web services

IEEE Transactions on Computers 2002 51 6 593 594

10.1109/tc.2002.1009145

2-s2.0-0036603476

26.

Banks

Carson

Nelson

B. L.

Nicol

Chapter 5. Statistical models in simulations and chapter 6. Queuing models

Discrete-Event Systems Simulation 2004 4th

Upper Saddle River, NJ, USA

Prentice Hall

141 222

27.

Wang

L.-X.

Mendel

J. M.

Generating fuzzy rules by learning from examples

IEEE Transactions on Systems, Man, and Cybernetics 1992 22 6 1414 1427

10.1109/21.199466

MR1212464

2-s2.0-0026943536

28.

Zadeh

L. A.

Is there a need for fuzzy logic?

Information Sciences 2008 178 13 2751 2779

10.1016/j.ins.2008.02.012

MR2414985

2-s2.0-42749097020

29.

Murugan

Ramachandran

Fuzzy decision making model for byzantine agreement

Journal of Engineering Science and Technology 2014 9 2 206 219

2-s2.0-84894595577

30.

Singhala

Shah

D. N.

Patel

Temperature control using fuzzy logic

International Journal of Instrumentation and Control Systems 2014 4 1 1 10

10.5121/ijics.2014.4101

31.

Luo

Chang

Online optimization of collaborative web service qos prediction based on approximate dynamic programming

International Journal of Distributed Sensor Networks 2015 2015 9

452492

10.1155/2015/452492

32.

Silic

Delac

Krka

Srbljic

Scalable and accurate prediction of availability of atomic web services

IEEE Transactions on Services Computing 2014 7 2 252 264

10.1109/tsc.2013.3

2-s2.0-84903193664

FR	FA
FR	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	S

FR	FA
FR	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	S

FR	FA
FR	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	S