The conceptual model of Fractal is the base of our work, and as it is extensible, we have added a few concepts to fulfill our needs. The Fractal specification defines conformance levels for implementations of the API (section 7.1. of the Fractal 2 specification). The implementation for ProActive is conformant up to level 3.2. . In other words, it is fully compliant with the API, except it does not consider the creation of components through template components.
The implementation for ProActive currently defines 2 extensions to the base component model :
Distributed deployment : components can be deployed onto distributed virtual machines, using the deployment facilities of ProActive.
Parallel components : this type of components is a specialization of the composite components. They encapsulate other components of the same type, and all incoming calls are forwarded to the corresponding internal interfaces of the enclosed components. This allows parallel processing while just manipulating one entity, the enclosing parallel component. As we use the typed groups API of ProActive, coupled with the concept of internal collective interfaces of Fractal, the communications to the enclosed components are either scattered or broadcasted. The following figure sums up the different kinds of components available.
![]() |
The different kinds of components with the ProActive implementation. Primitive components have customizable activities (primitive components are also active objects).
The API is the same for any Fractal implementation, though some classes are implementation-specific :
The fractal provider class, that corresponds to the fractal.provider parameters of the JVM, is org.objectweb.proactive.core.component.Fractive. The Fractive class acts as :
a bootstrap component
a GenericFactory for instantiating new components
a utility class providing static methods to create collective interfaces and retreive references to ComponentParametersController
The controller description and the content description of the components, as specified in the method public Component newFcInstance(Type type, Object controllerDesc, Object contentDesc) throws InstantiationException of the org.objectweb.fractal.api.factory.Factory class, correspond in this implementation to the classes org.objectweb.proactive.core.component.ControllerDescription and org.proactive.core.component.ContentDescription.
In composite or parallel components, collective bindings are performed automatically. For primitive component, the developer has to implement the bindings explicitely in the code. We provide a method in the org.objectweb.proactive.core.component.Fractal class for creating collective bindings :
public static ProActiveInterface createCollectiveClientInterface(String itf\ Name, String itfSignature) throws ProActiveRuntimeException
where itfName is the name of the interface, and itfSignature is the signature of the interface.
Suppose you have an attribute of the base class of the primitive component of type I, named i. The initialization of the binding would be :
i= (I) Fractal.createCollectiveClientInterface("i",I.class.getName());
Then the binding method (implementation of the BindingController interface) would be :
public void bindFc(String clientItfName, Object serverItf) { if (clientItfName.equals("i")) { ProActiveGroup.getGroup(i).add(serverItf); } }
You will be able to see the collective interface as an object of type I, and therefore invoke methods defined by I. But you will also be able to see the collective interface as a collection, as a group can also be manipulated as a collection :
Collection c = ProActiveGroup.getGroup(i);
As this implementation is based on ProActive, several conditions are required :
the base class for the implementation of a primitive component has to provide an empty, no-args constructor.
parameters types and return types of the methods provided by the interfaces of the components have to be reifiable.
© 2001-2005 INRIA Sophia Antipolis All Rights Reserved