Scientific Workflow Middleware


Scifloware is designed to be a middleware for the execution of workflows on different systems and software. Instead of taking back the different languages describing a workflow, we use our own data centric language to describe a "master" workflow between all the systems.

Using Scifloware services and components, we provide a distributed and parallel execution of our workflow using engines of different systems. This way, and as a middleware, Scifloware will also have the possibility to work and coordinates tasks between different software, each with their own specificity.


Scifloware is using the component and service oriented aspects of Osgi and SON and is composed of many different components, each one having its purpose.

Using this approach we can have a great modularity and choose which components to use or not in an application.


As specified in the previous point, we use our own language to describe workflows using algebraic operators like map, reduce, etc.

A workflow is described as a XML element with a description of each operator and links between them. This simple and easily-readable structure can be seen as a graph as well.


A graphical user interface (GUI) is under development for the visualization and edition of workflows written in our language.

This interface is using the Google Web Toolkit(GWT) which provide tools to make light and dynamic web application in java.


Using Osgi modularity and possibilities, we want to have a Scifloware component capable to deploy himself.

By installing only a small Osgi/Scifloware component with a minimum of functionality the deployment manager will be able to install all the component wanted and necessary to run Scifloware and a part of a workflow on a remote location.

Web Services

With the need of Scifloware to communicate with many other software, we decided to use a simple way to achieve this with REST web services.

In addition to using SON services to communicate between each Scifloware component, Scifloware implements his own way of using REST web services.

Each incoming or outgoing REST service can be treated transparently like a SON service to simplify communication between each components of the workflow.

With OpenAlea

In a first test with an other system, we tried to realize a map operation on one workflow on OpenAlea. For this we used a very simple operation and very simple data for the test to begin with, with the data passed over the REST services.

This working test of the communication between Scifloware and OpenAlea is showing us that we can now test a much complex application with more complex data management.

Data Manager


For the first tests of Scifloware with the basic components we needed a way to access and manage data, therefor a basic Data Manager was created first to communicate with a MySQL database.

Spring Data

With the diversity of software with their own specificity, we needed a way to communicate with many database and data-management systems. We decided to use the Spring framework to answer the problem and specifically SpringData which can handle a wide variety of databases, classic relational or NoSql systems.

A new component was created by adapting the Spring framework as an Osgi component and then as a new Datamanager component in Scifloware

Connection with Neo4j

SpringData can also handle a Neo4j graph database, this type of NoSql database is very interesting in our case to represent a workflow easily with a graph.

One of the application of testing the new Spring data manager was to store our workflow in Neo4j.

INRIA main page