Performance Evaluation 67 (2010) 659–675
Contents lists available at ScienceDirect
Performance Evaluation journal homepage: www.elsevier.com/locate/peva
On optimal service selection in Service Oriented Architectures Daniel A. Menascé a,∗ , Emiliano Casalicchio b , Vinod Dubey c a
Department of Computer Science, MS 5C8, George Mason University, Fairfax, VA 22030, USA
b
Dipartimento di Informatica Sistemi e Prod., Università di Roma ‘‘Tor Vergata’’, Roma, Italy
c
The Volgenau School of Information Technology and Engineering, George Mason University, Fairfax, VA 22030, USA
article
info
Article history: Received 19 January 2009 Received in revised form 12 May 2009 Accepted 8 July 2009 Available online 17 July 2009 Keywords: Service Oriented Architecture Service composition QoS Optimization Heuristic
abstract Service Oriented Architectures enable a multitude of service providers to provide loosely coupled and interoperable services at different Quality of Service and cost levels. This paper considers business processes composed of activities that are supported by service providers. The structure of a business process may be expressed by languages such as BPEL and allows for constructs such as sequence, switch, while, flow, and pick. This paper considers the problem of finding the set of service providers that minimizes the total execution time of the business process subject to cost and execution time constraints. The problem is clearly NP-hard. However, the paper presents an optimized algorithm that finds the optimal solution without having to explore the entire solution space. This algorithm can be used to find the optimal solution in problems of moderate size. A heuristic solution is also presented. Thorough experimental studies, based on random business processes, demonstrate that the heuristic algorithm was able to produce service provider allocations that result in execution times that are only a few percentage points (less than 2.5%) worse than the allocations obtained by the optimal algorithm while examining a tiny fraction of the solution space (tens of points versus millions of points). © 2009 Elsevier B.V. All rights reserved.
1. Introduction There has been significant recent interest in Service Oriented Architectures (SOA) [1–6]. The SOA model enables a multitude of service providers (SP) to provide loosely coupled and interoperable services at different Quality of Service (QoS) and cost levels in a number of service domains. This provides a unique opportunity for businesses to dynamically select services that better meet their business and QoS needs in a cost-effective manner. SOAs enable service composition and facilitate enterprises to re-engineer their business processes (BP), commonly defined as ‘‘. . . a structured set of activities designed to produce a specific output. . . ’’ [7–10]. An important consideration in service composition is the selection of service providers in a way that meets the specific QoS requirements and cost constraints of the resulting business process. The Business Process Execution Language (BPEL) [11] can be used to model business processes in a SOA. The execution of a business process is coordinated by a service broker (or broker for short). The business activities that compose the BP are implemented by services and executed by service providers, and invoked by service consumers using the Web Services communication paradigm. BPEL has emerged as a standards-based service orchestration technology that provides an XMLbased grammar for describing the control logic required to orchestrate Web services participating in a process flow [11]. Business processes defined in BPEL are portable and can be executed in any BPEL-compliant process engine. We consider a market of services in which SPs provide services at different QoS and cost levels. In this environment, it makes sense to investigate mechanisms to properly select a set of services that when composed satisfy QoS needs and cost
∗
Corresponding author. Tel.: +1 703 993 1537. E-mail addresses:
[email protected] (D.A. Menascé),
[email protected] (E. Casalicchio),
[email protected] (V. Dubey).
0166-5316/$ – see front matter © 2009 Elsevier B.V. All rights reserved. doi:10.1016/j.peva.2009.07.001
660
D.A. Menascé et al. / Performance Evaluation 67 (2010) 659–675
constraints of the business process. This problem is referred in the literature as the QoS-aware Service Selection or Optimal Service Selection problem [12–19]. To solve the optimal service selection problem, one must first provide a performance model of the business process that takes into account the composition of interacting services. Then, one must determine the service selection that satisfies the QoS and cost constraints. To solve the first problem we provide a performance model that takes into account the business process structure, including cycles, parallel activities, and conditional branches. For some performance metrics (e.g., cost, availability, reputation) the composition is a trivial linear combination of the performance measure of the composing services. On the contrary, for other metrics such as execution time, we have a nonlinear function of the performance level of the services being composed. Several approaches can be used to solve the service selection problem: linear and nonlinear programming [12,15,18,19], heuristics [13,14], and predictive performance models [16]. We use a nonlinear programming formulation and propose an algorithm to find the optimal solution that avoids exploring the entire solution space and a heuristic algorithm to find a suboptimal solution. Current proposals use exact algorithms or heuristics (e.g., [13] or genetic algorithms in [14]) to solve the QoS-aware (optimal) service selection problem for each request, whose exact solution has an exponential complexity. In [18], the authors define the problem as a multi-dimension multi-choice 0–1 knapsack one as well as a multi-constraint optimal path problem. A global planning approach to select an optimal execution plan by means of integer programming is used in [19]. In [12], the authors model the service composition as a mixed integer linear problem where both local and global constraints are taken into account. A linear programming formulation and flow-based approach is proposed in [15]. There, the authors consider not only sequential composition of services but also cycles and parallel activities. Algorithms for the selection of the most suitable candidate services to optimize the overall QoS of a composition are also discussed in [20]. A different approach, based on using a utility function as the QoS measure, is described in [16], where the authors propose a service selection mechanism based on a predictive analytical queuing network performance model. An additional contribution to service selection and composition can be found in [21]. The contributions of this paper are threefold. First, it provides a formulation of the optimization problem that is independent of the business process structure and of the characterization of the performance of the SPs. It is assumed that the SPs provide the Cumulative Distribution Function (CDF) and probability density function (pdf) of their QoS metrics. These can be either obtained by the SPs themselves by analyzing historical data or by external agents that monitor the SPs at regular intervals and fit the data to a distribution. Second, it proposes an algorithm to find the optimal solution in a way that avoids an exhaustive search of the solution space. Finally, it proposes an algorithm to conduct a heuristic search of the solution space in order to find a sub-optimal solution that is very close to the optimal solution but is obtained by examining a drastically reduced number of selections. In fact, the detailed experimental studies reported in this paper show that the heuristic algorithm was able to produce service provider allocations that result in execution times that are only a few percentage points (less than 2.5% on average) worse than the allocations obtained by the optimal algorithm while examining a tiny fraction of the solution space (tens of points versus millions of points). Both algorithms presented here (i.e., the optimal and sub-optimal solution) work for any kind of complex BP structure that may include parallel activities, cycles, and conditional selection of activities. This paper is an extension of a paper presented by the authors at the 2008 ACM Workshop on Software and Performance [22]. Its major extensions include (1) allowing for business processes with nested flows, (2) finding the distribution of the execution time of a sequence of activities when they appear within a flow, (3) handling the case of execution relationships, which means that two or more activities are constrained to execute in the same SP, and (4) a very thorough experimental evaluation of the heuristic using randomly generated business processes. The paper is organized as follows. Section 2 introduces the notation and formally defines the problem. The optimal solution approach is described in detail in Section 3 and the heuristic approach is described in Section 4. The problem of dealing with execution relationships is discussed in Section 5. Experimental results are discussed in Section 6. Section 7 concludes the paper. 2. Background and notation We use the average execution time of the business process as its main QoS metric. As previously discussed, this metric is a nonlinear function of the execution times of individual business activities and depends on the BP structure and composition constructs used. We assume that the probability density function and cumulative distribution function of the execution time of each SP are known. This can be accomplished, for example, by having service providers keep records of request execution times so that the well-known distribution fitting techniques (e.g., using Quantile–Quantile plots) can be applied and reported by the SPs. We also assume that the execution cost of each business activity provided by the SPs is given. Let,
• A business process B be composed of N business activities ai , i = 1, . . . , N. • Rmax be the maximum average execution time for B.
D.A. Menascé et al. / Performance Evaluation 67 (2010) 659–675
661
• Cmax be the maximum cost for the execution of B. • Si = {si1 , . . . , sik } be the set of service providers that can be used in the implementation of business activity ai . • Ri,j be the execution time for business activity ai when implemented by service provider sij ∈ Si . Ri,j is a random variable with a probability density function pi,j and a cumulative distribution function Pi,j .
• Ri be the execution time of business activity ai for a generic candidate service provider. This is a random variable whose distribution is specified when the service provider sij ∈ Si is allocated to ai . • Ci,j be the execution cost of business activity ai when it is implemented by service provider sij ∈ Si . • Ci be the execution cost of business activity ai for a generic candidate service provider. The actual cost is specified when the service provider sij ∈ Si is allocated to ai . • Z be the set of all possible service provider selections of the business activities of B. • z ∈ Z be a service selection of N service providers that support the execution of business process B. • z k be a subselection in which only the first k activities of a business process have service providers assigned to them. • z (i) be the service provider assigned to activity ai in service selection z. • R(z ) and C (z ) be the execution time and the cost associated with service selection z, respectively. R(z ) is a random variable with expected value denoted by E [R(z )]. 2.1. Problem formulation The Optimal Service Selection problem is formulated as a nonlinear programming optimization problem where the objective is to find a service selection z that minimizes the average execution time subject to cost constraints: min E [R(z )] subject to E [R(z )] ≤ Rmax C (z ) ≤ Cmax z ∈ Z. As shown in Section 3.3, E [R(z )] can be a complex nonlinear function that can be obtained from the well-known results from order statistics. 2.2. Problem solution The Optimal Service Composition problem formulated above is solved here using two different approaches. The first is an optimal solution approach (Optimal Service Selection) that avoids performing an exhaustive search of the solution space Z by dropping all selection sequences z = s1∗ , . . . , sk∗ , . . . , sN∗ that have a non-feasible subselection z k = s1∗ , . . . , sk∗ . A non-feasible selection is one that violates the execution time or cost constraint. It should be noted that this reduced search still finds the optimal selection without necessarily analyzing every possible selection (see Section 3). This approach may work well for small to moderate problems but it is still NP-hard in general. The second approach (Heuristic Service Selection) adopts a heuristic solution that reduces the problem complexity (see Section 4). The first required step for both the optimal reduced search and the heuristic is to be able to extract from the BPEL code that describes the business process, an expression for the global average execution time and another for the total execution cost. This expression needs to take into account the structure of the business process as well as the execution times and cost of the individual business activities. 3. Optimal Service Selection BPEL offers different constructs to combine business activities into a business process. The business logic is a structured activity obtained by putting together elementary business activities (in what follows, the term business process and business logic are used alternatively). Each business activity is essentially a synchronous or asynchronous invocation of a Web service operation. A structured activity includes sequential control, nondeterministic choice, and concurrency and synchronization of elementary activities. More specifically, the main structured activities in BPEL are:
• ordinary sequential control between activities:
, , and ; • concurrency and synchronization between activities: ; • nondeterministic choice based on external events: . Our goal is to compute the execution time R of a business process and its execution cost C . While the execution cost of a process is the sum of the execution costs of the activities of the business process (plus eventually some additional overhead), the execution time depends on how the business activities are structured. For example, if we have a P sequence of business activities a1 , . . . , an , and a service selection z, the execution time of the business process is R(z ) = i=1,...,n Ri,j
662
D.A. Menascé et al. / Performance Evaluation 67 (2010) 659–675
Fig. 1. An example of a BPEL business process on the left, the corresponding BPTree on the right, and an execution graph on the middle.
where sij is the service provider assigned to activity ai in z. The execution time of an activity ai that is repeated n times and that is supported by service provider si,j is simply R(z ) = n × Ri,j . If the number of repetitions of ai is not a fixed value n, but is a discrete random variable ni with a given distribution, then R(z ) = ni × Ri,j . In the P case of deterministic or nondeterministic choices, the computation of the total execution is easily computed as R(z ) = i=1,...,n qi × Ri,j where qi is the probability that activity ai is invoked. Finally, the execution time of the parallel execution of n business activities is given by R(z ) = maxi=1,...,n {Rij }. Two problems need to be solved: the first is how to compute an expression for R, the execution time of a business process B, as a function of the individual execution times of the various activities in B taking into account the structure of B. Note that R is a random variable. The second problem is that of computing E [R], the average execution time. 3.1. Computation of the execution time R A BPEL process can be represented in two equivalent ways: as a directed execution graph or as an execution tree, called BPTree (see Fig. 1). It is possible to compute an expression for R and then for E [R] by visiting the BPTree in post-order. We use an example to illustrate the approach. Consider the simple BPEL process shown in Fig. 1 that includes , , and constructs. For simplicity, we used a pseudo BPEL syntax. The corresponding execution tree is shown on the right of Fig. 1. We introduce two types of nodes in such a tree: construct nodes, represented as boxes, and activity nodes, represented as circles. Each node has associated with it an order number and a label. For example, node (4 : a2) is the 4th node and represents activity a2 and node (2:switch) is the second node and represents the switch. The BPTree can be constructed from left to right, by parsing the BPEL code from start to end, and associating the corresponding node to each BPEL element. The leaves of a BPTree are always activity nodes. In the example, nodes are numbered according to the above rule. An expression for the execution time of a business process can be automatically obtained from the BPTree using Algorithm 1, which visits the BPTree in post-order, computing the response time for the different BPEL constructs according to the rules defined in lines 8 through 13, and described in the previous section. In the algorithm, children(i) denotes the set of nodes that are children of node i and label(i) denotes the label of node i. Applying the algorithm to the example of Fig. 1 we obtain: R = R1 + q1 × max{R2 , (R3 + R4 )} + q2 × R5 + R6 .
(1)
3.2. Computation of the execution cost C An expression for the cost C of executing a business process can be automatically obtained from the BPTree using Algorithm 2, which is very similar to Algorithm 1. The main difference is that the cost of a flow is the sum of the cost of its branches. Applying the algorithm to the example of Fig. 1 we obtain: C = C1 + q1 × (C2 + C3 + C4 ) + q2 × C5 + C6 .
(2)
D.A. Menascé et al. / Performance Evaluation 67 (2010) 659–675
663
Algorithm 1 Compute the execution time of a BPEL process 1: 2: 3: 4: 5: 6: 7: 8: 9: 10: 11: 12: 13: 14: 15:
function Compute R(node i) if i is a leaf node then return Ri ; else for all k ∈ children(i) do Rk =Compute R(k); end for if label(i) = sequence then P return Ri = k∈children(i) Rk ; else if label(i) = switch then P return Ri = k∈children(i) qi × Rk ; else if label(i) = flow then return Ri = maxk∈children(i) Rk ; end if end if
Algorithm 2 Compute the cost of executing a BPEL process 1: 2: 3: 4: 5: 6: 7: 8: 9: 10: 11: 12: 13:
function Compute C (node i) if i is a leaf node then return Ci ; else for all k ∈ children(i) do Ck =Compute C (k); end for if (label(i) = sequence ) or (label(i) = P return Ci = k∈children(i) Ck ; else if label(i) = switch then P return Ci = k∈children(i) qi × Ck ; end if end if
flow) then
3.3. Computation of E [R] The computation of the average execution time E [R] can be done using the property that the expected value of a linear combination of random variables is a linear combination of the expected values of these random variables. Thus, E [q1 × R1 + · · · + qn × Rn ] =
n X
qi × E [Ri ].
(3)
i=1
The main challenge occurs when the business process has a , which yields a term in the expression of E [R] that requires the computation of the expected value of a random variable defined as the maximum of several random variables. The expected value of a maximum of a set of independent random variables can be obtained using order statistics arguments as indicated below [23]: n
E [max Ri ] = i =1
"
∞
Z
x 0
n Y
# Pi (x)
i=1
n X pi (x) i=1
Pi (x)
dx
(4)
where R1 , . . . , Rn are independent random variables, pi (x) is the pdf of Ri and Pi (x) is the CDF of Ri . Applying Eqs. (3) and (4) to Eq. (1) we obtain: ∞
Z
x [P2 (x) × P3+4 (x)] ×
E [R] = E [R1 ] + q1 × 0
Z + q1 × 0
∞
x [P2 (x) × P3+4 (x)] ×
p2 (x) P 2 ( x)
p3+4 (x) P3+4 (x)
dx
dx + q2 × E [R5 ] + E [R6 ]
where p3+4 (x) and P3+4 (x) are, respectively, the pdf and CDF of the random variable R3 + R4 . The probability density function of the sum of two independent random variables, is the convolution of their individual density pdf’s. Thus,
664
D.A. Menascé et al. / Performance Evaluation 67 (2010) 659–675
p3+4 (x) = P3+4 (x) =
Z Z
y=+∞
p3 (y)p4 (x − y)dy y =0 y=x
p3+4 (y)dy.
y =0
Numerical integration methods can be used to solve the integrals above. In general, when a flow has a branch that includes a sequence of activities, it is necessary to determine the pdf and CDF of the sum of the random variables that represent the execution times of the activities in this branch in order to apply Eq. (4). If random variables x1 , . . . , xn are independently distributed (a reasonable assumption in our case), with pdf’s px1 (x), . . . , pxn (x), the Laplace transform L[px1 +···+xn (x)] of the pdf px1 +···+xn (x) of the sum of these random variables is simply the product of the Laplace transforms of their pdf’s. In other words, n Y
L[px1 +···+xn (x)] =
L[pxi (x)].
(5)
i =1
The pdf px1 +···+xn (x) can be obtained by inverting the Laplace transform of Eq. (5). In many cases of practical interest, the Laplace transform of a sum of random variables can be written as the ratio P (s)/Q (s) between two polynomials of degrees m and n, respectively, with n > m (if m ≥ n one can divide P (s) by Q (s) and write down the result as a polynomial in s plus a ratio between two polynomials such that n > m). In the special case in which all zeros of Q (s) are distinct, one can invert L[px1 +···+xn (x)] using the Heaviside Expansion Theorem [24]: If L[px1 +···+xn (x)] = P (s)/Q (s) and (1) the degrees of P (s) and Q (s) are m and n, respectively, with n > m, and (2) Q (s) has n distinct simple zeros located at the points s1 , . . . , sn , then px1 +···+xn (x) = L−1 [P (s)/Q (s)]
=
n X P (sk ) sk x e . 0 (s ) Q k k=1
(6)
An expression for L−1 [P (s)/Q (s)] for the case in which Q (s) has zeros with multiplicity >1 can be found in [24]. For example, the pdf of a sum of n independently distributed exponential random variables with parameters λ1 , . . . , λn with λi 6= λj for i 6= j is given by px1 +···+xn (x) =
λ 1 . . . λn e−λk x n n P Q (−λk + λj )
n X k=1
(7)
i=1 j=1,j6=i
since in this case P (s) = λ1 . . . . λn and Q (sR) = (s + λ1 ). . . . (s + λn ). x The CDF Px1 +···+xn (x) of x1 + · · · + xn is 0 px1 +···+xn (y)dy. Its Laplace transform can be computed using the property that
L[
F (s)
Rx
f (y)dy] = s and Px1 +···+xn (x) can be obtained by inverting the Laplace transform. In the example of independently distributed exponential random variables, we get 0
Px1 +···+xn (x) = 1 +
n X λ1 . . . λn
Q 0 (−λk ) k =1
e−λk x
(8)
where Q (−λk ) = −λk 0
n n X Y i=1 j=1,j6=i
! (−λk + λj ) +
n Y
(−λk + λj ).
(9)
j =1
3.4. Dealing with business processes with nested flows If the business process has nested flows like the one shown in Fig. 2, Algorithm 1 will produce an expression for R that includes nested max operators. For example, applying Algorithm 1 to the example of Fig. 2 results in R = R1 + max{R2 , (R3 + max{R4 , R5 } + R6 )} + R7 .
(10)
Dealing with Eq. (10) poses a problem because the computation of the expected value for the first max operator in this equation would require the pdf and the CDF of the random variable R3 + max{R4 , R5 } + R6 according to Eq. (4). However, Eq. (10) can be rewritten as R = R1 + max{R2 , (R3 + R4 + R6 ), (R3 + R5 + R6 )} + R7 which solves the problem of having nested max operators for that equation.
(11)
D.A. Menascé et al. / Performance Evaluation 67 (2010) 659–675
665
Fig. 2. An example of a business process with nested flows.
In general, nested max operators can be eliminated by applying the following reduction rules to the expression generated by Algorithm 1. 1. max{max{X , Y }} → max{X , Y }; 2. max{Z , max{X , Y }} → max{Z , X , Y }; 3. max{Z + max{X , Y }} → max{Z + X , Z + Y }. These reduction rules follow directly from the properties of the max operator and guarantee that the expression for execution time has no nested max operators. 3.5. JOSeS algorithm — an efficient optimal solution The optimal solution to the optimal service allocation problem can be obtained using Algorithm 1 and Eq. (4). A naive and inefficient way of doing it would be to generate all possible service selections z ∈ Z and evaluate E [R(z )] and C (z ) for each z. After that, for example, we may order the solutions by increasing response time and decreasing cost, and choose the first allocation of the list (i.e., the fastest) such that E [R(z )] ≤ Rmax and C (z ) ≤ Cmax . Unfortunately, computing all possible QN solutions is an NP-hard problem. Indeed, |Z| = i=1 |Si | ≈ O(mN ), where m is the average of |Si |. If we consider a business process composed of one hundred activities and we have an average of 10 service providers for each activity, the solution space has cardinality of 10100 , which shows the impossibility to compute the optimal solution when N and |Si | grow. The computational complexity of obtaining the optimal solution can be somewhat reduced as explained below. We propose an algorithm, that we call Jensen-based Optimal Service Selection (JOSeS), to accomplish this. This algorithm does not require one to generate the entire solution space Z, but only a subset of the solution space where each point represents a feasible solution, i.e., one that satisfies the cost and execution time constraints. The name of the algorithm is derived from our use of Jensen’s inequality [25] to obtain a lower bound on the average of the maximum of independent random variables: E [max{R1 , . . . , Rn }] ≥ max{E [R1 ], . . . , E [Rn ]}.
(12)
We use this inequality to compute a lower bound on E [R] in the case of flows of activities. This allows one to reduce the cost of computing the optimal solution by reducing the number of useless computations of the average execution time of a flow of activities. Instead of the expensive computation of E [max{R1 , . . . , Rn }] (see Eq. (4)), we compute max{E [R1 ], . . . , E [Rn ]} and check if max{E [R1 ], . . . , E [Rn ]} ≥ Rmax . Only if the lower bound of the average execution time of an allocation z satisfies the time constraint it is worth computing E [R(z )] through Eq. (4). JOSeS algorithm receives as input an expression for the execution time, such as Eq. (1), and analyzes partial selections of service providers. For each partial selection, the partial execution time and partial cost are compared against their respective constraints. If any of the constraints is violated, then that partial selection is dropped and all other selections that have the same partial selection as a sub-selection will not even be considered. Before we present JOSeS algorithm in detail, it is helpful to consider in the example below how its operation applies to Eq. (1) and the data in Table 1. The algorithm considers sub-expressions and sub-selections to each sub-expression. E [R] ≥ E [R1 ]
666
D.A. Menascé et al. / Performance Evaluation 67 (2010) 659–675
Table 1 Sets of service providers for the execution of business activities a1 , . . . , a6 . Business activities
Service providers
E [R]
C
E [R]/C
a1 a2 a3 a4 a5 a6
s11 , s12 , s13 s21 , s22 s31 s41 , s42 s51 , s52 , s53 s61
1.5, 2, 3.5 1, 1.5 2 0.7, 1.2 0.8, 1.2, 1.5 2.3
3, 2, 1 1, 0.5 1.5 1, 0.5 2, 1, 0.5 1
0.5, 1, 3.5 1, 3 1.33 0.7, 2.4 0.4, 1.2, 3 2.3
Algorithm 3 AdvanceList Function 1: 2: 3: 4: 5: 6: 7: 8: 9: 10: 11: 12: 13: 14: 15:
function AdvanceList s ← next (k); if s = NULL then if k > 1 then reset (k); k ← k − 1; z ← z
(k) returns (s)
AdvanceList (k); else return s end if else return s; end if end function E [R] ≥ E [R1 ] + q1 × E [R2 ] E [R] ≥ E [R1 ] + q1 × max{E [R2 ], E [R3 ]} E [R] ≥ E [R1 ] + q1 × max{E [R2 ], E [R3 ] + E [R4 ]} E [R] ≥ E [R1 ] + q1 × max{E [R2 ], E [R3 ] + E [R4 ]} + q2 E [R5 ] E [R] ≥ E [R1 ] + q1 × max{E [R2 ], E [R3 ] + E [R4 ]} + q2 E [R5 ] + E [R6 ].
Jensen’s inequality is used to reduce the number of computations of the expected value of the maximum of a number of random variables. For example suppose that we are considering a sub-selection z 4 = {s11 , s21 , s31 , s41 } and that q1 = 0.3, Rmax = 15 and Cmax = 4. Consider also the fourth inequality (see above). Then, the execution time is bounded below by 1.5 + 0.3 × max{1, 2 + 0.7} = 2.31 and the cost of the partial allocation is 3 + 0.3 × (1 + 1.5 + 1) = 4.05. This allocation violates the cost constraint and therefore all service selections that have z 4 = {s11 , s21 , s31 , s41 } as a subsequence need not be considered. The steps of JOSeS algorithm are detailed in Algorithm 4, which uses the AdvanceList function shown in Algorithm 3. Let us define the ordered list lk = {sk1 , . . . , sknk } of service providers implementing activity ak . next (k) is a function that returns the next, not yet evaluated, service provider in lk , or returns null if all the SPs in lk were already evaluated. reset (k) is a function that sets all SPs in all lists lj (j = k, . . . , N) as ‘‘not-visited’’ and resets the pointer to the lists so that when next(j) is invoked it returns the first element in the list lj (j = k, . . . , N). We use k (1, . . . , N ) as an activity counter. In Algorithm 2, z stands for the current allocation of service providers being examined and s stands for a generic service provider. The notation z k s indicates that service provider s is concatenated to the right of partial allocation z. The notation z indicates that the last service provider of allocation z should be removed. For example, if z = afg and s = h then z k s results in z = afgh. If z = afgh, then z becomes afg. The notation L(E [R(z )]) stands for the lower bound on the average execution time obtained through Jensen’s inequality for the execution time of allocation z. If we apply JOSeS algorithm to our example, with constraints Rmax = 8 and Cmax = 4, we have to evaluate the value of E [R(z )] only on 19 of the total 36 possible cases. The optimal value obtained is E [R(z )] = 7.97 and C (z ) = 4 for the allocation z = s13 , s22 , s31 , s41 , s52 , s61 . 4. Heuristic service selection The goal of the proposed heuristic solution is to reduce the cost of finding the optimal solution, providing a sub-optimal selection as close as possible to the optimal. Fig. 3 shows the solution space and the feasible solution space of our problem. The solution space is the area delimited by the dashed lines, which indicate the lower and upper bounds for cost and execution time of the business process. The lower bound CC for the execution cost is the cost obtained by selecting the cheapest service providers for each activity.
D.A. Menascé et al. / Performance Evaluation 67 (2010) 659–675
667
Algorithm 4 Compute the Optimal Solution 1: 2: 3: 4: 5: 6: 7: 8: 9: 10: 11: 12: 13: 14: 15: 16: 17: 18: 19: 20: 21: 22: 23: 24:
function OptimalSolution() reset (1); k ← 1; /* initialize activity pointers */ s ← AdvanceList (k); z ← s; /* initialize solution */ zopt ← any allocation in Z; while s 6= NULL do if k < N then if (L(E [R(z )]) ≤ Rmax ) and (C (z ) ≤ Cmax ) then k←k+1 else z ← z end if else if (E [R(z )] ≤ Rmax ) and (C (z ) ≤ Cmax ) then if E [R(z )] < E [R(zopt )] then zopt ← z end if end if z ← z end if
AdvanceList (k); z ← z ||s end while return zopt end function
Fig. 3. A conceptual representation of the solution space and of the feasible solution space. The plane coordinates are average execution time and execution cost.
Similarly, the upper bound RS for the average execution time can be obtained by selecting the slowest service provider for each business activity. On the contrary, the upper bound CE for the execution cost is obtained by selecting the most expensive service provider for each activity and the lower bound RF for the average execution time is obtained by selecting the fastest service provider for each activity. The feasible solution space is represented by the shaded area and is the portion of the solution space delimited by the lower bound for the average execution time and execution cost and by the time and cost constraints (bold lines). The proposed heuristic is based on the following idea (see Fig. 3). We start from the service selection z0 characterized by the lowest average execution time, i.e., the point (CE , RF ). Assume that this point is outside the feasible solution space and that the cost constraint is violated. To find a feasible solution as close as possible to the optimum, we have to choose a selection z 0 that moves the solution inside the shaded area, say the point (C 0 , R0 ). To choose the solution z 0 we replace the service provider that provides the highest reduction in the execution cost C with the lowest increase in the execution time R. To determine such a provider, we need to compute the ratio
∆i,j,j0 = pi ×
Ci,j − Ci,j0 Ri,j0 − Ri,j
j0 > j
(13)
668
D.A. Menascé et al. / Performance Evaluation 67 (2010) 659–675
for each activity ai (i = 1, . . . , N ). In Eq. (13), j represents the service provider allocated to activity ai , j0 represents an alternate service provider for ai , and pi is the probability that activity ai is executed in the business process. This probability is a function of the structure of the business process and its branching probabilities. For example, the probability that activity a4 is executed in the business process of Fig. 1 is q1 . We then select the activity for which there is an alternate provider that maximizes the value of the ratio for all such ratios. More precisely,
(k, m) = arg
max
i=1,...,N ;j0 6=j
∆i,j,j0
(14)
where k is an activity index, m is a service provider index for activity ak and skm is the service provider that should replace z (k) so that ∆i,j,j0 is maximized over all activities and possible service provider replacements. According to Eq. (14), the service provider m when replacing service provider j in activity k yields the maximum value for the ratios ∆. We then evaluate the execution cost and execution time for the new service selection z 0 . If the constraints are satisfied we have a suboptimal solution. Otherwise, there are two possibilities: if the cost constraint is still violated and the time constraint is not yet violated, we are at a point such as (C 00 , R00 ) and we have to repeat the above-mentioned process, i.e., the selection of a new service provider that maximizes the ratio ∆ among all activities. If the execution time constraint is violated but the cost constraint is satisfied, we are at point such as (C 000 , R000 ) and we cannot accept such solution as we would continue to violate the execution time constraint at any further attempt of cost reduction. Then, we select the service provider that has the second best ratio ∆. The process is repeated until a feasible solution is found. Algorithm 5 shows the detailed steps of the heuristic. Let L∆ be the set of ∆i,j,j0 for all activities ai and service providers sij and sij0 ∈ Si where j0 > j. Let z k s stand for the operation of removing from solution z provider s for activity k. Similarly, let z ⊕k s denote the addition to solution z of provider s to activity k. Algorithm 5 Heuristic Solution 1: 2:
function ComputeDeltaSet (z) returns (DeltaSet) 0 DeltaSet = {∆i,j,j0 , ∀ai , ∀sij and si 0 ∈ Si , and j > j}; j
3: 4:
return DeltaSet end function
5: 6: 7: 8: 9: 10: 11: 12: 13: 14: 15: 16: 17: 18: 19: 20: 21: 22: 23: 24: 25: 26: 27: 28: 29: 30:
function heuristic() Find z such that E [R(z )] = RF ; if (E [R(z )] ≤ Rmax ) and (C (z ) ≤ Cmax ) then return z end if L∆ = ComputeDeltaSet (z) while L∆ 6= ∅ do ∆k,j,j0 = max{L∆ }; s ← sk,j ; z ← z k s; z ← z ⊕k sk,j0 ; if E [R(z )] ≤ Rmax then if C (z ) ≤ Cmax then return z; else L∆ = ComputeDeltaSet (z) end if else z ← z k sk,j0 ; z ← z ⊕k s;
L∆ ← L∆ − {∆k,j,j0 }
end if end while return infeasible solution end function
Now we use the proposed heuristic to compute the suboptimal solution for the business process in Fig. 1 using the service providers listed in Table 1. Fig. 4 shows the solution space, the feasible region and the values for RF , CE , RS , CC , Rmax and Cmax . The steps in this example are given below for Rmax = 6, Cmax = 6, and q1 = q2 = 0.5:
• First assignment: (6.75, 5.648). zF = s11 s21 s31 s41 s51 s61 , which is the service selection with the lowest execution time E [R(zF )] = RF = 5.648 and C (zF ) = 6.75. This solution violates the cost constraint.
D.A. Menascé et al. / Performance Evaluation 67 (2010) 659–675
669
Fig. 4. An example of the evolution of the heuristic solution.
• Step I: (5.75, 6.148). L∆ = {∆112 , ∆113 , ∆212 , ∆412 , ∆512 , ∆513 } = {2, 1.0, 0.5, 0.5, 1.25, 1.07}. Then, max{L∆ } = ∆112 = 2 and the new assignment is z1 = s12 s21 s31 s41 s51 s61 , with a corresponding average execution time and cost equal to E [R(z1 )] = E [R(zF )] + 0.5 = 6.148 and C (z1 ) = C (zF ) − 1 = 5.75. This assignment has to be discarded because it violates the execution time constraint.
• Step II: (6.25, 5.848). Removing ∆112 from L∆ (line 26 of Algorithm 5) we obtain L0∆ = {∆113 , ∆212 , ∆412 , ∆512 , ∆513 }, max{L0∆ } = ∆512 = 1.25. Computing again the average execution time and execution cost for assignment z2 = s11 s21 s31 s41 s52 s61 , we obtain the new values for E [R(z2 )] = E [R(zF )] + 0.5 × 0.4 = 5.848 and C (z2 ) = C (zF ) − 1 × 0.4 = 6.25. • Step III: (5.25, 6.348). Because the previous solution still violates the cost constraint, we need to compute again L∆ (line 21), which becomes L00∆ = {∆112 , ∆113 , ∆212 , ∆412 , ∆523 } = {2, 1.0, 1.0, 0.5, 0.833} and max{l00∆ } = ∆112 = 2. The new solution, z3 = s12 s21 s31 s41 s52 s61 , does not violate the cost constraint but has an execution time of E [R(z3 )] = 6.348, which still violates the execution time constraint.
• Step IV: (4.25, 7.848). We remove ∆max = ∆112 obtaining L000 ∆ = {∆113 , ∆212 , ∆412 , ∆523 } = {1, 0.5, 0.5, 0.83}. ∆max is ∆113 and the new solution is z4 = s13 s21 s31 s41 s52 s61 with an execution time of E [R(z4 )] = 7.848, which violates the constraint.
• Step V: (6, 5.998). We need one more step, and we remove ∆113 from the L∆ obtaining L0000 ∆ = {∆212 , ∆412 , ∆523 } = {0.5, 0.5, 0.833}. ∆max is now ∆523 = 0.833 and the corresponding solution z5 = s11 s21 s31 s41 s53 s61 is acceptable: E [R(z5 )] = E [R(z2 )] + 0.5 × 0.3 = 5.998 and C (z5 ) = C (z2 ) − 0.5 × 0.5 = 6. Fig. 4 shows the evolution of the heuristic in the solution space and the optimal solution that is (Copt , Ropt ) = (6, 5.998). The solution z is evaluated six times (5 steps plus the initial selection for zF ). 5. Dealing with business processes with execution relationships The optimal and heuristic solution presented in Sections 3.5 and 4, respectively, only considered precedence relationships between activities of a business process. This section introduces another type of relationship between activities: execution relationship. It is possible that due to design, security, or other types of constraints, two or more activities have to be assigned to the same service provider. For example, one may want to use the same service provider to reserve a flight and to later book the same flight in a travel planning business process. We denote the execution relationship between activities ai and aj as ai , aj to indicate that they need to be executed by the same service provider. If ai , aj then for each feasible solution z = s1k s2k . . . sik . . . sjk . . . snkn , sik = sjk . That is, ki = kj .
z}|{ 1
z}|{
2
i
j
i
j
The formulation of the optimization problem now becomes min E [R(z )] subject to E [R(z )] ≤ Rmax C (z ) ≤ Cmax z∈Z z (i) = z (j) ∀1 ≤ i, j ≤ N s.t . ai , aj
z}|{
where z (i) and z (j) denote the ith and jth elements of z, respectively.
670
D.A. Menascé et al. / Performance Evaluation 67 (2010) 659–675
Algorithm 6 Function new_next 1: 2: 3: 4: 5: 6: 7: 8: 9: 10: 11: 12: 13: 14: 15: 16: 17: 18: 19:
function new_next (k) returns (s) h ← constraint (k); if h = 0 then return next (k) else if index (h, k) = 1 then return next (k) else s ← next (k) if s 6= NULL then /* set all execution-related activities to the same SP */ for j = 1 to (index (h, k)-1) do z (Ih (j)) ← s end for end if return s end if end if end function
An execution relationship can impact R(z ) and C (z ) because it reduces the size of the solution space. We assume in what follows that service providers are able to provision enough resources to support the execution of more than one activity. QoS brokers such as the one discussed in [17] can be used to guarantee QoS agreements. An immediate consequence of execution relationships is that if ai , aj then the sets of service providers Si and Sj have to be restricted to Si ∩ Sj because no service provider that supports only one of the activities can be used in any feasible solution.
z}|{
5.1. JOSeS algorithm with execution relationships We need some additional definitions as well as a redefinition of the
next (k) function defined in Section 3.5. Let z }| {
Eh = {ah1 , . . . , ahnh } be an ordered list of activities with an execution relationship ah1 , . . . , ahnh for h = 1, . . . , Nc where
Nc is the number of different execution relationships. We assume without loss of generality that h1 < h2 < · · · < hnh . Let Ih (k) be the index of the kth activity in Eh . Consider the following example to illustrate the notation. If a2 , a6 and a3 , a4 then E1 = {a2 , a6 }, E2 = {a3 , a4 }, Nc = 2, and I1 (2) = 6. We introduce the new function constraint (k) which returns 0 if ak has no execution relationship and returns h if there is h ∈ {1, . . . , Nc } such that ak ∈ Eh . Using the example above, constraint (6) = 1 and constraint (3) = 2. We also introduce the function index (h, k) which returns the index of activity ak in Eh . For example, index (1, 6) = 2. The use of the function next (k) that appears in line 2 of JOSeS algorithm has to be replaced by the function new_next (k) defined in Algorithm 6. As lines 2 through 4 of Algorithm 6 indicate, if there are no execution relationships (i.e., h = 0), new_next (k) returns the same result as next (k). If there is an execution relationship but activity k is the first in Eh (i.e., Eh = {ak , . . .}), then new_next (k) returns the same result as next (k) (see lines 6 and 7). When activity ak has a precedence relationship as indicated in Eh and ak is not the first in Eh then the next non-null provider is assigned to ak and all SPs assigned to activities in Eh that precede ak have to be set to the same SP assigned to ak because of the execution relationship (see lines 9 through 15). Thus, the only required modification to JOSeS algorithm to take into account execution relationships is the replacement of next (k) by new_next (k) in line 2. Let us now apply JOSeS algorithm with this modification to the business process in Fig. 1 with the set of service
z }| {
z }| {
providers in Table 1 with the execution constraints a2 , a6 and a3 , a4 . Consider also that Cmax = 4 and Rmax = 8 and that s11 = s21 = s31 = s41 = s51 = s61 = SP1, s12 = s22 = s42 = s52 = SP2, and s13 = s53 = SP3. Then, the set of feasible solutions is limited to Z = {z = z1 SP1 SP1 SP1 z5 SP1 s.t. z1 ∈ {s11 , s12 , s13 }, z5 ∈ {s51 , s52 , s53 }}. The optimal solution obtained with JOSeS algorithm is z = s13 s21 s31 s41 s53 s61 , E [R(z )] = 7.998 and C (z ) = 4. This is the unique service selection that satisfies time and cost constraints as well as the execution relationships. We illustrate below some of the key steps of the algorithm (line numbers refer to Algorithm 4).
z }| {
z }| {
• Step I. k = 1 and AdvanceList(1) returns s11 . z 1 = s11 and the condition at line 23 is satisfied. Then, at line 24, the algorithm increments the value of k (k = 2) and a service provider for activity a2 is selected. AdvanceList(2) returns s21 and z 2 ← z 1 k s21 (line 37). • Step II. Execution time E [R(z )] and cost C (z ) are evaluated at line 23. The constraints are satisfied and k is increased to 3. AdvanceList(3) is computed and z 2 becomes z 3 = s11 s21 s31 .
D.A. Menascé et al. / Performance Evaluation 67 (2010) 659–675
671
• Step III. The evaluation of the partial solution z 3 at line 23 results in a cost constraint violation because C (z ) = 4.25.
• • • • •
• •
Then, at line 26 the last assignment is removed from z 3 and a new service provider is computed at line 36. When AdvanceList(3) is computed, new_next(3) returns null because no more service providers are available, then z 1 = z 2 = s11 and AdvanceList(2) is recursively computed. Because of the execution constraint, new_next(2) returns null, then s11 is removed from z 1 (line 7) and AdvanceList(1) is evaluated again obtaining z 1 = s12 . Step IV. C (z ) and E [R(z )] for the new partial solution z 1 = s12 are evaluated (line 23) and k is increased to 2 at line 24. AdvanceList(2) is computed and again s21 is selected. Three more steps (Step V to Step VII) allow to build the partial solution z 5 = s12 s21 s31 s41 s51 . Step VIII. C (z ) = 4.5 then z 4 = z 5 (line 26) and a new selection for a5 is evaluated. AdvanceList(5) returns s52 and z 5 = s12 s21 s31 s41 s52 . Step IX. C (z ) = 4, then k = 6 and AdvanceList(6) selects service provider s61 for activity a6 . Step X. The final selection is evaluated at line 29. E [R(z )] = 6.348, C (z ) = 5.25 ≥ Cmax , then the last selection is removed (line 34) and AdvanceList(6) is invoked (line 36). AdvanceList rolls back and recursively returns s = s53 that is concatenated to the partial solution z 5 = s12 s21 s31 s41 s53 (line 37). Step XI. C (z ) = 3.75. Then, AdvanceList(6) can be computed again and z 6 = z 5 k s61 . Step XII. C (z ) = 4.75, z 5 = z 6 (line 34) and AdvanceList(6) starts the roll-back. This time, no more service selections are available, nor for a5 neither for a2 , a3 , and a4 . Then, the algorithm rolls back to a new assignment for a1 .
The above steps are repeated until the final solution is obtained. 5.2. Adapting the heuristic to execution relationships A few minor modifications are required to take into account execution relationships in the heuristic solution presented above. Operations z k s and z ⊕k s are redefined as follows. If constraint (k) = 0 then z k s removes the assignment of provider s for activity ak . Otherwise (i.e., h > 0), z k s removes the assignment of s from all activities in Eh . Similarly, if constraint (k) = 0 then z ⊕k s assigns provider s to activity ak . Otherwise, (i.e., h > 0), z ⊕k s assigns s to all activities in Eh . 6. Experiments We implemented the heuristic and the optimal JOSeS algorithm to conduct experiments aimed at evaluating the efficiency of the former. In particular, we wanted to: (1) determine how close the heuristic solution is to the optimal, (2) compare the number of points in the solution space examined by each algorithm, (3) compare both algorithms over a wide range of parameters including the complexity of the business process topology, the tightness of the response time and cost constraints, and the number of SPs per activity. 6.1. Description of the experiments Fifty business processes were randomly generated as BPEL files and Algorithms 1 and 2 were applied, respectively, to each file to generate the expression for average execution time and execution cost. The process for the generation of business processes determined randomly when to generate sequences, flows, switches (and their switching probabilities) as well as the number of branches of flows and switches. No execution relationships were considered in these experiments. We used XMLBeans (http://xmlbeans.apache.org) to convert the BPEL schema into a Java package to help generate random instances of BPEL business processes. The number of activities for the randomly generated business processes varied from 6 to 11. The number of flows and switches in these business processes varied in the range zero to three and zero to two, respectively. The SAX parser was used to process the BPEL files. The experiments assumed that the execution time of each service provider s is exponentially distributed with an average execution time equal to E [Rs ] specified in Table 2 for each service provider. The cost of obtaining an average execution time E [Rs ] from service provider s was assumed to be equal to 1/E [Rs ]. In other words, the cost decreases with the inverse of the average service time offered by a service provider. For each experiment, the number of SPs per activity, denoted by nspa, was the same for all activities and varied as follows: 2, 3, 4, 5, 6, and 7. The complexity C (p) of a business process p is defined as
C (p) = #activities + #flows +
X
fanouti
(15)
∀ switch i
using an adapted version of the control flow complexity and other metrics discussed in [26]. After all business processes are generated, we compute for each normalized complexity C 0 (p) as follows
C 0 (p) =
C (p) − min C (s) ∀s
max C (s) − min C (s) ∀s
.
∀s
It can be easily seen that 0 ≤ C 0 (p) ≤ 1 for any process p.
(16)
672
D.A. Menascé et al. / Performance Evaluation 67 (2010) 659–675
Table 2 Sets of service providers for the execution of business activities a1 –a12 . SP
E [R ]
C
SP
E [R ]
C
SP
E [R]
C
1 1 1 1 1 1 1
1 2 3 4 5 6 7
1.5 2.0 2.5 3.0 3.5 4.0 4.5
0.67 0.50 0.40 0.33 0.29 0.25 0.22
2 2 2 2 2 2 2
1 2 3 4 5 6 7
1.0 1.5 2.0 2.5 3.0 3.5 4.0
1.0 0.67 0.50 0.40 0.33 0.29 0.25
3 3 3 3 3 3 3
1 2 3 4 5 6 7
2.0 2.5 3.0 3.5 4.0 4.5 5.0
0.50 0.40 0.33 0.29 0.25 0.22 0.20
4 4 4 4 4 4 4
1 2 3 4 5 6 7
0.7 1.2 1.7 2.2 2.7 3.2 3.7
1.43 0.83 0.59 0.45 0.37 0.31 0.27
5 5 5 5 5 5 5
1 2 3 4 5 6 7
0.8 1.2 1.5 1.8 2.1 2.4 2.7
1.25 0.83 0.67 0.56 0.48 0.42 0.37
6 6 6 6 6 6 6
1 2 3 4 5 6 7
2.3 2.7 3.1 3.5 3.9 4.3 4.7
0.43 0.37 0.32 0.29 0.26 0.23 0.21
7 7 7 7 7 7 7
1 2 3 4 5 6 7
1.9 2.4 2.9 3.4 3.9 4.4 4.9
0.526 0.416 0.344 0.294 0.256 0.227 0.204
8 8 8 8 8 8 8
1 2 3 4 5 6 7
1.4 1.9 2.4 2.9 3.4 3.9 4.4
0.714 0.526 0.416 0.345 0.294 0.256 0.227
9 9 9 9 9 9 9
1 2 3 4 5 6 7
2.4 2.9 3.4 3.9 4.4 4.9 5.4
0.416 0.345 0.294 0.256 0.227 0.204 0.185
10 10 10 10 10 10 10
1 2 3 4 5 6 7
1.1 1.6 2.1 2.6 3.1 3.6 4.1
0.909 0.625 0.476 0.385 0.323 0.277 0.244
11 11 11 11 11 11 11
1 2 3 4 5 6 7
1.2 1.6 1.9 2.2 2.5 2.9 3.1
0.833 0.625 0.526 0.455 0.40 0.345 0.323
12 12 12 12 12 12 12
1 2 3 4 5 6 7
2.7 3.1 3.5 3.9 4.1 4.7 5.1
0.370 0.323 0.286 0.256 0.204 0.213 0.196
ai
ai
ai
We then apply the k-means, with k = 3, clustering algorithm on all business processes using |C 0 (p) − C 0 (q)| as the distance between business processes p and q. The business processes in the cluster with the smallest centroid are called simple business processes, the ones in the cluster with the largest centroid are called complex, and the remaining ones medium business processes. This clustering process resulted in 8% complex, 62% medium, and 30% simple processes. The centroids of these clusters are 0.82, 0.52, and 0.24, respectively. For a given business process p and for a given number of SPs per activity, we compute the coordinates of the feasibility region (CC , RF ), (CE , RF ), (CC , RS ), and (CE , RS ). We then compute three sets of values for the constraints Rmax and Cmax according to how tight they are. We call them strict, medium, and relaxed constraints, and their values are: Cmax = CC + 2.5 (CE − CC )/6 for tight, Rmax = RF + (RS − RF )/3
for tight,
Cmax = CC + (CE − CC )/2
for medium,
Rmax = RF + (RS − RF )/2
for medium,
Cmax = CE − (CE − CC )/6
for relaxed, and
Rmax = RS − (RS − RF )/6
for relaxed.
Details about how the experiments were conducted are shown in Algorithm 7. All the data were collected in a relational database and several analyses were carried out as reported in the following section. 6.2. Results of the experiments The following metrics are used to evaluate the proposed heuristic.
• εR : absolute relative percentage average execution time difference defined as εR = 100 ×
|Rh − Ro | Ro
(17)
where Rh and Ro are the average execution times obtained using the heuristic and JOSeS algorithm, respectively.
• εC : absolute relative percentage average execution cost difference defined as εC = 100 ×
|Ch − Co | Co
where Ch and Co are the average execution costs obtained using the heuristic and JOSeS algorithm, respectively.
(18)
D.A. Menascé et al. / Performance Evaluation 67 (2010) 659–675
673
The results of the 735 experiments that were executed show that: 1. the average value of εR was 2.37% ± 0.21% with a 95% confidence level, i.e., the heuristic produced solutions that are less than 2.5% worse, on average, than the optimal solution in terms of average execution time; 2. the average value of εC was 1.49% ± 0.12% with a 95% confidence level and, on average, the execution cost of the heuristic solution was 2.4% below the cost constraint; 3. the number of points examined by JOSeS algorithm ranged from 44 to 60,466,164 with an average of 2885,323 while the same value for the heuristic algorithm ranged from 2 to 38 with an average of 6.35; and 4. the execution time for JOSeS algorithm ranged from 8.8 ms to 21 h and the execution of the heuristic solution ranged from 0.11 ms to 38.2 ms. These experiments were run on a machine with an Intel Core i7-920 2.66 GHz processor. These results clearly indicate that the heuristic algorithm was able to produce service provider allocations that result in execution times that are only a few percentage points (less than 2.5% on average) worse than the allocations obtained by the optimal algorithm while examining a tiny fraction of the solution space (tens of points versus millions of points). In order to verify the impact of the tightness of the constraints and of the number nspa of SPs per activities we conducted a 2-factor ANOVA (Analysis of Variance) on εR where the levels of the tightness factor are relaxed, medium, and tight and the levels of nspa are 2, 3, 4, and 5. We wanted to verify the following hypotheses:
• Null hypotheses (H0t ): the average value of εR is the same for each tightness level at a 95% confidence level. • Null hypotheses (H0n ): the average value of εR is the same for each values of nspa at a 95% confidence level. • Null hypotheses (H0t ,n ): there is no interaction between the factors. The results of the 2-factor ANOVA indicate that: all three null hypotheses above are rejected at the 95% level. This means that, at the 95% confidence level, the average value of εR is not independent of the tightness, nor of the number of SPs per activity. Besides, these two factors interact with one another. Fig. 5 displays the average value of R for the three execution time constraint levels (relaxed, medium, and tight) and for nspa = 2, 3, 4, and 5. The figure also displays 95% confidence intervals, which confirm the 2-factor ANOVA results. The figure shows that the value of R increases with the number of SPs per activity. This is due to the fact that the size of the state space grows exponentially with the number of SPs per activity and therefore it is more likely that the heuristic will not find a solution as close to the optimal. For relaxed constraints, the number of feasible solution points that the heuristic can evaluate is typically very large. Then, the probability of the heuristic finding a solution close to the optimum is smaller than that in the other cases, as indicated in Fig. 5. For tight constraints, the number of feasible solutions is very limited and also the distance between the feasible solutions and the optimal solution tends to be small. This motivates a small value of R with respect to medium constraints. In the latter case, it is possible that the heuristic algorithm finds an allocation that is feasible and sub-optimal but not as close to the optimum. Because of the limited number of feasible solutions in the solution space, as compared to the relaxed constraint case, the heuristic algorithm cannot find better solutions. At any rate, even in the most unfavorable situation depicted in the figure, i.e., nspa = 5 and medium constraints, the average value of εR is equal to 4.83% ± 1.06% at a 95% confidence level. This difference with respect to the optimal solution is still very small, especially when one takes into account the fact that the heuristic solution is obtained at a very small fraction of the computational cost. Fig. 6 explores the sensitivity of εR with respect to the complexity of the business process. The figure shows the average value of εR for simple, medium, and complex processes and for 2, 3, 4, and 5 SPs per activity. The graph also shows 95% confidence intervals for the average. As in the previous figure, as the number of SPs per activity increases, εR increases due to the increase in the size of the solution space. The figure also shows that in general, more complex business processes Algorithm 7 Experiments 1: 2: 3: 4: 5: 6: 7: 8: 9: 10: 11: 12: 13: 14: 15: 16: 17:
function Experiments() /* NBP: no. of business processes generated */ /* nspa: no. of business processes per activity */ for np = 1 to NBP do Generate a random business process p; Compute the complexity of the business process; Save the description of p in a database; for nspa ∈ {2, 3, 4, 5, 6, 7} do Compute Rs , RF , Cc , and CE for all (Cmax , Rmax ) ∈ {Relaxed, Medium, Tight } do Run JOSeS Algorithm on p; Run the Heuristic algorithm on p; Save the results of both runs in a database end for end for end for end function
674
D.A. Menascé et al. / Performance Evaluation 67 (2010) 659–675
Relative % execution time difference
7.0 6.0 5.0 4.0 3.0 2.0 1.0 0.0
2
3 4 No. SPs per activity relaxed
medium
5
tight
Relative % execution time difference
Fig. 5. Average value of εR vs. nspa for the three values of the constraint tightness.
6.0 5.0 4.0 3.0 2.0 1.0 0.0
2
3
4
5
No. of SPs Simple
Medium
Complex
Fig. 6. Average value of εR vs. nspa for simple, medium, and complex business processes.
imply in higher values for εR . But, for 4 and 5 SPs per activity, there is no significant difference at the 95% confidence level between medium and complex processes. 7. Concluding remarks The SOA model brings several new benefits to software design and architecture by enabling re-use and sharing of components through dynamic discovery. Service composition enables complex applications to be put together in a variety of ways. Each possible selection of services brings different levels of QoS and cost. Thus, there is a need to devise fast and efficient mechanisms that can be used for dynamic service selection among a set of service providers. This paper examined how service providers can be optimally allocated to support activities of business process with topologies that can include any combination of sequences, flows, and switches. The optimization problem in this case deals with finding an allocation that minimizes the average execution time of the business process subject to execution and cost constraints. The paper presented an extremely efficient heuristic algorithm that can find an allocation of service providers that is only a few percentage points worse than the optimal (less than 2.5% worse on average for the 735 cases examined) while examining a very tiny fraction of the solution space (tens of points versus tens of millions of points). The solution provided in this paper also covers the important case of execution constraints, i.e., a set of activities of a business process has to be allocated to the same service provider due to the logic of the business process. The reader will note that, even though the paper used BPEL constructs and examples, the approach and algorithms presented here are independent of the language used to express a business process. The approach presented in this paper did not explicitly consider communication times between activities of a business process. If these communication times are significant relative to the execution time of the activities of a business process, they need to be taken into account. While this is beyond the scope of this paper, we envision extensions of our approach in which communication activities are inserted between any two business process activities.
D.A. Menascé et al. / Performance Evaluation 67 (2010) 659–675
675
Acknowledgement This work is partially supported by grant CCF-0820060 from the National Science Foundation. References [1] [2] [3] [4] [5] [6] [7] [8] [9] [10] [11] [12] [13] [14] [15] [16] [17] [18] [19] [20] [21] [22] [23] [24] [25] [26]
M.B. Blake, Decomposing composition: Service oriented software engineers, IEEE Software (Nov.) (2007) 68–77. J. Bosch, Service orientation in the enterprise, IEEE Computer (Nov.) (2007) 51–56. F. Curbera, Component contracts in Service Oriented Architectures, IEEE Computer (Nov.) (2007) 74–80. M. Kaiser, Towards the realization of policy-oriented enterprise management, IEEE Computer (Nov.) (2007) 51–56. O. Nano, A. Zisman, Realizing service-centric software systems, IEEE Software (Nov.) (2007) 28–30. M.P. Papazoglou, et al., Service-oriented computing: State of the art and research challenges, IEEE Computer (Nov.) (2007) 38–45. T. Davenport, Process Innovation: Reengineering Work Through Information Technology, Harvard Business School Press, Boston, 1993. M. Hammer, J. Champy, Reengineering the Corporation: A Manifesto for Business Revolution, Harper Business, 1993. H.J.E. Johansson, Business Process Reengineering: BreakPoint Strategies for Market Dominance, John Wiley & Sons, 1993. M. Papazoglou, Web Services: Principles and Technology, Prentice Hall, 2008. Web Service — Business Process Execution Language (WS BPEL), Version 2.0 - OASIS Committee Draft, 17th May, 2006. D. Ardagna, B. Pernici, Global and local QoS guarantee in web service selection, in: Proc. of Business Process Management Workshops, 2005, pp. 32–46. R. Berbner, M. Spahn, N. Repp, O. Heckmann, R. Steinmetz, Heuristics for QoS-aware web service composition, in: Proc. Int’l Conf. on Web Services, Sept. 2006. G. Canfora, M. Di Penta, R. Esposito, M.L. Villani, An approach for QoS-aware service composition based on genetic algorithms, in: Proc. Genetic and Computation Conf., June 2005. V. Cardellini, E. Casalicchio, V. Grassi, L.P. Francesco, Flow-based service selection for web service composition supporting multiple qos classes, in: ICWS 2007. IEEE Intl. Conf. Web Services, July 9–13, 2007, pp. 743–750. D.A. Menascé, V. Dubey, Utility-based QoS brokering in service oriented architectures, in: IEEE 2007 Intl. Conf. Web Services, ICWS 2007, Application Services and Industry Track, Salt Lake City, Utah, July 9–13, 2007, pp. 422–430. D.A. Menascé, H. Ruan, H. Gomma, QoS management in Service Oriented Architectures, Performance Evaluation Journal 64 (7-8) (2007) 646–663. T. Yu, K.J. Lin, Service selection algorithms for composing complex services with multiple QoS constraints, in: Proc. of 3rd Int’l Conf. on Service Oriented Computing, Dec. 2005, pp. 130–143. L. Zeng, B. Benatallah, A.H.H. Ngu, M. Dumas, J. Kalagnanam, H. Chang, QoS-aware middleware for web services composition, IEEE Transactions on Software Engineering 30 (5) (2004) 311–327. M. Jaeger, G. Muhl, S. Golze, Qos-aware composition of web services: A look at selection algorithm, in: Proc. 2005 IEEE Intl. Conf. Web Services, ICWS05, 2005. M.A. Serhani, R. Dssouli, A Hafid, H. Sahraoui, A QoS broker based architecture for efficient web service selection, in: Proc. 2005 IEEE International Conference on Web Services, ICWS05, 2005. D.A. Menascé, E. Casalicchio, V. Dubey, A heuristic approach to Optimal Service Selection in service oriented architectures, in: ACM Workshop on Software and Performance, Princeton, NJ, June 23–26, 2008. H. David, Order Statistics, John Wiley & Sons, 1981. R.E. Ziemer, W.H. Tranter, D.R. Fannin, Signals & Systems: Continuous and Discrete, fourth ed., Prentice Hall, Upper Saddle River, NJ, 1998. R. Nelson, Probability, Stochastic Processes, and Queueing Theory, Springer-Verlag, 1995. J. Cardoso, J. Mendling, G. Neumann, H.A. Reijers, A discourse on complexity of process models, in: J. Elder, et al. (Eds.), BPM 2006 Workshops, in: LNCS, vol. 4103, Springer Verlag, Berlin, Heidelberg, 2006, pp. 115–126.
Daniel A. Menascé is the Senior Associate Dean and a Professor of Computer Science at the Volgenau School of Information Technology and Engineering at George Mason University, Fairfax, Virginia. He received a Ph.D. in Computer Science from the University of California at Los Angeles. He is a Fellow of the ACM, a senior member of the IEEE, and a member 7.2. He received the 2001 A.A. Michelson Award from the Computer Measurement Group. Menascé is the author of over 195 papers and five books. His current research interests include autonomic computing, e-commerce, performance analysis, and software performance engineering. His research has been funded by several organizations including the National Science Foundation, NASA, and DARPA. Menascé consulted for several US government agencies and several large companies.
Emiliano Casalicchio is a Researcher at the University of Roma ’’Tor Vergata,’’ Italy, from where he received a Ph.D in Computer Science in 2002. His research interests in design, modeling, and performance evaluation (e.g., Service Oriented Architectures, Web systems and Grid systems) and on critical complex systems modeling and simulation (e.g., critical infrastructures and interdependency analysis). He is the author of more than fifty publications on international journals and conferences and has been involved in many Italian and EU research projects (e.g., PERF, CRESCO, DIESIS, MOBI-DEV, AEOLUS, DELIS, SMS).
Vinod Dubey is an Associate at Booz Allen Hamilton in McLean, Virginia, USA. He is also a Ph.D. candidate in Information Technology at The Volgenau and Engineering at George Mason University, Fairfax, Virginia. He received an MS in Information Systems from George Mason and he received a doctoral fellowship award from the Computer Measurement Group. His research interests include system performance engineering, services computing, business process management, and QoS management in Service Oriented Architectures.