1. Reliable Web Services: Methodology, Experiment and Modeling International Conference on Web Services (ICWS 2007)
Pat. P. W. Chan, Michael R. Lyu
Department of Computer
Science and Engineering
The Chinese University of
Hong Kong
Miroslaw Malek
Department of Computer
Science and Engineering
Humboldt University Berlin,
Germany
Presented by Pat Chan

2. Outline Introduction to Web Services Problem Statement
Methodologies for Web Service Reliability
New Reliable Web Service Paradigm
Optimal Parameters
Experimental Results and Discussion
Conclusion
Introduction
Problem Statement
Methodologies for Web Service Reliability
New Reliable Web Service Paradigm
Road Map for Experiment
Experimental Results and Discussion
Conclusion
Future Directions

3. Introduction Service-oriented computing is becoming a reality.
The problems of service dependability, security and timeliness are becoming critical.
We propose experimental settings and offer a roadmap to dependable Web services.
With service-oriented computing becoming a reality, there is an increasing demand for dependability. Service-oriented Architectures (SOA) are based on a simple model of roles. Every service may assume one or more roles such as being a service provider, a broker or a user (requestor).
This model simplifies interoperability as only standard communication protocols and simple broker-request architectures are needed to facilitate exchange (trade) of services. Not surprisingly, the use of services, especially Web services, became a common practice. The expectations are that services will dominate software industry within the next five years. As services begin to pervade all aspects of life, the problems of service dependability, security and timeliness are becoming critical and appropriate solutions need to be found.
Several fault tolerance approaches have been proposed for Web services in the literature [1, 2, 3, 4], but the field still requires appropriate solid theory, appropriate models, effective design paradigms, a practical implementation, and an in-depth experimentation for building highly-dependable Web services [5, 6].
In this paper, we propose such experimental settings and offer a roadmap to dependable Web services. We compose a list of parameters that are closely related to evaluating quality of service from the dependability perspective. We focus on service availability and timeliness and consider them a cornerstone of our approach. Security, which can also be viewed as a part of dependability, is beyond the scope of this paper.

4. Problem Statement Fault-tolerant techniques
Replication
Diversity
Replication is one of the efficient ways for providing reliable systems by time or space redundancy.
Increasing the availability of distributed systems
Key components are re-executed or replicated
Protect against hardware malfunctions or transient system faults
Another efficient technique is design diversity
Employ independently designed software systems or services with different programming teams,
Defend against permanent software design faults.
We focus on the analysis of the replication techniques when applied to Web services.
A generic Web service system with spatial as well as temporal replication is proposed and investigated.
There are many fault-tolerant techniques that can be applied to the Web services including replication and diversity. Replication is one of the efficient ways for providing reliable systems by time or space redundancy. Redundancy has long been used as a means of increasing the availability of distributed systems, with key components being re-executed (replication in time) or replicated (replication in space) to protect against hardware malfunctions or transient system faults. Another efficient technique is design diversity. By independently designing software systems or services with different programming teams, diversity provides an ultimate resort in defending against permanent software design faults.
In this paper, we focus on the analysis of the replication techniques when applied to Web services. We will analyze the performance and the availability of the Web services with using spatial and temporal redundancy and study the tradeoffs between them. A generic Web service system with spatial as well as temporal replication is proposed and investigated.

5. Proposed Paradigm Web Service Client UDDI IIS Replication Manager
RR Algorithm /
Voting
WatchDog
UDDI
Registry
WSDL
Web Service
IIS
Application
Database
Client
Port
Register
Look up
Get WSDL
Invoke web service
Keep check the availability of all the web.
If Web service failed, update the list of availability of Web services
Update the WSDL

6. Proposed Paradigm Round Robin Parallel N-Version Majority result
Web Service
IIS
Application
Database
Web Service
IIS
Application
Database
Web Service
IIS
Application
Database
Web Service
IIS
Application
Database
Web Service
IIS
Application
Database
Adv: Fully use the resource
Majority result
Voting
Client

7. Experiments
A series of experiments are designed and performed for evaluating the reliability of the Web service,
Spatial replication 1
Reboot
Retry

8. Testing system Best Route Finding.
Provide traveling suggestions for users.
Starting point and destination.
The system needs to provide the best route and the price for the users.

9. System Architecture

10. Experimental Setup Examine the computation to communication ratio
Examine the request frequency to limit the load of the server to 75%
Fix the following parameters
Computation to communication ratio (e.g 10:1)
Request frequency

11. Experimental Setup Communication time: Computation time 143:14 (10:1)
Request frequency
1 request per min
Load
78.5%
Timeout period of retry
1 min
Timeout for Web service in RM
1s (web service specific)
Polling frequency
10 requests per min
Number of replicas 5
Max number of retries
Round-robin rate
1 s

12. Experiment Parameters
Fault mode
Temporary (fault probability: 0.01)
Permanent (fault probability: 0.001)
Experiment time 5 days (7200 requests)
Measure:
Number of failures
Average response time (ms)
Failure definition:
5 retries are allowed. If there is still no correct result from the Web service after 5 retries, it is considered as a failure.

13. Experimental Result with Round-robin (failures / response time in ms)
Experiments
Single server
Single
server with
retry
reboot
(continues
no response
for 3
requests)
server
with retry
and
Spatial
Replication RR
Hybrid
approach
RR+Retry
RR+
Reboot
All round
spatial +
Retry
(5 times) +
reboots
Normal case
0 / 183
0 / 193
0 / 190
0 / 187
0 / 188
0 / 195
Temp
705 / 190
0 / 223
723 / 231
0 / 238
711 / 187
0 / 233
726 / 188
0 / 231
Perm
6144 / --
6337 / --
1064 / --
5 / 2578
5637 / --
5532 / --
152 / 187
0 / 191

14. Experimental Result with N-Version (failures / response time in ms)
Experiments
Single server
Single
server with
retry
reboot
(continues
no response
for 3
requests)
server
with retry
and
Spatial
Replication
Voting
Hybrid
approach
Voting+
Retry
Voting +
Reboot
All round
spatial +
(5 times) +
reboots
Normal case
0 / 318
0 / 320
0 / 315
0 / 319
0 / 322
0 / 321
Temp
429 / 321
0 / 356
423 / 364
0 / 325
0 / 324
Perm
3861 / --
3864 / --
614 / --
3 / 4027
1544 / 323
1546 / 324
63 / 324
0 / 323

15. Varying the parameters
Number of tries
Timeout period for retry in single server
Timeout period for retry in our paradigm
Polling frequency
Number of replicas
Load of server

16. Number of tries Number of tries Number of failures in Temp
failures in Perm 95 76 1 2 3 4 5

17. Timeout period for retry in single server
Number of failures in
Temp
Perm 95
7265 2
7156 5
7314 6
6890 7
189 8 82 9 11 10 12 14 16 18

18. Timeout period for retry in single server
# of failure
If the timeout period for retry is too short, the server does not reboot on time to provide the service again.
Timeout period

19. Timeout period for retry in our paradigm
(s)
Number of failures in
Temp
Perm 2 81 5 10 20
As the timeout period for retry is too short, the replica cannot reboot on time and cause the number of failures increases. Also, another cause of the failure is that the replication manager cannot response on time to switch the primary web service. There are 5 tries, and the reboot time for a server is around 50 second,

20. Polling frequency Polling frequency (number of requests per min)
Number of failures
in Temp
in Perm
7124 1
811 2 30 5 12 10 15
213
254 20
1124
1023
If the polling frequency is low, the replication manager cannot response on time and the request will still send to the failed server and cause the failures in the system. When the polling frequency increases, the situation improves. The replication manager can response on time and reduce the number of failures

21. Polling frequency
# of failure
Polling frequency

22. Number of Replicas Number of replicas Number of failures in Temp
Number of failures in Perm
No replica 91
8152 2
356 3 4

23. Load of Web Server Load of the web server (%) Number of failures in
Temp
Perm 70 75 80 2 3 85 10 14 90
512
528 95
3214
3125
100
8792
8845
110
8997
8994

24. Summary of Parameters Number of tries = 2
Timeout period for retry in single server = 10s
Timeout period for retry in our paradigm = 5s
Polling frequency = 10 request per min
Number of replicas = 3
Load of server = < 75%

25. Petri-Net (Four identical replicas)

26. Petri-Net (N-version Web service with voting)

27. Reliability Model (a) (b) P1 λ1 μ1c2 S-j P2 μ2c2 λ2 S S-n F λN μ*c2λ*
S-1
S-2
(1-c1)μ1
(1-c1)μ2
(1-c2)μ1
(1-c2)μ2
C1 = P( RM response on time )
C2 = P( reboot success )
We develop the reliability model of the proposed Web service paradigm with Markov chain model. The model is shown in Figure 8. In Figure 8(a), the state s represents the normal execution state of the system with n Web service replicas. In the event of an error, the primary Web service failed, the system will either go into the other states, i.e s-j which represents the system with n-j working replicas remaining, the replication manager response on time, or it will go to the failure state F with conditional probability c1. λ* denotes this error rate at which recovery cannot complete in this state and c1 represents the probability that the replication manager response on time to switch to another Web service.
When the failed Web service is repaired, the system will back to the previous state, s-j+1. μ* denotes the rate at which successful recovery is performed in this state, c2 represents the probability that the failed Web service server reboot successfully. If the Web service is failed, it will go to another Web service. When all Web services are failed, the system enters the F state. λn is the network failure rate.
s-1 to s-n represents the working state of the n Web service replicas and the reliability model of each Web service is shown in Figure 8(b). There are two types of failures are simulated in our experiments, they are P1 recourses problem (server busy) and P2 entry point failure (server reboot). If failure occurred in the Web service, either the Web service can be repaired with μ1 or μ2 repair rate with conditional probability c1 or the error cannot be recovered, it will go to the next state s-j-1 with one less Web service replica available. If the replication manager cannot response on time, it will go to the failure state. From the graph, two formulas can be obtained:

28. Reliability Model ID Description Value λn Network failure rate 0.02 λ*
Web service failure rate
0.025 λ1
Resource problem rate
0.142 λ2
Entry point failure rate
0.150 μ*
Web service repair rate
0.286 μ1
Resource problem repair rate
0.979 μ2
Entry point failure repair rate C1
Probability that the RM response on time
0.9 C2
Probability that the server reboot successfully

29. Outcome (SHARPE)

30. Conclusion
Surveyed replication and design diversity techniques for reliable services.
Proposed a hybrid approach to improving the availability of Web services.
Carried out a series of experiments to evaluate the availability and reliability of the proposed Web service system.
Optimal parameters are obtained.
In the paper, we surveyed replication and design diversity techniques for reliable services and proposed a hybrid approach to improving the availability of Web services. Furthermore, we carried out a series of experiments to evaluate the availability and reliability of the proposed Web service system. From the experiments, we conclude that both temporal and spatial redundancy is important to the availability improvement of the Web service. In the future, we plan to test the proposed scheme with wider variety of fault injection scenarios. Moreover, we will also evaluate the schemes with design diversity techniques.