1. Modeling and Exploiting QoS Prediction in Cloud and Service Computing
Yilei Zhang
Thesis Committee
Chair: Prof. Pak Ching LEE
Supervisor: Prof. Michael R. LYU
Member: Prof. Fung Yu YOUNG
External Examiner: Prof. Qing LI
Sep. 12, 2013 1

2. Outlines Introduction Part1: QoS Prediction Approaches
Neighborhood-Based Approach
Time-aware Model-Based Approach
Online Approach
Part2: QoS-Aware Web Service Searching
Part3: QoS-Aware Byzantine Fault Tolerance
Conclusion 2

3. Cloud Computing Cloud component On-demand
Software, server, database, etc.
On-demand
Cloud computing is a new type of Internet-based computing, whereby shared resources, software, and information are provided to
computers and other devices as cloud component on demand. With the exponential growth of cloud computing as a solution for providing flexible computing resources, more and more large cloud companies provide convenient access to a shared pool of computing resources including Networks, servers, database, etc.

4. Cloud Applications Software-as-a-Service (SaaS) Case 1: New York Times
Large-scale, complicated, time sensitive, high-quality
Case 1: New York Times
Convert scanned articles to PDF
15 million files, 4TB data
EC2 & S3, 100 computers 24 hours
Case 2: Nasdaq
Stock and fund information
Millions of files, per 10 minutes S3
With thousands of cloud resources available over the Internet, cloud applications emerge in recent years. The architecture of the Software-as-a-Service (SaaS) systems in the delivering of cloud computing, typically involves multiple distributed cloud components communicating with each other over application programming interfaces, usually Web services. Cloud computing has become a scalable service consumption and delivery platform.
Cloud applications are usually large-scale and complicated, and are supposed finish time sensitive tasks in high-quality. One example of this tasks is new york times need to convert fifteen million scanned articles to pdf files in a short time. Finally, Amazon employs EC2 and S3 to build a cloud application, and use 100 computers finish this job in 24 hours. Another example of cloud applications is that nasdaq needs to deliver historic stock and fund information to its customers in time. There are millions of files showing price changes of entities over 10 minutes segments need to be delivered. A cloud application composed of S3 are implemented to handle this job.

5. Web Services Web APIs Accessed over a network,
Executed on remote systems
Loosely-coupled
Compositional nature
Web services are software systems designed to support interoperable machine-to-machine interaction over a network. Web services are usually provided as Web APIs, and are executed on remote systems. Their Loosely-coupled feature and Compositional nature make web services can be easily composed into users’ applications. The picture on the right is a webpage containing a video, actually the video data are not stored in the server of the website. Instead, they are provided by a video web service. When visitors playing the video, the browser sends a request to the web service, and present the stream data returned by the web service.

6. Service-Oriented-Architecture
Service-Oriented-Architecture (SOA)
Distributed Web services
30,000 services, 200,000 documents (seekda.com)
The technical foundations of cloud computing include Service-Oriented Architecture (SOA), which is becoming a popular and major framework for building Web applications in the era of Web 2.0, whereby Web services offered by different providers are discovered and integrated over the Internet. According to the statistics from seekda.com, thousands of public accessible web services and related documents are available now.
Typically, a service-oriented system consists of multiple distributed Web services interacting with each other over the Internet in an arbitrary way. Take the travel agency web site as a example. This website contains several web services. After accept a user’s query, the website need to invoke remote web services provided by different company, and obtain the hotel information, flight information, etc. then it compare these information and provide maybe a travel package to the user. If the user decide to reserve the travel package, it will invoke the remote credit card web service to process the payment procedure.

7. Performance of Services
Web service
Cloud component
User observed performance.
Remote network access
Location
Invocation time
Under the Software-as-a-service architecture, service in this thesis refers to Web service in service computing and component in cloud computing.
Left figure shows the saas system architecture in cloud computing. In a cloud environment, the cloud provider holds a large number of distributed services which can be provided to designers for developing various cloud applications. Designers of cloud applications can choose from a broad pool of distributed services when composing cloud applications. These services are usually invoked remotely through communication links
and are dynamically integrated into the applications. Therefore, due to the dynamic network environment and the locations of users and services, different services have different performance, even for the same service’s performance, different users may have different observations. Moreover, the perfomance of services are also impacted by the invocation time.

8. Quality-of-Service
Quality-of-Service (QoS): non-functional performance
User/Time-independent QoS properties
price, popularity
User/Time-dependent QoS properties
failure probability, response time, throughput
High quality applications depends on high quality services
Service selection, service searching, fault tolerance, service composition, etc.
In order to describe the non-functional performance, Quality-of-Service (QoS) is usually employed to represent the characteristics of services. Typically, QoS properties can be divided into two categories. One is user and time independent properties, like price or popularity which is usually identical to different users and invocation time. The other properties are user or time dependent, like failure probability, response time or throughput, the qos values are usually related to the corresponding user and invocation time. In this thesis, we focus on the second type of QoS properties.
QoS becomes a major concern for application designers when making service selection, service composition, etc. Moreover, for the existing applications, by replacing low quality services with better ones, the overall quality of applications can be improved. Therefore, High quality applications depends on high quality services. It is very important to obtain the QoS values of services.

9. Challenge 1: How to Obtain QoS?
Conducting real-world evaluations?
Drawbacks
Expensive (charge for real invocations)
Time-consuming (thousands of services)
Personalized evaluation (users’ perspective)
Expertise (extra cost and effort)
How to obtain the QoS performance of services becomes a big challenge. One possible way is conducting real-world evaluations to obtain the QoS values. However, this brings several drawbacks.
First, services are provided by different companies, many companies charge for real invocations. It will be very expensive to conduct service invocations for evaluation.
Second, there are thousands of services available over the Internet nowadays, it is time-consuming to evaluate all the services.
Third, QoS values are user-dependent. In order to provide QoS values from users’ perspective, personalized evaluation is needed. In other words, each user need to conduct evaluations on all services.
Last but not least, users may not be experts in service evaluation. It requires extra cost and effort for users to obtain the service evaluation expertise.

10. Challenge 1: How to Obtain QoS?
Solution: QoS Prediction (Part 1)
Collect users’ usage experiences
Analyze historical QoS data
Predict QoS values
Advantages
Economical (no additional invocation)
Precise (personalized QoS)
Effective (no extra expertise)
Efficient (provided as a service)
Therefore, we propose three QoS prediction approaches in part 1 to address this critical challenge. The key idea of QoS prediction is like this.
We first collect existed usage experiences on services from different users. Then we analyze these historical QoS data and extract the features of users and services. By studying the relationship between these features and QoS values, we can predict the QoS value of a service if invoked by a user.
The QoS prediction approaches have several advantages. First it is economical, since no additional invocation is required, we only use the existed data. Second, it is precise. Since we can predict QoS of a service for different users. Personalized QoS prediction results make it more precise. Third, it is effective. Since there is no evaluation are conducted on services, no extra expertise is required. Every user can get the prediction result. Last, it is efficient. The QoS prediction approaches can be deployed as a service. Users just need to send a request and can get the prediction results from the service. The computation task can be finished in the remote service server.

11. Challenge 2: How to Search Appropriate Services?
Problems
Thousands of services
Different QoS Performance
Solution: QoS-aware searching (Part 2)
Based on the QoS prediction results in part 1, we can address the challenge 2: how to search appropriate services?
One problem is that there are thousands of services available over the Internet, how to find the services whose functionality can fulfill users’ requirements. Another problem is that services sharing similar functionalities may have different QoS performance. How to find the services who QoS performance can fulfill the users’ non-functional requirements.
We propose a QoS-aware services searching approach in Part 2 to address the challenge. Traditional service searching approaches only find the Web services to fulfill users’ functionality requirements. In this part, we propose the first service searching approach that takes both functionality and QoS performance into consideration. The services in our searching result can fulfill users’ functionality requirements and have good QoS performance at the same time.

12. Challenge 3: How to Build Reliable Service-Oriented Systems
Problems
Services may contain various faults
QoS of remote services may not be stable, e.g., unavailability problem
Solution: QoS-aware fault tolerance (Part 3)
Based on the QoS prediction results in part 1, we can address the challenge 3: How to Build Reliable Service-Oriented Systems?
Service-oriented systems consist of several services. One problem is that these services are provided by different institutions, they may contain various faults, these faults may cause the systems unreliable. Another problem is that the QoS of the remote services may not be stable, for example, unavailability problem. This may cause the performance of the systems unstable.
Therefore, we proposed a QoS-aware fault tolerance framework in part 3 to address the challenge. We employ Byzantine fault tolerance strategy to tolerant various faults of services, including arbitrary behavior. Different from traditional Byzantine fault tolerance, we are the first to take QoS of services into consideration. Therefore, the services used in the service-oriented systems have good QoS performance. And the whole performance of the service-oriented system are significantly improved.

13. Part 2: QoS-Aware Searching
Thesis Structure
Part 2: QoS-Aware Searching
Part 3: QoS-Aware
Fault Tolerance
Chapter 6
Chapter 7
Part 1: QoS Prediction
In part 1, We formally identify the research problem of QoS prediction and propose three prediction approaches.
In chapter 3, we propose a neighborhood-based approach by employing the historical QoS data to model the features on both users and services.
Traditional QoS prediction approaches usually try to prediction the average QoS performance of services. However, QoS performance of services is highly related to invocation time. In chapter 4, we propose a tensor factorization prediction approach, in which time is taken into consideration.
The service status and network environments are highly variable over time, which requires efficient QoS prediction of services at run-time. In chapter 5, we propose an online QoS prediction approach for services.
Based on the QoS prediction results in part 1, In part 2, we improve the current research of service searching. We proposed a QoS-aware searching approach, which systematically fusing the functional approach and non-functional approach to achieve better performance.
Based on the QoS prediction results in part 1, In part 3, propose a QoS-aware Byzantine fault tolerance framework for building robust cloud systems. Different from traditional fault tolerance approach, Our approach use dynamic QoS information to improve the system performance.
Chapter 3
Chapter 4
Chapter 5

14. Approach 1 Neighborhood-based QoS Prediction
Part 2: QoS-Aware Searching
Part 3: QoS-Aware
Fault Tolerance
Chapter 6
Chapter 7
Part 1: QoS Prediction
Chapter 3
Chapter 4
Chapter 5
Approach 1
Neighborhood-based QoS Prediction 14

15. Toy Example User-component matrix: m × n, each entry is a QoS value.
Sparse
Prediction accuracy is greatly influenced by similarity computation.
Toy example to present the QoS prediction problem
Idea of neighborhood-based prediction
sparse

16. Latent Features Learning
u1 u2 u3 u4
c c c c c c6
2 full matrix
Transposed matrix
Latent-user matrix V
Latent-component matrix H T
W = V X H

17. Similarity Computation
Pearson Correlation Coefficient (PCC)
Similarity between users:
Similarity between components:
u1 u2 u3 u4
Latent-user matrix V
c c c c c c6
Latent-component matrix H

18. Neighbors Selection
For every entry wi,j in the matrix, a set of similar users towards user ui can be found by:
A set of similar items towards component cj can be found by:

19. Missing Value Prediction
Similar User-based:
Similar Component-based:
Hybrid:

20. Experiments QoS Dataset Metrices Mean Absolute Error (MAE)
Root Mean Squared Error (RMSE)
: the real QoS value.
: the predicted QoS value
N: the number of predicted values.

21. Performance Comparisons
IPCC
similar item
UPCC
similar user
UIPCC
similar item + similar user
NMF
matrix factorization
CloudPred
matrix factorization + similar item + similar user

22. Experimental Results
A smaller MAE or RMSE means a better performance

23. Impact of Matrix Density
With the increase of matrix density, the prediction accuracy increase.

24. Impact of Top-K
A small value of top k can not make full use of available information, a large value of top k introduce some noise information.

25. Impact of Dimensionality
Small not enough to characterize
Large overfitting

26. Part 1: QoS Prediction Part 2: QoS-Aware Searching Part 3: QoS-Aware
Fault Tolerance
Chapter 6
Chapter 7
Part 1: QoS Prediction
Chapter 3
Chapter 4
Chapter 5
Approach 2
Time-Aware Model-Based QoS Prediction 26

27. Time-Aware QoS Performance
Time-aware personalized QoS prediction is essential for:
Automatic selection
Dynamic composition
Traditional QoS prediction approaches usually try to prediction the average QoS performance of services. However, QoS performance of services is highly related to invocation time. Time-aware personalized QoS prediction is essential for:
Automatically service selection
Dynamically service composition

28. Case Study
Periodic feature + average performance
Fluctuate

29. latent-service matrix
Tensor Factorization
Time
User
Service
u1 u2 u3 u4 u5
s1 s2 s3 s4 s5
t1 t2 t3 t4 t5
latent-user matrix
latent-service matrix
latent-time matrix

30. Latent Features Learning
The error between estimated tensor and the original tensor
Objective function
Local optimal solution is found by incremental gradient descent
Regularization term which prevents the predicted QoS values from varying a lot against the average QoS value
Regularization terms which constrain the norms of U, S and T, to avoid overfitting problem

31. Missing Value Prediction
Given feature spaces U, S and T
Example:
latent-service matrix
latent-user matrix
u1 u2 u3 u4 u5
latent-time matrix
s1 s2 s3 s4 s5
t1 t2 t3 t4 t5
Given feature spaces U, S and T, a missing value is predicted by evaluating how the features of corresponding user, service and time apply to each other

32. Experiments
Time-Aware Web Service QoS Dataset

33. Performance Comparisons
Matrix Factorization extended methods
MF1: a set of user-service matrix slices in terms of time
MF2: compresses the user-service-time tensor into an user-service matrix
Tensor Factorization methods
TF :Tensor factorization-based prediction method.
WSPred :Tensor factorization-based prediction method with average QoS value constraints.
Matrix Factorization extended methods
MF1: This method considers the user-service-time tensor as a set of user-service matrix slices in terms of time. Then it applies MF on each matrix slice.
MF2: This method compresses the user-service-time tensor into an user-service matrix. Then it applies MF on this user-service matrix.

34. Performance improvement of WSPred
Experimental Results
A smaller MAE or RMSE value means a better performance
9~25% 5~15% 3~12% ~22% 3~13% ~12%
Performance improvement of WSPred

35. Impact of Tensor Density

36. Impact of Dimensionality

37. Approach 3 Online QoS Prediction
Part 2: QoS-Aware Searching
Part 3: QoS-Aware
Fault Tolerance
Chapter 6
Chapter 7
Part 1: QoS Prediction
Chapter 3
Chapter 4
Chapter 5
Approach 3
Online QoS Prediction 37

38. System Architecture Online QoS Prediction Procedures
The service status and network environments are highly variable over time. Therefore, it requires efficient QoS prediction of services at run-time. In the chapter we proposed an online QoS prediction approach for Web services and service-oriented systems.
Online QoS Prediction Procedures

39. Key Idea tc
t1 … tc-1

40. Step 1: Time-Aware Latent Feature Learning
Objective function:
The error between estimated matrix and the original matrix
Regularization terms which constrain the norms of p(t) and q(t), to avoid overfitting problem

41. Step 1: Time-Aware Latent Feature Learning
Iterative Process :
gradient descent

42. Step 2 & Step 3 (Offline Phase)
u u u u u5
c c c c c5

43. Step 2 & Step 3 (Online Phase)

44. System Level Performance
Calculation of Aggregated Response Time
Basic Compositional Structures

45. System Level Performance Prediction

46. Comparison with Other Methods
UPCC (time-insensitive) - Mean
IPCC (time-insensitive) - Mean
MF (time-insensitive) - Mean
TF (time-sensitive) - Periodic
WSPred (time-sensitive) – Periodic + Mean
OPred (time-sensitive) - Periodic + Mean + timely trend

47. Experimental Results

48. Impact of Density
Also show similar results of impact of density as before

49. Impact of Dimensionality

50. Impact of a and w
The parameter a controls the decaying rates of weights assigned to different time slices. A larger value of gives more weights to the recent time slices. w controls the information of how many past time slices are used for making prediction. In Figure 5.9, we vary the values of w from 1 to 20 with a step value of 1.
We observe that as w increases, the values of MAE and RMSE decrease (prediction accuracy increase) at first, but when w pass a certain threshold, the MAE and RMSE converge. This phenomenon coincides with the intuition that employing past performance information from more time slices can increase prediction accuracy. When w surpasses a certain threshold, the MAE and RMSE decrease little with further increase of the value of w. The reason is that when w is large enough, small weight values are assigned to the information of older time slices, which contribute little to the prediction accuracy. This observation indicates that too large w is unnecessary. The thresholds are different under different values of . Since a larger value of gives more weights to the recent time slices, the threshold is smaller than those under smaller values of . In Figure 5.9, OPred achieves the best performance when a = 0:2. The observation
confirms with the intuition that with a large value of a useful information from older time slice will be lost, and with a small value of noisy data will cause the decrease of prediction accuracy.

51. Average Computational Time
Opred use less time to conduct QoS prediction

52. System Level Performance Case Study

53. System Level Performance Case Study
System Performance Improvement of Dynamic Service Composition

54. Part 2: QoS-Aware Searching
Fault Tolerance
Chapter 6
Chapter 7
Part 1: QoS Prediction
Chapter 3
Chapter 4
Chapter 5 54

55. Problems How to find a service?  Functionality
Many Web services
How to find the best one?
Different QoS Performance
 Functionality
 QoS
To search an appropriate service, there are two major problems. One is that there are many services available, how to find a service that has the specified functionality. The other problem is that services have different QoS performance, how to guarantee that the service found has good QoS performance. Otherwise, the services found may not work as expected.
Traditional service searching approaches only find the Web services to fulfill users’ functionality requirements. In this part, we propose the first service searching approach that takes both functionality and QoS performance into consideration. The services listed in our searching result can fulfill users’ functionality requirements and have good QoS performance at the same time.

56. WSExpress Functional attributes & non-functional features.
Non-functional evaluation
Obtains QoS criteria values
QoS utility computation
Functional evaluation
WSDL preprocessing
Similarity computation
Pay respect to functional attributes as well as non-functional features of Web services.

57. Combination
The first term calculates the appropriateness value of a candidate for a query from functionality aspect.
The second term calculates the appropriateness value of a candidate for a query from QoS perspective.
lambda is between 0 and 1, it defines how much the functionality factor is more important than the non-functionality factor in the final recommendation

58. Performance Comparisons
A larger NDCG value means a better performance

59. Contributions Functionality and non-functionality
A large-scale distributed experimental evaluation
3738 Web services
69 countries
real-world WSDL dataset and QoS dataset
30+ institutes
The contributions of this chapter are three-fold: (1) different from previous approaches which only employ functional
features or non-functional features, we propose the first Web service searching approach which considers both functional and non-functional qualities of the service candidates; (2) we conduct a large-scale distributed experimental evaluation to verify the proposed approach. Functional and non-functional characters of 3738 Web services from 69 countries are studied. The experimental results demonstrate the effectiveness of our Web service searching approach; (3) we publicly release the real-world WSDL files of Web services and corresponding QoS records. More than 30 institutes have downloaded and utilized our datasets for extensive Web service research.

60. Part 2: QoS-Aware Searching
Fault Tolerance
Chapter 6
Chapter 7
Part 1: QoS Prediction
Chapter 3
Chapter 4
Chapter 5 60

61. How to Build Reliable Service-Oriented Systems
Problems
Services may contain various faults
QoS of remote services may not be stable, e.g., unavailability problem
Solution: QoS-aware fault tolerance
Based on the QoS prediction results in part 1, we can address the challenge 3: How to Build Reliable Service-Oriented Systems?
Service-oriented systems consist of several services. One problem is that these services are provided by different institutions, they may contain various faults, these faults may cause the systems unreliable. Another problem is that the QoS of the remote services may not be stable, for example, unavailability problem. This may cause the performance of the systems unstable.
Therefore, it is urgent to design a fault tolerance mechanism. This mechanism can handle different faults of services. it need also take QoS of services into consideration when replication techniques are employed in fault tolerance. we proposed a QoS-aware fault tolerance framework this chapter. We employ Byzantine fault tolerance strategy to tolerant various faults of services, including arbitrary behavior. Different from traditional Byzantine fault tolerance, we are the first to take QoS of services into consideration. Therefore, the services used in the service-oriented systems have good QoS performance. And the whole performance of the service-oriented system are guaranteed.

62. System Architecture BFT Group
Within a cloud application, there are several tasks. Each task is executed by a group of services. We call it BFT group. By using replication technique, The BFT group employs fault tolerant strategy to guarantee that the task is correctly finished. When selecting the services to form a BFT group, we take QoS performance of the services into consideration. Also when some of the services need to be replaced at runtime, we will also check the QoS of the newly selected services before update the BFT group.
BFT Group 62

63. Work Procedures of BFTCloud
Figure 3 shows the work procedures of BFTCloud. The input of BFTCloud is a sequence of requests with specified QoS requirements (e.g., preferences on price, capability, bandwidth, workload, response latency, failure probability, etc.) sent by the cloud module. The output of BFTCloud is a sequence of committed responses corresponding to the requests.
BFTCloud consists of five phases: primary selection, replicas selection, request execution, primary updating and replica updating. 63

64. Experimental Results Request/Response Size: 0/0 KB64

65. Contributions A Byzantine fault tolerance framework A prototype system
QoS-aware
A prototype system
Large-scale real-world experiments
The contribution of this chapter are as following: (1) we identify the Byzantine fault tolerance problem in cloud and propose a Byzantine fault tolerance framework to guaranteeing
the robustness of cloud application. Our approach uses dynamical replication techniques to tolerate various types of
Faults. It is the first approach which takes QoS performance of service into consideration; (2) we build a prototype system on a cloud, which consists of 257 cloud services from in 26 countries,
to test the fault tolerance middleware we designed; (3) we conduct large-scale real-world experiments to study the reliability performance of our approach

66. Part 2: QoS-Aware Searching
Thesis Structure
Part 2: QoS-Aware Searching
Part 3: QoS-Aware
Fault Tolerance
Chapter 6
Chapter 7
Part 1: QoS Prediction
Chapter 3
Chapter 4
Chapter 5

67. Conclusion Part 1: QoS prediction Prat 2: QoS-aware service searching
Three prediction approaches
Several following up works on this topic using the released datasets
Prat 2: QoS-aware service searching
Searching qualities are significantly improved
Part 3: QoS-aware fault tolerance
Byzantine fault tolerance
dynamic QoS information
(1) In part 1, We formally identify the research problem of QoS prediction and propose three prediction approaches.
The first approach predict the average QoS performance of services. The second approach employ tensor factorization and considered the service invocation time for prediction. The third approach provide an online solution for rapidly QoS prediction at runtime. We also publicly release several large-scale real-world QoS datasets. Several following up works from more than 30 research institutes on this topic using our released datasets.
(2) Based on the QoS prediction results in part 1, In part 2, we improve the current research of service searching. We proposed a QoS-aware searching approach, which, for the first time, systematically fusing the functional approach and non-functional approach to achieve better performance. we also conduct a large-scale distributed experimental evaluation to verify the proposed approach. And we release the real-world WSDL dataset and corresponding QoS records. Several institutes have downloaded and utilized our datasets for extensive Web service research.
(3) Finally, Based on the QoS prediction results in part 1, In part 3, propose a QoS-aware Byzantine fault tolerance framework for building robust cloud systems. Different from traditional fault tolerance approach, Our approach use dynamic QoS information to improve the system performance.

68. Publications Paper published
Yilei Zhang, Zibin Zheng and Michael R. Lyu. "Real-Time Performance Prediction for Cloud Components", in Proceedings of the 5th International Workshop on Real-Time Service-Oriented Architecture and Applications (RTSOAA 2012), Shenzhen, China, Apr. 11-Apr. 13, 2012, pp
Yilei Zhang, Zibin Zheng and Michael R. Lyu. "WSPred: A Time-Aware Personalized QoS Prediction Framework for Web Services", in Proceedings of the 22th IEEE Symposium on Software Reliability Engineering (ISSRE 2011), Hiroshima, Japan, Nov. 29-Dec. 2, 2011, pp
Yilei Zhang, Zibin Zheng and Michael R. Lyu. "Exploring Latent Features for Memory-Based QoS Prediction in Cloud Computing", in Proceedings of the 30th IEEE Symposium on Reliable Distributed Systems (SRDS 2011), Madrid, Spain, Oct. 4-7, 2011, pp.1-10.
Yilei Zhang, Zibin Zheng and Michael R. Lyu. "BFTCloud: A Byzantine Fault Tolerance Frame-work for Voluntary-Resource Cloud Computing", in Proceedings of the 4th IEEE International Conference on Cloud Computing (CLOUD 2011), Washington DC, USA, July 4-9, 2011, pp
Zibin Zheng, Yilei Zhang, and Michael R. Lyu, “Investigating QoS of Real-World Web Services”, IEEE Transactions on Service Computing.

69. Publications
Yilei Zhang, Zibin Zheng and Michael R. Lyu. "WSExpress: A QoS-Aware Search Engine for Web Services", in Proceedings of the 8th IEEE International Conference on Web Services (ICWS 2010), Miami, Florida, USA, July 5-10, 2010, pp
Zibin Zheng, Xinmiao Wu, Yilei Zhang, Michael R. Lyu and Jianmin Wang. "QoS Ranking Prediction for Cloud Services", IEEE Transactions on Parallel and Distributed Systems.
Zibin Zheng, Yilei Zhang and Michael R. Lyu. "Distributed QoS Evaluation for Real-World Web Services”, in Proceedings of the 8th IEEE International Conference on Web Services (ICWS 2010), Miami, Florida, USA, July 5-10, 2010, pp
Zibin Zheng, Yilei Zhang and Michael R. Lyu. "CloudRank: A QoS-Driven Component Ranking Framework for Cloud Computing", in proceedings of the 28th IEEE International Symposium on Reliable Distributed Systems (SRDS 2010), New Delhi, India, Oct.31-Nov.3, 2010.
Paper under review/preparation
Yilei Zhang, Zibin Zheng and Michael R. Lyu. "An Online Performance Prediction Framework for Service-Oriented Systems", submitted to the IEEE Transactions on Systems, Man and Cybernetics, Part A: Systems and Humans.
Yilei Zhang, Zibin Zheng and Michael R. Lyu. "QoS-Aware Web Service Searching ", prepared to submit to IEEE Transactions on Service Computing.
Yilei Zhang, Zibin Zheng and Michael R. Lyu. “QoS Prediction via Latent Feature Learning in Cloud Computing", prepared to submit to IEEE Transactions on Cloud Computing.

70. Thank you!
Q & A