Building Reliable SOA from the Unreliable Web Services Ben, Zibin ZHENG Department of Computer...

Building Reliable SOA from the Unreliable Web Services

Ben, Zibin ZHENG

Department of Computer Science & EngineeringThe Chinese University of Hong Kong

May. 09, 2008

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.

1. Motivation and Research Problems

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.

Service Oriented Application

Web service 1

Web service 2

Web service n

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 spe

cification.

• Critics: – Too expensive. – Reliability improvement is questionable in comparison

to a single version with all the cost of developing the multiple versions.

6

1.3 Fault tolerance for WS

Service Oriented Application

Replica 1 (Web service)

Replica 2

Replica n

• 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

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

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.

Lyric server 1

Lyric server 2

Lyric server n

2. Related Work

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

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 ser

vice 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

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

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.

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

15

3.1 Design questions1. 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

3.2 Architecture

Strategy Manager

Fault Injector

WSDL Analyzer

Web Site

Manager

Coordinator

1

7

User1

User N

Web Service 2

Web Service 1

Web Service N

2

TestCase Dispatcher

TestResult Reveriver

Result Database

TestResult Analyzer

8

TestCase Generator

Test Coodinator

Web Service 2

Web Service 1

Web Service N

6

WS-DREAM Server

Testing Engine

RulesManeger1.<parallel>2.<sequence>3. <retry>………...

TestRunner

4

3

5

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

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 Retry RB

Active 1.Active 4 6

Retry 5 2.Retry 8

RB 7 9 3.RB

18

3.3 Replication strategies4. Acitve+Retry 5. Retry+Active

6. Active+RB 7. RB+Active

8. Retry+RB 9. RB+Retry

1. Systematic introduction and comparison.

2. Strategy selection algorithm.

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

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

3.6 Strategy selection

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

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

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

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

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

3.9 Results-individual WS

•Response time performance (RTT) are vary from location to location.

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

3.10 Optimal strategy selection

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

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.

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

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

4.2 Architecture

Application Logic

App 2

QoS-Aware Middleware

Web Service A2

Web Service A1

Web Service An

Communication Bus

Web Service B2

Web Service B1

Web Service Bm

Service Community A Service Community B

Coordinator A Coordinator B

Service Community Broker

UDDI Registry

Auto-updater

Dynamic Selector

CommunicatorApp n

1. Coordinator address

2. Replica list and QoS.

3. Optimal strategy.

4. Record performance dat

a.

5. Exchange performance

data.

6. Adjust optimal strategy.

User-collaboration and QoS-Aware

34

4.2 Architecture

Replica list, Overall performance information

Individual Performance information

Replica list, Overall performance information

Individual Performance information

Replica list, Overall performance information

Coordinator

UserReplica list, Overall performance information

Individual Performance information

Replica list, Overall performance information

Individual Performance information

Replica list, Overall performance information

• Middleware: users can close the data exchange functionality.• BitTorrent: users can close the upload.

35

4.3 Dynamic fault tolerance strategy

• Dynamic sequential strategy:

• Dynamic parallel strategy: : u replicas in parallel, first v for voting.

36

4.4 User requirements

the largest RTT that the application can afford.

the largest failure-rate that the application cantolerate.

the largest resource consumption constraint.

the mode can be set by the service users tobe sequential, parallel, or auto.

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

4.5 RTT prediction algorithm

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

4.6 Dynamic optimal strategy selection

• Sequential or parallel strategy determination:

• Dynamic sequential strategy determination:

• Dynamic parallel strategy determination:– RTT prediction algorithm

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

4.7 Experiments

• The best overall performance. • Similar to the Active strategy.• Providing good RTT

performance for the User 1.

43

4.7 Experiments

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.

5. Conclusion

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

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

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

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.

Thank you!