Article Preview
TopIntroduction
Service composition is an effective way of combining a set of fine-grained web services to satisfy coarse-grained personalized demands. After a customer raises his functional and Quality-of-Service (QoS) expectations, the broker selects appropriate web services from a massive distributed set of candidates and assembles them into a composite service.
However, not all customer demands could be completely satisfied. For example, the expected functionality exceeds the functional scope of the candidate services, or the expected QoS is too strict to be reached. In these cases, the broker may either offer a composite service that is closest to the demand, or refuse to handle the demand.
A typical QoS attribute that is difficult to satisfy is strict reliability. Reliability is defined as “the probability of failure, the frequency of failures, or in terms of availability, a probability derived from reliability and maintainability” (Wikipedia, 2014). For other QoS attributes such as execution time and cost, even if the expectations thereof are not met, the composite service can still keep executing until the functional expectations are fulfilled completely. However, if the reliability is too low, the failure probability of the composite service is high, and consequently, the functional expectations cannot be fulfilled at all. As such, in many real-world scenarios, customers place a higher priority on reliability than other QoS attributes and would be prepared to pay extra money to obtain a composite service with higher reliability.
The reliability of a service-oriented system is determined by various factors on multiple technical layers, including the web service layer, transport layer, SOAP messaging layer, and business process layer (Erradi and Maheshwari 2005). Because most web services that comprise a composite service are offered by external service providers and exhibit characteristics of distributedness, autonomy, and heterogeneity (Guo, Huai et al. 2007), the reliability of a web service depends almost on the reliability of the technical environment on which it is deployed, and the reliability of the Internet connections between the service and the customer. Both aspects are completely out of the control of the broker, therefore, web service selection has to be based on either the declarations of service providers or the statistical analysis of the historical records of service invocations. In other words, the customers and brokers do not care about what internal factors determines the reliability of a service but just play the role of an “external observer” of the services.
Assuming that the reliability of available web services remains stable and cannot be significantly improved within a short period, a broker can adopt two typical strategies for effectively enhancing the reliability of composite services: design-time or run-time enhancement. The latter is achieved by improving the transport and messaging layers, or by dynamically re-scheduling and patching the composite service depending on its actual execution performance, e.g., self-healing (Dai, Yang et al. 2009) and dynamic substitution (Gong, Huang et al. 2014). This is in essence a kind of “afterwards remedy”. In contrast, design-time enhancement is aimed at the business process layer and enhances the anticipated reliability of the composite service before it is put into execution. The research in this paper falls into design-time enhancement, i.e., we do not consider the internal technical design but focus on the business-level design to enhance the reliability of a composite service before it is executed. Here the “business-level reliability” of a composite service is referred to as the success rate that the customer demand is fully fulfilled, instead of the probability of the service being normally running within a given period (namely “technical-level reliability”). The difference is that, even if a composite service has a high technical-level reliability, the business-level reliability might be relatively low. For example, a flight ticket booking service runs well in a certain period (i.e., its technical-level reliability keeps high), but it often cannot book the hot air tickets required by the customers, so its business-level reliability is relatively low.