FULL TITLE
Agrajag: modelling workflow behaviour

KEYWORDS

QoS, SLA, Fault, Workflow

SUMMARY

One of our project goals has been to implement a system which will automate the process of choosing services and modifying workflows in order to satisfy dependability requirements. This involves integrating the quality-of-service (QoS) ontology, service level agreement (SLA), and fault tolerant container (FTC) elements of our work into a coherent whole — the SLA specifies the dependability requirements, and the FTC (in conjunction with a workflow engine) allows us to boost the dependability characteristics of component services in order to meet the SLA. To link these up, we need to choose services and FTC policies which will best satisfy the SLA — but in order to make the right choices, we need to understand what the consequences of each choice would be in context of the target workflow.

Agrajag requires:

• A simplified description of the workflow
• Performance models for the candidate services detailing all of the QoS characteristics the SLA is concerned with (for example how quickly they run, or what their availability is)
• Information describing how FTC policies (such as “run these three, but take the first result as soon as you get it” or “run these five, and require that the majority agree on the result”) will affect the QoS characteristics of the candidate services

Agrajag calculates the aggregate QoS characteristics for the entire workflow. This makes it possible to choose the particular services and FTC policies which will best match the desired dependability requirements
Agrajag can model SLA-relevant characteristics as distributions (probability density functions / cumulative distribution functions), which means that the objects it generates representing individual workflow instances can answer queries common in SLAs (such as “What is the average time to complete?” or “Will 90% of requests be serviced in less than 5 seconds?”).

Links

Papers

Author

Conrad Hughes