QoS-driven Runtime Adaptation of Service Oriented Architectures

Transcription

1 Qo-driven Rntime Adaptation of ervice Oriented Architectres Valeria ardellini 1 Emiliano asalicchio 1 Vincenzo Grassi 1 Francesco Lo Presti 1 Raffaela Mirandola 2 1 Dipartimento di Informatica, istemi e Prodzione, Università di Roma Tor Vergata, Roma, Italy {cardellini, casalicchio, vgrassi, lopresti}@disp.niroma2.it 2 Dipartimento di Elettronica e Informazione, Politecnico di Milano, Milano, Italy mirandola@elet.polimi.it ABTRAT Rntime adaptation is recognized as a viable way for a serviceoriented system to meet Qo reqirements in its volatile operating environment. In this paper we propose a methodology to drive the adaptation of sch a system, that integrates within a nified framework different adaptation mechanisms, to achieve a greater flexibility in facing different operating environments and the possibly conflicting Qo reqirements of several concrrent sers. To determine the most sitable adaptation action(s), the methodology is based on the formlation and soltion of a linear programming problem, which is derived from a behavioral model of the system pdated at rntime by a monitoring activity. Nmerical experiments show the effectiveness of or approach. Besides the methodology, we also present a prototype tool that implements it. ategories and bject Descriptors D.2.11 [oftware Engineering]: oftware Architectres ;.4 [Performance of ystems]: Modeling Techniqes General Terms Management, Performance, Reliability Keywords ervice-oriented architectre, rntime adaptation, qality of service. 1. INTRODUTION ervice Oriented architectre (OA) is emerging as a paradigm for the design of complex software systems, which encorages the realization of new software systems by composing network-accessible loosely-copled services. According to this paradigm, the development focs shifts from activities concerning the in-hose cstom Permission to make digital or hard copies of all or part of this work for personal or classroom se is granted withot fee provided that copies are not made or distribted for profit or commercial advantage and that copies bear this notice and the fll citation on the first page. To copy otherwise, to repblish, to post on servers or to redistribte to lists, reqires prior specific permission and/or a fee. EE-FE 09, Agst 23 28, 2009, Amsterdam, The Netherlands. opyright 2009 AM /09/08...$ design and implementation of the system components, to activities concerning the identification, selection, and composition of services offered by third parties. These activities are driven by the goal of flfilling both the fnctional reqirements concerning the overall bsiness logic that mst be implemented and the non-fnctional reqirements concerning the qality of service (Qo) levels that shold be garanteed by the system. Achieving this goal in a OA environment is a challenging task, mainly becase of its dynamic and npredictable natre. To cope with this problem, a generally accepted idea is that a OA system shold be able to dynamically self-adapt to the changing conditions of its operating environment. everal methodologies have been proposed in the literatre for this prpose (e.g., [2, 5, 15, 20, 21, 26]), concerning the flfillment of fnctional or non-fnctional reqirements. In this paper, we present MOE (MOdel-based Elf-adaptation of OA systems), a methodology and a prototype tool aimed at driving the self-adaptation of a OA system to flfill non-fnctional Qo reqirements sch as system performance, reliability, and cost. Devising Qo-driven adaptation methodologies of OA systems is of tmost importance in the envisaged service marketplace, where different services may co-exist implementing the same fnctionality (we refer to the former as concrete services and the latter as abstract service). These competing services are differentiated by their Qo, ths allowing a prospective ser to choose the services that best sit his/her Qo reqirements. Hence, being able to deliver and garantee the Qo level reqired by a given class of sers may bring competitive advantage to a service provider over other providers. In this respect, it is generally assmed in the OA environment that the service provider and ser engage in a negotiation process, which clminates in the definition of a ervice Level Agreement (LA) concerning their respective obligations and expectations abot Qo [21]. Most of the proposed methodologies for Qo-driven adaptation of OA systems address this problem as a qestion concerning which services shold be sed (service selection problem): given the set of abstract services needed to compose a new added vale service, the goal is to identify for each abstract service a corresponding single concrete service, selecting it from a set of candidates (e.g., [2, 5, 7, 11, 21, 27]). When the operating conditions change (e.g., a selected concrete service is no longer available, or its delivered Qo has changed, or the ser Qo reqirements have changed), a new selection can be calclated and the abstract ser-

2 vices which compose the OA system are dynamically bond to a new set of concrete services. However, it may happen that, nder a specific operating condition, no selection exists of single concrete services allowing the flfillment of the Qo reqirements. In this case, adaptation methodologies based only on service selection fail to meet their objective, which cold case a loss of income and/or reptation for a service provider. To overcome this problem, with MOE we propose to broaden the range of the considered adaptation mechanisms, by exploiting the availability in a OA environment of mltiple independent implementations of the same fnctionality. Rather than considering only the binding of each abstract service to one single concrete service that implements it, MOE can more generally bind each abstract service to a set of fnctionally eqivalent concrete services, coordinated according to some spatial redndancy pattern (e.g., 1- ot-of-n redndancy, seqential retry). In this way, MOE may achieve Qo levels (concerning reliability and, in some cases, performance) that cold not be achieved otherwise, ths increasing the flexibility of a provider in facing a broader range of Qo reqirements and volatile operating conditions. The service selection mechanism considered in other papers ths becomes a special case of this more general mechanism, when the cardinality of the identified set of concrete services is eqal to one. Of corse the advantage achieved in this way shold be weighed against the higher cost cased by the se of mltiple concrete services. Hence, the basic idea nderlying MOE is that, besides asking which concrete services shold be bond to the abstract services sed to compose a OA system, we shold also ask how to se them to meet the Qo reqirements. To achieve the adaptation goal, the MOE framework relies on the se of a sitable model of the OA system to be adapted, which is kept p to date at rntime by a monitoring activity. This model is dynamically sed to calclate a re-arrangement of the available concrete services (i.e., a new answer to the which and how qestions), to se at best these services each time a relevant change is detected in the operating environment. The appropriate adaptation actions sed at rntime by MOE are determined by solving a Linear Programming optimization problem, whose formlation allows s to efficiently cope with a fast changing operating environment. The remainder of the paper is organized as follows. In ection 2 we present an overview of the MOE framework, which is then detailed in the next sections. In ection 3 we describe how we model within the MOE framework an adaptable OA system, and the related model that MOE maintains at rn time to spport the application of the adaptation methodology. Based on these models, in ection 4 we present the formlation of an optimization problem that is solved within the MOE framework. Then, in ection 5 we present the prototype tool that implements or methodology, and nmerical experiments that illstrate the kind of adaptation directives issed by MOE. In ection 6 we discss related works. Finally, in ection 7 we give some conclsions and sggestions for ftre work. 2. THE MOE APPROAH Devising an adaptation methodology strongly depends on the assmptions made abot the scenario where it will operate. Different assmptions may lead to different formlations of the problem to be solved, and corresponding soltion methodologies. In this respect, MOE focses on a scenario where several sers address a relatively sstained traffic of reqests to a OA system architected as a composite service. Each ser may have its own Qo reqirements, and negotiates a corresponding LA with the system. In this scenario, we assme that the Qo reqirements stated in the LA concern the average vale of Qo attribtes calclated over all the reqests belonging to a flow generated by a given ser. Within this scenario, the goal of MOE is to dynamically adapt the implementation of the OA system it manages, to meet the (possibly conflicting) per-flow Qo reqirements of several sers. Figre 1 shows the core elements of the MOE framework, their overall organization and their mapping onto the Monitor-Analyze- Plan-Execte (MAPE) model of adaptation proposed within the Atonomic ompting framework [16]. In this perspective, MOE can be seen as an instantiation of this model for the OA domain. MAPE model MOE approach Rntime Off line Monitor Analyze Plan Execte Rntime monitoring Monitored parameters Modeling Workflow validation and model generation Workflow (BPEL, ) Adaptation mechanisms Adaptation actions Figre 1: The MOE approach. Implementation The MOE inpt consists of the description of the composite service in some sitable workflow orchestration langage (e.g., BPEL [22]), and the set of candidate concrete services implementing the reqired fnctionalities (inclding the parameters of their LAs). At present, MOE relies on external entities for the definition of the workflow, the identification of the candidate concrete services and the negotiation with them of sitable LAs. The received workflow description is checked against a model of the class of OA systems MOE is able to manage, to verify whether it belongs to this class. In the positive case, MOE bilds a behavioral model of the composite service, and passes it to the rntime adaptation modles. As a first step to carry ot rntime adaptation, MOE ses the behavioral model to bild the template of an optimization problem. The parameters vales for this problem are derived from the parameters of the LAs negotiated with the composite service clients and providers, and from a monitoring activity. As detailed in ection 5, this latter activity is partly implemented within MOE itself, and partly relies on third party services. Besides maintaining p to date the parameters of the optimization problem, the monitoring activity checks and notifies whether some relevant change occrs in the composite service environment. hanges to be tracked inclde the arrival/departre of a client with the associated LA, an observed variation in the LA parameters of the constitent concrete services, and the addition/removal of a concrete service from the set of available concrete services. Upon receiving from the monitoring service a notification of a significant variation of the model parameters, MOE finds ot whether an adaptation action mst be performed. To this end, it

3 bilds a new instance of the optimization problem, with the new vales of the parameters. The calclated soltion provides indications abot the adaptation actions that mst be performed to optimize the se of the available resorces (i.e., the concrete services) with respect to some tility criterion, within the constraints defined by the existing LAs. Based on this soltion, MOE isses sitable directives to its implementation modle, so that ftre concrete instances of the composite service workflow will be generated according to these directives. We detail in ections 3 and 4 the kind of directives generated by MOE, and in ection 5 a prototype implementation. Table 1: Workflow composition patterns. Rle Meaning seq( + ) seqential exection of the services in + loop() repeated exection of the service sel( + ) conditional selection of one service in + par_and( + ) concrrent exection of the services in + (with complete synchronization) 3. MODELING OF AN ADAPTABLE OA YTEM 3.1 Architectral Model We se a two level grammar to model the kind of OA system MOE refers to, and to illstrate some basic concepts of the MOE methodology 1. The two levels of the grammar reflect a separation of concerns between two different roles: the first level concerns the role of composition manager, whose goal is the specification of the bsiness process. Within MOE, this level is only sed to check whether the orchestration pattern of an actal OA system matches the kind of patterns MOE is able to manage and, in the positive case, to spport the constrction of a sitable model. Other isses concerning this first level are ot of the MOE scope. The second level concerns the role of adaptation manager, whose goal (in or approach) is to determine for each abstract service, which concrete services shold be sed to implement it and how they shold be sed, to meet the Qo reqirements in a volatile operating environment. MOE specifically focses on this second role and its implementation in a OA system. The first level is defined as follows: ::= seq( + ) loop() sel( + ) par_and( + ) ::= m In this definition, denotes a composite service, 1, 2,..., m denote abstract services (i.e., fnctionalities needed to compose a new added vale service), and + denotes a list of one or more services. Hence, MOE crrently encompasses composite services consisting either of a single service, or of the orchestration of other services according to the composition rles: seq, loop, sel, par_and. Table 1 smmarizes the intended meaning of these rles. We point ot that the above grammar is prposely abstract, as it intends to specify only the strctre of the considered composite services. Details sch as how to express the terminating condition for a loop are therefore omitted. The grammar does not captre all the possible strctred orchestration patterns (a broader set is presented, for example, in [4]), bt incldes a significant sbset. Figre 2 shows an example of orchestration pattern described as a UML2 activity diagram, and the corresponding instance generated by the first level of the grammar. The second level consists of a set of prodction rles for each abstract service i considered at the first level (1 i m), defined 1 We point ot that or se of the term two level grammar has no relationship with the homonimos concept sed in formal langage theory (e.g., Van Wijngaarden grammar). as follows: Figre 2: A MOE-compliant workflow. i ::= switch(p + i ) P i ::= single(k i) (K + i ) par_or(k + i ) K i ::= k i1 k i2... k ini In this definition, k i1, k i2,..., k ini denote fnctionally eqivalent concrete services that have been identified as candidates to implement the abstract service i, and K + i is an ordered list of one or more of sch concrete services. If K + i consists of more than one concrete service, these services mst be coordinated according to a coordination pattern P i. More than one pattern can be sed to get an overall implementation of i. Hence, the implementation of i consists in general of a switch that, for each invocation of i, selects one of the patterns listed in P + i. At present, the MOE framework incldes three coordination patterns, denoted as single, and par_or. Table 2 smmarizes their intended meaning. Besides the simple single pattern (where a single concrete service implements i), the other two patterns se mltiple concrete services to improve some Qo attribtes of the i implementation with respect to the single pattern, as it will be explicitly shown in the next sbsection. Rle single(k i) (K + i ) par_or(k + i ) Table 2: oordination patterns. Meaning exection of a single concrete service seqential (ernate) exection of the concrete services listed in K + i, ntil either one of them sccessflly completes, or the list is exhasted concrrent exection of the concrete services in (with 1 ot of n synchronization) K + i The two levels of the grammar define together the class of OA systems managed by MOE. Given a composite service whose bsiness logic corresponds to an instance generated by the first level rles, different combinations of the second level rles lead

4 to different implementations, each characterized by different vales of its overall Qo attribtes. Hence, from the perspective of the strctral model presented in this section, the goal of the MOE framework is to determine at each change of the operating environment, which second level prodction rles shold be sed to bind each abstract service to a sitable implementation (and how possibly switch different reqests in a flow among them, if more than one implementation is selected), to meet the Qo objectives in the new environment. To achieve this goal, a key point is to calclate the vale of the overall Qo attribtes for each implementation corresponding to an instance generated by the two level grammar. In the next sbsection we present the behavioral model sed within MOE for this prpose. 3.2 Behavioral and Qo Model The overall Qo of a composite service implementation depends on the Qo of the concrete services that have been bond to the abstract services, on the way they are orchestrated, and on the sage profile of those services for a given class of sers: a rarely invoked service has obviosly a smaller impact on the overall Qo than a freqently invoked one, and different sers may invoke the same services with different freqencies 2. For each ser U (where U denotes the set of the considered sers), we model its sage profile by a labeled syntax tree. The syntax tree describes the first level prodction rles sed to generate the composite service logical strctre. Each leaf node of this tree (corresponding to an abstract service i) is labeled by Vi, the average nmber of times i is invoked for each reqest addressed to the composite service. MOE performs a monitoring activity to keep p to date the Vi vales. Figre 3 shows the sage profile model maintained by MOE for the composite service depicted in Figre 2. V1 1 seq loop par_and 2 3 V2 V4 V3 seq 4 V5 5 sel 6 Figre 3: Usage profile model. With this model, the Vi vales labeling the leaf nodes can be sed to weigh the Qo of each i implementation, while the nonterminal nodes of the syntax tree can be sed to specify rles that combine these weighted Qo s to get the overall Qo. The definition of both the Qo weight and composition rles depend on the considered Qo attribtes. MOE presently considers the following Qo attribtes: the expected response time R, which is the average time needed to flfill a ser- reqest for the composite service; 2 Users cold also be groped in homegeneos classes with the same profile, bt this does not change the methodology. V6 the expected exection cost, which is the average price to be paid for a ser- invocation of the composite service; the expected reliability D, which is the logarithm of the probability that the composite service completes its task for a ser- reqest. As in [27], we consider the logarithm of the reliability, rather than the reliability itself, to obtain linear expressions when composing the reliability of different services. Let s denote by R( i), Table 3: Recrsive rles to calclate the average vale of the Qo attribtes of a composite service, for a ser. First level Qo rles node (wherez = D R ) Z () =Z (d()) Z () =Z (d()) seq( + ) Z (seq( + )) = P c Z (c) + loop() Z (loop()) = Z () sel( + ) Z (sel( + )) = P c Z (c) + par_and( + ) (par_and( + )) = P c (c) + D (par_and( + )) = P c D (c) + R (par_and( + )) = max c +{R (c)} i Z () = Vi Z( i) ( i) and D( i) the average response time, cost and reliability of a given implementation of i. Table 3 provides rles to recrsively calclate R, and D, given R( i), ( i) and D( i), 1 i m. In these rles, d() denotes the child node of a node. These rles define a visit algorithm of the labeled syntax tree modeling the sage profile for a ser U, from which we get: R = R (); = (); D = D () To complete the calclation of R, and D for a given implementation of the composite service, we need to know the vale of R( i), ( i) and D( i). These vales depend on the pattern(s) sed to implement i and on the Qo attribtes of the concrete service(s) coordinated by each pattern. In the next section we complete this calclation and show how the model defined in this section can be sed to derive the template of an optimization problem. MOE bilds and solves a new instance of this problem at each relevant change of the operating scenario, to drive the system adaptation to the new scenario. 4. OPTIMAL ADAPTATION 4.1 Adaptation Policy Model We call an adaptation policy the set of directives issed by MOE to select the best implementation of the composite service in a given scenario. We recall that MOE assmes a flow-based service demand model with mltiple concrrent sers. Moreover, it can switch different reqests in a flow among different patterns to implement each abstract services i. Hence, determining an adaptation policy consists in determining, for each ser and each abstract service i: the coordination pattern(s) and the corresponding list of concrete services to be sed to bild concrete implementation(s) for i (selected among the single, and par_or patterns). the fraction of reqests generated by for i that mst be switched and bond to a specific implementation of i.

5 To this end, we model an adaptation policy for a set U of sers by associating with each U a vector x = [x 1,..., x m], where x i = [x ij] and 0 x ij 1. The index i of x ij ranges over the set of all abstract services, while the index J of x ij ranges over the following set: J Ii = (K i ( K + i {}) ( K + i {par_or})) In this definition K i = {k i1, k i2,..., k ini } is the set of available concrete services implementing i, and K + i is the set of all the ordered lists of elements of K i, where each element appears at most once (exclded the empty list) 3. For each abstract service i, x ij denotes the fraction of the reqests generated by for i to be bond to the implementation denoted by the index J. We have the following cases: J K i: in this case, the index J denotes a single concrete service, and x ij denotes the fraction of reqests for i to be bond to an implementation consisting of that single service; J K + i {}: in this case, the index J denotes a list of concrete services coordinated according to the pattern, and x ij denotes the fraction of reqests for i to be bond to an implementation consisting of those services; J K + i {par_or}: in this case, the index J denotes a list of concrete services coordinated according to the par_or pattern, and x ij denotes the fraction of reqests for i to be bond to an implementation consisting of those services. As an example, consider the case K i = {k i1, k i2, k i3} and assme that the adaptation policy x i for a given ser specifies the following vales: x i{k i1 } = x i{k i3 } = 0.3, x i{k i2,k i3 } par_or = 0.4 and x ij = 0 otherwise. This strategy implies that 30% of the ser reqests for service i are bond to service k i1, 30% are bond to service k i3 while the remaining 40% are bond to the pair k i1, k i3 coordinated by the par_or pattern (see Figre 4). From this example we can see that, to get some overall Qo objective for the flow generated by a ser, MOE may switch different reqests in this flow to different implementations (sing x i to drive the switch). Moreover, it may select implementations that se in different ways the same concrete service (k i3 in this example). 4.2 Policy-based Qo Metrics Given an adaptation policy x, we calclate in this section the Qo attribtes R (x), (x) and D (x) experienced by a ser U nder that policy. To this end, we denote by r ij, c ij, d ij, L ij the parameters of the LA negotiated with the provider of the concrete service k ij that implements the abstract service i (1 i m, 1 j n i), where r ij, c ij, and d ij are the average response time, cost, and logarithm of reliability of k ij. As we are in a flow-based setting, the LA states that these vales hold on the average for all the reqests in a flow, and are garanteed as long as the rate of reqests to k ij does not exceed the L ij threshold. Given the LAs parameters, we can determine the vale of the Qo attribtes R( i), ( i) and D( i). Let s denote by R( i; J), ( i; J) and D( i; J) the average response time, cost and logarithm of reliability of i, when i is implemented according to the pattern denoted by an index J Ii. We distingish among the three patterns: J K i: assming K i = {k ij}, the Qo attribtes coincide with those of the selected concrete service k ij: ( i; J) = c ij, D( i; J) = d ij, R( i; J) = r ij (1) J K + i {}: assming K + i = {k ij1,..., k ijl }, the concrete services listed in K + i are tried in seqence, starting from the first in the list, ntil one of them sccessflly completes. Hence, the logarithm of reliability of this pattern is derived from the probability that at least one service completes, while the cost and time to completion of all the elements of the list mst be smmed, each weighed by the probability that the invocations of all the preceding elements in the list have failed (where, for the sake of readability, we se a ij = e d ij, i.e., a ij is the reliability of k ij): ( i ; J) = l h 1 Y c ijh a ijh (1 a ijs ) h=1 D( i ; J) = log `1 R( i ; J) = s=1 ly (1 a ijs ) s=1 l h 1 Y r ijh a ijh (1 a ijs )N 1 h=1 s=1 (2) J K + i {par_or}: in this case, the costs of all the services in K + i mst be smmed as they are invoked in parallel: l ( i ; J) = c ijh h=1 D( i ; J) = log `1 ly (1 a ijs ) (3) s=1 ` Y Y R( i ; J) = a ij (1 a ij ) min {r ij}n 1 K 2 J j K \{ } j K j J\K Figre 4: Flow partitioning among different implementations. 3 We point ot that not all the instances generated by the second level prodction rles of ection 3 correspond to meaningfl implementations (for example, those where a concrete service k ij is repeated more than once in the par_or pattern). K+ i considers a meaningfl sbset of sch instances. In the expressions for R( i; J), N = `1 Q l h=1 (1 ) aij h is a normalization factor that acconts for the fact that at least one service terminates. We point ot that the expression for R( i; J) in (3) is exact nder the assmption that the average vale of the minimm of the response times of the services in K + i is eqal to the minimm of their average vales. This assmption holds when the distribtion of the response times is deterministic, otherwise the expression represents an approximation, which is qite accrate for distribtions with low variance. In other cases a more sitable

6 expression shold be sed, which wold reqire the knowledge of the response time distribtion, bt this is ot of the scope of this paper. From (1), (2) and (3), we see that the implementations of i according to the or par_or patterns have the same reliability when they se the same set of services. This reliability is higher than the reliability of the single pattern (for any single service belonging to the set sed by or par_or). On the other hand, it is easy to verify (with some algebra) that has a lower cost than par_or, bt a higher response time, since the seqential invocation sed by means that on the average not all the selected services are invoked, bt the response time of those invoked mst be smmed. Moreover, nder the deterministic assmption discssed above, the par_or pattern does not improve the response time with respect to the best selection of a service nder the single pattern, bt has a higher cost. par_or wold improve the response time over single in case of distribtion of the response time with non zero variance (e.g., exponential). Given expressions (1), (2) and (3) for ( i; J), D( i; J) and R( i; J), we can complete the calclation of (x), D (x) and R (x). From the recrsive rles of Table 3, we can easily derive the following closed forms for (x) and D (x): (x) = D(x) = m i=1 m i=1 V i V i x ij( i; J) (4) J Ii x ijd( i; J) (5) J Ii For R (x), we need to accont for the fact that the overall response time of the par_and pattern is the largest response time among its component activities. In this case, the response time is no longer additive and we cannot derive an expression analogos to (4) and (5). However, we have shown in [7] that we can still derive the following recrsive expression for R (x) sing the labeled syntax tree (we omit the proof here for space reasons): R (x) = Rroot(x) 8 max >< l d(l) R l P (x) Rl V P i (x) = i dd l V l >: J Ii x ijr( i; J)+ + P Vh h Π,h dd l Rh(x) V l l Π l / Π In (6), root denotes the root node of the labeled syntax tree, l is a generic node of the tree, Π denotes the set of par_and nodes in the tree, and dd is an order relationship among the nodes of the tree: given two nodes i and h, h dd i basically means that node h belongs to the sb-tree rooted at i and, within this sb-tree, h does not appear within a par_and activity (see [7] for details). We se this general closed form in the formlation of the optimization problem reported below. (6) 4.3 Optimization Problem We can now formlate the optimization problem solved by MOE to determine the optimal policy x in a given environment. To this end, we denote by R max,, D min, L the parameters of the LA negotiated by a ser for the access to the composite service managed by MOE. R max is an pper bond on the average response time the ser is willing to experience, while D min is a lower bond on the logarithm of the reliability. These bonds hold as long as the rate of service reqests generated by does not exceed the threshold L. is the cost pays for each invocation of the composite service. We assme that MOE wants, in general, to define an adaptation policy that optimizes mltiple - possibly conflicting - reqirements, within the constraints defined by the environment. We tackle this mlti-objective problem by transforming it into a single objective problem, where the objective fnction F(x) is an aggregate Qo measre given by the weighted sm of the (normalized) Qo attribtes of all sers. More precisely, let Z(x) = P U L Z (x) P U L where Z = R D is the expected overall response time, reliability and cost, respectively. We define the objective fnction as follows: F(x) = w r R max R(x) R max R min + w d D(x) D min D max D min + w c max (x) max min (7) where w r, w d, w c 0, w r + w d + w c = 1, are weights for the different Qo attribtes. R max (R min), D max (D min), and max ( min) denote, respectively, the maximm (minimm) vale for the overall expected sers response time, cost and the (logarithm of) reliability. We will describe how to determine these vales shortly. F(x) takes vales in the interval [0, 1]. With these definitions, the optimization problem can be formlated as follows: max F(x) sbject to: (x), U (8) D (x) D min, U (9) R (x) R max, U (10) R l (x) R l (x), l d(l), l Π, U (11) R l (x) = + i dd l V k i V k l h Π,h dd l x ij R( i; J)+ J Ii Vh Vl R h (x), l / Π, U (12) x ij V i L ij, 1 i m, 1 j n i (13) U J Ii,j J x ij 0, J Ii, x ij = 1, 1 i m, U (14) J Ii Eqations (8)-(12) are the Qo constraints for each ser on the cost, reliability and response time, where, Dmin, and Rmax are the LA parameters negotiated between the system managed by MOE and ser. The constraints (10)-(12) for the response time take into accont the pecliarity in the estimation of this attribte. Ineqalities (11), in particlar, allow s expressing the relationship among the response time Rl (x) of a par_and activity and that of its component activities R l (x), where for each par_and activity l we denote by d(l) the set of top-level activities/services which are nested within l in the syntax tree. Eqations (13) are the LA constraints negotiated with the providers of the component services, and ensre that the system managed by MOE does not exceed the volme of invocations agreed with those providers. Finally, Eqations (14) are the fnctional constraints. The maximm and minimm vales of the Qo attribtes in the objective fnction (7), sed to get a normalized vale, are determined as follows. R max, max, and D min are simply expressed respectively in terms of Rmax,, and Dmax. For example, the maximm response time is given by R max = P U L R max P U L. imilar expressions hold for max and D min. The vales for R min, min, and D max are determined by solving a modified optimization problem in which the objective fnction is the Qo attribte of interest, sbject to the constraints (13)-(14). We observe that the proposed optimization problem is a Linear Programming problem which can be efficiently solved via standard techniqes. This efficiency cold be otweighed by the high nm-

7 ber of variables x ij in the optimization problem, which is exponential in the nmber of concrete services implementing each abstract service. A possible way to tackle this problem is to restrict the nmber of considered sbsets J to those having at most a given cardinality, considering the diminishing Qo increase we can achieve with higher redndancy levels. 5. MOE IMPLEMENTATION AND NUMERIAL EPERIMENT In this section we describe the prototype tool that implements the MOE methodology and discss nmerical experiments that illstrate the kind of adaptation directives issed by MOE. These directives are determined as soltion of the optimization problem described in the previos section. 5.1 MOE Prototype This section describes or ongoing prototype implementation of MOE. As shown in Figre 5, the prototype consists of three main layers (Implementation, Rntime Monitoring, and Adaptation) and three axiliary components (Workflow Validation, Model Generation, and ervice Discovery & LA Negotiation). The Implementa- Workflow Monitored parameters Workflow Validation Model Generation LA Monitor Model ActiveBPEL Adaptation Rntime Monitoring Proxy Exection Monitor Implementation ervice Discovery & LA Negotiation Adaptation Manager MATLAB Notifications Admission ontrol Manager Monitored data Apache Tomcat Apache Axis MyQL Figre 5: The MOE prototype architectre (dark grey boxes indicate the spporting technologies). tion layer is the software platform that exectes the bsiness process with the opportne adaptation actions driven by the Adaptation layer and represents the ser front-end for the composite service provisioning. This layer is responsible for managing the ser reqests flow, once the ser has been admitted to the system with an established LA. It has been developed sing open sorce prodcts: ActiveBPEL for the BPEL engine, Apache Axis and Apache Tomcat for the OAP engine and servlet container respectively, and MyQL for the repository. The latter stores all the information needed by MOE to carry ot the rntime adaptation (among which the abstract and the corresponding concrete services with their Qo vales, and the x ij vales determined by the soltion of the optimization problem). When a ser invokes the bsiness process, ActiveBPEL creates a new instance of the process itself. Each generated instance can differ according to the soltion of the optimization problem determined by the Adaptation layer and stored in Adaptation actions the repository. As already discssed, for a given abstract service the reqests of sers with different (or even the same) LAs can be bond to different concrete services, also sing different coordination patterns. The crrent MOE prototype spports the three coordination patterns listed in Table 2 by means of the Proxy component, similarly to the proxy-based approach in [12] which addresses reliability spport in a BPEL process. The Implementation layer ses the soltion x of the optimization problem to drive the Proxy that selects, for each invocation of an abstract service i, the specific implementation to which it mst be bond. The Proxy, written in Java, has been designed to spport the coordination patterns in a transparent way to the BPEL engine and the BPEL process (apart from some patches that are atomatically applied by MOE to the BPEL process in order to let the process call the Proxy rather than other endpoints). While the single pattern is simply implemented by selecting the concrete service identified by the soltion of the optimization problem, the pattern reqires seqential invoke operations within a loop on the list of ernate concrete services determined at rntime by the soltion of the optimization problem. Finally, the par_or pattern (which does not have a corresponding BPEL constrct) has been implemented by means of the flow, throw, and catch activities. The Rntime Monitoring layer consists of the Exection Monitor and LA Monitor modles. The Exection Monitor collects and keeps p to date information abot the composite service sage profile, calclating estimates of the Vi vales. The LA Monitor collects information abot the performance and reliability levels (specified in the LAs) perceived by the sers and offered by the providers of the component services, and abot the mean volme of reqests generated by the sers. Frthermore, the LA Monitor gives warning to the Adaptation layer whether there is some variation in the pool of concrete services available for a given abstract service. Or crrent implementation of the LA Monitor measres the mean volme of reqests generated by the sers, as well as the response time and reliability offered by the providers to MOE. To monitor other LA parameters and estimate the network impact on the ser performance, the prototype cold also rely on third party LA monitors, sch as those provided by Keynote ystems [18]. The Admission ontrol Manager does not play a tre monitoring role, bt rather manages new ser arrivals to find ot whether a new ser can be accepted by the system, given its Qo expectations and the already existing LAs. Moreover, it notifies to the Adaptation Manager the flctation of workload intensity parameters cased by the arrival or departre of sers. In the Adaptation layer, we have the bsiness process model and the Adaptation Manager. The bsiness process model defines the parameters that will be observed by the Rntime Monitoring layer dring the bsiness process exection. Upon receiving a notification of a significant variation in the model parameters (from the latter layer), the Adaptation Manager finds ot whether and how an adaptation action has to be performed. To this end, it solves the optimization problem described in ection 4.3, sing the new instance of the system model with the changed vales of the parameters. The calclated soltion provides indications abot the adaptation actions that mst be performed to optimize the se of the available resorces (i.e., the concrete services) with respect to MOE optimization criterion. Based on this soltion, the Adaptation Manager isses sitable directives to the Implementation layer, so that ftre instances of the bsiness process will be served according to these directives. The constrction and soltion of the optimization problem is implemented in MATLAB. The axiliary components, only partially implemented in or

8 prototype, perform the following tasks. The Workflow Validation parses the BPEL workflow and verifies whether its strctre is compliant with MOE, as specified in ection 3.1. In the positive case, the Model Generation prodces from the workflow specified in BPEL code the behavioral model of the composite service. Finally, the ervice Discovery & LA negotiation is responsible to find the service providers offering fnctionally eqivalent service implementations and to negotiate with them the LAs. This latter component, hogh necessary for the system sage at prodction time, is crrently ot of the scope of or research. 5.2 Nmerical Experiments In this section, we illstrate the behavior of the proposed adaptation strategy scheme throgh the simple abstract workflow of Figre 2. For the sake of simplicity we assme that two candidate concrete services (with their respective LAs) have been identified for each abstract service except for service 2 for which for concrete services have been identified. The respective LAs differ in terms of cost, reliability and response time. Table 4 smma- corresponds to the income maximization for the composite service provider). The reslts are smmarized in Figres 6(a) and 6(b) that show the adaptation policies for User 1 and User 4, and in Table 6 where we list the reslting Qo metrics for all the sers. Observe that nder cost minimization, there is no incentive to garantee to the sers more than the minimm reqired. Ths, the soltion calclated by MOE garantees only the minimm reqired level of reliability and response time, i.e., D (x) = D min and R (x) = R max (see Tables 5 and 6), with increasing costs for increasing Qo ser reqirements. Table 6: Qo metrics achieved by MOE. User (x) D (x) R (x) log(0.99) log(0.95) log(0.95) log(0.9) 18 Table 4: oncrete services LA parameters. erv. c ij d ij r ij erv. c ij d ij r ij k 11 6 log(0.995) 2 k log(0.95) 2 k 12 3 log(0.99) 4 k 21 4 log(0.99) 2 k 22 2 log(0.95) 4 k log(0.99) 1 k 24 1 log(0.95) 4 k 31 2 log(0.995) 1 k 41 1 log(0.995) 0.5 k log(0.99) 1 k 51 2 log(0.99) 2 k log(0.95) 4 k log(0.99) 1.8 k log(0.9) 4 k11 k23 k12 k32 k31 k41 {OR} 0,61 0,39 k42 k21 k51 k51 k52 k61 k62 rizes the LA parameters r ij, c ij, d ij for each concrete service k ij. They have been chosen so that for abstract service i, concrete service k i1 represents the better service, which at a higher cost garantees higher reliability and lower response time with respect to service k i2, which costs less bt has lower reliability and higher response time. For all services, L ij = 10. On the ser side, {OR} (a) User 1 {OR} Table 5: User LA parameters. User D min R max L 1 25 log(0.99) log(0.95) log(0.95) log(0.9) 18 1 k12 k24 0,5 0,5 k32 k32 k31 k52 k42 k41 k61 k51 k62 we assme a scenario with for concrrent sers of the composite service managed by MOE. The LAs negotiated by these sers are characterized by a wide range of Qo reqirements as listed in Table 5, with User 1 having the most stringent reqirements, Dmin 1 = log(0.99) and Rmax 1 = 7 and User 4 the least stringent reqirements Dmin 4 = log(0.9) and Rmax 4 = 18. The LA costs parameters for these sers have been set accordingly, where User 1 has accepted to pay the highest cost per reqest, 1 = 25, while User 4 only 4 = 12. The sage profile of the different sers is given by the following vales for the expected nmber of service invocations: V1 = V2 = V3 = 1.5, V4 = 1, U; V5 = 0.7, V6 = 0.3, {1, 3, 4}; V5 2 = V6 2 = 0.5. In other words, all sers have the same sage profile except for User 2, who invokes the services 5 and 6 with different intensity. We illstrate the adaptation directives issed by MOE assming that its optimization goal is the minimization of the average cost to implement the composite service, i.e., w c=1 (this goal cold (b) User 4 Figre 6: Adaptation policies for the workflow of Figre 2. The reslting workflow for User 4 employs only the single and the coordination patterns (see Figre 6(b)): services 1 and 2 are bond to the cheaper k 12 and k 24, respectively; for the other services, the soltion bonds them to an implementation based on the pattern which, with the exception of 6, takes the form of (k i2, k i1) (observe that (k i2, k i1) and (k i1, k i2) have the same reliability, bt with or choice of concrete service Qo parameters, the former pattern is always characterized by a lower cost and higher response time). In the case of 3, note that a fraction of the traffic is switched to an implementation based on the pattern.

9 The soltion for User 1, who has more stringent Qo reqirements, differs sbstantially from the one jst described. From the figre we observe that User 1 workflow employs a redndant soltion for each service, and adopts the par_or pattern to implement some services (remember that the par_or pattern for the same level of reliability of the pattern yields lower response time at a higher cost), which comes at a significant higher cost per reqest (21.18, almost twice the needed to satisfy a User 4 reqest). To illstrate how the optimal adaptation changes pon environment variations, we now assme that the monitoring service notifies MOE that service k 32 is not longer available. In this case, MOE bilds and solves a new instance of the optimization problem. The new soltion has the same level of reliability and response time bt higher cost for all sers (we do not show the actal vales for space limitation). For User 1 we show the new adaptation policy in Figre 7. We can observe that in the new optimal soltion the decrease of reliability of the implementation of 3 de to the disappearance of concrete service k 32 is compensated by an increase of reliability of 5 which is now implemented only by par_or(k 51, k 52). Moreover in the implementation of 4, (k 41, k 42), which has the same level of reliability bt costs less, replaces par_or(k 41, k 42). k11 k23 k12 k21 k31 k51 {OR} k52 k41 k42 k61 {OR} k62 Figre 7: New adaptation policy for User RELATED WORK As otlined in [10], the topic of self-adaptive compting systems has been stdied in several commnities and from different perspectives. The atonomic compting framework is a notable example of general approach to the design of sch systems [16]. As indicated in the original proposal by IBM [17], the architectre of an atonomic system consists of a set of managers and managed resorces. The manager commnicates with the resorce throgh a sensor/actator mechanism and the decision is elaborated sing the so-called MAPE-K (Monitor, Analyze, Plan, Execte and Knowledge) cycle. This loop collects information from the system, makes decisions and then organizes the actions needed to achieve goals and objectives, and controls the exection. We have otlined in ection 3 the relationship between MOE and the MAPE cycle. Hereafter, we focs on works appeared in the literatre dealing with isses concerning the Qo evalation and the self-adaptation of OA systems, to garantee the flfillment of Qo reqirements. A basic problem to be solved when dealing with Qo isses of OA systems, is how to determine the Qo attribtes of a composite system, given the Qo delivered by its component services. ome papers have focsed on this specific isse [8, 19, 24], while others deal with it as a step within the more general problem of Qo based model-driven rntime adaptation of OA systems [2, 1, 3, 5, 7, 9, 13, 14, 23, 25, 26, 27]. ome of the works dealing with this general problem propose heristics (e.g., [3, 13] or genetic algorithms in [5]) to determine the adaptation actions. Others propose exact algorithms to this end: Y and Lin [26] formlate a mlti-dimension mlti-choice 0-1 knapsack problem as well as a mlti-constraint optimal path problem; Zeng et al. [27] present a global planning approach to select an optimal exection plan by means of integer programming; in [2, 13, 23] the adaptation actions are selected throgh mixed integer programming. As already otlined in the introdction, with regard to the mechanisms sed to carry ot the adaptation, most of these papers have focsed on dynamic service selection. Other papers have instead considered workflow restrctring, exploiting the inherent redndancy of the OA environment [9, 13, 14, 25]. [13] provides a methodology to select different redndancy mechanisms to improve the reliability experienced by a single reqest addressed to a composite service. In [9, 14, 25] the OA environment redndancy is sed as a way to adapt workflow by identifying mltiple diverse workflows that achieve the same goal. In this respect, the MOE aim is to provide a nified framework where service selection is integrated with other kinds of workflow restrctring, to achieve a greater flexibility in the adaptation of a OA system. An important aspect in model-driven adaptation of OA systems concerns the assmptions nderlying the proposed methodologies. In this respect, even if not always explicitly stated, proposed approaches share a common set of assmptions. They inclde synchronos invocation of services and stateless services. The former assmption is relevant for the estimation of the overall response time as (possibly weighted) sm of the response time of the invoked services. The latter provides the grond to freely (re-)bind different fnctionally eqivalent services to an abstract service, and to coordinate them by redndancy patterns. A relaxation of the stateless assmption can be fond in [2], where the proposed model allows to specify that some concrete services implementing different fnctionalities mst be bond to corresponding abstract services with an all or none logic. At present, MOE too is based on the above assmptions. On the other hand, a significant difference of MOE from other methodologies for rntime OA systems adaptation concerns the considered adaptation scenario. Most of the proposed approaches focs on a scenario concerning a single reqest addressed to a composite OA system [2, 5, 9, 13, 14, 25, 26, 27]. Their aim is to determine the adaptation action that is (possibly) optimal for that single reqest, independently of other concrrent reqests, considering a given set of Qo reqirements and the crrent conditions of the operating environment. MOE instead is intended to operate in a scenario where a qite sstained traffic of reqests is addressed to a OA system. Hence, its aim is to determine adaptation actions spanning the overall flow of reqests, rather than a single reqest. A potential drawback of this approach with respect to those focsing on single reqests is that we loose the possibility of cstomizing the adaptation action for each reqest. However, in the scenario we consider, performing a per-reqest rather than a per-flow adaptation cold case an excessive comptational load (in this respect, per-reqest approaches often lead to formlations of the problem to be solved as a NP-hard problem, which cold ths reslt too complex for rntime decisions). Moreover, per-reqest adaptation in a sstained traffic scenario cold incr in stability and management problems, since the local adaptation actions cold conflict with adaptation actions independently determined for other concrrent reqests. Preliminary versions of the per-flow approach adopted within MOE have been presented in [1, 6, 7]. However, those papers consider only service selection as adaptation mechanism.