Holistic Grid Workflow Environment

a-ma-de-us
   HOME       DETAILS       PUBLICATIONS       PEOPLE       LINKS   
 
Project Details
 
 

Visualisation

 visualisation
 planning
 execution
A user may specify the workflow with Teuta by composing the predefined elements of UML-based DSL for QoS-aware workflows. Furthermore, for each workflow element different parameters (such as execution time, price, location affinity) may be specified that determine the user's QoS requirements. Thereafter, Teuta verifies whether the specified workflow is well defined. In the case that the workflow model is well defined, Teuta generates the corresponding QoWL representation.

Screenshots of the Amadeus frontend with Teuta:

Teuta / Amadeus

Teuta / Amadeus  Teuta / Amadeus

Planning
The workflows specified with Teuta are translated into abstract QoWL. The abstract QoWL is transformed into a concrete workflow using the QWL engine. The aim of this component is to automate the selection of services in accordance with the requested QoS. Workflow planning comprises the following phases:
  • Selection of the workflow optimization strategy
  • QoS-aware workflow reduction
  • Negotiation
  • Workflow optimization

We distinguish between static and dynamic workflow planning strategies. The decision whether static or dynamic planning techniques should be used, depends on the meta data of the invoked services. If all meta data required for performance prediction is statically known (e.g. the size of the input file), the static planning strategy can be selected. If the meta data is generated or changed during workflow execution, the dynamic planning approach has to be used. Static planning implies the generation of the concrete workflow before the execution of the first workflow activity. In the case of the dynamic planning approach the concrete parts of the workflow are created for the ready-to-start activities during the workflow execution. The Meta Data Flow Analyzer (MDFA) verifies whether the static planning approach is feasible.

The planning for real-world workflows is a NP-hard problem. But, the task of workflow planning may be alleviated by reducing the complexity of the workflow. Commonly, Grid workflows are composed of several activities where some of them are time intensive, cost intensive or security relevant. Such activities determine the QoS of the overall workflow. Other kinds of activities (e.g. control tasks) that do not significantly affect the overall QoS may be neglected during the optimization phase of the workflow planning.

Based on the selected optimization strategy the WF Negotiator queries the specified registries, generates necessary requested QoS and receives offered QoS from services. For the workflow planning only activities selected during the workflow reduction phase are considered.

In case that user's requirements are specified in form of global QoS constraints (GC), analytical or heuristic solvers are needed in order to find services that satisfy the QoS constraints. We apply the Integer Programming (IP) method using the lp_solve package.

Execution
  The outcome of the workflow planning phase is a concrete workflow which is ready for execution. In the case of static planning approach the workflow execution phase is started after the completion of workflow planning phase. But, in the case of dynamic planning the execution and planning phases are performed for each activity of the workflow in an alternate fashion. Figure below illustrates the relationship of workflow planning and execution phases.

Static workflow execution  Dynamic workflow execution

Static workflow planning involves the following steps:

  • Strategy Selection
  • WF Reduction
  • WF Negotiation
  • WF Optimization

For the static planning approach global constraints (GC), such as maximum price of the workflow, are specified for the whole workflow. If GCs can not be satisfied after the WF Negotiation and WF Optimization, the workflow is reduced by excluding the first activity of the workflow. The excluded activity is optimized separately from the rest of the workflow by searching for the candidate service that offers the best QoS. In the next iteration only the reduced workflow is considered. However, the user may annotate each activity with the expected average runtime in order to increase the chance to find a solution with fewer iterations. If the GCs are satisfied, the WF execution may start.

In case the execution of certain activities modifies the meta data, the dynamic workflow planning is applied. For each activity A(m) the negotiation and optimization is performed individually before the execution. After the execution of activity A(m), the next activity A(m+1) is considered. This iterative process of dynamic planning is completed when all activities of the workflow are executed.