ProActive Overview

Grid computing is now a key aspect, from scientific to business applications, from large scale simulations to everyday life enterprise IT. After the old days of mainframes and servers with hundreds of persons sharing the same machines or the quite current days of the PCs with one person for one computer, we are just entering the era of Ubiquitous Computing with many computers at hand for every single individual.

Grids gather large amounts of heterogeneous resources across geographically distributed sites for use by virtual organizations. Resources are usually organized in groups of desktop machines and/or clusters, which are managed by different administrative domains (labs, universities, companies, etc.). The large amount of heterogeneous resources complicate the deployment task in terms of configuration and connection to remote resources. Deployment sites targeted may be specified beforehand, or automatically discovered at runtime. Each domain may have its own management and security policies. Grid applications aim to use a large number of resources, which are geographically distributed. Hence, Grid frameworks have to help applications with scalability issues, such as providing parallelism capabilities for a large number of resources.

The large number of resources distributed on different domains implies a high probability of faults, such as hardware failures, network downtime, or maintenance. Since a grid gathers geographically disperse and administratively independent computational sites into a large federated computing system with common interfaces, new programming models have to be defined to abstract away these complexities from programmers.

1.1. ProActive Programming Frameworks

1.1.1. Introduction

ProActive is an open source Java library aiming to simplify the programming of multithreaded, parallel, and distributed applications for Grids, multi-cores, clusters, and data-centers. It allows concurrent and parallel programming and offers distributed and asynchronous communications, mobility, and a deployment framework. With a small set of primitives, ProActive provides an API allowing the development of parallel applications, which may be deployed on distributed systems and on Grids. ProActive does not require any modifications to Java or to the Java Virtual Machine (JVM) therefore allowing the deployment of applications using the ProActive API on any operating system that provides a compatible JVM.

ProActive Features

Figure 1.1. ProActive Features


Overall, ProActive promotes a few basic and simple principles:

  • Activities are distributed, remotely accessible objects

  • Interactions are done through asynchronous method calls

  • Results of interactions are called futures and are first class entities.

  • Callers can wait for results using a mechanism called wait-by-necessity

1.1.2. Active Objects Model

ProActive is based on the concept of an active object, which is an entity with its own configurable activity. A distributed or concurrent application built using ProActive is composed of a number of entities called active objects. Each active object has one distinguished element, the root, which is the only entry point to the active object. Each active object has its own thread of control and is granted the ability to decide in which order to serve the incoming method calls that are automatically stored in a queue of pending requests. Method calls sent to active objects are asynchronous with transparent future objects and synchronization is handled by a mechanism known as wait-by-necessity. There is a short rendezvous at the beginning of each asynchronous remote call, which blocks the caller until the call has reached the context of the callee. More detailed information on active objects will be presented in Chapter 9, Active Object Definition

The ProActive solution relies on asynchronous method calls mastering both complexity and efficiency and proposes advanced features such as groups, mobility, and components. In the framework of formal calculus, Asynchronous Sequential Processes (ASP), confluence, and determinism have been proven for this programming model: CH05 and CHS04.

1.1.3. Implementation Language

Grids gather large amount of heterogeneous resources, different processor architectures and operating systems. In this context, using a language which relies on a virtual machine allows maximum portability. ProActive is developed in Java, a cross-platform language and the compiled application may run on any operating system providing a compatible virtual machine. Moreover, ProActive only relies on standard APIs and does not use any operating-system specific routines, other than to run daemons or to interact with legacy applications. There are no modifications to the JVM nor to the semantics of the Java language, and the bytecode of the application classes is never modified.

1.1.4.  Communication through typed asychronous messages

In ProActive, the distribution is transparent: invoking methods on remote objects does not require the developer to design remote objects with an explicit remoting mechanism. Therefore, the developer can concentrate on the business logic as the distribution is automatically handled and transparent. Moreover, the ProActive library preserves polymorphism on remote objects (through the reference stub, which is a subclass of the remote root object).

Communication between active objects is realized through method invocations, which are reified and passed as messages. These messages are serializable Java objects which may be compared to TCP packets. Indeed, one part of the message contains routing information towards the different elements of the library, and the other part contains the data to be communicated to the called object. Although all communications proceed through method invocations, the communication semantics depends upon the signature of the method, and the resulting communication may not always be asynchronous. Three cases are possible: synchronous invocation, one-way asynchronous invocation, and asynchronous invocation with future result.

  • Synchronous invocation - the method returns a non reifiable object: primitive type or final class:

     boolean foo() 
    

    the method declares a thrown exception:

    public void bar() throws AnException 
    

    In this case, the caller thread is blocked until the reified invocation is effectively processed and the eventual result (or exception) is returned. It is fundamental to keep this case in mind, because some APIs define methods which throw exceptions or return non-reifiable results.

  • One-way asynchronous invocation - the method does not throw any exception and does not return any result:

    public void gee()
    

    The invocation is asynchronous and the process flow of the caller continues once the reified invocation has been received by the active object (in other words, once the rendezvous is finished).

  • Asynchronous invocation with future result - the return type is a reifiable type, and the method does not throw any exception:

    public MyReifiableType baz() 
    

    In this case, a future object is returned and the caller continues its execution flow. The active object will process the reified invocation according to its serving policy, and the future object will then be updated with the value of the result of the method execution.

If an invocation from an object A on an active object B triggers another invocation on another active object C, the future result received by A may be updated with another future object. In that case, when the result is available from C, the future of B is automatically updated, and the future object in A is also update with this result value, through a mechanism called automatic continuation.

1.1.5. Programming With Components: GCM

1.1.6. Library features

ProActive uses the Chapter 48, MOP: Metaobject Protocol to provide flexibility and configurability: it allows the addition of meta-objects for managing new required features. Moreover, the library also proposes a deployment framework, which allows the deployment of active objects on various infrastructures. The MOP architecture is represented in the next figure.

MOP architecture

Figure 1.2. MOP architecture


The library may be represented in four layers: IDE, programming model, deployment facilities, and non-functional features.

ProActive offers IC2D, an interactive graphical enviroment for remote monitoring and control of distributed applications. Due to the fact that it uses the standard (starting with the J2SE platform 5.0) Java Management Extensions (JMX) technology in order to monitor distribution, IC2D can be deployed without requiring changes to the JVM or Java.

The programming model consists of the active objects model which offer asynchronous communication, typed group communication, and the object-oriented SPMD programming paradigm. In addition to the standard object oriented programming paradigm, ProActive also proposes a component-based programming paradigm, by providing an implementation of the Fractal component model geared at Grid computing.

The deployment layer includes a deployment framework; it is detailed in Part V, “Deployment And Virtualization”, and it allows the creation of remote active objects on various infrastructures. A scheduler is also proposed to manage the deployment of jobs. The load-balancing framework uses the migration capabilities to optimize the placement of the distributed active objects.

Non-functional features include a transparent fault-tolerance mechanism based on a communication-induced check-pointing protocol, a security framework for communications between remote active objects, migration capabilities for the mobility of active objects, a mechanism for the management of exceptions, a complete distributed garbage collector for active objects, and a mechanism for wrapping legacy code, notably as a way to control and interact with MPI applications.

In the communication layer several protocols are provided for the communication between active objects: Java RMI as the default protocol, SSH, HTTP, tunneled RMI. It is also possible to export active objects as Web Services, which can then be accessed using the standard SOAP protocol. A file transfer mechanism is also implemented; it allows the transfer of files between active objects, for instance to send large data input files or to retrieve results files. ProActive also provides a peer-to-peer (P2P) infrastructure that allows for starting computations on P2P networks by using a dynamic overlay network of JVMs. Under this framework, peers can dynamically join the network and participate in the computations.