Article Preview
TopAutonomic Workflow Activities Using The Award Framework
The emergence of e-Science initiatives (Foster & Kesselman, 2003; Hine, 2006; NeSC, 2012) requires improved software tools and environments towards more productive modeling and experimentation with physical and virtual phenomena in diverse application domains. This involves complex computational processes for simulation, visualization, access to large data sets, and increasing degrees of interaction with the user.
The workflow paradigm, early adopted in the business context (Hollingsworth, 1995), is also useful for modeling scientific applications and allowing flexible mappings between the application abstractions and the underlying computing infrastructures.
Workflows have been used for developing scientific applications in many domains (Taylor et al., 2007; Yu & Buyya, 2005; Deelman et al., 2005; Chin et al., 2011). Such efforts have been supported by multiple workflow tools (Lazweski, 2011), as Triana (2011), Taverna (2011) and Kepler (Kepler project, 2011). However, there is still a need for improving the support provided by the workflow tools, as discussed for example in Deelman (2007), Deelman et al. (2009), Chin et al. (2011) and Assuncao et al. (2009):
- 1.
There is a need for a more clear separation of the application logic from the workflow enactment. The application developer often needs to understand details at the level of workflow engine. For example in Kepler, in order to develop a new Actor, the programmer needs to implement methods that are difficult to understand and are dependent on the enactment engine, e.g. preinitialize(); initialize(); prefire(); fire(); postfire() and wrapUp() (Kepler project, 2011);
- 2.
Although multiple workflows models allow parallel execution, e.g. by following the Process Networks (PN) model (Kahn, 1974), (Parks, 1995), as in Kepler (PN Director) (Kepler project, 2011) and in (Agun & Bowers, 2011), however in such systems activities are usually executed as threads within the same process, which then acts as a monolithic workflow engine. Furthermore, a unique central entity as the Kepler Director handles the global coordination. In order to enable a more flexible workflow management and easing the mappings of the workflow activities across Clusters, Grids, and Clouds, there is a need for more decentralized control and coordination of the workflow activities, designed as autonomic components with separate control and behavior;
- 3.
Flexibility in workflow management has been a long-term concern in business workflows (Dadam & Reichert, 2009), (Halliday et al., 2001), (Burkhart & Loos, 2010), but it has also been a trend towards enabling more complex scientific experiments. For example, allowing separate parts of a workflow to be launched or controlled individually by different users. Also allowing dynamic workflow reconfiguration, in response to changes in the application logic and behavior, e.g., in computational steering experiments, or interactive workflows. Although several approaches have been proposed (Ngu et al., 2008), (Yu & Buyya, 2010), there are still insufficient experimentation reports illustrating the feasibility of the above dimensions in real applications.