Most of the time, activities and distribution are not known at the beginning, and change over time. Seamless implies reuse, smooth and incremental transitions.
![]() |
A huge gap yet exists between multithreaded and distributed Java applications which forbids code reuse in order to build distributed applications from multithreaded applications. Both JavaRMI and JavaIDL, as examples of distributed object libraries in Java, put a heavy burden on the programmer because they require deep modifications of existing code in order to turn local objects into remote accessible ones. In these systems, remote objects need to be accessed through some specific interfaces. As a consequence, these distributed objects libraries do not allow polymorphism between local and remote objects. This feature is our first requirement for a metacomputing framework. It is strongly required in order to let the programmer concentrate first on modeling and algorithmic issues rather than lower-level tasks such as object distribution, mapping and load balancing.
Given a standard object, we provide the ability to give it:
location transparency
activity transparency
synchronization
Three ways to transform a standard object into an active one:
Object[] params = new Object[] { new Integer (26), "astring" }; A a = (A) ProActive.newActive("example.A", params, node) ;
public class AA extends A implements Active {} Object[] params = new Object[] { new Integer (26), "astring" }; A a = (A) ProActive.newActive("example.AA", params, node) ;
Heterogeneous model both passive and active objects
Systematic asynchronous communications towards active objects
No shared passive object , Call-by-value between active objects
Automatic continuations , a transparent delegation mechanism
wait-by-necessity , automatic and transparent futures
Centralized and explicit control , libraries of Abstractions
Two key features :
Wait-by-necessity : inter-objects synchronization
Systematic, implicit and transparent futures. Ease the programming of synchronization and reuse of existing methods
Polymorphism between standard and active objects
Type compatibility for classes and not just for interface
Needed and done for the future objects as well
Dynamic mechanism (dynamically achieve if needed)
![]() |
© 2001-2005 INRIA Sophia Antipolis All Rights Reserved