Quality of Service for Workflows and Web Service Processes

Transcription

1 Joural of Web Sematics (accepted, to appear 2004), Elsevier. Quality of Service for Workflows ad Web Service Processes Jorge Cardoso 1, Amit Sheth 2, Joh Miller 2, Joatha Arold 3, ad Krys Kochut 2 1 Departameto de Matemática e Egeharias Uiversidade da Madeira Fuchal Portugal 2 LSDIS Lab, Departmet of Computer Sciece 3 Fugal Geome Resource laboratory, Departmet of Geetics Uiversity of Georgia Athes, GA USA Abstract Workflow maagemet systems (WfMSs) have bee used to support various types of busiess processes for more tha a decade ow. I workflows or Web processes for e-commerce ad Web service applicatios, suppliers ad customers defie a bidig agreemet or cotract betwee the two parties, specifyig Quality of Service (QoS) items such as products or services to be delivered, deadlies, quality of products, ad cost of services. The maagemet of QoS metrics directly impacts the success of orgaizatios participatig i e-commerce. Therefore, whe services or products are created or maaged usig workflows or Web processes, the uderlyig workflow egie must accept the specificatios ad be able to estimate, moitor, ad cotrol the QoS redered to customers. I this paper, we preset a predictive QoS model that makes it possible to compute the quality of service for workflows automatically based o atomic task QoS attributes. We also preset the implemetatio of our QoS model for the METEOR workflow system. We describe the compoets that have bee chaged or added, ad discuss how they iteract to eable the maagemet of QoS. 1 Itroductio With the advet ad evolutio of global scale ecoomies, orgaizatios eed to be more competitive, efficiet, flexible, ad itegrated i the value chai at differet levels, icludig the iformatio system level. I the past decade, Workflow Maagemet Systems (WfMSs) have bee distiguished due to their sigificace ad their impact o

2 orgaizatios. WfMSs allow orgaizatios to streamlie ad automate busiess processes ad reegieer their structure; i additio, they icrease efficiecy ad reduce costs. Several researchers have idetified workflows as the computig model that eables a stadard method of buildig Web service applicatios ad processes to coect ad exchage iformatio over the Web (Che, Dayal et al. 2000; Leyma 2001; Shegalov, Gillma et al. 2001; Fesel ad Bussler 2002). The ew advaces ad developmets i e-services ad Web services set ew requiremets ad challeges for workflow systems. Oe importat missig requiremet is the maagemet of Quality of Service (QoS). Orgaizatios operatig i moder markets, such as e-commerce activities ad distributed Web services iteractios, require QoS maagemet. Appropriate cotrol of quality leads to the creatio of quality products ad services; these, i tur, fulfill customer expectatios ad achieve customer satisfactio. While QoS has bee a major cocer i the areas of etworkig (Cruz 1995; Georgiadis, Gueri et al. 1996), real-time applicatios (Clark, Sheker et al. 1992) ad middleware (Ziky, Bakke et al. 1997; Frolud ad Koistie 1998; Hiltue, Schlichtig et al. 2000), few research groups have cocetrated their efforts o ehacig workflow systems to support Quality of Service maagemet. Most of the research carried out to exted the fuctioality of workflow systems QoS has oly bee doe i the time dimesio, which is oly oe of the dimesios uder the QoS umbrella. Furthermore, the solutios ad techologies preseted are still prelimiary ad limited (Eder, Paagos et al. 1999). The idustry has a major iterest o the QoS of workflows ad workflow systems. Curretly, ad-hoc techiques ca be applied to estimate the QoS of workflows. For orgaizatios, beig able to characterize workflows based o QoS has four distict advatages. (1) QoS-based desig. It allows orgaizatios to traslate their visio ito their busiess processes more efficietly, sice workflow ca be desiged accordig to QoS metrics. For e-commerce processes it is importat to kow the QoS a applicatio will exhibit before makig the service available to its customers. (2) QoS-based selectio ad executio. It allows for the selectio ad executio of workflows based o their QoS, to better fulfill customer expectatios. As workflow systems carry out more complex ad missio-critical applicatios, QoS aalysis serves to esure that each applicatio meets user requiremets. (3) QoS moitorig. It makes possible the moitorig of workflows based o QoS. Workflows must be rigorously ad costatly moitored throughout their life cycles to assure compliace both with iitial QoS requiremets ad targeted objectives. QoS moitorig allows adaptatio strategies to be triggered whe udesired metrics are idetified or whe threshold values are reached. (4) QoS-based adaptatio. It allows for the evaluatio of alterative strategies whe workflow adaptatio becomes ecessary. I order to complete a workflow accordig to iitial QoS requiremets, it is ecessary to expect to adapt, repla, ad reschedule a workflow i respose to uexpected progress, delays, or techical coditios. Whe adaptatio is ecessary, a set of potetial alteratives is geerated, with the objective of chagig a workflow as its QoS cotiues to meet iitial requiremets. For each alterative, prior to actually carryig out the 2

3 adaptatio i a ruig workflow, it is ecessary to estimate its impact o the workflow QoS. This paper is composed of two parts. The first part presets a comprehesive model for the specificatio of workflow QoS as well as methods to compute ad predict QoS. We start by ivestigatig the relevat QoS dimesios that are ecessary to correctly characterize workflows. We ot oly target the time dimesio, but also ivestigate other dimesios required to develop a usable workflow QoS model. Oce the QoS model is defied, algorithms are ecessary to compute the QoS of workflows. Quality metrics are associated with tasks, ad tasks compose workflows. The computatio of workflow QoS is doe based o the QoS of the tasks that compose a workflow. The secod part of this paper describes the ehacemets that eed to be made to workflow systems to support processes costraied by QoS requiremets. The ehacemets iclude the implemetatio of a QoS model, the implemetatio of algorithms to compute ad predict workflow QoS, ad the implemetatio of methods to record ad maage QoS metrics. These ehacemets have bee carried out for the METEOR system (Kochut, Sheth et al. 1998) to allow the specificatio, recordig, ad computatio of QoS. The support of QoS requires the modificatio ad extesio of several workflow system compoets, ad the developmet of additioal modules. While the implemetatio was made for the METEOR system ad the developmet is based o a specific coceptual model, the mai ideas preseted i this study ca be applied to the vast majority of workflow systems available. This paper is structured as follows. Sectio 2 describes a workflow process that illustrates a real world sceario, which will be used to exemplify QoS through the rest of the paper. Based o our sceario, a set of ew requiremets is derived ad the curret limitatios of WfMSs techology are stated. I sectio 3, we itroduce our workflow QoS model ad describe each of its dimesios. Sectio 4 describes how the quality of service of workflow tasks is calculated. Sectio 5 described how QoS estimates are set. I Sectio 6, we preset a algorithm to compute ad estimate workflow QoS. Sectio 7 is extesive ad describes the modificatio of existig workflow system compoets ad the creatio of ew modules that have bee developed to support the workflow QoS maagemet for the METEOR system. Each of the workflow compoets ad ew modules are aalyzed idividually. Sectio 8 presets a example of how to compute the QoS for the workflow itroduced i our iitial sceario. Sectio 9 discusses the related work i the QoS area. Fially, sectio 10 presets our coclusios. 2 Workflows, Tasks, Web services, ad Web processes Web services ad e-services have bee aouced as the ext wave of Iteret-based busiess applicatios that will dramatically chage the use of the Iteret (Fabio Casati, Mig-Chie Sha et al. 2001). With the developmet ad maturity of ifrastructures ad solutios that support e-services, we expect orgaizatios to icorporate Web services as part of their busiess processes. While i some cases Web services may be utilized i a isolated form, it is atural to expect that Web services will be itegrated as part of workflows (Fesel ad Bussler 2002). The icreasigly global ecoomy requires advaced iformatio systems such as those supportig multi-eterprise ad Web-scale 3

4 processes. Importat developmets have already bee made with the costructio of systems to support workflows (eterprise level), distributed workflows (iter-eterprise ad B2B level), ad Web processes (global level) (Bussler 2003). I the QoS model preseted i this paper, tasks ad Web services ca be treated with o differece. Workflow systems require tasks to have a structure which icludes iformatio such as task ame, formal parameters, relevat data, ad ivoked applicatios. Web services iclude the same kid of iformatio. For example, i METEOR workflow system (Kochut, Sheth et al. 1999), busiess tasks have bee wrapped with CORBA objects to eable a trasparet remote ivocatio. With recet techological developmets, a busiess task ca ow be wrapped with a Web service iterface. Oe of the advatages of usig Web services is to eable easier ad greater iteroperability ad itegratio amog systems ad applicatios. The aalogy draw betwee tasks ad Web services is also valid for workflows ad Web processes. Workflows represet the automatio of a busiess process, i whole or part, durig which documets, iformatio or tasks are passed from oe participat to aother for actio, accordig to a set of procedural rules ad are made of elemets which comprise trasitios, logic coditios, data flows, parallel ad coditioal buildig blocks, startig ad edig poits, splits, ad jois. Web processes have precisely the same characteristics. These allows us to coclude that Web processes ca be viewed as workflows that maage Web services istead of tasks (Cardoso ad Sheth 2003). Therefore, throughout this paper, the term task or workflow task correspods to a traditioal workflow task or a Web service. It will later become evidet that i order for our model to be applied to workflows or Web processes, tasks or Web service oly have to adhere to the QoS model. 3 Sceario The Fugal Geome Resource laboratory (FGR 2002) at the Uiversity of Georgia has realized that to be competitive ad efficiet it must adopt a ew ad moder iformatio system ifrastructure. Therefore, a first step was take i that directio with the adoptio of a workflow maagemet system (METEOR (Kochut, Sheth et al. 1999)) to support its laboratory processes (Hall, Miller et al. 2003). Sice the laboratory supplies several geome services to its customers, the adoptio of a WfMS has eabled the logic of laboratory processes to be captured i a workflow schema. As a result, all the services available to customers are stored ad executed uder the supervisio of the workflow system. 3.1 Workflow Structure Before discussig this sceario i detail, we review the basis elemets of the METEOR workflow model. A workflow is composed of tasks, etworks ad trasitios. Tasks are represeted usig circles, etworks (sub-workflows) usig rouded rectagles, ad trasitios are represeted usig arrows. Trasitios express depedecies betwee tasks ad are associated with a eablig probability (p 1, p 2,.., p ). Whe a task has oly oe outgoig 4

5 trasitio, the eablig probability is 1. I such a case, the probability ca be omitted from the graph. A task with more tha oe outgoig trasitio ca be classified as a ad-split or xor-split. Ad-split tasks eable all their outgoig trasitios after completig their executio. Xor-split tasks eable oly oe outgoig trasitio after completig their executio. Ad-split tasks are represeted with a * ad xor-split tasks are represeted with a +. A task with more tha oe icomig trasitio ca be classified as a ad-joi or xor-joi. Ad-joi tasks start their executio whe all their icomig trasitios are eabled. Xor-joi tasks are executed as soo as oe of the icomig trasitios is eabled. As with ad-split ad xor-split tasks, ad-joi tasks ad xor-joi tasks are represeted with the symbol * ad +, respectively. Whe o symbol is preset to idicate the iput or output logic of a task, the it is assumed to be a xor. 3.2 Workflow Descriptio Geomic projects ivolve highly specialized persoel ad researchers, sophisticated equipmet, ad specialized computatios ivolvig large amouts of data. The characteristics of the huma ad techological resources ivolved, ofte geographically distributed, require a sophisticated coordiatio ifrastructure to maage ot oly laboratory persoel ad equipmet, but also the flow of data geerated. Oe of the services supplied by the research laboratory is the DNA Sequecig workflow. A simplified versio of the DNA Sequecig workflow is depicted i Figure 1. p 1 + t 1 + t 5 p 2 t 6 t 7 t 8 Setup t 2 t 3 t 4 Test Quality Get Sequeces Sequece Processig Proces Report Prepare Sample Prepare Cloes ad Sequece Assembly Figure 1 DNA Sequecig workflow The workflow is composed of eight mai tasks: Setup, Prepare Sample, Prepare Cloe ad Sequece, Assembly, Get Sequeces, Sequece Processig, ad Process Report. Each idividual task carries out a particular fuctio; if ecessary, the workflow ca be spread across multiple research ceters. The Setup task is resposible for iitializig iteral variables of the workflow process. The secod task, Prepare Sample, cosists of isolatig DNA from a biological sample. The samples ca be prepared usig a variety of protocols. These protocols eed to be followed rigorously i order to obtai DNA that is ot degraded i ay form. A correctly prepared sample will origiate a better DNA sequecig, sice the quality of the DNA template is oe of the most critical factors i DNA sequecig. 5

6 The task Prepare Cloes ad Sequece cloes specific regios of the geome from DNA isolated i the previous step. This step ca be fully automated by computer cotrol (usig, for example, a robotic system). This task also executes the sequecig, which uses DNA sequecig machies to read each biochemical letter (A, G, C or T) of a cloed DNA fragmet. The output is composed of short decoded segmets (a sequece such as AGGCATTCCAG ). The use of automated sequecers has revolutioized the field of bioiformatics by eablig scietists to catalogue sequece iformatio hudreds of times faster tha was possible with pre-existig scaig techiques. This ew approach allows for automatic recogitio, without major huma itervetio. The Assembly task aalyzes the DNA segmets geerated i the sequecig task. This step icludes the assembly of larger cotiguous blocks of sequeces of DNA from small overlappig fragmets. This is complicated by the fact that similar sequeces occur may times i may places of the geome. The Test Quality task screes for the Escherichia coli (E. coli) cotamiat i DNA cotigs. The cloes grow i bacterial hosts are likely to be cotamiated. A quick ad effective way to scree for the E. coli cotamiat is to compare a give DNA sequece to the E. coli geome. For E. coli, this task is made easier by the availability of its full geome. Get Sequeces is a simple task that dowloads the sequeces created i the assembly step, usig the FTP protocol. The Sequece Processig task aalyzes the DNA segmets geerated i the assembly step. The goal of this task is to fid DNA sequeces i order to idetify macromolecules with related structures ad fuctios. The ew DNA sequece is compared to a repository of kow sequeces (e.g., Swiss-Prot or GeBak), usig oe of a umber of computatioal biology applicatios for compariso. After obtaiig the desired data from the Sequece Processig task, the results are stored, ed, ad a report is created. The Process Report task stores the data geerated i the previous task i a database ad creates a fial report. It is resposible for electroically mailig the sequecig results to the persos ivolved i this process, such as researchers ad lab techicias. 3.3 Workflow Applicatio Requiremets I its ormal operatio, the Fugal Geome Resource laboratory executes the DNA Sequecig workflow i a regular maer. Workflow istaces are started i order to reder the sequecig services. I this sceario, ad with curret workflow techology, the executio of the workflow istaces is carried out without ay quality of service maagemet o importat parameters such as delivery deadlies, reliability, ad cost of service. The laboratory wishes to be able to state a detailed list of requiremets for the service to be redered to its customers. Its requiremets iclude the followig: The fial report has to be delivered i 31 weeks or less, as specified by the customer (e.g., NIH). The profit margi has to be 10%. For example, if a customer pays $1,100 for a sequecig, the the executio of the DNA Sequecig workflow must have a cost for the laboratory that is less tha $1,000. 6

7 I some situatios, the cliet may require a urget executio of DNA sequecig. Therefore, the workflow has to exhibit high levels of reliability, sice workflow failures would delay the sequecig process. The requiremets for the geetic workflow applicatio preseted uderlie three ofuctioal requiremets: time, cost, ad reliability. While the specificatio of such quality requiremets is importat, curret WfMSs do ot supply a model to delieate their specificatio or maagemet. Havig already give a good descriptio of the problem ad motivatig why a solutio is eeded for the specificatio ad maagemet of QoS, i the ext sectio we preset a QoS model which captures the specificatio of QoS metrics. This model is a basic stoe of our work, ad will be used, ot oly to specify the QoS, but also compute the QoS of workflows. 4 Workflow Quality of Service Workflow QoS represets the quatitative ad qualitative characteristics of a workflow applicatio ecessary to achieve a set of iitial requiremets. Quatitative characteristics ca be evaluated i terms of cocrete measures such as workflow executio time, cost, etc. Qualitative characteristics specify the expected services offered by the system, such as security ad fault-tolerace mechaisms. QoS should be see as a itegral aspect of workflows; therefore, it should be itegrated with workflow specificatios. The first step is to defie a workflow QoS model. 4.1 Characteristics of the QoS Model Oe of the most popular workflow classificatios distiguishes betwee ad hoc workflows, admiistrative workflows, ad productio workflows. This classificatio was first metioed by (McCready 1992). The mai differeces betwee these types iclude structure, repetitiveess, predictability, complexity, ad degree of automatio. The QoS model preseted here is better suited for productio workflows (McCready 1992) sice they are more structured, predictable, ad repetitive. Productio workflows ivolve complex ad highly-structured processes, whose executio requires a high umber of trasactio accessig differet iformatio systems. These characteristics allow the costructio of adequate QoS models for workflow tasks. I the case of ad hoc workflows, the iformatio, the behavior, ad the timig of tasks are largely ustructured, which makes the procedure of costructig a good QoS model more difficult ad complex. 4.2 Workflow QoS Model Quality of service ca be characterized accordig to various dimesios. We have ivestigated related work to decide which dimesios would be relevat to compose our QoS model. Our research targeted two distict areas: operatios maagemet for orgaizatios ad quality of service for software systems. The study of those two areas is 7

8 importat, sice workflow systems are widely used to model orgaizatioal busiess processes, ad workflow systems are themselves software systems. O the orgaizatioal side, Stalk ad Hout (1990) ad Rommel et al. (1995) ivestigated the features with which successful compaies assert themselves i competitive world markets. Their results idicated that success is related to the capability to compete with other orgaizatios, ad it is based upo three essetial pillars: time, cost, ad quality. Kobielus (1997) suggests that these dimesios should costitute the criteria that workflow systems should iclude ad might beefit from. O the software system side, Frolud ad Koistie preset a set of practical dimesios for distributed object systems reliability ad performace, which iclude TTR (time to repair), TTF (time to failure), ad availability. Chug et al., (2000) preset a framework, a set of tools, ad methodology to make system desig decisios based o aalysis o-fuctioal requiremets. Based o previous studies ad our experiece i the workflow domai, we have costructed a QoS model composed of the followig dimesios: time, cost, ad reliability. QoS specificatios are set for task defiitios. Based o this iformatio, QoS metrics are computed for workflows (see sectio 6). 4.3 Task Time Time is a commo ad uiversal measure of performace. The philosophy behid a timebased strategy usually demads that busiesses deliver the most value as rapidly as possible. Shorter workflow executio time allows for a faster productio of ew products, thus providig a competitive advatage. The first measure of time is task respose time (T). Task respose time correspods to the time a istace takes to be processed by a task. The task respose time ca be broke dow ito two major compoets: delay time ad process time. Delay time (DT) refers to the o-value-added time eeded i order for a istace to be processed by a task. This icludes, for example, the istace queuig delay ad the setup time of the task. While, those two metrics are part of the task operatio, they do ot add ay value to it. Process time (PT) is the time a workflow istace takes at a task while beig processed; i other words, it correspods to the time a task eeds to process a istace. Therefore, task respose time for a task t ca be computed as follows: T(t) = DT(t) + PT(t) The delay time ca be further broke dow ito queuig delay ad setup delay. Queuig delay is the time istaces sped waitig i a tasklist, before the istace is selected for processig. Setup delay is the time a istace speds waitig for the task to be set up. Setup activities may correspod to the warmig process carried out by a machie before executig ay operatio, or to the executio of self-checkig procedures. Aother time metric that may be cosidered to itegrate with the delay time is the sychroizatio delay, which correspods to the time a workflow istace waits for other istaces i a ad-joi task (sychroizatio). I our QoS model, this metric is ot part of the task respose time. This is because the algorithm we use to estimate workflow QoS 8

9 ca derive this metric directly from the workflow structure ad from the task respose time. This will become more clear whe we describe workflow QoS computatio. Breakig task respose time ito various pieces is importat sice it gives a more detailed model to be used by busiess aalysts. Each piece correspod to a importat attribute that eeds to be aalyzed ad should ot be overlooked. I may situatios the differet attributes are set by differet people. 4.4 Task Cost Task cost represets the cost associated with the executio of workflow tasks. Durig workflow desig, both prior to workflow istatiatio ad durig workflow executio, it is ecessary to estimate the cost of the executio i order to guaratee that fiacial plas are followed. The cost of executig a sigle task icludes the cost of usig equipmet, the cost of huma ivolvemet, ad ay supplies ad commodities eeded to complete the task. The followig cost fuctios are used to compute the cost associated with the executio of a task. Task cost (C) is the cost icurred whe a task t is executed; it ca be broke dow ito two major compoets: eactmet cost ad realizatio cost. C(t) = EC(t) + RC(t) The eactmet cost (EC) is the cost associated with the maagemet of the workflow system ad with the moitorig of workflow istaces. The realizatio cost (RC) is the cost associated with the rutime executio of the task. It ca be broke dow ito: direct labor cost, machie cost, direct material cost, ad setup cost. Direct labor cost is the cost associated with the perso carryig out the executio of a workflow huma task (Kochut, Sheth et al. 1999), or the cost associated with the executio of a automatic task with partial huma ivolvemet. Machie cost is the cost associated with the executio of a automatic task. This ca correspod to the cost of ruig a particular piece of software or the cost of operatig a machie. Direct material cost is the cost of the materials, resources, ad ivetory used durig the executio of a workflow task. Setup cost is the cost to set up ay resource used prior to the executio of a workflow task. The EC ad RC captures the distictio betwee the ruig costs of the workflow system deploymet, operatio, maiteace ad moitorig vs. the costs associated with the executio of tasks. 4.5 Task Reliability To model the reliability dimesio of workflows, we have used cocepts from system ad software reliability theory (Hoylad ad Rausad 1994; Ireso, Jr. et al. 1996; Musa 1999). The reliability aalysis of systems ofte uses reliability block diagrams (RBD) as a represetatio of how the compoets of a system are coected. Elemetary cofiguratios of a RBD iclude the series ad parallel cofiguratios. Our approach is to create a mappig betwee RBD ad workflow structures. This allows us to view a workflow as a system of idepedet compoets which ca be the modeled ad 9

10 aalyzed usig similar fuctios applied to RBD. The first step is to model the reliability of a idividual task. Task reliability (R) models what ca be cosidered the most importat class of workflow failures, task failures (Eder ad Liebhart 1996) (also kow as activity failures). Task failures ca be orgaized ito two mai classes: system failures ad process failures ((Eder ad Liebhart) calls this secod type of failures, sematic failures). System failures. These cosist of iformatio techology ad software failures which lead to a task termiatig abormally. Iformatio techology ad software iclude operatig systems, commuicatio protocols, hardware, etc. For example, a task maager is ot able to cotact its task because the CORBA server maagig the task has failed due to a system breakdow is a system failure. Process failures. These cosist of busiess process exceptios which lead to a aomalous termiatio of a task. I a workflow, task structure (Krishakumar ad Sheth 1995) has a iitial state, a executio state, ad two distict termiatig states. For otrasactioal tasks, oe of the termiatig states idicates that a task has failed, while the other state idicates that a task is doe ( Figure 2). For trasactioal ad ope 2PC tasks, the termiatig states are aborted ad committed. The model used to represet each task idicates that oly oe startig poit exists whe performig a task, but two differet states ca be reached upo its executio. For example, a database access task fails because of a ivalid user password. The task eters the aborted state. Figure 2 - Two task structures (Krishakumar ad Sheth 1995) To describe task reliability we follow a discrete-time modelig approach. We have selected this solutio sice workflow task behavior is most of the time characterized i respect to the umber of executios. Discrete-time models are adequate for systems that respod to occasioal demads, such as database systems (i.e, discrete-time domai). This dimesio follows from oe of the popular discrete-time stable reliability models proposed i (Nelso 1973) ad it is show below. R(t) = 1 (system failure rate + process failure rate) System failure rate is the ratio betwee the umbers of time a task did ot perform for its users ad the umber of times the task was called for executio, i.e. #(usuccessful executios)/#(called for executio). Process failure rate provides iformatio cocerig the relatioship betwee the umber of times the state doe/committed is reached ad the 10

11 umber of times the failed/aborted state is reached after the executio of a task (see the task model structure show i Figure 2). It is calculated usig the formula #(failed or aborted)/(#(failed or aborted) + #(doe or commit)). Alteratively, cotiuous-time reliability models ca be used whe the failures of the malfuctioig equipmet or software ca be expressed i terms of times betwee failures, or i terms of the umber of failures that occurred i a give time iterval. Such reliability models are more suitable whe workflows iclude tasks that cotrol equipmet or machies that have failure specificatios determied by the maufacturer. Ireso, Jr et al. (1996) presets several software reliability models which ca be used to model this QoS dimesio. The ideal situatio would be to associate with each workflow task a reliability model represetig its workig behavior. While this is possible, we believe that the commo workflow system users do ot have eough kowledge ad expertise to apply such models. 5 Creatio of QoS Estimates I order to facilitate the aalysis of workflow QoS, it is ecessary to iitialize task QoS metrics ad also iitialize stochastic iformatio which idicates the probability of trasitios beig fired at rutime. Oce tasks ad trasitios have their estimates set, algorithms ad mechaisms, such as simulatio, ca be applied to compute overall workflow QoS. 5.1 Creatio of QoS Estimates for Tasks Havig previously defied the QoS dimesios for tasks, we ow target the estimatio of QoS metrics of tasks. The specificatio of QoS metrics for tasks is made at desig time ad re-computed at rutime, whe tasks are executed. Durig the graphical costructio of a workflow process, the busiess aalyst ad domai expert set QoS estimates for each task. The estimates characterize the quality of service that the tasks will exhibit at rutime. Settig iitial QoS metrics for some workflow tasks may be relatively simple. For example, settig the QoS for a task cotrollig a DNA sequecer ca be doe based o the time, cost, ad reliability specificatios give by the maufacturer of the DNA sequecer. I other cases, settig iitial QoS metrics may prove to be difficult. This is the case for tasks that heavily deped o user iput ad system eviromet. For such tasks, it is coveiet to study the workflow task based o real operatios. The estimates are based o data collected while testig the task. The idea is to test the task based o specific iputs. This ca be achieved by the elaboratio of a operatioal profile (Musa 1993). I a operatioal profile, the iput space is partitioed ito domais, ad each iput is associated with a probability of beig selected durig operatioal use. The probability is employed i the iput domai to guide iput geeratio. The desity fuctio built from the probabilities is called the operatioal profile of the task. At rutime, tasks have a probability associated with each iput. Musa (1999) described a detailed procedure for developig a practical operatioal profile for testig purposes. 11

12 The task rutime behavior specificatio is composed of two classes of iformatio (Table 1): basic ad distributioal. The basic class associates with each task s QoS dimesio the miimum value, average value, ad maximum value the dimesio ca take. For example, the cost dimesio correspods to the miimum, average, ad maximum cost associated with the executio of a task. The secod class, the distributioal class, correspods to the specificatio of a costat or of a distributio fuctio (such as Expoetial, Normal, Weibull, ad Uiform) which statistically describes task behavior at rutime. I some situatios it may ot be practical to derive a distributio fuctio, a alterative is to sample the distributio ad specify it i the form of a histogram rather tha a aalytical formula. For example, Table 1 ad Table 2 show the QoS dimesios for a automatic task (the SP FASTA task) ad for a maual task (the Prepare Sample task; see sectio 3.2 for tasks descriptios). Basic class Distributioal class Mi value Avg value Max value Dist. Fuctio Time Normal(0.674, 0.143) Cost Reliability - 100% Table 1 Task QoS for a automatic task Basic class Distributioal class Mi value Avg value Max value Dist. Fuctio Time Normal(196, 1) Cost Reliability - 100% Table 2 Task QoS for a maual task The values specified i the basic class are typically employed by mathematical methods i order to compute workflow QoS metrics, while the distributioal class iformatio is used by simulatio systems to compute workflow QoS (Chadrasekara, Silver et al. 2002; Miller, Cardoso et al. 2002). To devise values for the two classes, the desiger typically applies the fuctios preseted i the previous sectio to derive the task s QoS metrics. We recogize that the specificatio of time, cost, ad reliability is a complex operatio, which whe ot carried out properly ca lead to the specificatio of icorrect values. Additioally, the iitial specificatio may ot remai valid over time. To overcome this difficulty, a task s QoS values ca be periodically re-computed for the basic class, based o previous executios. The distributioal class may also eed to have its distributio re-computed. At rutime, the workflow system keeps track of actual values for the QoS dimesios moitored. QoS rutime metrics are saved ad used to recompute the QoS values for the basic class which were specified at desig time. The workflow system re-computes the QoS values for each dimesio; this allows the system to make more accurate estimatios based o recet istace executios. 12

13 The re-computatio of QoS task metrics is based o data comig from desiger specificatios ad from the workflow system log. Depedig o the workflow data available, four scearios ca occur: a) For a specific task t ad a particular dimesio Dim, the average is calculated based oly o iformatio itroduced by the desiger (Desiger Average Dim (t)); b) the average of a task t dimesio is calculated based o all its executios idepedetly of the workflow that executed it (Multi-Workflow Average Dim (t)); c) the average of the dimesio Dim is calculated based o all the times task t was executed i ay istace from workflow w (Workflow Average Dim (t, w)); ad d) the average of the dimesio of all the times task t was executed i istace i of workflow w (Istace Average Dim (t, w, i)). Sceario d) ca oly occur whe loops exist i a workflow. While the formulae preseted oly show how to compute average metrics, similar formulae are used to compute miimum ad maximum values. The task QoS for a particular dimesio ca be determied at differet levels; it is computed followig the equatios described i Table 3. a) QoS Dim (t) = Desiger Average Dim (t) b) QoS Dim (t) = wi 1 * Desiger Average Dim (t) + wi 2 * Multi-Workflow Average Dim (t) c) QoS Dim (t, w) = wi 1 * Desiger Average Dim (t) + wi 2 * Multi-Workflow Average Dim (t) + wi 3 *Workflow Average Dim (t, w) d) QoS Dim (t, w, i) = wi 1 * Desiger Average Dim (t) + wi 2 * Multi-Workflow Average Dim (t) + wi 3 * Workflow Average Dim (t, w) + wi 4 * Istace Workflow Average Dim (t,w, i) Table 3 QoS dimesios computed at rutime The workflow system uses the formulae from Table 3 to predict the QoS of tasks. The weights wi k are set maually. They reflect the degree of correlatio betwee the workflow uder aalysis ad other workflows for which a set of commo tasks is shared. The differet equatios are used based o the historical data available from past executios of tasks ad workflows. For example, if the workflow system does ot have ay historical data i its log describig the QoS metrics of task t, the the equatio a) will be used to predict a QoS model for task t. I the other had, if the workflow system log s cotais historical data describig the QoS metrics of task t, the equatio b), c) ad d) will be used to predict QoS metrics. The sectio of a equatio depeds o how much data is available. Let us assume that we have a istace i of workflow w ruig ad that we desire to predict the QoS of task t w. The followig rules are used to choose which formula to apply whe predictig QoS. If task t has ever bee executed before, the formula a) is chose to predict task QoS, sice there is o other data available. If task t has bee executed previously, but i the cotext of workflow w, ad w!= w, the formula b) is chose. I this case we ca assume that the executio of t i workflow w will give a good idicatio of its behavior i workflow w. If task t has bee previously executed i the cotext of workflow w, but ot from istace i, the formula c) is chose. Fially, if 13

14 task t has bee previously executed i the cotext of workflow w, ad istace i, meaig that a loop has bee executed, the formula d) is used. 5.2 Probabilities Estimates for Trasitios I the same way we seed tasks QoS, we also eed to seed workflow trasitios. Iitially, the desiger sets the trasitio probabilities at desig time. At rutime, the trasitios probabilities are re-computed. The method used to re-compute the trasitios probabilities follows the same lies of the method used to re-compute tasks QoS. Whe a workflow has ever bee executed, the values for the trasitios are obviously take from iitial desiger specificatios. Whe istaces of a workflow w have already bee executed, the the data used to re-compute the probabilities come from iitial desiger specificatios for workflow w, from other executed istaces of workflow w, ad if available, from the istace of workflow w for which we wish to predict the QoS. This correspods to the use of fuctios similar to the oes previously defied for tasks QoS (see Table 3). The iitializatio of tasks QoS metrics ad the iitializatio of stochastic iformatio idicatig the probability of trasitios beig fired at rutime give the ecessary data to carry out the QoS computatio of workflows. The QoS computatio is ivestigated i the ext sectio. 6 Workflow QoS Computatio Oce QoS estimates for tasks ad for trasitios are determied, we ca compute overall workflow QoS. We describe a mathematical modelig techique that ca be used to compute QoS metrics for a give workflow process. 6.1 Mathematical Modelig To compute QoS metrics for workflows based o task s QoS metrics we have developed the Stochastic Workflow Reductio (SWR) algorithm (Cardoso 2002). The SWR algorithm repeatedly applies a set of reductio rules to a workflow util oly oe atomic task (Kochut, Sheth et al. 1999) remais. Each time a reductio rule is applied, the workflow structure chages. After several iteratios oly oe task will remai. Whe this state is reached, the remaiig task cotais the QoS metrics correspodig to the workflow uder aalysis. Graph reductio rules have already bee successfully used to verify the correctess of workflows. Sadiq ad Orlowska (1999) preset a algorithm that employs a set of graph reductio rules to idetify structural coflicts i workflows. The algorithm starts by removig all structures from the workflow graph that are correct. This is achieved by iteratively applyig a coflict-preservig reductio process. The reductio process evetually reduces a structurally correct workflow to a empty graph. If the workflow is ot completely reduced, the structural coflicts exist. I our approach, the set of reductio rules that ca be applied to a give workflow correspods to the set of iverse operatios that ca be used to costruct a workflow. We 14

15 have decided to oly allow the costructio of workflows which are based o a set of predefied costructio systems; this protects users from desigig ivalid workflows. Ivalid workflows cotai desig errors, such as o-termiatio, deadlocks, ad splitig of istaces (Aalst 1999). Additioal reductio rules ca be developed. We have decided to preset the reductio cocept with oly six reductio rules, for three reasos. The first reaso is because a vast majority of workflow systems support the implemetatio of the reductio rules preseted. A study o fiftee major workflow systems (Aalst, Barros et al. 2000) show that most systems support, the reductio rules preseted. The study does ot discuss etwork patters. The etwork patter is iteded to provide a structural ad hierarchical divisio of a give workflow desig ito levels, i order to facilitate its uderstadig by the groupig of related tasks ito fuctioal uits. The secod reaso is that the reductio rules are simple, makig it easy to uderstad the idea behid the workflow reductio process. The last reaso is that these rules are supported by the METEOR workflow maagemet system ad form a basic set of rules that should be supported by ay moder workflow system. The algorithm uses a set of six distict reductio rules: (1) sequetial, (2) parallel, (3) coditioal, (4) fault-tolerat, (5) loop, ad (6) etwork. Reductio of a Sequetial System. Figure 3 illustrates how two sequetial workflow tasks t i ad t j ca be reduced to a sigle task t ij. I this reductio, the icomig trasitios of t i ad outgoig trasitio of tasks t j are trasferred to task t ij. t i t j t ij (a) (b) Figure 3 - Sequetial system reductio This reductio ca oly be applied if the followig two coditios are satisfied: a) t i is ot a xor/ad split ad b) t j is ot a xor/ad joi. These coditios prevet this reductio from beig applied to parallel, coditioal, ad loop systems. To compute the QoS of the reductio, the followig formulae are applied: T(t ij ) = T(t i ) + T(t j ) C(t ij )= C(t i ) + C(t j ) R(t ij ) = R(t i ) * R(t j ) Reductio of a Parallel System. Figure 4 illustrates how a system of parallel tasks t 1, t 2,, t, a ad split task t a, ad a ad joi task t b ca be reduced to a sequece of three tasks t a, t 1, ad t b. I this reductio, the icomig trasitios of t a ad the outgoig trasitio of tasks t b remai the same. The oly outgoig trasitios from task t a ad the oly icomig trasitios from task t b are the oes show i the figure below. 15

16 t 1 t a * t 2 * t b t a t 1 t b t (a) (b) Figure 4 - Parallel system reductio The QoS of tasks t a ad t b remai uchaged. To compute the QoS of the reductio the followig formulae are applied: T(t 1 ) = Max I {1..} {T(t i )} C(t 1 ) = C(t i ) 1 i. R(t 1 ) = 1 i. R(t i ) Reductio of a Coditioal System. Figure 5 illustrates how a system of coditioal tasks t 1, t 2,, t, a xor split (task t a ), ad a xor joi (task t b ) ca be reduced to a sequece of three tasks t a, t 1, ad t b. Task t a ad task t b do ot have ay other outgoig trasitios ad icomig trasitios, respectively, other tha the oes show i the figure. I this reductio the icomig trasitios of t a ad outgoig trasitio of tasks t b remai the same p a1 t 1 t a + p a2 t 2 + t b t a t 1 t b p a t (a) (b) Figure 5 - Coditioal system reductio The QoS of tasks t a ad t b remai uchaged. To compute the QoS of the reductio the followig formulae are applied: 16

17 T(t 1 ) = 1 i. C(t 1 ) = 1 i. R(t 1 ) = 1 i. p ai * T(t i ) p ai * C(t i ) p ai * R(t i ) Reductio of a Loop System. Loop systems ca be characterized by simple ad dual loop systems. Figure 6 illustrates how a simple loop system ca be reduced. A simple p oi i= 1 loop system i task t i ca be reduced to a task t li. I this reductio, p i + = 1. Oce the reductio is applied, the probabilities of the outgoig trasitios of task t li are p ok chaged to p lk =, ad p lk = 1. I the reductio of a loop system the loop is 1- pi k = 1 removed. Sice the loop is removed we eed to update the remaiig outgoig trasitios. Therefore, the probability of each outgoig trasitio eeds to be divided by the probability of the loop ot beig followed (i.e., 1-pi). p i t i + + p o1 + + t li p l1 (a) p o (b) p l Figure 6 Simple loop system reductio To compute the QoS of the reductio the followig formulae are applied: R(t li ) = T(t li ) = C(t li ) = T( t i ) 1- p i t C( i ) 1- p i (1- pi) * R( ti) 1- p R( t ) i i Figure 7 illustrates how a dual loop system ca be reduced. A dual loop system composed of two tasks t i ad t j ca be reduced to a sigle task t ij. I this reductio, 17

18 p oi i= 1 p i + = 1. Oce the reductio is applied, the probabilities of the outgoig trasitios of task tij are chaged to p lk = p ok 1- p i p lk k = 1 ad = 1. t j p j + + t i p o1 + + t ij p l1 (a) p o (b) p l Figure 7 Dual loop system reductio To compute the QoS of the reductio the followig formulae are applied: T(t ij ) = C(t ij ) = T( t i ) + T( t C( t ) + C( t i R(t ij ) = j j (1- p 1- p j ) (1- p ) ) (1- p )C( t (1- p ) (1- p )T( t ) R( t )R( t j j ) * R( t ) j i i j j j ) j j ) Reductio of a Fault-Tolerat System. Figure 8 illustrates how a fault-tolerat system with tasks t 1, t 2,, t, a ad split (task t a ), ad a xor joi (task t b ) ca be reduced to a sequece of three tasks t a, t 1, ad t b. The executio of a fault-tolerat system starts with the executio of task t a ad eds with the completio of task t b. Task t b will be executed oly if k tasks from the set {t 1, t 2,, t } are executed successfully. I this reductio, the icomig trasitios of t a ad the outgoig trasitio of tasks t b remai the same. The idea of this reductio system is to allow several tasks {t 1, t 2,, t } to be executed i parallel, carryig out the same fuctio but i a differet way, util k tasks have completed their executio. For example, i geomics several algorithms ca be used to query geome databases give a iitial probe. Let us assume that the tasks t 1, t 2,, t 5 are execute i parallel ad each task executes a distict algorithm. Usig a fault-tolerat system, we ca specify that the parallel executio of the tasks cotiues util two of them complete their executio. I this sceario, we cosider that the aswers of the first two queries to complete are sufficiet for the process to cotiue. 18

19 t 1 t a * t 2 K t b t a t 1 t b t (a) (b) Figure 8 Fault-Tolerat system reductio The QoS of tasks t a ad t b remai uchaged. To compute the QoS of the reductio the followig formulae are applied: The fuctio Mi(s) selects the set of the k smallest umbers from the set s, ad k fuctio g(x) is defied as followed: 0, x < 0 g ( x) = 1, x 0 T(t 1 ) = Mi T( t ),...,T( t )}) k ({ 1 1 R(t 1 ) = i 1 = 0 1 g( i = 0 j= 1 i j C(t 1 ) = 1 i. k) *((1 i ) + (2i 1 1 C(t I ) 1)R( t 1 )) *...*((1 i ) + (2i 1)R( t )) The formula R(t 1 ) is utilized to compute reliability ad correspods to the sum of all the probabilistic states for which at least k tasks execute successfully. A fault-tolerat system with tasks ca geerate 2 distict probabilistic states (the power set). The fuctio R(t 1 ) adds all the probabilistic states that leads to the successful executio of the fault-tolerat system (i.e. at least k tasks execute successfully). I the formula R(t 1 ), the summatio over i 1,, i geerates all the possible probabilistic states. Each probabilistic state is represeted with a biary sequece (i 1 i ) for which 0 represets the failig of a task, ad 1 represets its success. For example, i a fault-tolerat system with three parallel tasks (=3), the values of the idexes i 1 =1, i 2 =0, ad i 3 =1 represet the probabilistic state for which tasks t 1 ad t 3 succeed ad task t 2 fails. The term g( j= 1 i j k) is used to idicate if a probabilistic state should be cosidered i the reliability computatio. A probabilistic state is cosidered oly if the umber of tasks succeedig is greater or equal to k, i.e. i j k (or equivaletly i j k 0 ). I j = 1 j = 1 19

20 our previous example, sice i 1 =1, i 2 =0, i 3 =1 ad = 2, the probabilistic state (i1=1, i 2 =0, i 3 =1) will be oly cosidered if k 2. The reliability of a valid state (i.e., a state for which at least k tasks are executed successfully) is computed based o the product of the reliability of the tasks that compose the state. I our previous example, where i 1 =1, i 2 =0, i 3 =1, ad with k=2, the reliability of this state is g(2-2)*((1- i 1 )+(2i 1-1)R(t 1 ))*((1- i 2 )+(2i 2-1)R(t 2 ))*((1- i 3 )+(2i 3-1)R(t 3 )) which ca be reduced to 1*R(t 1 )*(1-R(t 2 ))*R(t 3 ). This correspods to the product of the probability of task t 1 to succeed, the probability of task t 2 to fail, ad the probability of task t 3 to succeed. i j j = 1 Reductio of a Network System. A etwork task represets a sub-workflow (Figure 9). It ca be viewed as a black box ecapsulatig a ukow workflow realizatio with a certai QoS. A etwork task s, havig oly oe task t i, ca be replaced by a atomic task t j. This reductio ca be applied oly whe the QoS of task t i is kow. I this replacemet, the QoS of the atomic task t j is set to the workflow QoS of the task t i, i.e, X(t j ) = X(t i ), X {T, C, R}. s t j t i (a) (b) Figure 9 - Network system reductio The iput ad output trasitios of the etwork task s are trasferred to the atomic task t j. 7 QoS Model Implemetatio I the previous sectios, we preseted a QoS model ad the SWR algorithm to address o-fuctioal issues of workflows, rather tha workflow process operatios. The model ad algorithm that we have developed has bee implemeted for the METEOR workflow maagemet system. The METEOR project is represeted by both a research system (METEOR 2002), ad a suite of commercial systems that provide a ope system based, high-ed workflow maagemet solutio, as well as a eterprise applicatio itegratio ifrastructure. The system has bee used i prototypig ad deployig workflow applicatios i various domais, such as bio-iformatics (Hall, Miller et al. 2003), healthcare (Ayawu, Sheth et al. 2003), telecommuicatios (Luo, Sheth et al 2003), defese (Kag, Froscher et al. 1999), ad uiversity admiistratio (CAPA 1997). 20

21 The METEOR system has two eactmet egies, ORBWork (Kochut, Sheth et al. 1999) ad WEBWork (Miller, Palaiswami et al. 1998). I this sectio we describe the compoets that make up the METEOR system ad the compoets that have bee modified, exteded, ad created to eable QoS maagemet i the cotext of the ORBWork egie. The work discussed i this paper is part of the research system ad is ot part of ay commercial product yet. It is ecessary to make chages to four mai compoets: the Eactmet, the Maager, the Builder, ad the Repository. These compoets ad their relatioship to the overall workflow system are illustrated i Figure 10. Simulatio System Task QOS Estimator B uses QoS Model uses Builder Istace Level A N1 E N2 F C D Cost Time Reliability Applicatio Dimesios System Dimesios A C B N1 E N2 F D Cotrol Flow Data flow QoS metrics Schema Level Workflow schema Load Create ad Maage workflow istaces Moitor QoS DBLog uses Repository Workflow Level WfMS compoets Maager Eactmet Service Moitor Workflow Istace QoS Data Workflow Tasks Trasitios QoS Istaces uses CORBA server, commuicatios, OS, Hardware, etc. Ifrastructure Level Figure 10 QoS Maagemet Architecture 7.1 Eactmet System The modificatios that have bee made to the ORBWork eactmet system iclude alteratios to the task schedulers, task maagers, tasks, ad moitors. I ORBWork eactmet system, task schedulers, ad tasks are resposible for maagig rutime QoS metrics. From the implemetatio poit of view, we divide the maagemet of the QoS dimesios ito two classes: the system ad the applicatio class. The dimesios of the system class are maaged by system compoets (e.g. a task scheduler), while the dimesios of the applicatios class are maaged by compoets dyamically created to support a particular workflow applicatio (e.g. a task implemetatio). I our system, the system class icludes the time ad reliability dimesios, while the applicatio class icludes the cost dimesio. Sice task schedulers decide the startig time of task executio ad are otified of task completio, they are resposible for maagig the dimesios of the system class. Task 21