ProActive Parallel Suite is an open-source software for enterprise workload orchestration, part of the OW2 community. A workflow model allows a set of executables or scripts, written in any language, to be defined along with their dependencies, so ProActive Parallel Suite can schedule and orchestrate executions while optimising the use of computational resources.
ProActive Parallel Suite is based on the "active object" design pattern (see Active objects) to optimise task distribution and fault-tolerance.
ProActive Parallel Suite key features
Workflows ease task parallelization (Java, scripts, or native executables), running them on resources matching various constraints (like GPU acceleration, library or data locality). Web interfaces are provided to design and execute job workflows and manage computing resources. A RESTful API provide interoperability with enterprise applications. Computational resources can be federated (cloud, clusters, virtualized infrastructures, desktop machines) into a single virtual infrastructure. It provides auto-scaling and ease resource management strategies. Interoperability is provided with heterogenous workflows, where tasks can run on various platforms, including Windows, Mac and Linux.
ProActive Java framework and Programming model
The model was created by Denis Caromel, professor at University of Nice Sophia Antipolis. Several extensions of the model were made later on by members of the OASIS team at INRIA. The book A Theory of Distributed Objects presents the ASP calculus that formalizes ProActive features, and provides formal semantics to the calculus, together with properties of ProActive program execution.
Active objects
Active objects are the basic units of activity and distribution used for building concurrent applications using ProActive. An active object runs with its own thread. This thread only executes the methods invoked on this active object by other active objects, and those of the passive objects of the subsystem that belongs to this active object. With ProActive, the programmer does not have to explicitly manipulate Thread objects, unlike in standard Java.
Active objects can be created on any of the hosts involved in the computation. Once an active object is created, its activity (the fact that it runs with its own thread) and its location (local or remote) are perfectly transparent. Any active object can be manipulated as if it were a passive instance of the same class.
An active object is composed of two objects: a body, and a standard Java object. The body is not visible from the outside of the active object.
The body is responsible for receiving calls (or requests) on the active object and storing them in a queue of pending calls. It executes these calls in an order specified by a synchronization policy. If a synchronization policy is not specified, calls are managed in a "First in, first out" (FIFO) manner.
The thread of an active object then chooses a method in the queue of pending requests and executes it. No parallelism is provided inside an active object; this is an important decision in ProActive's design, enabling the use of "pre-post" conditions and class invariants.
On the side of the subsystem that sends a call to an active object, the active object is represented by a proxy. The proxy generates future objects for representing future values, transforms calls into Request objects (in terms of metaobject, this is a reification) and performs deep copies of passive objects passed as parameters.
Active object basis
ProActive is a library designed for developing applications in the model introduced by Eiffel//, a parallel extension of the Eiffel programming language.
In this model, the application is structured in subsystems. There is one active object (and therefore one thread) for each subsystem, and one subsystem for each active object (or thread). Each subsystem is thus composed of one active object and any number of passive objects—possibly no passive objects. The thread of one subsystem only executes methods in the objects of this subsystem. There are no "shared passive objects" between subsystems.
These features impact the application's topology. Of all the objects that make up a subsystem—the active object and the passive objects—only the active object is known to objects outside of the subsystem. All objects, both active and passive, may have references onto active objects. If an object o1 has a reference onto a passive object o2, then o1 and o2 are part of the same subsystem.