Quality of Service for Workflows and Web Service Processes

Transcription

1 Wright State Uiversity CORE Scholar Ko.e.sis Publicatios The Ohio Ceter of Excellece i Kowledge- Eabled Computig (Ko.e.sis) Quality of Service for Workflows ad Web Service Processes Jorge Cardoso Amit P. Sheth Wright State Uiversity - Mai Campus, amit.sheth@wright.edu Joh A. Miller Wright State Uiversity - Mai Campus Joatha Arold Krzysztof J. Kochut Follow this ad additioal works at: Part of the Bioiformatics Commos, Commuicatio Techology ad New Media Commos, Databases ad Iformatio Systems Commos, OS ad Networks Commos, ad the Sciece ad Techology Studies Commos Repository Citatio Cardoso, J., Sheth, A. P., Miller, J. A., Arold, J., & Kochut, K. J. (2004). Quality of Service for Workflows ad Web Service Processes. Web Sematics: Sciece, Services ad Agets o the World Wide Web, 1 (3), This Article is brought to you for free ad ope access by the The Ohio Ceter of Excellece i Kowledge-Eabled Computig (Ko.e.sis) at CORE Scholar. It has bee accepted for iclusio i Ko.e.sis Publicatios by a authorized admiistrator of CORE Scholar. For more iformatio, please cotact corescholar@

2 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

3 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

4 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

5 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

6 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

7 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

8 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

9 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

10 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

11 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

12 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

13 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

14 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

15 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

16 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

17 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

18 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

19 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

20 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

21 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

22 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

23 realizatios are the cadidate compoets to maage the cost dimesio sice they iclude the ecessary fuctios to dyamically chage iitial estimates. 7.2 Maagig Time I sectio 2 we have described task respose time (T) as the time a istace takes to be processed by a task. Task respose time is composed of two major compoets: delay time (DT) ad process time (PT). Delay time is further broke dow ito queuig delay (QD) ad setup delay (SD). This makes the respose time of a task t represeted as followed: T(t) = DT(t) + PT(t) = QD(t) + SD(t) + PT(t) To efficietly maage the time dimesio, workflow systems must register values for each of the fuctios ivolved i the calculatio of task respose time (T). Curretly, we register values for all the fuctios, except for the setup delay. The time dimesio has its values set accordig to the task structure illustrated i Figure 11. Each state has bee mapped to oe of the fuctios that compose the time dimesio. ORBWork system follows this task structure to represet workflow task executio behavior (Krishakumar ad Sheth 1995). To more effectively support QoS maagemet, the origial structure has bee exteded, with the iclusio of the Pre-Iit, as show i Figure 11. Pre-Iit Iitial Executig Doe/Commit Failed/aborted Sychroizatio Delay Queuig Delay Task Respose Time Processig Time Task Reliability Figure 11 Revised task structure (exteded from (Krishakumar ad Sheth 1995)) The sychroizatio delay time is calculated based o the differece betwee the time registered whe a task leaves the pre-iit state ad the time registered whe it eters the state. A task t remais i the pre-iit state as log as its task scheduler is waitig for aother trasitio to be eabled i order to place the task ito a iitial state. This oly happes with sychroizatio tasks, i.e. ad-joi tasks (Kochut 1999), sice they eed to wait util all their icomig trasitios are eabled before cotiuig to the ext state. For all other types of iput ad output logic (xor-split, xor-joi, ad-split) the sychroizatio delay time is set to zero. As for the sychroizatio delay time, the queuig time is the differece betwee the time a task leaves ad eters the iitial state. A task i the iitial state idicates that the task is i a queue waitig to be scheduled (by its task scheduler). ORBWork task schedulers treat their queues with a FIFO policy. Oe iterestig queuig policy variatio 22

24 is associated with the schedulig of huma-tasks. For a huma-task istace, beig i the iitial state meas that the task has bee placed i a worklist for huma processig. A user ca select ay huma-task i a worklist, as log as the user role matches the task role. I this case, the queuig policy is SIRO (Serve I Radom Order). Depedig o the workflow system, other useful queuig policies ca be used, such as priority queues. Whe a task istace eters a queue a time-stamp is attached to it. Whe the task is removed from the queue for schedulig, aother time-stamp is attached to it so that the total queuig time ca be calculated later. Whe a task is ready to be executed it trasits to the executig state. As with the previous calculatios, the time a task remais i this state correspods to the processig time. Aother importat time metric is the sychroizatio delay (SycD). This measure correspods to the time ad-joi tasks sped waitig for all the icomig trasitios to be eabled. The SycD(t) of a task t is the differece of t b, the time registered whe all the icomig trasitios of task t are eabled, ad t a, the time registered whe the first icomig trasitio was eabled, i.e. t b - t a. This measure gives valuable iformatio that ca be used to re-egieer busiess processes to icrease their time efficiecy. 7.3 Maagig Reliability Whe a task is ready to execute, a task scheduler activates a associated task maager. The task maager ivokes ad oversees the executio of the task itself. Oce activated, the task maager stays active util the task itself completes. Whe the task has completed or termiated prematurely with a exceptio, the task maager otifies its task scheduler. Durig a task ivocatio or realizatio, a umber of udesirable evets may occur. Two distict types of failure may arise (see sectio 4.5): system failure ad process failure. A system failure occurs whe the task scheduler is ot able to create a task maager or whe a task maager is ot able to ivoke its task. A process failure occurs whe a exceptio is raised durig the realizatio of the task. A exceptio is viewed as a occurrece of some abormal evet that the uderlyig workflow maagemet system ca detect ad react to. If a exceptio occurs durig the realizatio of a task, it ca be placed i the doe or fail state (for o-trasactioal tasks) ad commit or abort (for trasactioal tasks). The former state idicates that the task executio was usuccessful, while the latter state idicates that a task is executed successfully (Krishakumar ad Sheth 1995). I our implemetatio, it is the resposibility of task schedulers to idetify the failures of a task ivocatio or executio i order to subsequetly set the reliability dimesio. Later this iformatio is used to compute the failure rate, which is the ratio betwee the umber of times the failed/aborted state is reached ad the umber of times a task was ivoked for executio plus the ratio betwee the umber of times the task scheduler is ot able to create a task maager or whe a task maager is ot able to ivoke its task ad the umber of times a task was scheduled for executio by the workflow system. 23

25 7.4 Maagig the Cost Task maagers are implemeted as a object ad are classified as trasactioal or otrasactioal, depedig o the task maaged. Huma tasks do ot have a associated task maager. The task maager is resposible for creatig ad iitializig a QoS cost data structure from QoS specificatios for the task oversee. Whe the supervised task starts its executio, the data structure is trasferred to it. If the task is a o-trasactioal oe (typically performed by a computer program), a set of methods is available to programmatically maage the iitial QoS estimates. No methods are supplied to chage the time ad reliability dimesios sice the task schedulers are resposible for cotrollig these dimesios. For trasactioal tasks (i.e. a database operatio), oly the time ad reliability dimesios are dyamically set at rutime. The cost dimesio, oce iitialized from the QoS specificatios, caot be chaged. This is because database systems do ot make available iformatio evaluatig the cost of the operatios executed. Oce the task completes its executio, the QoS data structure is trasferred back to the task maager, ad later from the task maager to the task scheduler. The oly resposibility of the task scheduler will be to icorporate the metrics registered for the time ad reliability dimesios (see sectio 4.2) ito the QoS data structure ad sed it to the moitor to be processed (see ext sectio). I the case of huma tasks (performed directly by ed-users), the QoS specificatios for the cost dimesio is icluded i iterface page(s) (as HTML templates) preseted to the ed-user. Whe executig a huma task, the user ca directly set the cost dimesio to values reflectig how the task was carried out. As metioed previously, huma-tasks do ot have a task maager associated with them, ad therefore a specific task scheduler is resposible for the task supervisio. Whe the task completes its realizatio, the task scheduler parses the iterface page(s) ad retrieves the ew QoS metrics that the user may have modified. 7.5 Moitor Whe workflows are istalled ad istaces are executed, the eactmet system geerates iformatio messages (evets) describig the activities beig carried out. The moitor is a idepedet compoet represeted by a object that records all of the evets for all of the workflows beig processed by the eactmet system. The DBlog is a suitable iterface that the moitor uses to store workflow rutime data i a database. The rutime data geerated from workflow istallatios ad istaces executio is propagated to the DBlog that will be i charge of storig the iformatio ito a specified database. The data model icludes metadata describig workflows ad workflow versios, tasks, istaces, trasitios, ad rutime QoS metrics. I additio to storig rutime QoS, we also store desiger-defied QoS estimates. The data model captures the iformatio ecessary to subsequetly ru suitable tools to aalyze workflow QoS. Oe of the primary goals of usig a database system loosely coupled with the workflow system is to eable differet tools to be used to aalyze QoS, such as project maagemet ad statistical tools. 24

26 DBlog is populated whe workflows are istalled ad istaces executed. The DBlog schema was desiged to store three distict categories of iformatio, reflectig workflow systems operatios with QoS maagemet. The first category correspods to data evets geerated whe workflows are istalled. Durig istallatio, iformatio describig workflow structure (which icludes tasks ad trasitios) is stored. The secod category of iformatio to be stored correspods to the QoS estimates for tasks ad trasitios that are specified at the workflow desig phase. The third category correspods to the iformatio which describes how istaces are behavig at rutime. This icludes data idicatig the tasks processig time, cost, ad the eablig of trasitios. The moitorig of trasitios is importat to build fuctios which probabilistically describe their eabled rate. The computatio of workflow QoS metrics is based o this stochastic structure. Sice the database stores real-time rutime iformatio of tasks QoS metrics, we are also ivestigatig the implemetatio of mechaisms to automatically otify or alert operators ad supervisors whe QoS metrics reach threshold values, so that corrective actios ca be take immediately. 7.6 Workflow Builder The workflow builder tool is used to graphically desig ad specify a workflow. I most cases, after a workflow desig o extra work is ecessary ad it ca be coverted automatically to a applicatio by a code geerator. The builder is used to specify workflow topology, tasks, trasitios (cotrol flow ad data flow), data objects, task ivocatio, roles, ad security domais (Kag, Park et al. 2001). Durig the desig phase, the desiger is shielded from the uderlyig details of the rutime eviromet ad ifrastructure, separatig the workflow defiitio from the eactmet system o which it will be istalled ad executed. To support workflow QoS maagemet the desiger must be able to set estimates for trasitio probabilities ad QoS estimates for tasks. This iformatio is later combied with historical data, which plays a larger role as more istaces are executed, to create a rutime QoS model for tasks ad a probability model for trasitios. The workflow model ad the task model have bee exteded to support the specificatio of QoS metrics. To support these extesios, the builder has bee ehaced to allow desigers to associate probabilities with trasitios ad to make possible the specificatio of iitial QoS metrics for tasks (see sectio 5.1). Previously, the workflow model oly icluded data flow mappigs associated with trasitios. The associatio of probabilities with trasitios trasforms a workflow ito a stochastic workflow. The stochastic iformatio idicates the probability of a trasitio beig fired at rutime. The QoS model specified for each task ad trasitios probabilities are embedded ito the workflow defiitio ad stored i XML format Settig Iitial Task QoS Estimates At desig time, each task receives iformatio which icludes its type, iput ad output parameters, iput ad output logic, realizatio, exceptios geerated, etc. All this iformatio makes up the task model. The task model has bee exteded to accommodate 25

27 the QoS model. Task QoS is iitialized at desig time ad re-computed at rutime whe tasks are executed. Durig the graphical costructio of a workflow process, each task receives iformatio estimatig its quality of service behavior at rutime. This icludes iformatio about its cost, time (duratio), ad reliability. The task QoS estimates are composed of two classes of iformatio (see sectio 5.1): basic ad distributioal. The basic class associates with each task QoS dimesio the estimates of the miimum, average, ad maximum values that the dimesio ca take. The secod class, the distributioal class, correspods to the specificatio of a distributio fuctio which statistically describes tasks behavior at rutime. Figure 12 illustrates the graphical iterface that is used to specify the basic ad distributioal iformatio to setup iitial QoS metrics. Figure 12 Task QoS basic ad distributioal class The values specified i the basic class are used by mathematical methods, while the distributioal class iformatio is used by simulatio systems. Oce the desig of a workflow is completed, it is compiled. The compilatio geerates a set of specificatio files ad realizatio files for each task. The specificatio files (Spec files) iclude iformatio describig the cotrol ad data flow of each task. The realizatio files iclude the operatios or istructios for a task to be executed at rutime. For huma tasks, HTML files are geerated, sice they are carried out usig a web browser. For o-trasactioal tasks, java code files are geerated ad compiled. At rutime, the executables are executed automatically by the eactmet system. Fially, for o-trasactioal tasks a file cotaiig the ecessary data to coect to databases is geerated. To eable the eactmet system to acquire ad maipulate QoS iformatio, the builder has bee exteded to geerate QoS specificatio files for each task. For huma tasks we have decided to embed the QoS metrics directly ito the HTML forms that are geerated Re-Computig QoS Estimates The iitial QoS specificatios may ot be valid over time. To overcome this difficulty we re-compute task QoS values for the basic class, based o previous executios, as described i sectio 5.1. The same applies for trasitios. The distributioal class also eeds to have its distributio re-computed. This ivolves the aalysis of rutime QoS 26

28 metrics to make sure that the QoS distributio fuctios associated with a task remai valid or eed to be modified. The re-computatio of QoS estimates for tasks ad for trasitio probabilities is doe based o rutime data geerated from past workflow executios that have bee stored i the database log. We have developed a QoS Estimator module that lies betwee the builder ad the database log. The QoS Estimator creates a QoS model for tasks based o the iformatio stored i the DBlog. It also calculates trasitio probability fuctios based o the trasitios eabled at rutime. Figure 13 illustrate the architecture of the QoS Estimator module. Whe a workflow is beig desiged, if the tasks selected to compose the workflow have bee previously executed, the their QoS metrics are recomputed automatically usig the QoS Estimator module. QoS QoS Model Model Costructio Costructio Trasitio Trasitio Probability Probability Statistical Computatio Database DB Coector Data Selectio Data Coversio Figure 13 QoS Estimator Module DB coector. The DB Coector is resposible for the establishmet of a coectio to the database. Curretly, we support relatioal databases that implemet the JDBC protocol. Data Selectio. The data selectio compoet allows for the selectio of task QoS metrics, as defied by the desiger ad tasks previously executed. Four distict selectio modes exist, ad for each oe a specific selectio fuctio has bee costructed. Each fuctio correspods to oe of the fuctios preseted to re-compute QoS estimates for tasks i sectio 5.1. The compoet ca select tasks QoS metrics from iformatio itroduced by the user at desig time, from tasks executed i the cotext of ay workflow, from tasks executed i the cotext of a specific workflow w, ad from tasks executed from a particular istace i of workflow w. Data Covertio. Oce a subset of the tasks preset i the database log is selected, the data describig their QoS may eed to be coverted to a suitable format i order to be processed by the Statistical Computatio compoet. The data coversio compoet is resposible for this coversio. For example, if the processig time of a task is stored usig its start executio date ad ed executio date, the data coversio compoet applies the fuctio f(t) = ed_executio_date(t) - start_executio_date(t) to compute the processig time (PT). As aother example, let us assume that the reliability of a task is stored i the database usig the keywords doe, fail, commit, ad abort (as i ORBWork). I this case, the data coversio compoet coverts the keywords doe ad commit to the value 1, idicatig the success of the task, ad coverts the keywords fail ad abort to the value 0, idicatig the failure of the task. This abstractio allows the statistical compoet to be idepedet from ay particular choice of storig rutime iformatio. 27

29 Figure 14 GUI to calculate QoS estimates Statistical Computatio. Oce a appropriate set of tasks has bee retrieved from the database ad their QoS data has bee coverted to a suitable format, it is trasferred to the statistical computatio compoet to estimate QoS metrics. Curretly, the module oly computes the miimum, average, ad maximum for QoS dimesios, but additioal statistical fuctios ca be easily icluded, such as stadard deviatios, average deviatio, ad variace. Four distict fuctios have bee developed to compute estimates for the tasks selected i the previous step. Each fuctio is to be used whe computig QoS dimesios ad correspods to four scearios that ca occur. Model Costructio. The QoS Model Costructio compoet uses the iformatio from the Statistical Computatio compoet ad applies a set of fuctios to re-compute the QoS model (the fuctios have bee preseted i Table 3) for each task. Figure 14 shows the graphical user iterface available to set the QoS fuctios ad their associated weights, ad to visualize the QoS estimates automatically computed for workflows, 28

30 istaces, tasks, ad trasitios. The QoS computatio is carried out usig the SWR algorithm (described i the ext sectio). 8 Workflow QoS Computatio Example The Fugal Geome Resource (FGR) laboratory is i the process of reegieerig their workflows. The laboratory techicias, domai experts, ad maagers have agreed that a alteratio to the Prepare ad Sequece ad Sequece Processig workflows would potetially be beeficial whe sequecig DNA. Figure 15 Prepare ad Sequece Workflow Figure 16 Sequece Processig Workflow To improve the efficiecy of the processes beig maaged by the workflow system, the bioiformatics researchers decided to merge the two processes. The researchers oticed that the quality of the DNA sequecig obtaied was i some cases useless due to E. coli cotamiatio. Additioally, it was felt that it would be advatageous to use other algorithms i the sequece processig phase. Therefore, to improve the quality of the process, the Test Quality task ad the SP FASTA task were added. Cloes grow i bacterial hosts are likely to become cotamiated. A quick ad effective way to scree for the Escherichia coli (E. coli) cotamiats is to compare the cloes agaist the E. coli geome. For E. coli, this task is made easier with the availability of its full geome. 29

31 The task SP FASTA has of the same objective of the task SP BLAST (a task of the sequece processig sub-workflow). Both tasks compare ew DNA sequeces to a repository of kow sequeces (e.g., Swiss-Prot or GeBak.) The objective is to fid sequeces with homologous relatioships to assig potetial biological fuctios ad classifyig sequeces ito fuctioal families. All sequece compariso methods, however, suffer from certai limitatios. Cosequetly, it is advatageous to try more tha oe compariso algorithm durig the sequece processig phase. For this reaso, it was decided to employ the BLAST (Altschul, Gish et al. 1990) ad FASTA (Pearso ad Lipma 1988) programs to compare sequeces. The followig actios were take to reegieer the existig workflows: a) Merge the Prepare ad Sequece workflow from Figure 15 ad the Sequece Processig workflow from Figure 16, b) Add the task Test Quality to test the existece of E. coli i sequeces, ad c) Execute the search for sequeces i geome databases usig a additioal search algorithm (FASTA). At this poit, the alteratios to itroduce ito the processes have bee idetified. From the fuctioal perspective, the lab persoel, domai experts, ad workflow desiger all agreed that the ew workflow will accomplish the iteded objective. The ew reegieered workflow is amed DNA Sequecig. It is illustrated i Figure 17. Figure 17 DNA Sequecig Workflow 8.1 Settig QoS Metrics While the workflow desig meets the fuctioal objectives, o-fuctioal requiremets also eed to be met. Prior to the executio of the ew workflow, a aalysis is ecessary to guaratee that the chages to be itroduced will actually produce a workflow that meets desired QoS requiremets, i.e., that the workflow time, cost, ad reliability remai 30