Résumé :

L’approche à composants est une méthodologie qui soutient l’idée que la

construction de logiciels peut être réalisé à partir de l’assemblage d’entités logicielles
réutilisables appelées composants [SZY].Un composant définit de manière explicite
un ensemble de provisions de dépendances pour permettre de réaliser sa
composition. Un aspect important de l’approche à composants est qu’elle suppose
que les activités de développement de composants et leur assemblage sont
clairement différenciés, ces activités peuvent d’ailleurs être réalisées par les acteurs
distincts. Pour mettre en évidence le rôle de chaque composant et ses activités qu’il
réalise, nous avons pensé à concevoir un patron générique, avec des couches,
illustrant chaque entité ce qu’elle remplit comme rôle. Actuellement, il existe de
nombreux modèles à composants. Parmi ces modèles, certains sont destinés à des
domaines d’applications spécifiques, tels que COM, EJB, CCM et .NET tandis que
d’autres se veulent plus universels comme Fractal [BRU].

1. Introduction :

La complexité croissante du système d’information et leur évolution de plus en plus

rapide, ont suscité un intérêt accru pour le développement de logiciels à base de
composants. Cet intérêt est motivé par la réduction des coûts et des délais de
développement des applications. Il est reconnu que ce sont les premières étapes du
développement du logiciel qui sont cruciales pour parvenir à la meilleure adéquation
entre les besoins exprimés et la réalisation proposée, et pour éliminer au maximum
toute source d'erreur.Une application peut être divisée en plusieurs parties, chacune
de ces parties définissant une fonctionnalité à part entière. Les parties peuvent être
détachées les unes des autres et définies d'une manière indépendante, souvent par
une personne autre que le programmeur principal.

Dans le modèle MADCAR [GRO], on trouve un modèle de moteurs, capable

d’assembler et d’adapter automatiquement et dynamiquement des applications à
base de composants. Ce moteur d’assemblage possède quatre entrées : un
ensemble de composants à assembler, une description de l’application qui
représente la spécification de l’assemblage en termes de propriétés fonctionnelles et
extra-fonctionnelles, une politique d’assemblage qui dirige les décisions d’adaptation
et un contexte qui contient un ensemble de données (état de l’application, CPU
disponible, bande passante, etc.).

De ce fait, nous proposons dans ce papier, un modèle générique, qui n’est plus
complexe, orienté composant, qui permet de réaliser des applications multi
composant, extensible et adaptable aux différents environnements ainsi qu’aux
contextes, tout en passant par une reconfiguration automatique. Nous avons introduit

1
la notion du Contrôleur dans une couche, qui fait la sélection des composants à
assembler et maintenir l’état de l’application, et sans déterminer le rôle de chaque
composant, c’est-à-dire, sans construire déjà des composants liés et assemblés, ce
qui rend en fait, la tâche du développeur de l’application difficile.

De notre part, nous avons proposé un composant dit Composant Intelligent, dans
la couche Contrôleur, assurant le contrôle, la gestion du cycle de vie et qui connait
les différents composants, incluant les trois interfaces qui sont respectivement,
BindingCotroller, LifeCyleController et ContentController.

En effet, nous avons introduit une notion, qui s’appelle Conteneur, qui répond aux
besoins de réutilisation et de configuration de l’exécution de composants et qui gère
le cycle de vie des composants.

Cet article est structuré de la façon suivante. La section 2 présente un schéma

général du modèle proposé avec les quatre couches. La section 3 détaille chaque
couche composite de ce modèle. La section 4 présente une synthèse illustrant le
fonctionnement de notre modèle. Et finalement la section 5 présente une conclusion
et des perspectives à ce travail.

2. Modèle générique :
Nous avons proposé un modèle qui permet la configuration, la sélection des
composants appropriés, l’assemblage et l’adaptation automatiques d’applications à
base de composants logiciels. Chaque partie de ce modèle joue un rôle et réalise
une activité, afin de construire une application à base de composants qui satisfait
une fonctionnalité du système.

Tout cela, dans le but de générer un patron qui respecte tous les aspects d’un
système informatique et les contraintes qu’il peut confronter. Un modèle qui est
capable d’être projeté sur toutes les plates formes et indépendant de tout un langage
de programmation.

Comme illustré dans la figure 1, nous avons présenté un modèle générique

permettant de construire ou d’adapter une application à partir de quatre entrées : une
entrée est la couche de Modèle de Configuration de l’Application. Elle représente un
ensemble de composants à assembler en langage universel IDL. L’autre entrée du
modèle est la couche Contrôleur. Elle est destinée à faire l’assemblage adéquat pour
satisfaire une fonctionnalité. Quant à l’entrée de la couche contexte, il a pour rôle de
détecter l’environnement d’exécution pour l’adaptation de l’application. Finalement,
pour la couche Conteneur, il gère le cycle de vie des composants de l’application.

2
 Contexte interne Contexte externe

Assemblage de composants

Contexte
(1)

Moteur de Contrôle (3)

Composants en Buffer
Contrôle, Recherche
Et Gère.

Contrôleur

(2) Composants en Pool

Description des composants en IDL

Conteneur
Modèle de Configuration de l’Application

Figure1. Schéma du Modèle générique.

3. Les Couches-Composites :

3.1 Couche-Composite : Modèle de configuration de l’application MCA

Cette couche dite, Modèle de configuration de l’application est considéré, une

réserve pour le stockage des composants déjà configurés.Tous les composants qui
forment l’application toute entière, sont bien décrits afin de faciliter et faire le bon

3
assemblage. Cette description sous forme : Types de composants, leurs ports ainsi
que la signature des interfaces décrites à l’aide du langage OMG Interface
Definition Language (OMG IDL 3.0). Le rôle principal de cette couche est de bien
présenter chaque composant qui va être assemblé pour réaliser la fonctionnalité
voulue et du coup de l’application.

Dans le langage IDL, il y a des éléments des composants à décrire qui fournissent
toutes les informations nécessaires (Nom, Type, Interface, Nom Composant,…)
pour l’utilisation de ce composant lors d’un appel, en vue de répondre à un besoin de
l’utilisateur. Et conformément à la démarche MDA (Model driven
architecture) [MDA], notre modèle à couche est un modèle indépendant
de toute plate-forme (PIM). Le concepteur peut adapter le modèle
spécifique (PSM) obtenu, en particulier en définissant ses choix
d'implantation.

Coder en langage de programmation IDL.

Cibler un langage de programmation

Cibler une plate-forme

Figure2. Description d’indépendance de la couche Modèle de configuration de l’application

Pour bien comprendre le rôle de cette couche dans notre modèle, nous proposons
un exemple d’un composant logiciel, qui remplit une fonctionnalité dans un système
informatique. On prend une simple application appelée ANNUAIRE [COR], comme
étant un répertoire gérant la liste des personnes, avec des propriétés comme : Nom,
information, Email, Téléphone. Dans cette application, on peut créer plusieurs
répertoires, chacun est désigné par un nom (libellé). On peut même utiliser un
répertoire via son interface : ajouter, supprimer, modifier, obtenir, lister des
personnes. Ce composant est décrit en langage Interface Definition Language
(OMG IDL 3.0), afin d’être programmé en un autre langage selon les besoins.

4
Fichier annuaire.idl

// contrat OMG IDL de l!application Annuaire

# include <date.idl> // Réutilisation du service de dates

#pragma prefix = «"lifl.fr"» // Organisation auteur

module annuaire {

typedef string Nom; // Nom d!une personne

typedef sequence<Nom> DesNoms; // Ensemble de noms
struct Personne { // Description d!une personne

Nom nom; // - son nom

string informations; // - données diverses
string telephone; // - numéro téléphone
string email; // - adresse éléctronique
string url; // - adresse web
::date::Date date_naissance; // - date de naissance

};

interface Repertoire {

readonly attribute string libelle; // le libellé (nom) du répertoire

exception ExisteDeja (Nom nom; );

exception Inconnu (Nom nom; );

void ajouterPersonne (in Personne personne)

raises ExisteDeja ;

void retirerPersonne(in Nom nom)

raises Inconnu ;

void modifierPersonne(in Nom nom, in Personne personne)

raises Inconnu ;

Personne obtenirPersonne (in Nom nom)

raises Inconnu ;

DesNoms listerNoms ();

}; // fin interface

}; // fin module

5
 3.1 Couche-Composite : Conteneur Logique

Désigné à contenir des instances de composants et à leur fournir les services

nécessaires à leur exécution dans un environnement donné, le conteneur est un
point de recherche central dans les plates-formes à composants [GED]. Ils
répondent aux besoins de réutilisation et de configuration de l’exécution de
composants. En effet, les conteneurs permettent l’isolation de code métier
(encapsulé dans les instances de composant) des spécificités de l’environnement
d’exécution. La réutilisation du code est possible par adaptation de l’ensemble de
services fournis par le conteneur [VAM].

Ce conteneur est considéré l’infrastructure de gestion pour un ou plusieurs

composants. Il est responsable de la création et destruction des composants, il gère
ces composants pendant leur existence, en particulier nommer et localiser. En plus,
il est susceptible de faire activation ou passivation, mais selon les besoins
engendrés.

Il contribue énormément aux performances de la machine d’exécution, et ceci en

éliminant les composants non utilisés. De ce fait, il fait la gestion des appels entrants
et sortant venu de la part du Contrôleur qui prend les composants convenables et
les connecter pour former la fonctionnalité voulue.

Entre autres, il encapsule les composants qui ont rôle à remplir pour répondre à un
service. Il est doté aussi d’un buffer qui lui permet de gérer tous les éléments
composants qui sont en mode connecté ou déconnecté ainsi qu’une cache mémoire
afin d’optimiser les performances d’exécution.

Le conteneur est à l’interface entre les composant et les fonctionnalités. Le

paramétrage et la configuration de chaque composant de l’application dans la
couche : Modèle de configuration de l’application ont permis de faire
l’assemblage approprié (Couche Contrôle) et faire la gestion de cycle de vie des
composants (Couche Conteneur).

3.2 Couche-Composite : Contrôleur

L’utilisateur d’une application à multi composants, peut lancer un traitement en vue

d’obtenir un résultat qui répond à ses attentes. Pour ce faire, il est vu, pour accomplir
cette mission en toute pertinence, d’allouer à une partie de l’application, la prise en
charge entière, de scruter ce traitement. Ce dernier est le responsable de déclencher
tout un processus, qui a fait naissance d’une couche qui ne cesse d’être de plus en
plus étudié, par les architectes et les professionnels.

6
Cette couche est considérée la plus importante de ce modèle générique, pour une
application à multi composants. Il inclut un composants nommé : Composant de
Contrôle. En plus des interfaces connues dans un composant, ce dernier dispose
d’une liste des interfaces de contrôle incluant, entre autres, une interface dédiée à la
gestion du cycle de vie (LifecycleController -LC-), à la liaison entre instances
(BindingController -BC-) et au contrôle du contenu (ContentController -CC-) dans
le cas où le composant serait composite [HUM]. D’ailleurs, grâce à l’interface
BindingController que cette couche fait son rôle essentiel. De ce fait, cette interface
assure les liaisons entre les composants avec d’autres composants. On pourrait dire
c’est un composant intelligent. Il connaît la spécification de chaque composant
(Configuration), en terme de propriétés fonctionnelles et extra-fonctionnelles et il
dirige les décisions d’adaptation selon le contexte fourni qui reflète aussi bien les
informations sur les ressources matérielles (CPU disponible, bande passante, etc.)

Cette couche assure énormément la reconfiguration de cette application. Pour faire

l’assemblage adéquat, le composant Contrôleur lance une recherche sur les
composants à lier dans la couche Modèle de Configuration de l’application, puis il
envoie cet assemblage de composants dans la couche Conteneur pour procéder à
sa gestion. Le Contrôleur ordonne toujours le Conteneur de faire la suppression, la
création (Instanciation), ou le remplacement nécessaire pour former un autre
assemblage de composants en cas de changement de l’état de l’application. Le
Conteneur suit les ordres du Contrôleur, que ce soit au niveau d’installation,
d’activation ou passivation. Le Contrôleur prend en charge le déroulement de cycle
de vie des composants d’une application. Donc, Le Contrôleur donne des ordres,
contrôle et détecte. Au même titre, si une déconnexion survient, le Contrôleur
déclenche une alarme pour avertir le Conteneur pour qu’il garde l’assemblage,
désigné par le Contrôleur, en son buffer pour sa prochaine connexion. D’autre part,
la couche Contrôleur peut gérer un ensemble d’utilisateurs en même temps, grâce à
son pool. Et pour gagner toujours de performance, le Contrôleur ordonne le
Conteneur de charger dans sa mémoire cache, un ensemble défini de composants,
car la couche Contrôleur, via son pool, connaît les utilisateurs qui vont faire recours
aux mêmes ensembles de composants.

3.3 Couche-Composite : Contexte

En fait, « Le Contexte n’est pas simplement l’état d’un environnement prédéfini avec
un ensemble fixe de ressources d’interaction. Il fait partie d’un processus
d’interaction avec un environnement en perpétuel changement composé de
ressources reconfigurables, migrables, distribuées et multi-échelles » [COU].

Par conséquent, la première entrée d’un contrôleur est un gestionnaire de contexte

qui modélise l’évolution d’un contexte d’exécution. Le gestionnaire de contexte doit
définir un ensemble de données pertinentes utilisées par un contrôleur non

7
seulement pour affecter les décisions d’adaptation mais aussi pour déclencher les
adaptations.

Le gestionnaire de contexte peut être en rapport avec les aspects internes ou

externes de l’application. Le contexte externe d’une application inclut les
informations sur les ressources matérielles (par exemple, CPU et mémoire), les
réseaux disponibles (par exemple, bande passante courante et bande passante
maximale) et des données géophysiques (par exemple, localisation et température).
Le contexte interne d’une application est constitué des informations issues des
composants de l’application : Pourquoi et dans quelle domaine cette application,
quels composants sont utilisés, quelles sont les connexions entre les composants et
quel est l’état courant de l’application.

4. Synthèse :

User 9 3 Contexte

1-2

7-8

4-5-6
Contrôleur
Conteneur

MCA

Figure3. Synthèse du Modèle générique.

8
1. L’utilisateur lance une requête en vue d’obtenir un service.

2. Le contrôleur reçoit cette requête et commence son traitement de cette

requête.

3. Le contrôleur d’abord, se dirige vers la couche Contexte pour prendre les

décisions et déclenche l’adaptation.

4. D’après le résultat du traitement de la requête, le contrôleur lance une

recherche dans la couche Modèle de Configuration de l’Application.

5. Dans cette recherche approfondie basée sur la description de chaque

composant, Le contrôleur procède à une sélection des composants
convenables qui peuvent être assemblés.

6. Le contrôleur réalise l’assemblage dans la couche Contrôleur, via son

interface BindingController.

7. Après avoir réalisé l’assemblage, le contrôleur envoie cet assemblage à la

couche Conteneur.

8. Dans la couche Conteneur, se fait la gestion de cycle de vie, de

l’ensemble des composants. (Création d’instance, Remplacement,
Suppression).

8.1 Si le Contrôleur reçoit une requête pour répondre à un autre

service, il lance un ordre de créer une autre instanciation ou de
faire le remplacement d’un composant (Reconfiguration
dynamique).

8.2 Si le Contrôleur reçoit plusieurs et mêmes requêtes, c’est-à-dire,

qu’il y a plusieurs utilisateurs qui demandent les mêmes
fonctionnalités, il ordonne le Conteneur d’activer son pool pour
faire la gestion de ces utilisateurs.

8.3 Si le Contrôleur voit qu’un ensemble de composants se réutilisent

souvent, ou bien une déconnexion qui survient, il ordonne ainsi, le
Conteneur d’activer sa cache mémoire, pour répondre
rapidement à un service.

9. L’utilisateur reçoit son service voulu.

9
Conclusion et perspective :

Le développement à base de composants est devenu un concept fondamental dans

la construction d’une application. Il comporte tous les critères de la qualité, ce qui
mène la communauté des développeurs, à s’orienter entièrement au cours des
années, à ce type de développement. En effet, notre vision s’inscrit dans le cadre de
concevoir un modèle générique qui permet de construire une application à base de
composants, pour les systèmes d’information.

Dans ce papier, nous avons introduit une approche, qui présente le modèle sous
forme de quatre couches, chaque partie de ce modèle accomplit une mission. Parmi
les fonctionnalités qu’il est censé à appliquer, faire l’assemblage approprié des
composants, adaptation dynamique avec l’environnement d’exécution et du contexte.
Le modèle proposé combine les avantages de l’approche du moteur MADCAR
[GRO] et le framework Fractal [HUM] et bien sûr le développement à base de
composants.

Dans les prochaines études, nous comptons porter plus de détails, sur la couche du
Contrôleur (Composant Intelligent), avec les différentes interfaces de ce composant,
en l’occurrence, BindingController, LifeCyleController et ContentController,
sachant que chacune de ces interfaces joue un rôle défini, pour accomplir sa
mission. Et sans oublier, la couche Conteneur, qui contribue énormément, dans ce
modèle, pour la réalisation d’une application multi composant. Actuellement, Cette
notion se trouve dans de nombreuses applications modèles à composants. Parmi
ces modèles, certains sont destinés à des domaines d’applications spécifiques, tels
que COM, EJB, CCM et .NET tandis que d’autres se veulent plus universels comme
Fractal [DAH]. Et Nous allons enfin aborder, l’aspect Contexte de ce modèle
générique, qui permet une adaptation dynamique avec les différentes contraintes.

10
Bibliographie :

[MDA] OMG Model-Driven Architecture Home page,

http://www.omg.org/mda/.

[BRU] Bruneton E., Coupaye T., Stefani J.-B., The Fractal Composition
Framework Version 2.0-3, ObjectWeb Consortium, Juillet 2004.

[SZY] Szyperski, C., Component software: beyond object-oriented

programming, ACM Press/Addison-Wesley Publishing Co., 1998.

[GRO] Guillaume Grondin, Noury Bouraqadi et Laurent Vercouter :

Assemblage automatique et adaptation d’applications à base de
composants, 2006.

[HUM] Humberto Cervantes, Mikael Désertot, Didier Donsez : FROGi :

Déploiement de composants Fractal sur OSGi.

[GED] G.Eddon, H.Eddon. Inside Distributed COM. Microsoft Press, 1998,

Sun Microsystems. Enterprise Java Beans Specification Version: 2.0. Sun
Microsystems. 2000.

[VAM] Vania Marangozova_, Projet SARDES - INRIA Rhône-Alpes : Patrons

de conception pour la duplication de composants.

[DAH] Daniel Hagimont IRIT/ENSEEIHT : Le modèle de composants Fractal.

[SAK] Sacha Krakowiak, Université Joseph Fourier, Projet Sardes (INRIA et

IMAG LSR) : Composants logiciels Introduction aux composants.

[COU] Coutaz, J., J. L. Crowley, S. Dobson, et D. Garlan (2005). Context is

key. Commununication of the ACM 48(3), 49–53.

[COR] CORBA : Exemple d’application repris de : J.-M. Geib, C. Gransart et

Ph. Merle.

Meriem Belguidoum, Antoine Beugnard, Fabien Dagnat ENST Bretagne :

Analyse des dépendances pour le déploiement automatique de
composants.

11
12