Using workflows for scientific calculations, experiments and simulations has been a success story in many cases. Unfortunately, most of the existing scientific workflow systems implement proprietary, non-standardized workflow languages, not taking advantage of the achievements of the conventional business workflow technology. It is only natural to combine these two research branches in order to harness the strengths of both. In this demonstration, we present Mayflower, a workflow environment that enables scientists to model workflows on the fly using extended business workflow technology. It supports the typical trial-and-error approach scientists follow when developing their experiments, computations or simulations and provides scientists with all crucial characteristics of the workflow technology. Additionally, beneficial to the business stakeholders, Mayflower brings additional simplification in workflow development and debugging.
The introduction of workflows to scientific computations and simulations has proven beneficial for scientists in many domains, e.g. image processing in physical astronomy [1], earthquake simulations in geology [2], or simulation regarding the biodiversity of species [3]. Workflows speedup scientific computations through automation and straightforward parallelization of tasks, reduce the programming effort for scientists, and improve traceability of scientific results. There is a broad spectrum of scientific workflow systems available, such as Kepler1, Triana2, Taverna3 and Pegasus4. Most of these systems have been developed from scratch, implement proprietary, nonstandardized workflow languages, and serve specific scientific application domains.
There are also approaches to enhance tools and concepts of the business workflow
technology in order to facilitate modeling and execution of scientific computations
and experiments [4, 5, 6]. We are convinced that the well-established conventional
workflow technology brings many advantages compared to existing solutions for
scientific workflows, namely: (
The life cycle of business workflows differs from that of their scientific counterpart [4]. That is one of the reasons why the current business workflow technology needs profound extension to be applicable in the scientific domain. Scientists develop software and workflows much more explorative and experimental in a trial-and-error manner [4, 6, 7]. They know the goal of their research but often not the exact way towards this goal or the exact (intermediary) results. That means the scientists approach their goals by trying out different parameter values, by adding or removing activities, by repeating steps of an experiment, or by using different solvers for equations. From the viewpoint of the conventional workflow technology the workflow modeling and runtime phases are not strictly separated, but they are experienced by scientists as a single phase because they can alternate arbitrarily. Furthermore, the workflows are not deployed by scientists. Instead, they are simply started and the workflow deployment is hidden behind a run operation. The scientists are the driver of all life cycle phases. They need a single, integrated, easy-to-use tool to deal with workflows in their respective phases without switching between the tools.
We call this flexible development of scientific workflows Model-as-you-go since
workflows are modeled on the fly during execution [4]. The approach simplifies
workflow modeling and increases the robustness of workflows because the user can
fix structural failures, repair the workflow context or handle runtime faults without
restarting the workflow. Model-as-you-go also integrates approaches for workflow
flexibility such as ad hoc adaptations, instance migration, versioning and ad hoc
backward loops. The challenges are (
In this demo, we present an implementation of the Model-as-you-go concepts: Mayflower, the Model-as-you-go Workflow Developer. Mayflower uses BPEL as workflow language and is built upon existing BPEL implementations, namely the Eclipse BPEL Designer5 as modeling tool and the Apache ODE6 as workflow engine. 5 http://eclipse.org/bpel/ 6 http://ode.apache.org/ The software makes development and debugging of BPEL workflows easier and hence can also be used in business scenarios. 2
Mayflower consists of five major parts (Fig. 1): (
(
Model and run workflows
Register servers and services, load simulation data
a) Simulation b) Service Context Registry
Check availability Find service c) Process
Management d) Deployment e) Logic
Adaptation f) Event
Publisher
Invoke service b) Integration
Layer a) Navigator e c a Iftrbn e e )hW
a) Execution
Control d) Versioning
b) Instance
Monitor e) Breakpoint f) Change Registry Tracking c) Adaptation
g) Server h) Service i) Context Mgmt. Mgmt. Mgmt.
j) Workflow k) Auditing l) Breakpoint
Mgmt. View View
(
resume, undeploy, … Load data
Publish
execution g) Context
events Access
started by the editor. It also correlates the workflow model in the engine with that in
the modeling framework, since they have different representations and identifiers.
(
Fig. 2 shows the user interface of Mayflower and some of its components: 1. Workflows can be started, suspended, resumed and terminated via a toolbar extension. 2. The instance monitor is an extension of the editor pane. Workflow models are enriched with instance information and the activities are colored according to their execution state (see the legend in Fig. 2). 3. The process instance state is displayed in the upper left corner of the editor pane. 4. Breakpoints can be specified in the properties of activities via the new debug tab.
One or more execution events of an activity can be registered as breakpoint. 5. A reached breakpoint is signaled via a highlighted activity. 6. The user can skip the breakpoint with the help of a toolbar function.
Fig. 2. Screenshot of Mayflower’s Modeling Framework with its main components.
We demonstrate Mayflower with the help of a use case for the simulation of the ageing process in copper-alloyed steel, an example of a solid-body simulation. The simulation computes how the atomic structure of steel changes when being operated over many years. The atoms exchange their positions and build precipitations or clusters that negatively influence the material properties (Fig. 3). We have re-engineered the simulation tool with the help of BPEL and Web services in order to speed up the simulation runtime through automation of formerly manual tasks and parallelizing postprocessing steps [9]. The workflow will be the basis for the demonstration.
The following aspects of Mayflower are shown: 1. Workflow modeling, execution and monitoring. The user can drag activities from the palette and drop them on the editor pane in order to specify the logic of the workflow. When a valid workflow model (fragment) is created, the user starts the workflow and puts in parameter values he is requested for by the tool. Monitoring of the running workflow starts automatically; the state is displayed by changing the activities’ color based on workflow execution events. 2. Usage of breakpoints. Breakpoints are specified in the properties of activities.
Workflow execution is paused when a breakpoint is reached. It is possible in parallel branches to pause one path while the other path continues. 3. Adaptation and Versioning. Modification of running workflows is experienced by scientists as workflow modeling: activities can be added, removed, or changed, while the process instance is already being executed. The changes are propagated to the engine with versioning and instance migration techniques. Furthermore, the user can inspect and change variable values and conduct ad hoc backward loops. 4. Ad hoc rerun of activities. The user can jump backwards to an arbitrary activity in the past of the workflow instance. He can select to compensate already completed work in the iteration body. As input for the next run of the activities it is possible to take either the current variable values or variable values that were valid at a former time step during workflow execution [11]. 5. Resource Management. Via the resource manager plug-in the user provides the servers and scientific services that should be taken for a simulation. He can monitor the workload in the system by having a look at the number of service requests and the number of granted service usage tickets. Furthermore, the user can inspect intermediary results in the simulation context [9].
The software is a prototypical implementation of the Model-as-you-go concept developed in the past three years in the scope of our work in the research cluster SimTech7. A demonstration video of the tool is available online8.
Acknowledgements. The authors would like to thank the German Research Foundation (DFG) for financial support of the project within the Cluster of Excellence in Simulation Technology (EXC 310/1) at the University of Stuttgart.