Back to Search Start Over

Reconfiguratión and life-cycle distributed components: asynchrony, coherence and verificatión

Authors :
Rivera, Marcela
Henrio, Ludovic
Université Nice
Source :
Tesis CONICYT, CONICYT Chile, instacron:CONICYT
Publication Year :
2011

Abstract

This thesis is related to the dynamic adaptation problem in the context ofcomponent-based applications. Dynamic adaptation, in this context, is the ability to change a component system at runtime without stopping it completely. Many real component systems are critica! and can not indeed be really stopped, and their maintenance is very costly. For example, there are applications for which their adaptation must be realized with mínimum perturbation, like banking applications, or like routing Internet applications. There are various reasons for adapting a system, for example:• The behaviour of the system is not correct, then it is necessary to identify and change the components which are defectives for a new version ofthose components. The new version of the components must ha ve the same functionalities ofthe old version, but with a corrected behaviour.• The behaviour is correct but the original environment or rules have changed, then the system must be adapted to the new execution environment. Thesystem changes the components needed so that the application can behavewell under the new conditions.• The system needs new functionalities that were not considered in the conception of the system. The system must add the extensions associated to thosefunctionalities, it can add new components or change old components into new components with new functionalities.• The behaviour is correct, but the performance ofthe system is poor. Then the system needs to be optimized for improving its performance.It is very difficult to know at conception time all the problems that a system can have during its lifetime. Adaptation of a system is, thus, an essential point to consider if the system must run for a long time. The very general context ofthis thesis is components models. Indeed, the OASIStcam is highly involved in the design of a Grid Component Model (GCM), whichconsists in a Grid-oriented extension of the Fractal component model. The OASIS team is developing a distributed implementation of Fractal (overProActive- a Java library for distributed computing), together with model checkingtools adapted to those components systems. ProActive/Fractal implementationmerges the notions of active objects and Fractal components, yielding to a distributed component framework having a single thread for each component.Component models provide a structured programming paradigm, and ensure abetter re-usability of programs. Indeed application dependencies are defined togcther with provided functionalities by the mean of provided/required ports; thisimproves the program specification and thus its re-usability. In distributed systems, this takes even more importance as the structure of components can also be used at runtime to discover services or adapt component behaviour. Several effective distributed component models have been specified, developed, and implemented in the last years [27; 90; 10; 6] ensuring different kinds ofproperties to their users. To beable to prove such properties, one must rely on sorne well defined semantics for the underlying programming language or middleware. We rely here on a model for distributed components. This model is based on one key principie: Components are the unit of concurrency. More precisely, components only communicate by sending requests or results for those requests. We say that this model is asynchronous because requests can be treated in an asynchronous manner thanks to the introduction offutures (place-holders for request results). Inorder to prevent other communications or concurrency to occur, we require thatcomponents do not share memory, which ensures that components really are theconcurrency unit. From a computational point ofview, components are loosely coupled: the only strong synchronisation consists in waiting for the result of a request, and can be performed only when and where this result is really needed thanks to the use of futures. Such componcnts can then provide a convenient abstraction for distribution:each component can be placed on a different (virtual) machine. Indeed, the abstractions suggested above imply that each memory location is only accessible by one component, and thus it is easy to place each component on a different independent location. This makes our component model adapted to distribution.In general for component programming, but even more specifically in distributedand Grid environments, components need to be highly adaptative. A great part ofadaptativeness relies on dynamic reconfiguration of component systems. Fractal predefines basic controllers that should be present in most of Fractal components. We are interested here in binding, life-cycle, and content controllers. The primitivesproposed in Fractal are expressive enough for encoding any reconfiguration,but they are situated ata rather low-level and they were done for non distributed systems. Reconfigurations and all other aspects defined by component controllers are called non-functional. Doctor en Ciencias TERMINADA PFCHA-Becas 144p. PFCHA-Becas

Details

Language :
English
Database :
OpenAIRE
Journal :
Tesis CONICYT, CONICYT Chile, instacron:CONICYT
Accession number :
edsair.od......3056..37bf1cf6bf34f3a870203a68bef59567