SimTech Logo SimTech Logo IAAS Logo

Projects Walkthrough

  1. Before automated execution of a simulation workflow can take place, the workflow has to be designed using a Modelling Tool. During the workflow design, the scientist specifies which services have to be invoked in order to perform the simulation. We devise a modelling environment that builds on business process technologies, though extended for the particular needs of a scientist. For example, the Modelling Tool needs to provide support for workflow fragments in order to ease service invocation and make the overall handling of the workflow design more comfortable. After the workflow has been designed it is ready for execution on a Workflow Engine.

  2. During the deployment phase the workflow model will be transformed into an engine-internal representation, installed on the Workflow Engine, and published as a Web service. In our prototype, the deployment of a workflow is part of the “Start/Resume” operation and therefore hidden for the scientists. After clicking the "Start/Resume" button an integrated deployment component automatically conducts all relevant steps.

  3. On receipt of a message the Workflow Engine instantiates a published workflow model (service) with provided input data, navigates through the graph of activities, triggers the execution of activity implementations and handles faults as well as events from the outside. In our prototype, a create-instance message is sent to the Workflow Engine as part of the “Start/Resume” operation after the deployment of the workflow model.

  4. While the Workflow Execution Engine triggers the execution of activity implementations the Service Bus invokes Web services that implement workflow activities, e.g. to solve matrix equations. Therefore the Service Bus discovers and selects services and resources, routes messages, and transforms data. Furthermore, it helps to prepare a simulation environment, e.g. by creating a specific directory structure or compiling source code. During service discovery the Service Bus queries registries to find suitable services (e.g. for result visualization) by means of descriptive information (functional or non-functional properties). In addition, it is responsible for the resource management. Since resources have different properties, the Service Bus is used, for instance, to identify servers or Grids that have enough storage capacity and calculation power to carry out a computationally intensive task.

  5. The Service Bus invokes Web services that make the actual functionality of simulation tools available, e.g. solvers or data handling tools. The Web service technology is an approach to provide and request services in distributed environments independent of programming languages, platforms, and operating systems. Existing non-Web service enabled software can be provided by so-called Web service wrappers or it can be extended with additional Web service functionality, e.g. to control the execution from outside the application by the Workflow Engine.

  6. Particular parts of the execution of a simulation workflow may require an interaction with a human before automatic processing can proceed. When the workflow execution engine reaches such a part in the simulation workflow, namely a simulation task, then all information required to fulfill that task is sent to the Simulation Task Manager. This information may, for instance, include a dataset that needs to be checked, a set of options the human user may choose from, or a link to an application. When accessing the Simulation Task Manager the human user can retrieve a list of tasks that currently need to be performed. Then, the simulation task is performed by the human user. For example, such a task may be to make a decision about further processing or aborting the simulation. When the human user has completed the simulation task, the workflow can continue processing at that particular part. Of course, such human tasks do not necessarily interrupt the simulation workflow in total, but just one branch in the workflow graph.

  7. Scientific/Simulation workflows are often developed in an iterative, explorative fashion. That means a scientist has a specific scientific goal, but only a rough notion about how to reach it. Sometimes the concrete way to that goal reveals not until some steps are taken towards it. In such cases the scientist would model a part of a workflow (e.g. the generation of an finite element method (FEM) grid), start it, and see how the simulation and the (intermediate) results are developing. If the workflow instance runs out of work, it is suspended automatically, or it may be suspended explicitly by the scientist. Depending on his observations the scientist may append additional steps (i.e. activities) or change already modeled but not yet executed ones. Then, he resumes workflow execution.

  8. The changes of the workflow model are propagated to the Workflow Engine as follows. A new version of that model is deployed on the engine. After that the considered workflow instance is migrated from the old model to the new one. Other already existing workflow instances can proceed according to the old model. We foresee a mechanism called concurrent evoluation of workflows where both old and new model versions remain active, i.e. can be instantiated in future. It allows scientists running every workflow version (i.e. every simulation configuration) if desired. This is especially useful if a former simulation instrumentalization has to be conducted again because the results have to be validated. Some changes of workflows do not require a redeployment of the workflow model (e.g. enforced iteration of activities, changing variables). These modifications are directly propagated to the corresponding workflow instance in the engine over well-defined interfaces. The flexibility approaches increase the robustness of the overall solution. This is in particular useful to prevent from a loss of data in possibly long-running simulations.