1. Building Reliable SOA from the Unreliable Web Services Ben, Zibin ZHENG Department of Computer Science & Engineering The Chinese University of Hong Kong May. 09, 2008

2. 2 Outlines 1. Motivation and Research Problems 2. Related Work 3. WS-DREAM: A Distributed Reliability Assessment Mechanism for Web Services 4. A QoS-Aware Middleware for Fault Tolerant Web Services 5. Conclusion and the Proposed Future Research.

3. 1. Motivation and Research Problems

4. 4 1.1 Web services Application and data integration Cost saving Remote Web services may become unavailable. Remote Web services may contain faults. The Internet environment is unpredictable. Reliability of the Service-oriented applications become difficult to be guaranteed.

5. 5 1.2 Software fault tolerance In traditional software reliability engineering, fault tolerance is a major approach for reliability improvement. –Design diversity. –Redundant alternative components follow a same specification. Critics: –Too expensive. –Reliability improvement is questionable in comparison to a single version with all the cost of developing the multiple versions.

6. 6 1.3 Fault tolerance for WS Service-Oriented Computing is becoming popular. Web services with an identical interface are emerging. Fault tolerance becomes less expensive and becomes an attractive choose for reliability enhancement. “Replica”: representing the Web services with an identical interface.

7. 7 1.4 Obtaining replicas Manual selection. Machine learning technical. Service communities. –A standard interface requirement. –Service users will go to the service communities to find suitable services. –Companies would like to join in the communities to enhance business benefit. Assuming replicas can be obtained by certain approaches, my work focuses on employing the replicas for fault tolerance purpose.

8. 8 1.5 Research questions For a service user: Which replica is optimal? Which fault tolerance strategy is optimal? Which fault tolerance strategy is optimal in different geography locations. Which fault tolerance strategy is optimal in the highly dynamic environment? WS-DREAM: 1, 2 and 3. QoS-Aware Middleware: 1, 2, 3 and 4.

9. 2. Related Work

10. 10 2. Related work- Web service evaluation Reputation model [E.M. Maximilien, 2002] –eBay: A buyer can rate the other party numerically or write a text. –Design a mechanism for rating Web services automatically. –Web services need to receive, record, and publish the rating information. QoS management frameworks [V. Deora, 2003] –Different users will have different expectations. –Rating + user expectations.

11. 11 2. Related work- Web service evaluation A Bayesian network based QoS assessment model [G.Wu, 2007]. –QoS requirements of applications will also be recorded as part of the service level agreement (SLA), which outlines the commitments between consumers and providers. –The requirements of applications users will be classified into different classes (particular SLA). –Users with similar Qos requirements will be treated in a similar way by the providers. –Difficult to divide the service providers into different classes. –Geography locations are not considered.

12. 12 2. Related work-fault tolerance for WS FT-SOAP [D. Liang, 2003] –A stand-alone replication manager (RM) for handling fault tolerance of Web services. –Performance bottle neck. –RM may crash down. FTWeb [G. T. Santos, 2005] –WSDispatcher and WSDispatcher backup –Employing active replication strategy –The fault tolerance strategy is generic enough.

13. 13 2. Related work-fault tolerance for WS “Fault tolerance connector for unreliable Web services” [N. Salatge, 2007]. –Connector (client-side, third-party, server-side.) –Develop a specific language called DeWeL (Dependable Web service Language). –Passive replications and active replications. “Qos-Aware Middleware for web services composition” [L.Z. Zeng, 2004] –Auto-adjust to highly dynamic environment. –Deployed in client-side.

14. 3. WS-DREAM: A Distributed Reliability Assessment Mechanism for Web Services

15. 15 3.1 Design questions 1.Which Web service is optimal? –Overall performance information of target replicas. –Individually obtained performance information. 2.Which fault tolerance strategy is optimal? –Requirements of applications. –Objective performance of target replicas. –Characteristics of fault tolerance strategies. 3.Which fault tolerance strategy is optimal in different geography locations? –User-collaboration. –YouTuBe: sharing videos. Wikipedia: sharing knowledge. –WS-DREAM: sharing evaluation results on target Web services.

16. 16 3.2 Architecture 1. Assessment request 2. Load Applet 3. Create test cases 4. Test task scheduling 5. Client get test plans 6. Client run test plans 7. Send back results 8. Analyzing and return final result to client. User-collaboration

17. 17 3.3 Fault tolerance strategies 1.Active. The application sends requests to different replicas in parallel. 2.Retry. The same Web service will be tried several times in sequence if it fails. 3.RB. Another standby Web service will be tried in sequence if the original Web service fails. Active RetryRB Active 1.Active46 Retry52.Retry8 RB793.RB

18. 18 3.3 Replication strategies 4. Acitve+Retry5. Retry+Active 6. Active+RB7. RB+Active 8. Retry+RB 9. RB+Retry 1. Systematic introduction and comparison. 2. Strategy selection algorithm.

19. 19 3.4 Test plans Includes several test cases. Tests performance of different replication strategies. Created by WS-DREAM server and executed in the client-side.

20. 20 3.5 User requirements t-user: –represents the user requirement on response time improvement of increasing one parallel replica. –designed to facilitate the user to make a tradeoff between the response time performance and resource consuming. f-user: –the failure-rate requirement provided by users.

21. 21 3.6 Strategy selection Determining parallel replica number: v. Excluding bad performance replicas: |W|. Determining detailed optimal strategy based on: p1,p2,p3.

22. 22 3.7 Implementation JDK + Eclipse Client-side: –Java Applet Server-side: –an HTTP Web site (Apache HTTP Server) –a TestCaseGenerator (JDK6.0 + Axis library) –TestCoodinator (Java Servlet + Tomcat 6.0) –MySQL (Record testing results)

23. 23 3.8 Experiment-description Assume a service user Ben plans to employ several Web services in his commercial Web site. –An Amazon book displaying and selling Web Service. (a-us, a-jp, a-de, a-ca, a-fr and a-uk) –A Global Weather Web Service to display currently weather information. –A GeoIP Web Service to get geography information of Website visitors.

24. 24 3.8 Experiment-procedures 1.Assessing the performance of individual Web Services. 2.Measuring the performance of different fault tolerance strategies employing the six identical Web services provided by Amazon. 3.Determining the optimal fault tolerance strategy.

25. 25 3.9 Results-individual WS Timeout: 3865; Unavailable service (http 503): 2456; Bad gateway (http 502): 1 Failure-rates are vary from location to location.

26. 26 3.9 Results-individual WS Response time performance (RTT) are vary from location to location.

27. 27 3.9 Results-FT strategies Strategy 1 has the best RTT performance, and the worst fail-rate. Sequential strategies (2:Retry, 3:RB, 8:Retry+RB, and 9:RB+Retry) obtain the worst RTT performance, and the best failure-rate.

28. 28 3.10 Optimal strategy selection

29. 29 3.11 Contributions Proposed a user-collaboration mechanism for Web services evaluation. Compared various fault tolerance strategies and designed an optimal fault tolerance strategy selection algorithm. Enrich real world experiments.

30. 30 3.12 Weak points Can not handle the highly change of environment. Need a centralize server for assigning evaluation tasks and storing evaluation results. The fault tolerance strategies are too static.

31. 4. A QoS-Aware Middleware for Fault Tolerant Web Services

32. 32 4.1 Design considerations Design a middleware: Record historical performance data of replicas. Update replica list and their overall performance. Auto-adjust the optimal fault tolerance strategy dynamically.

33. 33 4.2 Architecture 1. Coordinator address 2. Replica list and QoS. 3. Optimal strategy. 4. Record performance data. 5. Exchange performance data. 6. Adjust optimal strategy. User-collaboration and QoS-Aware

34. 34 4.2 Architecture Middleware: users can close the data exchange functionality. BitTorrent: users can close the upload.

35. 35 4.3 Dynamic fault tolerance strategy Dynamic sequential strategy: Dynamic parallel strategy: : u replicas in parallel, first v for voting.

36. 36 4.4 User requirements the largest RTT that the application can afford. the largest failure-rate that the application can tolerate. the largest resource consumption constraint. the mode can be set by the service users to be sequential, parallel, or auto.

37. 37 4.5 RTT prediction algorithm The users may be not willing to store a lot of historical data. Without historical data, it is difficult to make QoS prediction. Solution: Dividing the time into k timeslots. k+2 counters for k timeslots, fl and fn. for calculating the probability of a certain RTT belongs to a certain category.

38. 38 4.5 RTT prediction algorithm

39. 39 4.5 RTT prediction algorithm min(Tv): Active strategy. max(Tv): NVP. middle(Tv, x): v parallel replicas and employs the first x response for voting.

40. 40 4.6 Dynamic optimal strategy selection Sequential or parallel strategy determination: Dynamic sequential strategy determination: Dynamic parallel strategy determination: –RTT prediction algorithm

41. 41 4.7 Experiments The experimental system is implemented by JDK6.0, Eclipse3.3, Axis2.0, and Tomcat6.0. Developed six Web services following an identical interface to simulate replicas in a same service community. Service-oriented applications are implemented as Java Applications.

42. 42 4.7 Experiments The best overall performance. Similar to the Active strategy. Providing good RTT performance for the User 1.

43. 43 4.7 Experiments

44. 44 4.7 Experiments 1.Traditional fault tolerance strategies have good performance in some cases, by have bad performance in others. 2.The proposed dynamic strategy obtains the best overall performance for all the six users in the experiments.

45. 5. Conclusion

46. 46 5.1 Conclusion Proposed WS-DREAM, which encourage user contribution, for assessing Web services and determining optimal fault tolerance strategies. Designed a QoS-Aware Middleware for auto- adjust optimal fault tolerance strategies dynamically to the environment changes.

47. 47 5.2 Proposed future research Extend the current work to handle stateful and asynchronous Web services in real world. –More complex. –Limited related work.

48. 48 5.2 Proposed future research Involve more QoS properties. –Average response time, failure-rate, and resource. –Price, standard-deviation of RTT, change degree of Web services. –Reputation of service providers, rating of service users. –Used information of the Web services.

49. 49 5.2 Proposed future research Mobile Web services. –More dynamic. –Reliability becomes more important. Peer-to-Peer Web services. –Reliability improvement approaches may be quite different. –Limited related work.

50. Thank you!

51. 51 2.2 Scheduling algorithm Fairness. Different Web Services should have fair chances to be assessed. Distributed. Web Services should be assessed by users in as many geography locations as possible. Feasible. Task assignment should dynamically adjust to the frequently changed number of users and number of test plans. Efficient. The algorithm should be efficient and it should not slow down the testing progress.