Article Preview
TopIntroduction
Within Service Oriented Architecture, service orchestration refers to the compositions where one central controller “orchestrates” (steers) the execution logic, according to a pre-defined workflow. Due to the inherent stochastic nature of web services execution environment, QoS provisioning is a difficult task and Service Level Agreements (SLAs) violations could occur relatively often, leading to providers' (financial) losses and customer dissatisfaction. The issue of QoS provisioning is a challenging one, and is usually addressed by adaptation of the composition itself at runtime. One way to perform the adaptation of the web service composition at runtime may be by service rebinding/substitution, (Ardagna, Comuzzi et al., 2007; Leitner, Hummer et al., 2011). In such a case, the adaptation is performed by exchanging a service within the composition by another (in ideal case functionally equivalent) one, that is usually faster but more expensive than the initial service selected. This implies that service adaptation usually brings additional costs for the composite service provider. When actual service adaptation costs are not carefully taken into account, one may end up with the situation when it is economically better to pay the penalty for the SLA violation without adaptation, than otherwise, (Leitner, 2011).
This paper addresses the problem of runtime adaptation of the orchestrated service composition that is based on conditional retry mechanisms. The goal of such adaptation is to maximize the revenues of the composite service provider (CSP), while meeting the end-to-end deadline specified in the SLA that the CSP has with its clients, even when some of the services used for the composition becomes transiently less responsive (its performability worsens). Motivated by practical applications, an important feature of our model is that it takes into account multiple QoS service parameters, like (heavy-tailed) response time performance and service costs. We use a dynamic programming approach (described in Bellman (2003)) in order to derive the optimal selection policy that will be used at runtime. This policy is determined before the actual deployment of a composite service, and allows optimal service selection at runtime. The policy also specifies the (optimal) moments when retry should be attempted, and which service should be used for a retry. As the policy is determined before runtime, our solution does not require lengthy (and time consuming) re-calculation of the service composition (i.e. adaptation) at runtime. At the same time, the calculated policy takes into account actual time to deadline, current performability of the services, execution costs and expected revenue of the composite service provider.
To illustrate our approach, we observe the orchestrated composite web service which sequential workflow is depicted at Figure 1. This example workflow consists of four abstract services (tasks), and each task maps to a number of concrete services (alternatives), which are deployed by (independent) third-–party service providers. When the client's request is served within the agreed end-–to-–end deadline, the composite service provider is rewarded by the client. Otherwise, when the deadline is not met, the provider pays a penalty to the client. The orchestrator performs run-time service selection for a given task at decision points illustrated at Figure 1 by A, B, C and D, respectively. The selection or retry decisions at each of these points are taken based on a pre-calculated policy, and takes into account which of the considered services are available at the decision moment, the execution costs, and the remaining time to meet the end–-to-–end deadline.
Figure 1. Conditional retry adaptation of orchestrated service composition. Run-time service composition and adaptation is based on pre-calculated policy. Decisions are taken at points A-D, and e.g. it is known to the orchestrator at C how long to wait for response before a retry is made.