Building Reliable SOA from the Unreliable Web Services

1
Building Reliable SOA from the Unreliable Web
Services
Ben, Zibin ZHENGDepartment of Computer Science
EngineeringThe Chinese University of Hong
KongMay. 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.

3
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.
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
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
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.

9
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 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
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.

14
3. WS-DREAM A Distributed Reliability Assessment
Mechanism for Web Services
15
3.1 Design questions

• Which Web service is optimal?
• Overall performance information of target
  replicas.
• Individually obtained performance information.
• Which fault tolerance strategy is optimal?
• Requirements of applications.
• Objective performance of target replicas.
• Characteristics of fault tolerance strategies.
• 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

• 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

• Active. The application sends requests to
  different replicas in parallel.
• Retry. The same Web service will be tried
  several times in sequence if it fails.
• RB. Another standby Web service will be tried in
  sequence if the original Web service fails.

18
3.3 Replication strategies

• 4. AcitveRetry 5. RetryActive
• 6. ActiveRB 7. RBActive
• 8. RetryRB 9. RBRetry

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

• Assessing the performance of individual Web
  Services.
• Measuring the performance of different fault
  tolerance strategies employing the six identical
  Web services provided by Amazon.
• 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 (2Retry, 3RB, 8RetryRB,
  and 9RBRetry) 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.

31
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
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
4.2 Architecture

• 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 can tolerate. the largest resource
consumption constraint. the mode can be set by
the service users to be 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.
• k2 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

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

45
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.

50
Thank you!
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.