|
![]() |
Computing Grids and Peer-to-Peer networks are inherently heterogeneous and distributed, and for this reason they drive new technological challenges : complexity in the design of applications, complexity of deployment, reusability and performance issues. The objective of our work is to provide an answer to these problems through the implementation for ProActive of an extensible, dynamical and hierarchical component model, Fractal. This document is an overview of the implementation of Fractal with ProActive. First, it explains the goals and the reasons for a new implementation of the Fractal model. Second, it shows the extensions to the model and the conformance to the Fractal specification. The third section is a word on the current Architecture Description Language. The fourth section goes through some examples to illustrate the use of the API and the distribution of components. The final section is about our forthcoming research work. You can also get an overview of the architecture of this implementation here.
For a general overview of our work , you can also refer to a paper presented at the International Symposium on Distributed Objects and Applications (DOA), in November 2003. (.pdf)
Fractal defines a general conceptual model, along with a programming application interface (API) in Java. According to the official documentation, the Fractal component model is "a modular and extensible component model that can be used with various programming languages to design, implement, deploy and reconfigure various systems and applications, from operating systems to middleware platforms and to graphical user interfaces".
So far, to our knowledge, there is only one implementation fully compliant with the Fractal API. It is the reference implementation, called Julia.
We first tried to use Julia to manipulate active objects
(the fundamental entities in ProActive), but we wouldn't have been
able to reuse the features of the Proactive library, because of the architectures of the libraries.
Julia manipulates a base class by modifying the bytecode or adding interception objects to it. On
the other hand, ProActive is based on a meta-object protocol and provides a reference to an active object through
a typed stub. If we wanted to use active objects with Julia, the Julia runtime would try to manipulate the stub, and
not the active object itself. And if trying to force Julia to work on the same base object than ProActive, the control flow
could not traverse both ProActive and Julia.
Eventually, re-implementing ProActive using Julia could be a solution (a starting point could be the "protoactive" example of Julia), but this would imply a full refactoring of the library, and therefore quite a few resources...
More generally speaking, Julia is designed to work with standard objects, but not with the active objects of ProActive. Some features (see next section) would not be reusable using Julia with ProActive active objects.
Therefore, we had to go for our own implementation.
This implementation is different from Julia both in its objectives and in the programming technniques. As previously stated, we target Grid and P2P environments. The programming techniques and the architecture of the implementation is described in a following section.
The combination of the Fractal model with the ProActive library leverages the capabilities of both of them.
Distribution is achieved in a transparent manner over the Java RMI protocol thanks to the use of a stub/proxy pattern. Components are manipulated indifferently of their location (local or on a remote JVM).
ProActive provides a deployment framework for creating a distributed component system. Using a configuration file and the concept of virtual nodes, this framework :
A fundamental concept of the ProActive library is this of active objects, where activities can actually be redefined so as to customize their behavior.
Asynchronous method calls with transparent futures is a core feature of ProActive, and it allows concurrent processing. Indeed, suppose a caller invokes a method on a callee. This method returns a result on a component. With synchronous method calls, the flow of execution of the caller is blocked until the result of the method called is received. In the case of intensive computations, this can be relatively long. With asynchronous method calls, the caller gets a future object and will continue its tasks until it really uses the result of the method call. The process is then blocked (it is called wait-by-necessity) until the result has effectively been calculated.
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 :
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 :
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 itfName, 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, some conditions are required :
The Architecture Description Language (ADL) is used to configure and deploy component systems. The architecture of the system is described in a normalized XML file.
The ADL has been updated and is now an extension of the standard Fractal ADL, allowing to reuse ProActive-specific features such as distributed deployment using deployment descriptors.
The distributed deployment facilities offered by ProActive are reused, and the notion of virtual node is integrated in the component ADL. For this reason, the components ADL has to be associated with a deployment descriptor (this is done at parsing time : both files are given to the parser).
One should refer to the Fractal ADL tutorial for more detailed information about the ADL. Here is a short overview, and a presentation of some added features.
Note that because this ADL is based on the Fractal ADL, it requires the following libraries (included in the /lib directory of the ProActive distribution) : fractal-adl.jar, dtdparser.jar, ow_deployment_scheduling.jar
Components are defined in definition files, which are .fractal files. The syntax of the document is validated against a DTD retreived from the classpath
classpath://org/objectweb/proactive/core/component/adl/xml/proactive.dtd
The definition element has a name (which must be the same name that the file's) and inheritance is supported through the attribute "extends" :
definition name="org.objectweb.proactive.examples.components.helloworld.helloworld-distributed-wrappers"
The exportedVirtualNodes elements is described later in this section
Components can be specified and created in this definition, and these components can themselves be defined in other definition files :
component name="client-wrapper" definition="org.objectweb.proactive.examples.components.helloworld.ClientType"
Nesting is allowed for composite components and is done by adding other "component" elements.
The binding element specifies bindings between interfaces of components ", and specifying "this" as the name of the component refers to the current enclosing component.
binding client="this.r" server="client.r"/
The controller elements can have the following "desc" values : "composite", "parallel" or "primitive". A parallel component and the components it contains should be type-compatible
Primitive components specify the content element, which indicates the implementation class containing the business logic for this component :
content class="org.objectweb.proactive.examples.components.helloworld.ClientImpl"
The virtual-node element offers distributed deployment information. It can be exported and composed in the exportedVirtualNodes element.
The component will be instantiated on the virtual node it specified (or the one that it exported). For a composite or a parallel component, it means it will be instantiated on the (first if there are several nodes mapped) node of the virtual node. For a primitive component, if the virtual node defines several nodes (cardinality="multiple"), there will be as many instances of the primitive component as there are underlying nodes. Each of these instances will have a suffixed name looking like : "primiveComponentName-cyclicInstanceNumber-n", where primitiveComponentName is the name defined in the ADL. This automatic replication is used in the parallel components.
virtual-node name="client-node" cardinality="single"
The syntax is similar to the standard Fractal ADL, and the parsing engine has been extended. Features specific to ProActive are :
The easiest way to understand the ADL is to see an example. It corresponds to the helloworld example described later in this document.
Components are deployed on the virtual node that is specified in their definition ; it has to appear in the deployment descriptor unless this virtual node is exported. In this case, the name of the exported virtual node should appear in the deployment descriptor, unless this exported virtual node is itself exported.
When exported, a virtual node can take part in the composition of other exported virtual nodes. The idea is to further extend reusability of existing (and packaged, packaging being a forthcoming feature of Fractal) components.
In the example, the component defined in helloworld-distributed-wrappers.fractal exports the virtual nodes VN1 and VN2:
exportedVirtualNodes exportedVirtualNode name="VN1" composedFrom composingVirtualNode component="client" name="client-node" /composedFrom /exportedVirtualNode exportedVirtualNode name="VN2" composedFrom composingVirtualNode component="server" name="server-node"/ /composedFrom /exportedVirtualNode /exportedVirtualNodes
VN1 is composed of the exported virtual node "client-node" from the component named client
In the definition of the client component (ClientImpl.fractal), we can see that client-node is an exportation of a virtual node which is also name "client-node" :
exportedVirtualNodes exportedVirtualNode name="client-node" composedFrom composingVirtualNode component="this" name="client-node"/ /composedFrom /exportedVirtualNode /exportedVirtualNodes ... virtual-node name="client-node" cardinality="single"/
Although this is a simplistic example, one should foresee a situation where ClientImpl would be a prepackaged component, where its ADL could not be modified ; the exportation and composition of virtual nodes allow to adapt the deployment of the system depending on the existing infrastructure. Colocation can be specified in the enclosing component definition (helloworld-distributed-wrappers.fractal) :
exportedVirtualNodes exportedVirtualNode name="VN1" composedFrom composingVirtualNode component="client" name="client-node" composingVirtualNode component="server" name="server-node"/ /composedFrom /exportedVirtualNode /exportedVirtualNodes
As a result, the client and server component will be colocated / deployed on the same virtual node. This can be profitable if there is a lot of communications between these two components.
When specifying "null" as the name of an exported virtual node, the components will be deployed on the current virtual machine. This can be useful for debugging purposes.
This new ADL will facilitate integration with other tools from the Fractal community, notably the Fractal GUI and the packaging tools. We are currently finalizing an extension of the FractalGUI for ProActive.
The parser is launched from the org.objectweb.proactive.core.component.adl.Launcher
class :
Launcher [-java|-fractal] <definition> [ <itf> ] [deployment-descriptor])
where [-java|-fractal] comes from the Fractal ADL Launcher (put -fractal for ProActive components, this will be made optional for ProActive components in the next release), <definition> is the name of the component to be instantiated and started, <itf> is the name of its Runnable interface, if it has one, and <deployment-descriptor> the location of the ProActive deployment descriptor to use. It is also possible to use this class directly from its static main method.
2 examples are presented : code snippets for visualizing the transition between active objects and components, and the "hello world", from the Fractal tutorial. The programming model is Fractal, and one should refer to the Fractal documentation for detailed examples.
In Java, objects are created by instantiation of classes. With ProActive, one can create active objects from Java classes, while components are created from component definitions. Let us first consider the "A" interface :
public interface A { public String foo(); // dummy method }
"AImpl" is the class implementing this interface :
public class AImpl implements A { public AImpl() {} public String foo() { // do something } }
The class is then instantiated in a standard way :
A object = new AImpl();
Active objects are instantiated using factory methods from the ProActive class (see the ProActive Hello World example ). It is also possible to specify the activity of the active object, the location (node or virtual node), or a factory for meta-objects, using the appropriate factory method.
A active_object = (A)ProActive.newActive( AImpl, // signature of the base class new Object[] {}, // Object[] aNode, // location, could also be a virtual node );
As components are also active objects in this implementation, they benefit from the same features, and are configurable in a similar way. Constructor parameters, nodes, activity, or factories, that can be specified for active objects, are also specifiable for components. The definition of a component requires 3 sub-definitions : the type, the description of the content, and the description of the controller.
The type of the component (i.e. the functional interfaces provided and required) is specified in a standard way : (as taken from the Fractal tutorial)
We begin by creating objects that represent the types of the components of the application. In order to do this, we must first get a bootstrap component. The standard way to do this is the following one (this method creates an instance of the class specified in the fractal.provider system property, and uses this instance to get the bootstrap component):
Component boot = Fractal.getBootstrapComponent();
We then get the TypeFactory interface provided by this bootstrap component:
TypeFactory tf = (TypeFactory)boot.getFcInterface("type-factory");
We can then create the type of the first component, which only provides a A server interface named "a":
// type of the a component ComponentType aType = tf.createFcType(new InterfaceType[] { tf.createFcItfType("a", "A", false, false, false) });
The second step in the definition of a component is the definition of its content. In this implementation, this is done through the ContentDescription class :
ContentDescription contentDesc = new ContentDescription( AImpl, // signature of the base class new Object[] {}, // Object[] aNode, // location, could also be a virtual node );
Properties relative to the controller can be specified in the ControllerDescription :
ControllerDescription controllerDesc = new ControllerDescription( "myName", // name of the component Constants.PRIMITIVE // the hierarchical type of the component // it could be PRIMITIVE, COMPOSITE, or PARALLEL );
Eventually, the component definition is instantiated using the standard Fractal API. This component can then be manipulated as any other Fractal component.
Component component = componentFactory.newFcInstance( componentType, // type of the component (defining the client and server interfaces) controllerDesc, // implementation-specific description for the controller contentDesc // implementation-specific description for the content );
There are 2 kinds of interfaces for a component : those that offer services, and those that require services. They are named respectively server and client interfaces.
From a Java class, it is fairly natural to identify server interfaces : they (can) correspond to the Java interfaces implemented by the class. In the above example, "a" is the name of an interface provided by the component, corresponding to the "A" Java interface.
On the other hand, client interfaces usually correspond to attributes of the class, in the case of a primitive component. If the component defined above requires a service from another component, say the one corresponding to the "Service" Java interface, the AImpl class should be modified. As we use the inversion of control pattern, a BindingController is provided, and a binding operation on the "requiredService" interface will actually set the value of the "service" attribute, of type "Service".
First, the type of the component is changed :
// type of the a component ComponentType aType = tf.createFcType(new InterfaceType[] { tf.createFcItfType("a", "A", false, false, false), tf.createFcItfType("requiredService", "A", true, false, false) });
The Service interface is the following :
// The Service interface public interface Service { public String bar(); }
And the AImpl class is :
// The modified AImpl class public class AImpl implements A, BindingController { Service service; // attribute corresponding to a client interface public AImpl() {} // implementation of the A interface public String foo() { return s.bar(); // for example } // implementation of BindingController public Object lookupFc (final String cItf) { if (cItf.equals("requiredService")) { return service; } return null; } // implementation of BindingController public void bindFc (final String cItf, final Object sItf) { if (cItf.equals("requiredService")) { service = (Service)sItf; } } // implementation of BindingController public void unbindFc (final String cItf) { if (cItf.equals("requiredService")) { service = null; } } }
The mandatory helloworld example (from the Fractal tutorial) shows the different ways of creating a component system (programmatically and using the ADL), and it can easily be implemented using ProActive.
You can find the code for this example in the package org.objectweb.proactive.examples.components.helloworld of the ProActive distribution.
The code is almost identical to the Fractal tutorial's example.
The differences are the following :
newFcInstance
method of the GenericFactory
interface, used for directly creating components, takes 2 implementation-specific parameters. So you should use the org.objectweb.proactive.component.ControllerDescription
and org.objectweb.proactive.component.ContentDescription
classes to define ProActive components. (It is possible to use the same parameters than in Julia, but that hinders you from using some functionalities specific to ProActive, such as distributed deployment or definition of the activity).Fractive.createCollectiveClientInterface
method will prove useful with this implementation : you are then able to use the functionalities provided by the typed groups API.The helloworld example is a simple client-server application, where the client (c) and the server (s) are components, and they are both contained in the same root component (root).
Another configuration is also possible, where client and server are wrapped around composite components (C and S). The goal was initially to show the interception shortcut mechanism in Julia. In the current ProActive implementation, there are no such shortcuts, as the different components can be distributed, and all invocations are intercepted. The exercise is still of interest, as it involves composite components.
This section is specific to the ProActive implementation, as it uses the deployment framework of this library.
If the application is started with (only) the parameter "distributed", the ADL used is "helloworld-distributed.fractal", where virtualNode of the client and server components are exported as VN1 and VN2. Exported virtual node names from the ADL match those defined in the deployment descriptor "deployment.xml".
One can of course customize the deployment descriptor and deploy components onto virtually any computer, provided it is connectable by supported protocols. Supported protocols include LAN, clusters and Grid protocols (see deployment descriptors documentation).
Have a look at the ADL files "helloworld-distributed.fractal" and "helloworld-distributed-wrappers.fractal". In a nutshell, they say : "the primitive components of the application (client and server) will run on given exported virtual nodes, whereas the other components (wrappers, root component) will run on the current JVM.
Therefore, we have the two following configurations :
1. The one without wrappers, where the primitive components are distributed.
2. The one with wrappers, where again, only the primitive components are distributed.
Currently, bindings are not optimized. For example, in the configuration with wrappers, there is an indirection that can be costly, between the client and the server. We are currently working on optimizations that would allow to shortcut communications, while still allowing coherent dynamic reconfiguration. It is the same idea than in Julia, but we are dealing here with distributed components. It could imply compromises between dynamicity and performance issues.
You can either compile and run the code yourself, or follow the instructions for preparing the examples and use the script helloworld_fractal.sh (or .bat). If you choose the first solution, do not forget to set the fractal.provider system property.
If you run the program with no arguments (i.e. not using the parser, no wrapper composite components, and local deployment) , you should get something like this:
01 --> This ClassFileServer is reading resources from classpath 02 Jini enabled 03 Ibis enabled 04 Created a new registry on port 1099 05 //crusoe.inria.fr/Node363257273 successfully bound in registry at //crusoe.inria.fr/Node363257273 06 Generating class : pa.stub.org.objectweb.proactive.core.component.type.Stub_Composite 07 Generating class : pa.stub.org.objectweb.proactive.examples.components.helloworld.Stub_ClientImpl 08 Generating class : pa.stub.org.objectweb.proactive.examples.components.helloworld.Stub_ServerImpl
You can see :
Then you have :
01 Server: print method called 02 at org.objectweb.proactive.examples.components.helloworld.ServerImpl.print(ServerImpl.java:37) 03 at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) 04 at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) 05 at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) 06 at java.lang.reflect.Method.invoke(Method.java:324) 07 at org.objectweb.proactive.core.mop.MethodCall.execute(MethodCall.java:373) 08 at org.objectweb.proactive.core.component.request.ComponentRequestImpl.serveInternal(ComponentRequestImpl.java:163) 09 at org.objectweb.proactive.core.body.request.RequestImpl.serve(RequestImpl.java:108) 10 at org.objectweb.proactive.core.body.BodyImpl$ActiveLocalBodyStrategy.serve(BodyImpl.java:297) 11 at org.objectweb.proactive.core.body.AbstractBody.serve(AbstractBody.java:799) 12 at org.objectweb.proactive.core.body.ActiveBody$FIFORunActive.runActivity(ActiveBody.java:230) 13 at org.objectweb.proactive.core.body.ActiveBody.run(ActiveBody.java:145) 14 at java.lang.Thread.run(Thread.java:534) 15 Server: begin printing... 16 --------> hello world 17 Server: print done.
What can be seen is very different from the output you would get with the Julia implementation. Here is what happens (from bottom to top of the stack):
Now let us have a look at the distributed deployment : execute the program with the parameters "distributed parser". You should get the following :
01 --> This ClassFileServer is reading resources from classpath 02 Jini enabled 03 Ibis enabled 04 Created a new registry on port 1099 05 ************* Reading deployment descriptor: file:/0/user/mmorel/ProActive/classes/org/objectweb/proactive/examples/components/helloworld/deployment.xml ******************** 06 created VirtualNode name=VN1 07 created VirtualNode name=VN2 08 created VirtualNode name=VN3 09 **** Starting jvm on crusoe.inria.fr 10 --> This ClassFileServer is reading resources from classpath 11 Jini enabled 12 Ibis enabled 13 Detected an existing RMI Registry on port 1099 14 //crusoe.inria.fr/VN1462549848 successfully bound in registry at //crusoe.inria.fr/VN1462549848 15 **** Mapping VirtualNode VN1 with Node: //crusoe.inria.fr/VN1462549848 done 16 Generating class : pa.stub.org.objectweb.proactive.examples.components.helloworld.Stub_ClientImpl 17 **** Starting jvm on crusoe.inria.fr 18 --> This ClassFileServer is reading resources from classpath 19 Jini enabled 20 Ibis enabled 21 Detected an existing RMI Registry on port 1099 22 //crusoe.inria.fr/VN21334775605 successfully bound in registry at //crusoe.inria.fr/VN21334775605 23 **** Mapping VirtualNode VN2 with Node: //crusoe.inria.fr/VN21334775605 done 24 Generating class : pa.stub.org.objectweb.proactive.examples.components.helloworld.Stub_ServerImpl 25 //crusoe.inria.fr/Node1145479146 successfully bound in registry at //crusoe.inria.fr/Node1145479146 26 Generating class : pa.stub.org.objectweb.proactive.core.component.type.Stub_Composite 27 MOPClassLoader: class not found, trying to generate it 28 ClassServer sent class Generated_java_lang_Runnable_r_representative successfully 39 MOPClassLoader: class not found, trying to generate it 30 ClassServer sent class Generated_java_lang_Runnable_r_representative successfully 31 MOPClassLoader: class not found, trying to generate it 32 ClassServer sent class Generated_org_objectweb_proactive_examples_components_helloworld_Service_s_representative successfully 33 MOPClassLoader: class not found, trying to generate it 34 ClassServer sent class Generated_org_objectweb_proactive_examples_components_helloworld_ServiceAttributes_attribute_controller_representative successfully 35 ClassServer sent class pa.stub.org.objectweb.proactive.examples.components.helloworld.Stub_ServerImpl successfully
What is new is :
Then we get the same output than for a local deployment, the activity of active objects is independent from its location.
01 Server: print method called 02 at org.objectweb.proactive.examples.components.helloworld.ServerImpl.print(ServerImpl.java:37) 03 at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) 04 at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) 05 at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) 06 at java.lang.reflect.Method.invoke(Method.java:324) 07 at org.objectweb.proactive.core.mop.MethodCall.execute(MethodCall.java:373) 08 at org.objectweb.proactive.core.component.request.ComponentRequestImpl.serveInternal(ComponentRequestImpl.java:163) 09 at org.objectweb.proactive.core.body.request.RequestImpl.serve(RequestImpl.java:108) 10 at org.objectweb.proactive.core.body.BodyImpl$ActiveLocalBodyStrategy.serve(BodyImpl.java:297) 11 at org.objectweb.proactive.core.body.AbstractBody.serve(AbstractBody.java:799) 12 at org.objectweb.proactive.core.body.ActiveBody$FIFORunActive.runActivity(ActiveBody.java:230) 13 at org.objectweb.proactive.core.body.ActiveBody.run(ActiveBody.java:145) 14 at java.lang.Thread.run(Thread.java:534) 15 Server: begin printing... 16 ->hello world 17 Server: print done.
The Comanche example is a nice introduction to component based development with Fractal. It explains how to design applications using components, and how to implement these applications using the Fractal API.
You will notice that the example presented in this tutorial is based on Comanche, a simplistic http server. However, this example extensively uses reference passing through components. For example Request
objects are passed by reference. This is incompatible with the ProActive programming model, where, to avoid shared passive objects, all passive objects passed to active objects are actually passed by copy(see ProActive basis). As active objects are themselves passed by reference, one could argue that we could turn some passive object into active objects. This would allow remote referencing through stubs. Unfortunately, for reasons specific to the Sockets and Streams implementations, (Socket streams implementations do not provide empty no-arg constructors), it is not easily possible to encapsulate some of the needed resource classes into active objects.
Currently, we have a functional implementation of the Fractal API and model. One can configure and deploy a distributed system made of components.
However, there are currently no optimizations apart from those already offered by ProActive, such as direct communications when communicating entities are in the same virtual machine.
We are currently working on strategies for optimizations that would allow us to reduce the interceptions and the network latency times (when the components are distributed).
Reusability and Components should be accessible through predefined / preconfigured packages. A bit like enterprise archives for Enterprise JavaBeans, though there is also a notion of composition of deployment that should be addressed
Another area of investigation is the tools for configuring, deploying and monitoring distributed component systems.
Because component based programming is somewhat analogous to the assembly of building blocks into a functional product, graphical tools are well suited for the design and monitoring of component based systems. The Fractal community actually proposes such a tool : the Fractal GUI. We have extended this tool to evaluate the feasibility of a full-fledge graphical interface for the design and monitoring of distributed components. The result is available within the IC2D GUI, you can try it out, but consider it as a product in alpha state. Development is indeed currently discontinued as we are waiting for a new release of the Fractal GUI, and some features are only partially implemented (runtime monitoring, composition of virtual nodes).
The GUI allows the creation of ADL files representing component systems, and - the other way around - also allows to load ADL files and get a visual representation of systems described in the ADL files. We have worked on the manipulation of virtual nodes - a deployment abstraction - : components display the virtual nodes where they are deployed, and it is also possible to compose virtual nodes
Ultimately, we would like to couple the visualization of components at runtime (currently unavailable here) with the standard monitoring capabilities of IC2D : we would get a structural view of the application in the Fractal GUI, and a topological view in the standard IC2D frame
If you want to try out the extended Fractal GUI for ProActive :
Other areas of research that we are opening around this work include :
Some features of the Fractal model are not supported yet :
History :
March 2004 : 1st version
June 2004 : typo fix (bindFc method in "conformance ... / collective bindings" references i, not i2)
November 2004 : updated ADL documentation and examples ; updated perspectives ; super controller now included (not a limitation anymore)
February 2005 : added ADL parser usage
April 2005 : added GUI info and usage