Runtime Adaptability driven by Negotiable Quality Requirements

Run time Adaptabilit y driv en b y Negotiable Qualit y Requiremen ts Adina Mosincat Universit y of Lugano, Switzerland adina.dian a.mosincat@usi.c h Abstract. Tw o of the common features of business and the w eb are diversi ty and dynamism. Div ersity res ults in users having different pref- erences for the qu alit y requirements of a system. D ivers ity also makes p ossible alternative implementations for functional requ irements , called v arian ts, each of them p ro viding different qu alit y . The qu alit y provided by the system ma y v ary du e to different v arian t comp onents and changes in the environmen t. The challenge is to dy n amically adapt t o quality v ari- ations and to find the v ariant that b est fulfills the multi-criteria q ualit y requirements driven by user preferences and current runtime conditions. F or service-oriented systems this challenge is augmented by their dis- tributed natu re and lac k of control ov er the constituent services and their provided q ualit y of service (Q oS ) . W e prop ose a nov el approach to runtime adaptab ility that detects QoS changes, up dates the system mod el with runtime information, and uses the mod el to select the v ari- ant to execute at runtime. W e introduce negotiable maintenance goals t o express user quality preferences in th e requirements model and automati- cally interpret them qu antita tively for system execution. Our light w eight selection strategy selects t he v ariant that best fulfills the user req uired multi-criteri a QoS based on up dated Q oS v alues. Keywords: runtime adaptabilit y , quality requ iremen ts, QoS , user pref- erences, service comp osition 1 In tro duction Systems ar e increasing ly required to run in a dynamic en vir onment where run- time adapta bility is crucial. The diversit y makes p os sible alternative implemen- tations for functional re quirements, called v aria nt s. Dynamically adaptive sys- tems ensur e functional requirements are met by switch ing betw een v ar iants a t runtime. Quality requirements are imp ortant asp ects of a softw are system. Ther e ar e t wo imp ortant issues to b e taken into considera tion when quality r e q uirements are concerned: firstly , us e r s may have different, sometimes conflicting, prefer e nces regar ding q uality r equirements, a nd sec ondly , the delivered q uality estimated a t design time may v a ry due to par ameter changes at runtime. The system not only has to meet the user s’ different quality exp ectations, but it also has to ada pt to changes in the en viro nment to meet these re quirements. Thus, runtime adapt- ability is also cruc ia l when quality req uirements of the system are concerned. Service comp ositions allow reusing existing functionalities to build new a p- plications. The quality requirements of a service oriented system are express e d as Quality of Ser vice (Qo S) parameter s guara ntees, calle d s e rvice le vel ob jectives (SLOs [1]), in service level ag reements (SLAs [1 ]). Usually , only o ne exclusive SLO for each Q oS para meter is provided for a ll users. Howev er, in the diverse and dynamic web environmen t, it is v ital that the s ystem is aw are o f different user preferences and is able to meet differ e n t user exp ectations. W e address this issue by introducing the neg otiable ma int enance goals to allow users to expres s their QoS preferences in the requir ement s mo del. The negotiable maintenance goals allow for flexibility but do no t leav e ro om to misinterpretations when the user preferences are interpreted qua nt itatively . W e a ddr ess the issue o f runtime adaptability by using a mo del a nnotated with QoS v alues. The mo del is upda ted with runtime infor mation and the Qo S v alues a re r e-computed when changes o ccur. The mo del is use d a t runtime to select the v aria nt ex e cution that o ffers the delivered q uality closer to the user preferences. The selection strateg y takes into considera tion the user preferences expressed by the neg otiable maintenance goals and the up dated QoS v a lues tha t reflect the cur rent r unt ime conditio ns . In previous work [29 ] we hav e introduced an approa ch to runtime adaptability making use of an evolving mo del at runtime to ensure the unique SLO o f the system is met. The work presented in this pap er fo cuses on handling different user preferences that a re expr essed at the model level and must b e met at runtime, th us a llowing for multiple SLOs. The contributions of this pap e r a re tw o- fold: (1) W e introduce a nov el ap- proach to express user preferences regar ding quality require men ts in the req uire- men ts mo del and ensure their fulfillment down to the s ystem ex ecution level. W e prese n t a tax o nomy of nego tiable multi-criteria QoS that are automatica lly conv erted into mathematica l formulas ev aluated at runtime. (2) W e present a light weigh t str ategy for optimal runtime v ariant selec tion. T ogether with the change detection mechanism, our strategy allows the sys tem to adapt to changes that affect the pr ovided qua lit y . This pap er is s tructured as follows: Section 2 int ro duces our appr o ach. Sec- tion 3 details the system mo dels and the negotia ble maint ena nce goa ls, while the v ar iant selectio n strateg y is describ ed in Sec tion 4. W e pr esent ev aluation results in Section 5, dis c uss re lated work in Section 6, and conclude with Section 7. 2 Approac h Ov erview Fig. 1 shows the a rchitecture of our appr oach. The g rey b oxes r epresent thir d- party comp onents, a nd the das hed b oxes gro up the compo nent s according to four ma in a ctivities in our appr oach - expres s, find, (re)estimate, execute: 1. Qualit y r equirements are expr essed a s negotiable ma in tenance goals attached to functional r equirements in the Re quir ements Mo del . Computation al model Requirement s model Variant Finde r QoS Estimat or QoS Converter Runtime Info rmation Change Detector SLA update QoS formula trigger trigger Dispatcher Running Sys tem selectVariant Service Repository update Functional Requirement Selection Po licies Negotiable Maintenance goals Fig. 1. Appro ach Overview. 2. The V ariant Finder a utomatically finds v a riants, i.e. implementations, for each functional requirement, g enerating the computational mo del. 3. V ariants from the Computational Mo del are a nnotated with quality v alues that are (re-)estimated on change ba sed on runtime informa tion. 4. V ariants selected by the Dispa tc her of the Running System ar e exec uted. Express Users have different preferences with regar d to quality requirements. Often users are willing to negotiate the quality requirements a ccording to what the system can o ffer a nd to the imp or ta nce of each QoS par ameter for them. The sy stem m ust b e aw are o f the differ e n t user preferences, which implies that the user m ust be able to express his preferences, and the system must b e able to int er pret these preferences. In the GORE tec hnique, maintenanc e go als are used to express the sys- tem quality req uirements. Usually , maintenance goals ar e g lobal, i.e., one for all users, and leav e ro om to misinterpretations when the req uir ement is quantified. W e in tro duce ne gotiable maintenanc e go als to allow users to express sp ecific preferences. W e define a s et of macr o s that are us ed by the QoS Conv erter to conv ert the negotiable maintenance go als into mathematica l formulas which are implemen ted by Selectio n Policies and ev aluated during the v aria n t selection. Find The diversit y of the business landsca pe and the burst of the web ser vices makes po ssible tha t a functional r equirement of a system ca n b e implemented in dif- ferent wa ys. V ar iants implemen ting the same functional re q uirement may use completely different comp onents a nd pr ovide different quality . In this pa pe r we strictly r efer to v aria n ts e x pressed as serv ice comp os itions. The V ariant Finder is res po nsible with matc hing functional req uirements with exis ting v aria n ts, i.e. implementations. The V a riant Finder can b e a hu- man, a nd thus the v ariants are manually provided, or it can b e an a utomated system such as auto matic comp oser systems ([2]) that query the ser v ice rep os - itory finding the set o f ser vice co mpo sitions whic h solve the requir ement . The automatic comp oser systems impo se constraints such a s expressing the func- tional r equirement in a quer y lang uage the comp oser understands. Usually ser vice discov er y and matchmaking is a time co nsuming pro ces s. A set of v a riants so lv ing the functiona l requir ement are provided statically at de- sign time. The se a rch for a new v aria nt can b e trigger ed up on r eceiving r un time information signaling a significant change, such as the av ailability of a new ser- vice. The V a riant Finder up dates the co mputational mo del when it finds a new v ar iant for the functional requirement. (Re)Estimate The initial Q o S v a lues are co mputed for each v ar iant based on par ameters av a il- able at design time. How ever, given the dynamic nature o f services , these pa- rameters ma y c hang e during runtim e and affect the system provided quality . The Change Detecto r signals when a significa nt change o ccurs and trigger s the re-estimation of the provided quality . The QoS Estimator re-co mputes the QoS parameter v alues for each affected v aria n t ba sed on run time information and upda tes the computational mo del with the new v alues. Execute Some systems that ar e a n aggreg ation of distributed a pplica tions, s uch as service- oriented s ystems, can b e s een as a co mpo sition of functional requir ement s imple- men ted indepe nden tly . Each v aria nt is a service comp o sition. The system co re is a dispatcher that forwards requests to the v aria n t selected for execution. The v ar iant is se lected according to selection p olicies tha t implement the user Q oS preferences a nd according to QoS v alues. Monitor ing information is g athered during the v aria nt e xecution and is used along with thir d-party runtime infor- mation in the re- estimate a ctivit y . Activities that are time- consuming and computational int ense, namely ex- press, find and initial estimatio n of QoS v alues, are p erfor med statically when the c omputational mo del is gener ated. estimate traffic estimate time select info satellite image find network Computational Model Provide driving time road info VariantID Response time C ost V1 V2 V3 3s 5s 4.5s 10ct 0ct 7ct N1 N2 N3 N6 N4 N5 (N1,N6) (N2,N3,N6) (N4,N5,N6) . . . Accuracy 9 2 8 Fig. 2. Part of the computational mo del detailing the ”provide driv ing time” functional requirement. Resp onse time expressed in se conds, co st in cents. 3 System Mo dels W e use as r equirements mode l a goal mo del w ith functional goa ls (functional requirements) as pr e sented in [3] and attach negotiable maintenance goa ls to the functional g oals. W e generate the computational model fro m the requirements mo del b y providing v a riants for the functiona l requir ements. Fig. 2 shows a fragment of the computational mo del for an intelligent route- planner system. The functiona l re quirement detailed in the figur e is ”pr ovide the time needed to drive b etw een tw o lo cations based on traffic conditions”. Each no de in the graph r epresents a ser vice. The V a riant Finder provides three v ar iants that solve the functional requirement: 1. The sys tem gets traffic information for the route area from the road de- partment (no de N1 road info in the figure) a nd estimates the driving time considering the av aila ble information such a s trip leng th, sp eed limitations, and traffic queues (No de N6 estimate time). 2. The sys tem searches drivers netw orks and gathers information abo ut the traffic in the route area (no de N2 find netw ork), it filters the gather ed infor- mation (no de N3 se le ct info) and estimates the driving time (no de N6). 3. The system gets r oad imag es for the planned ro ute from a satellite databas e (no de N4 satellite ima g e), and computes traffic estimates by comparing the retrieved images (no de N5 estimate tr affic). It then computes the driving time ba sed o n the tra ffic estimates (no de N6). The functional r equirement in the co mputational mo del is annotated w ith the QoS v a lues computed for each v ariant. Thr e e QoS par a meters are considered: resp onse time, cost, and the user defined par ameter ac curacy . The pa rameter accuracy of the provided time estimation has v a lues in the integer in terv al [0 – 10]. At mo del generation, the Q oS v alue s are co mputed based on infor mation from the pr oviders of the comp osing services, e.g . av a ilable in the services ’ SL As. 3.1 Negotiable Quali t y Re quiremen ts Often users hav e different prefere nces r egarding the system req uir ements. Qual- it y requirements express ed in natur al language le ave ro o m to misinterpretations. F or instance , a user might say that co st is the only para meter that matters , but he might change his mind when faced with low v alues of other par ameters such as resp onse time. The nego tiable maintenance goals a llow for flexibility and av oid misint er pretations by mea ns of thresholds a nd prio rities. Thr e s holds allow users to sp ecify the tolerance limits for Qo S pa rameter v alues. Pr iorities are weigh ts assigned to ea ch QoS para meter reflecting the impor tance of the par ameter to the us er. W e use the fo llowing taxonomy of negotiable maintenance go als: 1. High Priority – the user can define one QoS pa rameter that ha s high prior- it y . T his means that the system should try to achiev e the b est v a lue for the sp ecified QoS para meter, r e gardless of the v alues of the other Qo S pa rame- ters. The user can optionally fix thr e sholds for all par ameters, i.e . the worst v alue he is willing to accept for the para meters. Fixing thresho lds applies to all types o f ne g otiable maintenance go als. E.g.: Resp onse time is hig h priority . Resp onse time is less than 1 day . Cost is less than 10 euro s. 2. Distribute d Priority – the user can cho ose several Qo S par ameters that have the s ame level of prio rity , while all o ther pa r ameters a r e igno red. E.g.: Resp onse time, co st is high priority . Maximum time to recov ery is les s than 1 day . 3. Condi tional Priori ty – the user chooses one or more Q oS parameters that can v ar y (degr ade) if one or more parameters with higher priority v aries (upgrades). E.g.: If co st upgr ades by 20 % then resp onse time de g rades by 20%. W e define the following macros that map the neg otiable maintenance g oals to mathematical formulas that a re implemented in the Selection Policies log ic which we use at runtime for the v ar iant selection: 1. list ( par amete rs ) IS HIGH PRIORITY maps to pri ority P i = 1 /m, ∀ P i ∈ l ist ( par ameter s ) pri ority P j = 0, ∀ P j / ∈ l ist ( par ameter s ), where m is the num b er of Q o S parameters in the list, and P s ta nds for parameter. 2. list ( par amete rs ) IS LESS THAN v al ue maps to thres hold P i = v al ue , ∀ P i ∈ l ist ( par ameter s ). Used for negative par ameters, such as resp ons e time (low er v alues are better ). 3. list ( par amete rs ) IS GREA TER THAN v al ue ma ps to thr eshol d P i = v al u e , ∀ P i ∈ l ist ( par ameter s ). Used for positive pa rameters, suc h as accuracy (higher v alues a re b etter). 4. IF l i st ( f irs t p aram ) UPGRADES BY f ir stv al ue THE N l is t ( se condparam ) DEGRADES BY secondv al ue The f ir stv al ue , resp ectively secondv al ue are pe r centages. The macro is mapp ed to the fo llowing equa tions: (a) F or neg ative parameters . thre s hol d P i = thre shol d P i + ( f i rstv a lu e ∗ thr eshol d P i ) / 100 thre s hol d P j = thr eshol d P j − ( se condv al ue ∗ thr eshol d P j ) / 100, ∀ P i ∈ l ist ( f ir stpar am ), ∀ P j ∈ l ist ( se condparam ), P j 6 = P i . (b) F or po sitive parameters. thre s hol d P i = thre shol d P i − ( f i rstv a lu e ∗ thr eshol d P i ) / 100 thre s hol d P j = thr eshol d P j + ( se condv al ue ∗ thr eshol d P j ) / 100, ∀ P i ∈ l ist ( f ir stpar am ), ∀ P j ∈ l ist ( se condparam ), P j 6 = P i . (c) F or b o th p ositive and nega tive parameter s, the prio rities are mo dified according to the following pse udo co de, where P i ∈ l i st ( f ir s t p aram ), P j ∈ l ist ( se condparam ), l ist ( f ir stpar am ) ∩ l i s t ( secondpar a m ) = ∅ , m is the n um b er of pa rameters in the f ir stpar am list, and n is the nu mber o f para meters in the secondpar am list: max = maxi m u m ( f ir stv al ue, secondv a lu e ); if ma x > 10 0 then b egin pri ority P i = 1 / m ; pri ority P j = 0; end else b egin min = mi nimum ( pr ior ity P i ) dif f er ence j = pr ior ity P j − mi n ∗ max ; pri ority P j = min ∗ max ; pri ority P i = pr ior ity P i + P n j =1 dif f er ence j /m ; end In the example in Fig. 2, ther e ar e at least tw o different user pr eferences regar ding the Qo S: 1. Users for whom time is vital need to get the informa tio n a s so on as p ossible , for ins tance to b e able to find alter native r outes in case o f tr affic jams. These us e rs a gree to pay up to a cer tain a mount for the information. The corres p o nding negotiable maintenance go al is: Resp onse time is high prio rity . Resp onse time is les s than 4s . Cost is less than 1 0 ct. 2. Users who a re not under time pr essure a re interested in the informatio n, but only if it comes for free. These users agree to wait to get the infor mation. The corres po nding neg otiable ma in tenance goa l is: Cost is less than 0 ct. 4 QoS Estimation, V arian t Selection and Change Detection The cumulativ e end-to-end QoS of a s ervice comp os ition dep ends on the indi- vidual QoS of ea ch co nstituen t ser vice. The mo difica tion o f the QoS par a meters of one se r vice can therefor affect the QoS o f the v a riants that use the ser v ice. V ario us techniques hav e b een pro po sed to ta ckle the o ptimization of the cumu- lative QoS at the level o f ser vice s e le ction, re sulting in different ma thematical optimization mo dels, s uch as m ultiple attribute utilit y theory and reg ression mo dels [4,5]. Usually thes e ar e time and res o urce consuming solutions. Although o ur appr oach c an integrate these s olutions, for p er formance as well as visibilit y consideratio ns w e use a fixed set o f v aria nts provided a t model generation time and preserve the constituent services o f the v ar iant. W e co mpute the cumulativ e Q oS parameter s of each v ariant based on the formulas introduced in [6]. The initial Qo S computatio n formulas derived at mo del g e ne r ation time ar e stored in the system a nd used for Qo S re-c o mputation. When a QoS pa rameter of a service changes, the QoS para meter is re- computed fo r all v ar iants using the service. When s e le cting the v aria nt to execute the Dispatcher takes into co ns ideration the user prefer ences a s expressed by the nego tiable maintenance goa ls and sto red in the Selectio n Policies. The nego tiable maintenance go als set the thr eshol d and pri oriti e s v alues which are used by the v ar iant selection str ategy . The selec tio n strategy ensures that the v ariant that b est fulfills the user preferences is se le c ted from the a v ailable v aria nt s. The str ategy uses the la t- est up dated v a lues of the QoS parameters computed for each v ariant based on runtime information. W e consider m v a riants a nd n QoS para meter s. F or all parameters for which no thres hold v alues ar e given thre s hol d P i = max ( P i monitore d ) , where thres hold P i is the thres hold v alue for parameter P i and max ( P i monitore d ) is the maximum mo nitored v alue for parameter P i . F or each v a r iant we compute the deviatio n from the thr e s hold in p ercentage for ea ch pa rameter a s σ P i j = ( P i crt − thre shol d P i ) ∗ 1 00 /thr eshol d P i , 1 ≤ i ≤ n, 1 ≤ j ≤ m, where P i crt is the last co mputed v alue for pa rameter P i . All v aria nt s for which ∃ σ P i j > 0 , ∀ i, j where 1 ≤ i ≤ n, 1 ≤ j ≤ m and P i is a neg ative parameter, resp ectively ∃ σ P i j < 0, ∀ i, j where 1 ≤ i ≤ n, 1 ≤ j ≤ m and P i is a p ositive parameter are excluded from selection. This means that a ll v aria nt s that hav e at least o ne parameter v alue exceeding, resp ectively no t reaching, the us e r defined threshold are excluded fro m selection. W e choo s e the v ar iant v , 1 ≤ v ≤ m with n X i =1 pri ority P i u ∗ σ iv = min n,m X i =1 ,j =1 pri ority P i u ∗ σ P i j , where p rior ity P i u is the priority of par a meter P i for us e r u , and n X i =1 pri ority P i u = 1 . Change Detectors ca n deter mine when a critical change has occur red a nd trigger the re-estimate Qo S activity . An exa mple of a change that could have a high impact on the QoS of a v aria n t is a violation of the SLOs of one of the constituent services . Assuming the ser vice SLA is av aila ble, a dedicated change detector ca n use monitoring informatio n and implement tests to determine if a violation has o ccur r ed by using sta tistic metho ds, such a s sta tistical hypothesis testing [7]. In order for s tatistical tes ts to be effective, a la rge num b er of samples, i.e. monitoring v alues, might b e needed. Since the sy stem relies up on monitor ing and runt ime informatio n pr ovided by third par ties, a simpler Change Detector testing for fluctuations in the Qo S par ameter v alues mig ht be b etter s uited. W e e x plain b elow the Change Detector we use in our ev aluatio n. The Chang e Detector detects ser vice QoS fluctuations b y computing the deviation of the last re ceived QoS parameter v alue from the av erag e Qo S para meter v a lue . The av erag e QoS parameter v alue is stor ed in the s ystem a nd computed fro m all previous v a lues received. If a sig nificant QoS par ameter fluctuation is detected, the Chang e Detector trigg e rs the re- computation of the Q oS para meter v alues of all v ar iants using the service. The log ic implemented by the Cha ng e Detector is expr essed b elow. monitor edQoS i sid is the monitor ed Qo S parameter v alue of the service identified by sid and ref ere nceQoS i sid is the QoS parameter av era g e v alue o f servic e sid stored in the system: if   monitore dQoS i sid − r ef er ence QoS i sid   > thre shol d the n trigger() end The configura ble para meter thresho ld con tro ls the significance of the QoS parameter fluctuation. F or Q oS parameters that are not exp ected to fluctuate, such as cos t, the thresho ld is 0. F o r QoS para meters that are usually suffering mo derate fluctuations, such a s resp onse time, the v alue o f the thresho ld par a m- eter is c omputed a s function of the av erag e v alue, e.g.1 / 2 ∗ ref ere nceQoS i sid . 5 Ev aluation In this sec tio n we ev aluate o ur approach by exploring the ability of the system to meet the user pr eferences considering the av ailability of v aria nt s with different QoS v a lues, r esp ectively in the presence of changes that affect the provided v ar iant QoS. W e assess the effectiveness of our sele c tio n strategy in settings with hig h n umbers of v ar iants, QoS pa rameters and user req ues ts. W e base our ev aluation on the in telligent r oute-planner example. F or the implemen tatio n of the dr iving time functional r equirement, our s y stem provides 5 v ariants each o f them implemented as BPE L pro cess es. As sour ce of runtim e information in terms of r esp onse time we use ADULA [8 ,9], a fr a mework for mon- itoring BPE L pro ces ses. W e simulate a third-pa r ty runtime infor ma tion provider for the co st and ac c uracy QoS parameter s . W e use tw o different settings to explor e the correc tness of o ur selec tio n str at- egy for three different user negotiable main tenance go als, high priority , dis - tributed prio rity , respe ctively co nditional prior it y: (1) In the first setting we show how the v aria nt selection strateg y works when the environmen t is sta ble, i.e., no changes o ccur. (2) In the second setting we explore the system behavior in the presence o f resp onse time fluctuations a nd cos t c hang e s . W e show how the s ystem ada pts to changes and how the ch a ng es a ffect the v a riant selection. T able 1. Left side: Initial val ues for QoS parameters for each v ariant. Right side: Threshold ( T RT , T C , T A ), priorit y ( P RT , P C , P A ) va lues, and selected v arian t (Sel) for high priority , distribut ed p riorit y and conditional p riorit y goals. QoS para meter V1 V2 V3 V4 V5 Goal T RT P RT T C P C T A P A Sel Resp onse time (R T) 3s 5s 4.5s 10 s 3 .5s High 10 s 1 20ct 0 2 0 V1 Cost (C) 10ct 0ct 7ct 20ct 8 ct Distributed 10s 1/3 20 ct 1/3 5 1 /3 V5 Accuracy (A) 9 2 8 10 9 Conditional 4.8s 1/10 8ct 9/ 10 2 0 V3 W e use 10 different ser vices for the 5 v ariants implementing the dr iving time functional requirement. The serv ice that es timates the driving time ba sed on the road infor mation is used by four o f the v aria n ts (V1 – V4) and we identify it as service S, as we will use it further for describing the ev alua tion settings. V aria nt V1 uses tw o services: one se rvice that provides road information in terms o f num b er of car s on the road s e ctor and av er age driving sp eed, and service S. V aria nt V2 uses 3 differen t serv ic e s: one service to gather road information from the netw ork , one service to s elect meaningful informa tion from the gathered road info rmation, and serv ice S. V ariant V3 uses 3 different s e rvices: o ne service to retrieve a satellite image of the road sector, one service to compute r oad information from the sa tellite image and ser vice S. V ar ia nt V4 uses 4 different services: one s ervice to retrieve several images of the targeted ar ea taken from helicopters surveilling the area , one service to co mpare the imag es a nd render one comp osed ima ge of the r o ad secto r, one ser vice to compute ro a d informatio n from the compos ed imag e and ser v ice S. V a riant V5 uses three services, o ne service to read roa d sensor s infor mation, o ne service to compute the num b er of cars a nd av er age driving time based on the r oad sensors informatio n, and one service to estimate the dr iv ing time bas ed on the r oad informa tio n and weather conditions. W e consider the following three nego tia ble maintenance go als, high prio r ity , distributed priority , res pectively co nditional pr io rity: 1. Response time is high priority . 2. Response time, cost, accur acy is high pr iority . Accur acy is gr eater than 5. 3. If cost upgrades b y 20% then r esp onse time degra des by 20%. Cost is less than 10 ct. Respo nse time is less than 4 s. Left side o f T able 1 shows the QoS v alues computed for each v ariant whe n the computationa l mo del is crea ted. Right side of T able 1 shows the thresholds, priorities a nd the s elected v aria nt for ea ch of the three negotiable maintenance goals. F or the high pr iority g oal, only para meter resp onse time is consider ed for the v ariant selectio n. V ar iant V 1 is selected b ecause it ha s the be s t res p o ns e time v alue. F or the distributed pr io rity goa l all three QoS pa r ameters influence the se- lection. V ariant V 2 with accura cy b elow the user defined thresho ld is ex cluded from se lection. V ar iant V 5 with the b est overall Q oS is selected. F or the conditiona l priority goa l the us er accepts a degr adation of the re- sp onse time par ameter if the co st is low e r. When the cost is low er than 8 ct T able 2. S elected v ariant with up dated Q oS parameter val ues computed after eac h change. Changes are: (1) service S slo ws down by 0.6s, (2) service S slow s d o wn by 0.9s, (3) service S returns to initial state (sp eeds up by 1.5s), and cost is decreased, (4) service S slow s down by 0.6s, (5) service S slow s down by 0.9s. RT S is the resp on se time of service S, C is the cost of service used by V1. Goal RT S = 1 . 6 s RT S = 2 . 5 s RT S = 1 s RT S = 1 . 6 s RT S = 2 . 5 s C = 10 ct C = 10 ct C = 6 ct C = 6 ct C = 6 ct High V5 { 3.5s,8ct,9 } V5 { 3.5s,8 ct,9 } V1 { 3 s,6ct,9 } V5 { 3.5s,8 ct,9 } V5 { 3 .5s,8ct,9 } Distributed V5 { 3.5s,8 ct,9 } V5 { 3 .5s,8ct,9 } V1 { 3s,6ct,9 } V1 { 3 .6s,6ct,9 } V5 { 3.5s,8ct,9 } Conditional V5 { 3 .5s,8ct,9 } V5 { 3.5s,8ct,9 } V1 { 3s,6 ct,9 } V1 { 3.6s,6ct,9 } V1 { 4.5 s,6ct,9 } (20% deviation fr o m the cost thresho ld), the resp onse time co uld b e higher than 4 s. Howev er, the resp ons e time should not b e higher than 4.8 s (20% devia- tion from the thres hold). V ariant V 3 is selected a s it offers the b est QoS v alues meeting these r equirements. In o ur second ev alua tion setting, firstly we v ar y the r esp onse time of ser vice S which influences the resp onse time of v aria nt s V 1, V 2, V 3 a nd V 4. F or servic e S we use a discr ete time Markov chain [24] serv ice mo del with 3 different states. In the fir st state the res p ons e time o f s e rvice S is 1s, in the seco nd state the r esp onse time of S is 1.6s , and in the third state the resp onse time o f S is 2.5s . The service changes state every 5 r equests. W e use the Change Detector to detect when the resp onse time changes. The Change Detector uses the mo nito ring information provided b y ADULA. Secondly , after the first 15 r equests, we change the cost parameter of the r oad informa tion ser vice used by v ar iant V 1 by 40%. T able 2 s hows the selected v a r iant after every change with the new co mputed QoS v alues in curly bra ck ets. As se r vice S is used by v a riants V 1– V 4 the resp onse time v alue of these v ar ia nt s is re-computed when the res p o ns e time of ser vice S changes. V a riant V 5 remains unchanged. The up dates of the resp ons e time v alues result in different v a riant selections for the three nego tiable maintenance go als. Thu s, when s ervice S b eco mes s low, v aria n t V 5 b ecomes the fa stest av aila ble v ar iant a nd is selected for all g oals. W e change the cost of the serv ice used by v ariant V 1 s o that it de c reases fro m 10ct to 6ct. Since this is the only service with cost used by v ar ia nt V 1, the c o st v alue for v ar iant V 1 is re-co mputed and b eco mes 6ct. Giv en the updated cost v alue, v aria n t V 1 is selected for the distributed and conditional priority goal. In the third setting w e assess the e ffectiveness o f our selection strategy for complex systems. W e use a n abstra ct functional requirement for which we con- sider 20 0 v aria nt s and 2 0 QoS para meters and measure the time needed for v ar iant s election. All v a riants use the seq uential workflow pattern. As exp ected, the time needed fo r v ariant selection is negligible, up to 2 ms p er user request, resp ectively a n av er age o f 2 80ms to select the v ar iant for 300 user requests (the requests are sta rted by 5 concur rent threads ). In conclusion, our selection strategy chooses the b est v ar iant av ailable to fulfill the user differ e n t quality exp ectations. When changes o ccur, the system adapts to these changes switching b etw een existing v a riants to preserve the pro- vided quality that bes t mee ts the user different quality exp ectations. 6 Related W ork There are different approaches that address finding the optimal solution to meet the cumulativ e multi-criteria Q oS o f a service comp os itio n, i.e. v a riant. Some of these s olutions a nalyze and comp ose the QoS of individual services to obta in the QoS o f the pro ce ss statically at design time [10,11]. In contrast, our so lution is dynamic and we consider changes in the environment . Other solutions contin u- ously r ecompute the estima ted Qo S [4,5,1 2,13,14]. These appro aches pro po se a mathematical mo del based o n which the c o nstituent s e r vices a re selec ted at run- time. In contrast to our a pproach, these so lutions can als o adapt to changes that o ccur dur ing the v ariant execution. On the other hand, they are computational exp ensive. While our a pproach can in tegra te these solutions, for p er fo rmance consideratio ns we prefer to use a set o f fixed v ariants that are pr ovided at mo del generation. The QoS of the v ariants is r e-computed on change and our selection strategy us es the up dated v alues allowing for inexp ensive v ar ia nt sele c tion. A solution using machine le arning techn iques is pr esented in [5]. The solution uses r egressio n mo dels and r e-computes the QoS pa rameter v alues at differ en t po int s dur ing the pr o cess execution, sp ecified initially by the pro c ess developer. The solution a llows for hig h accuracy of pre dic tio n and can react to changes that o ccur b etw een the defined chec kp oints, but it has to pay the price in com- putational expens e a nd to rely o n the developer’s ability of instrumenting the pro cess. In contrast, our solution requires user awareness in the r equirement analysis pha se and o ffers co mplete transpa rency to the developer. In [14] the author s reason ab out the p ossible outcomes of the overall quality of a compo sition when a ser v ice is selected based on Graph T ransfo r mation System. The metho d is us e d to pr edict a ll p ossible architectural configurations that can b e rea ched by selecting a service. A flexible appro ach allowing for integration o f user prefer ences in the com- putation of Q o S par ameters that affect service s election is the LCP-nets frame- work [4]. When co mputing the QoS of the pro cess the framework takes int o consideratio n us er preferences, relative imp ortanc e , a nd tra deoffs b etw een QoS parameters , which are expres sed in ling uistic terms using LCP-nets . It then c o m- pares the candidate services up on several different QoS dimensions, applying the expressed pr eferences to the c urrently measur ed QoS v alues. As our solution do es not co nsider selection of indiv idual comp osing services, it allows for less compu- tational exp ensive v ar ia nt sele c tio n. A different directio n is taken b y the Planning as Mo del Checking [15] ap- proach, whic h allows to monitor the ex e c ution of the comp os itio n and take cor- rective actions in cas e so me of the conditions are not met. The appro a ch uses planning techniques as well as the EaGLe go al la nguage [16], a languag e that allows e x pressing sy stem goals s uch as non-functional requir ement s. Another approach to deal with unsa tisfactory QoS provided by ser v ices is SLA nego tiation [17,18 ,1 9,20]. The negotiatio n can b e manual, requir ing human int er vention, or a utomatic in which case softw are ag ents are used. Negotiation of SLA is done on a client basis, which means that a service can hav e a different SLA for each of its c onsumers. These so lutions are based on agents that carry out nego tiation, i.e., explor e p os sible solutions that even tually lead to an ag ree- men t, using different algor ithms and nego tiation s trategy mo dels. While so me approaches use optimization algorithms to sp eed up the negotiation pro cess [1 7], finding an a greement may b e a long-la s ting pro cess. [21] takes a new view on contract (SLA) neg otiation, consider ing the evolu- tion o f the contract based on the p ossible evolution of the par ties inv olved in the contract. The solution pr ovides a wa y of defining constraints on the contract, defining b oundaries in which the provided ser vice QoS can v ary and wha t is ac- ceptable bo th to pr ovider and consumer. Therefor e, a contract violatio n is more strictly defined in an evolving co nt ext and the nee d of re-neg o tiation is reduced. In [22] the authors address the need to a llow for flex ibility of quality require- men ts by defining cons traints in the r equirement mo de l. The norms ens ure the non-functional pr o p e r ties of the service are expresse d in the requirements mo del and service warranties protect the stakeholder from v a riations of the norms. This approach stops at the requir ement s mo del level witho ut considering a n evolution of the mo del based on runtime information. Recent fo cus on encapsula ting adaptation at the r equirements mo del level led to a num ber o f interesting solutions . KAMI [23] is a fra mew o r k that pr o- vides informa tion o n non-functional v alues based on cur rent runtime conditions. KAMI use s DTMC [24] mo dels to rea son ab out non-functional prop erties of the system and bay esia n techniques to estimate their v alues based on runt ime infor- mation. O ur solution also ha ndles different user preferences and uses the mo del at r un time to allow the system to a dapt to changes that affect the provided quality . An int er e sting solution that makes use of a go al-oriented mo del at r un time is [2 5]. The authors intro duce adaptive goa ls to allow sp ecification of differe nt adaptive features in the re quirements mo del a nd tr igger ada ptation a c tio ns when the satisfaction level of a goa l deviates from the required v alue. Our solution fo cuses on sp ecifying user preferenc e s in the mo del which then drive the sy stem execution. CCAP [26] is a system that pr ovides supp ort for co nfigurable and a daptive service comp ositions aw ar e of user co n text a nd differ e n t needs. The s ystem makes use of a configurable comp os itio n mo del which pr ovides abs tractions for service context and exceptions, and of an execution mo del based o n control tuples , fav oring r obust a nd adaptive ser vice e x ecution. Another approach to comp osition adaptability a t the architectural level is taken in [27] which int r o duces Adaptive Service Orie nted Architecture (ASOA). ASOA mer ges the autonomic computing with SOA. A solution allowing fo r self-r econfiguratio n to adapt and recov er from failures is prop osed in [28], which intro duces a conceptual architecture to provide systems with a daptive c apabilities. [29] in tro duces a n approach close to ours to ensure r esp onse time SLOs of the system ar e met rega rdless of the c hang es in the environment . The re s po nse time of the v a riants is monitored and stor ed in the system to detect based on statistic tes ts when an SLO viola tion o ccurs. The approach co nsiders only the resp onse time parameter a nd one e xclusive SLO for all users of the sy stem. Our approach focus e s on different user pr eferences, which might result in multiple SLOs, a nd take into co nsideration multi-criteria Qo S. [30] presents a solution to provide the requir e ment engineer with feedback on s ervice b ehavior gathered using online testing techniques. Based on the feed- back the requir ement e ng ineer can decide on ada ptation actio ns to execute. In contrast, our solution automatica lly adapts to changes that affect the Q oS pa- rameter v alues and do es not require manual mo dification of the re quirements mo del. ALBER T [31] is a la nguage that is used to s pec ify functional a nd non- functional prop erty asser tions which are verified at design time by mo del chec k- ing and used a t runtime as dynamically ev aluated a s sertions. Our appr o ach takes dynamic mo dels into cons ide r ation, i.e., mo dels that can evolve at runtime b e- cause of environmental changes. Run time ada ptation in our appr oach leverages the idea of using soft ware mo dels at r un time introduced in Mo dels@Run.Time [32]. 7 Conclusion In this pap er we hav e presented a nov el solution for runtime adaptability that enables the system to provide different quality in o rder to meet the us e r QoS preferences. W e hav e intro duced negotiable maintenance goals to allow express - ing user prefer ences. Our appro a ch avoids misinterpretations of quality require- men ts by auto ma tically conv er ting user preferences in to mathematical for mulas ev alua ted at runtime. The solution g e nerates a computational mo del from the system requirements mo del a nd a nno tates it with QoS v a lues. The QoS v alues are up dated based on runtime informa tion to r eflect changes in the environment. The choice of the v aria nt executed a t run time is driv en by the negotiable maintenance goals a nd uses the up dated mo del. In this wa y our solution ensures that the system adapts to changes in the environment s o as to provide the qua lit y that bes t fulfills the user s different ex p ecta tio ns. The solution dep ends on the av aila bilit y of r un time infor mation. W e have ev alua ted our approach in tegr ating an e x isting monito ring system for BPEL pro cesses, a nd s hown that our selection str ategy selects the b est av aila ble v ar i- ant to fulfill different user q ua lit y requirements and that our sys tem ada pts to changes o f pa rameters w hich affect the provided quality . References 1. Op en Grid F orum: WS-Agreement specification. http://www.ogf .org/ d ocu- ments/ GFD.107.p df (2008) 2. Klusch, M., F ries, B., S ycara, K .P .: Owl s-mx : A hybrid semantic web service matc hmaker for owl-s services. J. W eb Sem. 7 (2) (2009) 121–133 3. Lamsw eerde, A.: Reasoning ab out alternativ e requirements options. In: Conceptual Modeling: F ound ations and App lications: Essa ys in Honor of John Mylop oulos, Berlin, Heidelb erg, Springer-V erlag (2009) 380–397 4. Chˆ atel, P ., Malenfant, J., T ruck, I.: Qos-b ased late-binding of service invocations in adapt ive business pro cesses. In : ICWS (2010) 227–234 5. W etzstein, B., Leitner, P ., Rosenberg, F., Brandic, I., Dustdar, S., Leymann, F.: Monitoring and analyzing influential factors of bu siness pro cess p erformance. In: EDOC (2009) 141–150 6. Mabrouk, N.B., Beauche, S ., K u znetso va , E., Georgan tas, N., Issarn y , V .: Qos- a ware service comp osition in dynamic service orien ted environments. In : Midd le- w are (2009) 1–20 7. Romano, J.: T esting Statistical Hyp oth eses. Berlin: Springer-V erlag (2005) 8. Mosincat, A ., Binder, W.: T ransparent Ru ntime Adaptability for BPEL Pro cesses. In: ICSOC (2008) 241–255 9. Mosincat, A., Binder, W.: Enhancin g BPEL Pro cesses with Self-tuning Behavior. In: SOCA ( 2009) 210–217 10. Xiao, H., Chan, B., Zou, Y ., Benay on, J.W., O’F arrell, B., Litani, E., H a wkins, J.: A Framew ork for V erifying SLA Compliance in Composed Services. In: ICWS (2008) 457–464 11. Mei, L., Chan, W.K., Tse, T.H.: An A d aptive Serv ice S election Approach to Service Composition. In: ICWS (2008) 70–77 12. Canfora, G., Di Pen ta, M., Esp osito, R., Villani, M.L.: A Framew ork for QoS- Awa re Binding and R e-binding of Composite W eb Services. Journal of Systems and Soft ware 81 (10) (2008) 1754–1769 13. Zeng, L., Benatallah, B., Ngu, A.H.H., Dumas, M., Kalagnanam, J., Chang, H .: QoS-Aware Middlew are for Web S ervices Comp osition. IEEE T rans. Softw are Eng. 30 (5) (2004) 311–327 14. Golshan, F., Barforoush, A .: A n ew approac h for tracing q ualit y attributes in service oriented architecture using graph transformation sy stems. In: CSICC (2009) 10 –16 15. Pistore, M., Barbon , F., Bertoli, P ., S haparau, D., T rav erso, P .: Planning and monitoring web service composition. In: A AAI ( 2004) 106–11 5 16. Lago, U.D., Pistore, M., T ra verso, P .: Planning with a language for ext ended goals. In: AAAI (2002) 447–454 17. Nitto, E.D., Pen ta, M.D., Gambi, A., Ripa, G., Villani, M.L.: Negotiation of service leve l agreements: A n architecture and a search-based approac h. I n: I CSO C (2007) 295–306 18. Chhetri, M.B., Lin, J., Goh, S., Zhang, J.Y., Kow alczyk , R., Y an, J.: A coordinated arc hitecture for the agent-based service lev el agreemen t negotiation ofw eb service composition. In: ASWEC (2006) 90–99 19. Com uzzi, M., Pernici, B.: An Architecture for Flexible Web Serv ice QoS Negotia- tion. In: EDOC (2005) 70–82 20. Nc ho, A ., A ¨ ımeur, E.: Building a multi-agen t sy stem for aut omatic negotiation in w eb service applications. In: AAMAS (2004) 1466–1467 21. Andrikopoulos, V., F ugini, M., Papazogl ou, M.P ., Parkin, M., Pernici , B., Siadat, S.H.: Qos contract formation and evolution. In: EC-WEB (2010) 119–130 22. Regev, G., Haya rd, O., Gause, D.C., W egmann, A .: T o ward a service management quality mod el. In: REFSQ (2009) 16–21 23. Epifani, I., Ghezzi, C., Mirandola, R., T am bu rrelli, G.: M o del evolutio n by run- time parameter adaptation. In: ICSE. (2009) 111–121 24. Meyn, S.P ., Tweedie, R.L.: Mark ov Chains and Sto chastic Stabilit y . London: Springer-V erlag (1993) 25. Baresi, L., P asquale, L.: Live goals for adaptive service comp ositions. In: SEAMS (2010) 114–123 26. Sheng, Q.Z., Benatallah, B., Maamar, Z., N gu , A.H.H.: Configurable composition and adaptive p ro visioning of web services. IEEE TSC 2 (1) (2009) 34–49 27. Hiel, M., W eigand, H., v an den Heuvel, W.J.: An adaptive service-oriented archi- tecture. In: IESA. (2008) 197–208 28. Dalpiaz, F., Giorgini, P ., Mylop oulos, J.: A n architecture for requirements-driven self-reconfiguration. In : CAiSE. (2009) 246–260 29. Mosincat, A ., Binder, W., Jaza yeri, M.: R u ntime adaptabilit y through automated mod el evolution. In: EDOC (2010) 217 –226 30. Gehlert, A., Hielscher, J., Danylevych, O., Karastoy anov a, D.: Online T esting, Re- quirements Engineering and Service F aults as Drivers for Adap t ing Service Com- p ositions. In: ServiceW av e 2008, MONA+, Springer Berlin Heidelb erg (2009) 31. Baresi, L., Bianculli, D., Ghezzi, C., Guinea, S., S p oletini, P .: V alidation of w eb service compositions. IET Softw are 1 (6) (2007) 219–232 32. Blair, G.S., Bencomo, N ., F rance, R.B.: Mo dels@ run.time. IEEE Computer 42 (10) (2009) 22–27