Execution Engine Specification

This is part of the Facilities Specification Template.

Overview

A brief overview of the subsystem should be here. It should include the key features.

Key features

Orchestration for external computational and storage infrastructures.

PE2ng allows users and systems to exploit computational resources that reside on multiple eInfrastructures in a single complex process workflow.

Native computational infrastructure provider and manager.

PE2ng can be used to exploit the computational capacity of the D4Science Infrastructure by executing tasks directly on the latter.

Control and monitoring of a processing flow execution.

PE2ng provides progress reporting and control constructs based on an event mechanism for tasks operating both on the D4Science and external infrastructures.

Handling of data staging among different storage providers.

All PE2ng Adaptors handle data staging in a transparent way, without requiring any kind on external intervention.

Handling of data streaming among computational elements.

PE2ng exploits the high throughput point to point on demand communication facilities offered by gRS2

Expressive and powerful execution plan language

The execution plan elements comprising the language can execute literally anything.

Unbound extensibility via providers for integration with different environments.

The system is designed in an extensible manner, allowing the transparent integration with a variety of providers for storage, resource registries, reporting systems, etc.

Alignment with cloud computing principles

Application as a Service (AaaS), Plarform as a Service (PaaS), Infrastructure as a Service (IaaS)

User Interface

PE2ng offers a User Interface to launch and monitor commonly used workflows and aims to provide a fully fledged Graphical User Interface for the graphical composition of arbitrary workflows.

Design

Philosophy

This is the rationale behind the design. An example will be provided.

Architecture

The main software components forming the subsystem should be identified and roughly described. An architecture diagram has to be added here. A template for the representation of the architecture diagram will be proposed together with an opensource tool required to produce it.

Deployment

Usually, a subsystem consists of a number of number of components. This section describes the setting governing components deployment, e.g. the hardware components where software components are expected to be deployed. In particular, two deployment scenarios should be discussed, i.e. Large deployment and Small deployment if appropriate. If it not appropriate, one deployment diagram has to be produced.

Large deployment

A deployment diagram suggesting the deployment schema that maximizes scalability should be described here.

Small deployment

A deployment diagram suggesting the "minimal" deployment schema should be described here.

Use Cases

The subsystem has been conceived to support a number of use cases moreover it will be used to serve a number of scenarios. This area will collect these "success stories".

Well suited Use Cases

Describe here scenarios where the subsystem proves to outperform other approaches.

Less well suited Use Cases

Describe here scenarios where the subsystem partially satisfied the expectations.