Section: New Results

Component-oriented Grid Programming

Mechanised formalisation of a Distributed Component Model

Participants : L. Henrio, M. Khan, M. Rivera.

Component models provide a good structure for programs, and allow management of programs at runtime. The structure of component applications describes component dependencies, and can be used to reconfigure automatically the component system. Reconfiguration enables adaptation to new requirements. In this context we want to develop a mechanised model of a component model in order to prove properties on the implementation of the component model itself or on management algorithms designed for this model.

In this context, we start from a component model based on the GCM plus asynchronous invocations with futures between components. Our components communicate via asynchronous requests and replies where the requests are en-queued at the target component. The component making the invocation receives a future which represents the result of this invocation. Our model is precise enough to enable the specification of a formal semantics. Futures play a major role for such asynchronous components. ProActive/GCM is a variant of this model.

We provided a reduction semantics for the component model. This reduction semantics has been specified in the Isabelle theorem prover(available at http://www-sop.inria.fr/oasis/Ludovic.Henrio/misc.html ), and will be used to prove properties on the component model and its implementations [16] .

The above mentioned work has been further extended and a paper is under submission. This paper presents a model for distributed components communicating asynchronously using futures. Our model supports first class futures: futures can be transmitted to other components as request parameters or return values. As a consequence, future references can be dispersed among components. When the result is available for a future, it needs to be transmitted to all interested components, as determined by the particular future update strategy being used. We present formal semantics of our component model incorporating formalization of one such future update strategy. Our model has been mechanically formalized in Isabelle/HOL, together with the proof of properties. This approach validates the actual implementation of the future update strategy itself.

Designing Non-Functional Concerns as Components

Participants : F. Baude, L. Henrio, P. Naoumenko.

As part of the design of the GCM, we progressed on the research concerning the componentisation of component membranes [49] (a membrane encapsulates the component control and supervision of the functional part). This consists in adopting a component view of the non-functional and control aspects, in the same way the component model structures the functional concerns. This contribution should result in a powerful model for the design and adaptation of components control. By taking advantage of the component-oriented approach, components inside the membrane (or managers) give powerful means to design and make evolve autonomic strategies for GCM components. Indeed, GCM components can be considered as autonomic entities that change their behaviour according to changes in their environment in order to maintain an equilibrium with respect to the environment. The advantages of this approach are a better structuring of non-functional aspects, and better reconfiguration possibilities. The new structure of the membrane allows the design of distributed and hierarchical autonomic decisions, since managers inside the membrane can connect to managers situated either in membranes of inner functional components or in membranes of external components. We built a prototype and implemented an API introducing non-functional (NF) components inside the membranes of GCM components. It is now possible to create and manage NF components programmatically.

The BIONETS European projects aims at building autonomous services inspired by biology. In this context, the work on componentised membranes is used for dynamic composition and evolution of services. Indeed, a plan of composition and several autonomic and evolution strategies can be designed as component systems inside the non-functional part of BIONETS services. We successfully implemented an example of an application with autonomous entities. This work is presented in [56] . We published a more detailed implementation of this example [19] , by establishing a mapping between GCM components and the architectural elements from Autonomic Computing. We show the benefits of using a component-oriented architectural approach for designing self-adaptive systems in general. We highlight the architecture of the membranes of GCM components, as a solution to design and implement feedback loops, which are the heart of the dynamic self-adaptive behavior. The fact that the managers can be reconfigured gives the possibility to dynamically update self-adaptive strategies.

In 2009, efforts have been made to improve the ADL (Architecture Description Language) used to describe the component architecture, by introducing componentized membranes at the level of the architecture description. The idea of the improvement, apart from introducing components inside the membrane, is to reach a better separation between the membrane and the functional content, in order to allow specialists to design and develop separately the respective parts of a GCM component. Although we focus on separation of aspects, the communication between those two parts is crucial, because the membrane has to supervise the components inside the functional content. To allow this communication, we defined explicit interfaces, through which the membrane and the content can exchange messages. The detailed improvement of the model is explained in [39] . We also plan to use this new ADL to describe and implement new examples of autonomic systems with GCM components.

Reconfiguring Distributed Components

Participants : L. Henrio, M. Rivera.

We have finalised the definition of a framework to support distributed reconfiguration of component systems. This work extended an existing scripting language to enable remote interpretation of reconfiguration procedures. To support this extension of the language, we had to extend components with a non-functional ability: the interpretation of reconfiguration scripts. Thanks to this approach, reconfiguration scripts can now be evaluated in a distributed, i.e., non-centralised, manner. The resulting interpreter, together with the script extension have been implemented and experimented using the ProActive implementation of the Grid Component Model. This work is presented in [17] .

We plan to design a way of specifying synchronisation between reconfiguration steps and the application, this should be the main interaction between functional and non-functional aspects, and should be studied carefully in order to maintain the "good separation of aspects" that exists in Fractal and GCM.

SPMD and Components

Participants : F. Baude, E. Mathias.

In the context of the DiscoGRID ANR funded project, we have continued to promote the usage of a GCM-based infrastructure to support an MPI-like hierarchical SPMD programming model (Section  8.1.2 ). The idea of this infrastructure is to wrap MPI processes within primitive components and use the components and their inherent features to efficiently support point-to-point and collective communication whenever the MPI communications are not possible.

This work is done in collaboration with applied mathematicians (namely the CAIMAN/NACHOS and SMASH teams, partners of the DiscoGRID project). As a matter of fact, they represent a community where programmers are used to the standard SPMD message-passing based model, and that are quite reluctant to adopt another model. Nonetheless, they are ready to design and program their parallel algorithms in a way that takes the physical hierarchy into consideration. A key point to the success of this partnership is the development and usage of solutions in a completely transparent way for programmers.

In order to support DiscoGrid primitives and MPI collective communications we have improved GCM collective interfaces and extended the proposed specification of GCM collective interfaces by defining a complex collective interface called gather-multicast, which is, in fact, a concatenation of a gather and a multicast interface [57] . These improvements came from the need to perform more advanced collective communication at interface level and include the possibility to define partial-multicast and partial-gathercast invocations along with the configuration of communication semantics, aggregation, distribution and reduction policies.

The usage of GCM components has introduced scalability and performance issues due to bottlenecks in aggregation and distribution policies. Our approach to tackle this problem has been the definition of direct bindings among components to bypass the bottlenecks and somehow distribute the gather-multicast communication semantics whenever a direct link exists between involved resources. Otherwise, the standard MxN communication is still available. These concepts and results over the Grid5000 platform were published in [21] and have shown the usefulness and the importance of introduced interfaces and their optimisations.

Recently, we have also included in the implementation of the hierarchical SPMD the support of SSH message tunnelling and forwarding to make possible the integration of resources behind firewalls and NAT addressing. Such an approach has made possible the integration of resources in multiple domains even without direct network connectivity, without much of overhead, be these domains parts of computing grids or computing clouds. The implementation and practical results have been presented in a paper that has been submitted to CCGrid'2010, and contributing materiel for chapter submitted to a book entitled Cloud Computing: Principles, Systems and Applications to be published by Springer in 2010.

The implemetation of the hierarchical SPMD has proved to be general enough to be used in different contexts where applications running in different domains need to transparently communicate. For this reason, this solution is currently being adapted to the SOA4All project specificities, aiming to provide a communication layer capable of federating Distributed Enterprise Service Buses at internet scale. Section  6.4.4 and [18] describe this work in more details.

Monitoring Components

Participants : F. Baude, C. Ruz.

Monitoring components is important not only for optimising or fine-tuning an application. Being able to collect on-line monitoring data can help to make runtime decisions over the configuration of a system in order, for example, to ensure a previously agreed QoS.

We are designing a monitoring component-based system that will reside (at least partly, some complementary aspects being for instance deployed as probes at the level of the service bus) in the membrane of GCM components. This monitoring system will be able to track the runtime path of a request triggered by an executing component-based application. The information of the components involved in serving a request and the time it took to serve it in each of them will help to determine weak points in the application.

Our current implementation takes profit of the componentised membrane of GCM components, to introduce a Monitoring Component which stores the relevant information for doing performance monitoring, in a distributed, scalable and low intrusive way [23] . We have performed tests over a small proof-of-concept application, while we are in the way to extend to a more real scenario.

The monitoring scheme must be general enough to be used for any GCM application, whatever its hierarchical architecture, and to allow for scalability considering that no single component must need to keep all the information of the system (see [23] ); instead the components in charge of monitoring can interact with external components by using non functional interfaces to obtain the desired information in a pull mode. In a similar way, inner components of a composite can send notifications to their parent in a push mode, also using non functional interfaces. This feature will be also promoted to GCM components applications seen as SCA applications. Indeed, membranes of GCM components will host controllers to give these components an SCA personality. Among the controllers in the membrane, we will be able to plug those dedicated to monitoring, thus, getting for free, an innovative way to monitor SCA based SOA applications.

Mapping Workflows on Components

Participants : F. Baude, V. Legrand Contes.

The need of a scalable, agile, and adaptable workflow engine is gaining more and more interest in the SOA community. This kind of workflow engine will provide non functional features to service compositions. Those non-functional features could include fault tolerance, agility, and adaptability according to the execution context or service availability.

In the context of the SOA4All project and the Galaxy INRIA ADT we aim at demonstrating the interest of mapping a service composition (i.e. workflow) into a GCM component; a workflow is thus represented by a hierarchical and distributed component. Thus, it benefits from the Fractal properties, and in particular dynamic reconfiguration.

We explored different ways to model a service composition with GCM components and identified the best way to use GCM at the different steps of the workflow life-cycle: deployment, dynamic and distributed workflow execution, and monitoring of the execution.

We achieved a first proof-of-concept [43] enacting the dynamic and possibly distributed execution of a BPEL process. As BPEL processes can be enacted in any BPEL engine, we chose to evaluate the Active BPEL engine, however we plan to evaluate another engines like e.g. Apache ODE, Orchestra, or the BPEL engine of the Xservices platform.

Up to now, our prototype is able to intercept calls between the engine and the involved services in the process. This gives us a finer and better control over the bindings and allows us to change them at will (like e.g. when an error occurs, a machine goes down or a network failure or software issue in the impacted service). We thus progressed in the design and implementation of a reconfiguration tool for SCA-based applications. Our reconfiguration tool manages components that are described using any kind of workflow language (BPEL, XPDL or any other). Our tool is in charge of the deployment of the needed workflow engines, and also, it effectively manages and modifies at will during the workflow execution, the SCA bindings to the involved services. A publication has been submitted to a journal mid-september (IJARAS). Demonstration of the proof-of-concept was done at Java One in June 2009.