References: http://www-sop.inria.fr/sloop/javall/

Thanks to Kavan and Hiren’s tireless combing of the web in search of ways to present cluster computing, the Underdog group is able to present an example of the ProActive Java library for Parallel, Distributed and Concurrent computing. Developed at the Universite Nice Sophia Antibolis in France, ProActive PDC is a 100% Java library that utilizes a Multiple Instruction Multiple Data (MIMD) model, implements a small set of primitives and requires very little modification to existing code and none to the Java Virtual Machine.

Because ProActive PDC is in the business of dealing with distributed objects it is based on the RMI Java standard library. In JavaRMI the transformation of a local object to a remotely accessible one—a near necessity for cluster computing—requires excessively deep modification to existing code. In this headache lies one of the founding motivations of the ProActive PDC doctrine.

In the eyes of the ProActive team, a programmer should not have to waste valuable (and often expensive) development resources on the sometimes intensely difficult issues low-level tasks such as object distribution, mapping and load balancing can cause. In their eyes these resources should, instead, be freed for a tighter focus on modeling and algorithmic issues. And in this goal the ProActive library has been successful.

Based on the MIMD model mentioned above, active objects—the basic unit of activity and distribution used for building concurrent applications using ProActive PDC—provide this desired "transparency" of the low-level tasks described above. We will delve deeper into active objects later on, but for now it will suffice to say that an active object owns it’s own thread and is composed of two objects: one a standard Java object , the other a "body" which handles and executes all calls on the active object using the active objects thread. Confused? Relax, things will become clearer.

Thus, the good people at UNSA have created an all Java library that allows for simplified parallel, distributed and concurrent computing through the providing of location and activity transparency as well as the trimming away of unnecessary and nasty low-level task coding; and the members of Underdog group would like to thank and applaud their efforts. They certainly made our life easier.

As stated earlier active objects are the basic units of the ProActive PDC library. And it is through the use of active objects that transparency on an activity and locational level is achieved. So what exactly is an active object?

Based upon a Meta-Object Protocol (MOP) built on the idea of using a standard objects to represent elements of a language that are not normally objects, active objects in the ProActive PDC library are used to represent class and method calls. How is it that a class or method call is converted into an object? The term is reification. To reify a call is to construct an object that represents the call so that it can be manipulated like an object.

Hold on, I still don’t get it? Well, neither did we the first time through, so we will give you a second shot.

Put in more plain terms, an active object is a composition of two objects, a "body" and a standard Java object, that owns it’s own thread. Since we all understand what a standard Java object is (if not, jump ship now, it’s only gettin’ worse), we will discuss the body.

An active object’s body has the responsibility of receiving, storing and executing all calls made on it’s object. Hence, it is the body through which activity transparency is directly achieved. When a call is made on an active object’s method it is placed in a queue residing inside the body. From this queue, the body chooses to execute calls on the active object’s thread. The order in which these calls are chosen is based upon a predefined synchronization policy whose default is first in first out (FIFO). The transparency arrives from the fact that the body (and by the transitive property, the active object’s thread) is not visible outside the active object. This means that to outside users an active object appears only as a passive standard Java object. It’s beginning to sound a lot like transparency.

Great, now that we have laid the foundation for learning how ProActive PDC achieves transparency, let us finish it by talking about something called future objects.

The essence of a future object is to allow the thread which made the call on our active object (from here on the calling thread) to continue executing uninterrupted. How, you may be asking, can the calling thread execute uninterrupted if our active object’s method it is trying to invoke has an extended execution time? Well it can, almost, and I’m about to show you how. It is through the ingenious creation, by the authors of ProActive PDC, of our new friend the future object. When a method is invoked on an active object it immediately returns a future object which the calling thread gladly accepts as a return object. This is legal because the future object is actually an instance of a subclass of the returned object. Effectively, the future object acts as a placeholder waiting for the invoked method to complete it’s execution and return the proper object. This is why the calling thread is able to continue execution.

Before any questions are asked I would like to state that there is a catch. Should the calling thread try to invoke methods on the return object before it has returned, it is the future object’s design to block the execution of that thread until the proper object is returned.

Due to the polymorphistic behavior of the future object it does have some limitations. Rules defined by the Java programming language do not allow primitive types and final classes to be subclassed, hence they can not become future objects. Furthermore, dictated by the ProActive PDC library, the use of future objects for methods that throw checked exceptions are forbidden.

A Java object is created in the following manner:

A a = new A("foo", 3);

where a is of type A and is created with the parameters "foo" and 3.

An active object can be created in one of three ways using the ProActive PDC library: instantiation based, class based or object based.

Object [ ] params = { "foo", new Integer(3) }

A a = (A) Javall.newActive( "A", params, myNode);

The newActive method from the ProActive PDC library is called in this example to create an active object of the first parameter it is passed, the class "A". newActive’s second parameter is an array of objects that make up the activated class’ parameters and determine which constructor will be called. The third parameter is the node upon which the activated class is going to be created. If Null it is created on the current node.

class pA extends A implements Active{}

Object [ ] params = { "foo", new Integer(3) }

A a = (A) Javall.newActive( "pA", params, myNode);

Much like instantiation based, the only difference is the creation of an active instance of a subclass of A. In doing this the programmer may choose a specific proxy and body to implement for their active object.

a = (A) Javall.turnActive( "pA", params, myNode);

There are some restrictions when it comes to creating an active object of a class:

• final classes may not be turned into active objects

This limitation arises from the fact that a subclass can not be made of a final class. Remember by definition a future object is an instance of a subclass of the activated object.

• classes without a no arg constructor can not be made into active objects.

The no arg constructor is always called when an active object is first created. If it does not exist unpredictable results may occur.

In the creation of one active instance, B, there are actually 4 objects—Stub_B, ProxyForBody, Body, instance of B—working together to give the active object it’s functionality.