ProActive

Infobox_Software
name = ProActive



caption =
collapsible =
developer = OW2 Consortium
latest_release_version =
latest_release_date =
latest_preview_version =
latest_preview_date =
operating_system = Cross-platform
programming_language = Java
genre = Grid Computing
license = GNU General Public License
website = http://proactive.inria.fr/

ProActive is a Java Grid middleware (part of the ObjectWeb/OW2 consortium and developed by INRIA, CNRS and University of Nice Sophia Antipolis, with Open Source code under GPL license) for parallel, distributed and multi-threaded computing.

ProActive provides a comprehensive framework and parallel programming model to simplify the programming and execution of parallel applications: running on multi-core processors, distributed on Local Area Network (LAN), on clusters and data centers, on intranets and Internet Grids.

The ProActive programming model combines the Active Object design pattern with Futures objects.

ProActive features the following:
* a resource acquisition and deployment framework,
* a set of programming frameworks, including:
** Master/Worker for solving Embarrassingly parallel problems
** Branch & Bound
** SPMD
** Skeletons
** Active Objects (Actors)
** Legacy Code Wrapping
** component framework as a reference implementation of the Grid Component Model(GCM), an extension to the Fractal Component Model.
* a set of non-functional services, including:
** Fault-tolerance
** Load-balancing
** Mobility
** Security
* a set of external tools (called "ProActive Parallel Suite"), including
** a SWT plugin for monitoring and benchmarking ProActive applications called "IC2D"
** a "Resource Manager" - bundled with a SWT plugin client - for managing in real-time grid resources coming from multiple resource providers (other Cluster Job Schedulers such as Platform LSF, P2P Networks , etc...).
** a "Scheduler" - bundled with a SWT plugin client - for setting up a collaborative grid execution environment where users are able to run Java or Native Tasks inside the grid.
ProActive brings ease-of-use in the world of parallel computing. Leading programmers to write standard Java code (no changes to the Java Virtual Machine, no preprocessing or compiler modification) for their parallel and Grid applications. It's major benefit as a parallel programming model, is that an application written using the model will need no structural change whether they run in a Single-threaded, Multi-threaded or Distributed environment.

Programming Model

Originally, the model [ [http://www-sop.inria.fr/oasis/proactive/userfiles/file/papers/towards.ps Towards a Method of Object-Oriented Concurrent Programming] , D. Caromel, pp. 90-102, in CACM, Communications of the ACM, Volume 36, Number 9, September 1993. [http://www-sop.inria.fr/oasis/ProActive/bibtex.html#Towm bibtex] ] has been created by Denis Caromel, professor at University of Nice Sophia Antipolis. Several extensions [ [http://www-sop.inria.fr/oasis/ProActive/userfiles/file/papers/ProgrammingComposingDeploying.pdf Programming, Composing, Deploying for the Grid] Baude F., Baduel L., Caromel D., Contes A., Huet F., Morel M. and Quilici R., in "GRID COMPUTING: Software Environments and Tools", Jose C. Cunha and Omer F. Rana (Eds), Springer Verlag, January 2006. [http://www-sop.inria.fr/oasis/ProActive/bibtex.html#pdcg06 bibtex] ] of the model were made later on by members of the OASIS team at INRIA. A book [ [http://www-sop.inria.fr/oasis/Denis.Caromel/TDO/ A Theory of Distributed Objects] , isbn 3-540-20866-6D. Caromel, L. Henrio - Springer] presents the ASP calculus that formalizes ProActive features, and provides formal semantics to the calculus together with properties on a ProActive program execution.

Active Objects

Active Object basis

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. As a matter of fact, any active object can be manipulated as if it were a passive instance of the same class. ProActive is a library designed for developing applications in a model introduced by Eiffel//, a parallel extension of the Eiffel programming language. Its main features are:


* 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 zero). The thread of one subsystem only executes methods in the objects of this subsystem.


* There are 'no "shared passive objects"' between subsystems. These two main features have a lot of important consequences on the topology of the application:
* 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.

This has also consequences on the semantics of message-passing between subsystems.
* When an object in a subsystem calls a method on an active object, the parameters of the call may be references on passive objects of the subsystem, which would lead to shared passive objects. This is why passive objects passed as parameters of calls on active objects are always passed by deep-copy. Active objects, on the other hand, are always passed by reference. Symmetrically, this also applies to objects returned from methods called on active objects.

Figure 2. A call onto an active object as opposed to a call onto passive one

Thanks to the concept of asynchronous calls, futures (see below), and no data sharing, an application doesn't need any structural change (actually hardly any change at all) whether it runs in a Sequential, Multi-threaded or Distributed environment.
Figure 1. The Model: Sequential, Multithreaded, Distributed

What is an Active Object ?

The active object is actually the composition of two objects: a "body" and a standard Java object. The body is not visible from the outside of the active object, then everything looks like if the standard object was active.

The body is responsible for receiving calls on the active object, storing these calls in a queue of pending calls (we also call them "requests". It also executes these calls in an order specified by a specific synchronization policy. If no specific synchronization policy is provided, calls are managed in a FIFO manner (first come, first served)).

Then, the thread of an active object alternatively chooses a method in the queue of pending requests and executes it. It is important to note that no parallelism is provided inside an active object. This is an important decision in the design of ProActive which enables the use of pre-post conditions and class invariants.

On the side of the subsystem which sends a call to an active object, this active object is represented by a "proxy", whose main responsibility is to generate future objects for representing future values, transform calls into Request objects (in terms of metaobject, this is a reification) and perform deep-copy of passive objects passed as parameters.

Asynchronous calls and futures

A Simple Example

The code excerpt below highlights the notion of "Future" objects. Let's suppose a user calls a method foo and a method bar from an Active Object a, the foo method returns void and the bar method returns an object of class V:

a.foo (param); // A one way typed asynchronous communication towards the (remote) AO a // A request is sent to a,V v = a.bar (param); // A typed asynchronous communication with result. // v is first an awaited Future, to be transparently filled up after // service of the request, and reply...v.gee (param); // Use of the result of an asynchronous call.

// If v is still an awaited future, it triggers an automatic // wait: Wait-by-necessity

When foo is called on an active object a, it returns immediately (as the current thread cannot execute methods in the other subsystem). Similarly, when bar is called on a, it returns immediately but the result v can't be computed yet. A future object, which is a placeholder for the result of the method invocation, is returned. From the point of view of the caller subsystem, no difference can be made between the future object and the object that would have been returned if the same call had been issued onto a passive object. After both methods have returned, the calling thread continues executing its code as if the call had been effectively performed. The role of the future mechanism is to block the caller thread when the gee method is called on v and the result has not yet been set : this inter-object synchronization policy is known as "wait-by-necessity".

Key Features

* Whenever possible a method call on an active object is reified as an "asynchronous" request. If not possible the call is "synchronous" and blocks until the reply is received. In case the request is asynchronous, it immediately returns a future object.

* This object acts as a placeholder for the result of the not-yet-performed method invocation. As a consequence, the calling thread can go on with executing its code, as long as it doesn't need to invoke methods on the returned object, in which case the calling thread is automatically blocked if the result of the method invocation is not yet available. Note although a future having a quite similar structure as an active object, a future object is not active. It only has a Stub and a Proxy as shown in figure below:

Figure 4. A future object

References

External links

* [http://www-sop.inria.fr/oasis/proactive/ The ProActive website]
* [http://www-sop.inria.fr/sloop/javall/release-doc/html/IC2D_EclipsePlugin.html The ProActive IC2D eclipse plugin]
* [http://www.coregrid.net/mambo/images/stories/Deliverables/d.pm.04.pdf The Grid Component Model specification]