| Description des sous-projets(Environ
2 pages imprimées par sous-projet)
En prenant
comme point de départ les travaux autour de TINA, qui propose de
construire une application répartie sous la forme d'un assemblage
de composants reliés entre eux par des objets de liaison (appelés
connecteurs), nous avons organisé ce projet en 5 sous-projets :
-
Sp 1 : Architecture d'une infrastructure réflexive
à composants répartis : concevoir et réaliser
un telle infrastructure en prenant comme point de départ un langage
de programmation (Java et sa machine virtuelle), un middleware de communication
(Jonathan développé dans le cadre du projet PAROL) et un
middleware d'intégration (JOnAs proche du modèle EJB pour
l'intégration des bases de données ; Joram proche du modèle
JMS pour l'intégration des applicatifs existants).
-
Sp 2 : Ajout dynamique de propriétés
non-fonctionnelles aux composants : validation de l'architecture réflexive
pour mettre en oeuvre des propriétés de mobilité,
migration, réplication et mode déconnecté.
-
Sp 3 : Ajout dynamique de propriétés
non-fonctionnelles aux objets de liaison : validation de l'architecture
réflexive pour mettre en oeuvre des propriétés liées
à la communication (communication de groupe, coordination, interaction).
-
Sp 4 : Supervision et configuration dynamique
: validation de l'architecture pour la prise en compte du déploiement,
de l'administration, de la reconfiguration de composants. Ce sous-projet
servira d'application de test permettant de mettre en évidence la
flexibilité de la plate-forme et l'adaptabilité des composants.
-
Sp 5 : Intégration, évaluation de
la plate-forme et diffusion des résultats : coordination de
l'intégration de tous les éléments développés
dans le cadre du projet. Évaluation fonctionnelle de la plate-forme
au travers d'applications tests. Evaluation quantitative de la plate-forme
extensible réalisée. Diffusion des résultats dans
le consortium ObjectWeb et dans d'autres organisations.
Sous-projet 1
: Architecture d'une infrastructure réflexive à composants
répartis (Responsable : ESLO - Partenaire : tous)
-
Description du sous-projet, du responsable
et des partenaires
Ce sous-projet va spécifier l'architecture
d'une plate-forme extensible (qui peut être étendue dynamiquement)
basée sur des composants adaptables (capables de se modifier pour
prendre en compte une évolution de l'environnement). Ce projet s'inscrira
dans le cadre du langage de programmation Java (et de sa machine virtuelle),
du middleware de communication Jonathan (développé dans le
cadre du projet RNRT PAROL) et du middleware d'intégration JOnAs
(proche du modèle EJB).
1) Motivation
Historiquement, la réutilisation était
l'une des principales promesses de la programmation par objets. Malheureusement,
cet objectif n'est que partiellement atteint. L'une des origines de cet
échec se trouve être le mélange, lors de l'implémentation
des applications, des définitions des services réalisés
("fonctionnalités'') avec des propriétés d'infrastructure
représentant les mécanismes d'exécution (distribution,
réplication, migration, ...). Aujourd'hui, les architectures d'intégration
de composants ne doivent pas perdre de vue ce constat pour proposer une
solution garantissant la réutilisation et l'adaptabilité
des composants.
Afin d'éviter l'entrelacement de code dans
la définition des composants, le paradigme de la séparation
des aspects considère que les services d'une application ("propriétés
fonctionnelles") et ses propriétés d'infrastructure ("propriétés
non fonctionnelles") correspondent à des aspects qui doivent
être définis séparément les uns des autres.
L'application finale est alors obtenue par la composition ("assemblage'')
de ces différents aspects. L'utilisation de ce paradigme pour la
conception des architectures d'intégration de composants constitue
un enjeu considérable pour améliorer la réutilisation
des composants et esquisser la notion de composant adaptable.
La réflexion constitue l'une des
approches possibles pour mettre en oeuvre la séparation des aspects.
Rappelons qu'un système est dit réflexif s’il possède
une auto-représentation décrivant la connaissance qu’il a
de lui-même. Un tel système peut alors répondre à
des questions le concernant, mais aussi s’auto-modifier. Les diverses caractéristiques
des programmes sont rendues concrètes (i.e. réifiés)
et peuvent être manipulées par des méta-programmes.
Dans un langage à objets réflexif, la réflexion permet
de distinguer ce que fait un objet (son niveau de base) de comment il le
fait (son méta-niveau). Il existe alors une séparation clairement
définie entre les fonctionnalités de l’application ("aspects
fonctionnels"), programmées au niveau de base, et leurs représentations
et contrôles ("aspects non fonctionnels"), programmés au méta-niveau.
La mise en oeuvre de la réflexion dans les architectures à
composants va donc permettre de construire des composants réutilisables
et des infrastructures d'accueil flexibles.
2) Description
Ce sous-projet a pour but d'étudiar la
faisabilité et de concevoir une infrastructure flexible pour composants
répartis, en s'appuyant principalement sur les techniques de réflexion.
Cette infrastructure proposera une structure d'accueil fournissant un ensemble
de services communs (propriétés non fonctionnelles) pour
composants adaptables. La flexibilité apportée par la réflexion
permettra une évolution aisée (par ajout, par modification)
des différents services offerts par la structure d'accueil. En complément,
l'infrastructure devra supporter une configuration et une adaptabilité
dynamique
des composants. En effet, les applications auront la capacité d'adapter
dynamiquement le comportement de leurs composants aux conditions changeantes
d'exécution, pour satisfaire un ensemble de propriétés
et de contraintes de qualité de service.
L'infrastructure ainsi définie devra prendre
place au sein de la plate-forme à objets ObjectWeb (Jonathan+Jonas).
3) Responsable et partenaires
Le responsable technique du sous-projet
1 sera Thomas Ledoux - Maître Assistant à l'Ecole des Mines
de Nantes.
Ce tâche essentielle pour le devenir du
projet sera conduite par l'équipe ESLO de l'Ecole des Mines de Nantes
constituée de 2 professeurs, 5 maîtres-assistants et 3 thésards.
Cette équipe s'intéresse en particulier à la notion
de composants et aux nouveaux moyens de composition et d'adaptation fournis
par la réflexion et la programmation par aspects. En particulier,
la réflexion fournit une base d'implémentation de la programmation
par aspects qui, en retour, permet d'en maîtriser la puissance. Les
problèmes de performance inhérents à cette approche
sont fortement réduits grâce à des techniques de spécialisation
de programmes comme l'évaluation partielle.
Les différentes équipes participantes
à ce projet travaillent aujourd'hui sur l'apport de la réflexivité
soit pour étendre dynamique une plate-forme répartie, soit
pour adapter le comportement d'un composant. Elles participeront de manière
active à la réalisation de ce sous-projet qui est à
la base des autres sous-projets.
-
État de l'art en matière de plate-forme
extensible et de mécanismes pour l'adaptabilité des
composants.
-
Étude de la plate-forme d'intégration
ObjectWeb.
-
Spécification et évaluation d'une infrastructure
flexible à composants répartis basée sur la réflexion.
-
Définition d'un cadre de réactivité
fixant des conditions minimales d'adaptation des composants en fonction
de l'évolution de l'environnement d'exécution.
-
Étude des coûts de l'approche retenue
et optimisation grâce à des techniques de spécialisation
de programmes comme l'évaluation partielle.
-
Détail des réalisations
et échéances
1) État de l'art sur l'adaptabilité
Faire une synthèse précise des
différentes approches permettant de prendre en compte l'adaptabilité.
a) les travaux portant sur l'architecture du
système d'exploitation : approches fondées sur les exo-noyaux
et nano-noyaux, tels que : Aegis (MIT), L4 (GMD), Nemesis (U. Cambdrige)
; systèmes d'exploitation réflexifs tels que : Flexinet (APM
), Apertos (Sony) ; systèmes d'exploitation extensibles tels que
Spin (U. de Washington), Synthetix (Oregon Institute) ;
b) les travaux portant sur des technologies de
compilation, tels que : Tempo, Harissa, JSpec (IRISA), HotSpot (Sun
Microsystems), Java Hot Set ;
c) les travaux portant sur des versions réflexives
de Java : Reflective Java (APM), MetaXa (U. d'Erlangen), Kava (U. de Newcastle),
Javassist (U. de Tsukuba) ;
d) les travaux autour de la programmation par
aspects : AspectJ (Xerox PARC), HyperJ (IBM Watson), Aspectual
components (Northeastern University) ;
e) les travaux portant sur les approches "middleware"
ouvertes, c'est-à-dire sur la construction de services systèmes
pour gérer l'adaptabilité en fonction des besoins des applications.
Cette approche repose aussi sur l'existence d'une API flexible pour réaliser
le dialogue entre l'application et le système : Reflective
Middleware (Lancaster Uni), OpenCorba (Ecole des Mines de Nantes),
DynamicTAO (Uni of Illinois).
2) Étude de l'environnement d'intégration
a) étude des possibilités d'intégration
à Java de protocoles d’introspection et d’intercession permettant
de mettre en oeuvre une programmation réflexive efficace ;
b) étude approfondie des modèles
de composants actuels (COM, EJB, CCM), de leur utilisation et des outils
associés. En effet, le projet ne vise pas la création d'un
nouveau modèle de composants et d'outils ad hoc. Il s'agit d'en
expliciter les limites quant à notre domaine d'intérêt
- l'adaptation - et de fournir, à différents niveaux
(des concepts aux outils) des éléments permettant de les
dépasser. Le middleware d'intégration JOnAs sera la plate-forme
cible ;
c) étude approfondie du middleware de
communication Jonathan. Ce dernier décrit un ORB minimal extensible,
qui autorise l'implantation de mécanismes de liaison arbitraires
entre objets répartis. Ces mécanismes de liaison sont aujourd'hui
définis dans des objets de liaison (binding objects) qui encapsulent
la sémantique de la communication entre objets répartis.
Dans cette approche, il faut donc anticiper les besoins des applications
et définir statiquement tous les objets de liaison susceptibles
d'être utilisés par la suite dans une relation client-serveur.
Ce point sera étudié conjointement avec le sous-projet 3
qui s'attache à donner des spécifications précises
aux objets de liaison par l'intermédiaire d'un modèle exécutable
dans la plate-forme.
3) Spécification et évaluation
d'une infrastructure flexible basée sur la réflexion
En fonction des études précédentes,
des différentes expériences propres aux équipes du
consortium, le projet devra dans un premier temps définir une architecture
permettant la construction d'une infrastructure flexible basée sur
la réflexion et dans un second temps, proposer un modèle
de composant adaptable.
a) infrastructure flexible basée sur la
réflexion
La structuration d'un programme à l'aide
de protocoles de méta-objets représente un des moyens
les mieux adaptés pour séparer la mise en oeuvre de différents
aspects. Les aspects de distribution et de synchronisation, par exemple,
ont déjà été exprimés dans des cadres
réflexifs avec beaucoup de succès (voir p. ex. les travaux
autour de CodA de J. McAffer). Ce sous-thème a pour objectif de
spécifier l'infrastructure d'une plate-forme extensible à
l'aide de la réflexion.
b) modèle de composant adaptable
L'infrastructure doit pouvoir faire face à
l'évolution de ses besoins propres ou à des variations de
son environnement d'exécution. En effet, d'une part, la demande
des applications évolue dans le temps pour différentes raisons
:
-
l’exigence en matière de qualité de
service, par exemple pour manipuler des flots multimédias, varie
dans le temps ;
-
la structure même de l’application évolue
de façon dynamique (changement de version d’un composant logiciel,
introduction d’un nouveau service applicatif, etc.).
D'autre part, l'évolution de l'environnement
d'exécution dans le temps est soumis à des fluctuations,
temporaires (congestion du réseau, panne d'une machine, etc.) ou
permanentes (connexion d'une nouvelle machine par exemple). La notion de
composant adaptable est donc nécessaire pour garantir la réactivité
de l'application à des contraintes de qualité de service.
Ce sous-thème a pour but de définir un cadre de réactivité
fixant des conditions minimales d'adaptation des composants en fonction
de l'évolution de l'environnement d'exécution. L'introspection
du débit réseau et la prise en compte de ce débit
pour adapter dynamiquement le comportement des composants, constitue un
premier exemple de ce cadre de réactivité.
Ce travail d'architecture se fera en lien avec
une étude de l'architecture de la plate-forme d'intégration
ObjectWeb afin que les résultats puissent être rapidement
disponibles
4) Coûts et optimisation
Ce sous thème vise à concilier
les impératifs de généricité - apportée
par la réflexion - et de coûts. Les problèmes
de performance inhérents à la réflexion sont fortement
réduits grâce à des techniques de spécialisation
de programmes comme l’évaluation partielle. Plus précisément,
cette dernière technique consiste à rendre performant un
programme générique en l'adaptant à un contexte donné
d'utilisation. Le contexte est défini par un ensemble de paramètres
qui peuvent être relatifs à la taille du problème traité,
à des propriétés sur les valeurs d'entrée,
à la configuration du matériel, etc. Ce contexte peut être
déterminé avant l'exécution du programme ou peut varier
à différents stades de son exécution. En conséquence,
le processus d'adaptation doit pouvoir être effectué à
la fois statiquement, à la compilation, et dynamiquement, lors de
l'exécution.
-
Critères d'évaluation
du résultat et de décision de poursuite du sous-projet
Le déroulement de ce sous projet (sp 1) se
fera de la manière suivante :
-
sp 1.1 : état de l'art sur l'adaptabilité
-
sp 1.2 : étude de l'environnement d'intégration
-
sp 1.3 : spécification et évaluation
d'une infrastructure flexible basée sur la réflexion
-
sp 1.4 : coût et optimisation
| |
T0 |
T0+3 |
T0+6 |
T0+9 |
T0+12 |
T0+15 |
T0+18 |
T0+21 |
T0+24 |
T0+27 |
T0+30 |
T0+33 |
| sp 1.1 |
|
|
|
|
|
|
|
|
|
|
|
|
| sp 1.2 |
|
|
|
|
|
|
|
|
|
|
|
|
| sp 1.3 |
|
|
|
|
|
|
|
|
retour
sur
expéri-
mentation |
|
|
|
| sp 1.4 |
|
|
|
|
|
|
|
|
|
|
|
|
Les fournitures de ce sous-projet seront :
-
D1.1 : document d'état de l'art sur l'adaptabilité
(T0+6 : document interne - T0+12 : document à soumettre pour publication)
-
D1.2 : document sur l'étude de l'environnement
d'intégration (T0+6 : interne - T0+12 : document public)
-
D1.3 : document d'architecture (T0+12 : interne -
T0+36 : public), ce document évoluera en fonction des expérimentations
menées dans les sous-projets 2, 3 et 4.
-
D1.4 : document "Coût et optimisation" (T0+33)
Les critères d'évaluation seront essentiellement
ceux employés par les sous projets sp 2, 3 et 4 à savoir
: adéquation de l'infrastructure à être extensible
et à supporter de manière efficace l'exécution de
composants adaptables. L'application de démonstration choisie sera
le support d'administration de l'application elle-même. Celle-ci devra
mettre en évidence la capacité d'extension permettant de
déployer des composants non initialement prévue, d'ajouter
dynamiquement de nouvelles fonctionnalités à la plate-forme
et d'adapter le comportement des composants.
Sous-projet
2 : Ajout dynamique de propriétés non-fonctionnelles aux
composants (Responsable INRIA/Oasis - Partenaires : ESLO, Rainbow, Sirac)
-
Description du sous-projet, du responsable
et des partenaires
1) Description
Ce sous-projet aborde la définition de
propriétés non-fonctionnelles des composants. Plus spécifiquement,
les propriétés visées sont directement liées
à la nature de plus en plus distribuée et mobile des
composants logiciels (migration, communication asynchrone, mode déconnecté,
etc.).
Par rapport à l'ensemble du projet, les
résultats du sous-projet 1 (Architecture d'une infrastructure réflexive
à composants répartis) serviront de base à l'expression
et à l'implémentation des propriétés non-fonctionnelles
de ce sous-projet. Celles-ci devraient à leur tour être utilisées
pour l'expression de propriétés non-fonctionnelles de plus
haut niveau d'abstraction : celles liées aux objets de liaison (sous-projet
3).
2) Motivation
La motivation principale découle de la
nature de plus en plus répartie des applications, et de l'utilisation
de plus en plus fréquente de composants mobiles.
Une application est dite mobile lorsque l'un de
ses constituant (matériels, logiciels, utilisateurs) change de localisation
physique en cours d'exécution. Ces applications se développent
très rapidement en raison des nouveaux modes de travail et des possibilités
techniques : communication sans fil, appareils portables (ordinateurs et
téléphones mobiles, PDA). Même lorsque la mobilité
ne concerne que les utilisateurs, il se pose le problème de fournir
un environnement uniforme à un utilisateur qui change de point d'accès.
Dans l'architecture extensible qui doit supporter
l'exécution des différents composants, objectif de cette
proposition RNTL, la partie déploiement et assemblage de composants
est primordiale. Les propriétés non-fonctionnelles
que nous allons aborder dans ce sous-projet devront pouvoir être
configurées lors du déploiement (Sous-projet 4, Supervision
et configuration dynamique).
3) Responsable et partenaires
Le responsable technique du sous-projet
2 sera Denis Caromel - Professeur à l'Université de Nice-Sophia
Antipolis.
Ce sous projet sera conduit par l'équipe
OASIS (INRIA Sophia Antipolis, projet commun I3S CNRS), constituée
de 6 chercheurs ou enseignants-chercheurs et d'environ 7 Doctorants. Dans
le cadre des applications réparties (réseaux Internet et
intranets, cartes à puce et terminaux), l'objectif d'OASIS est de
proposer des principes fondamentaux, des techniques et des outils pour
la construction, l'analyse, la validation, la vérification et la
maintenance de systèmes fiables. Un des objectifs scientifiques
est en particulier la construction de bibliothèques facilitant
la programmation et la maintenance d'applications multi-threadées,
distribuées, sécurisées, en particulier pour les applications
collaboratives et le commerce électronique.
Les autres partenaires seront l'équipe
ESLO (Équipe Systèmes et Langages à Objets) du département
informatique de l'École des Mines de Nantes, le projet Rainbaow
(laboratoirre I3S/Université de Nice) et le projet Sirac (Univ Grenoble/INRIA).
Globalement, l'objectif consiste donc à
:
-
définir un ensemble de propriétés
non-fonctionnelles
-
fournir des primitives d'accès (API) qui
permettent leur utilisation, par exemple au niveau de containers, ou encore
dans la partie générique de configuration des applications
-
à implémenter ces primitives en particulier
en utilisant l'architecture réflexive définie dans le sous-projet
1 .
Pour chaque propriété, il faudra définir
les contraintes (s'il en existe) à imposer à un composant
afin qu'il puisse bénéficier de la configuration dynamique
de cette propriété. D'autre part, il faudra fixer l'interface
permettant de manipuler ces propriétés dans l'architecture
répartie. Par exemple, comment un composant donné devient
sensible à une propriété donnée.
Enfin, dans une troisième étape,
chacune de ces propriétés non-fonctionnelles et leur
interface d'utilisation devra être implémenté dans
l'architecture globale.
Nous envisageons les propriétés
non-fonctionnelles suivantes :
-
Communication asynchrone, synchronisation par
futurs
Les infrastructures habituelles offrent pour
la plupart une communication synchrone. Une communication asynchrone permet
bien souvent une plus grande indépendance entre les composants,
avec en particulier une meilleure résistance aux inter-blocages.
Nous souhaitons donner la possibilité de désynchroniser facilement
les communications entre deux composants, et donc il nous semble nécessaire
d'avoir une telle propriété.
Par contre, les communications asynchrones souffrent
d'une manière évidente d'un manque de synchronisation, en
particulier en cas de dépendances fonctionnelles entre composants.
Pour cette raison, la propriété de communication asynchrone
pourra être couplée avec la possibilité d'avoir une
synchronisation par futurs entre composants.
-
Communication en mode déconnecté
Cette propriété prolonge d'une
certaine manière la précédente. Dans le cas d'une
communication asynchrone, on peut demander aux deux composants d'être
tous deux activés et connectés au moment de la communication;
cela permet entre autre de garantir certaines propriétés.
Mais on peut, et dans certains cas c'est une contrainte forte de l'application,
vouloir permettre une communication dite en ``Mode déconnecté''.
Il n'est plus alors nécessaire que les deux composants soient connectés
au même instant.
Notons que dans ce cas, les synchronisations
par futurs sont également un aspect pertinent et fort utile.
-
Communication de groupe
La capacité à participer à
une communication de groupe est une propriété importante
dans le cadre de composants devant servir à la construction d'applications
collaboratives, de commerce électronique, ou encore de services
télécoms.
Il est donc important de définir les modalités
d'une telle communication comme un aspect non-fonctionnel configurable,
et d'en implémenter les primitives nécessaires.
Par rapport aux autres sous-projets, cette propriété
servira de support pour la gestion de données dupliquées
(réplication), et pour la communication de groupe de plus haut niveau
d'abstraction nécessaire aux aspects interactions (Sous-projet 3).
-
Migration
Les techniques de migration et de mobilité
sont une des bases permettant aux applications de s'adapter aux changements
de localisation de ses différents composants et de se reconfigurer.
La migration peut se faire au moyen de la mobilité de code, de calcul,
ou de donnée. La mobilité des données, associée
à des techniques de gestion de caches répartis, permet à
la fois de diminuer la latence d'accès aux informations et de modifier
dynamiquement l'environnement d'exécution d'une application pour
répondre à des besoins changeants. La mobilité
du code et de calculs permet par exemple de déplacer dynamiquement
l'exécution d'un processus client vers un serveur de données
pour remédier à la variabilité des performances d'un
réseau, ou à une déconnexion.
L'aspect migration de composants est donc une
propriété non-fonctionnelle fondamentale. Il faudra donc
définir les caractéristiques et contraintes nécessaires
pour permettre la migration d'un composant, et définir une ou plusieurs
sémantiques de migration (faible, forte, etc.).
-
Création, placement dynamique, et accès
à distance
Un composant est habituellement créé
et placé de façon statique dans un container. Avec les nouvelles
techniques de programmation d'architecture répartie mises en oeuvre
dans ce projet, et en particulier les aspects réflexifs, il devrait
être possible de créer dynamiquement des composants à
partir d'objets Java standard, de les rendre ainsi accessible à
distance par d'autres composants pré-existants, voir même
de les placer dynamiquement dans d'autres containers.
-
Sécurité
Les techniques utilisant la mobilité du
code et des calculs impliquent l'exécution sur un serveur de programmes
provenant d'une autre machine. En l'absence de mesures de protection appropriées,
une telle exécution présente un danger potentiel. Des aspects
sécurités doivent donc être pris en compte.
Définir la sécurité comme
une propriété non-fonctionnelle devrait permettre une configuration
dynamique de cet aspect qui est absolument nécessaire en présence
de migration. En effet, lorsque des composants se déplacent d'un
domaine administratif à un autre, les securités à
utiliser lors des communications changent. Il est donc impératif
d'adapter dynamiquement les caractéristiques de la communication
point à point entre chaque paire de composants (authentification,
cryptage, etc.).
-
Détail des réalisations
et échéances
1) Définir un ensemble de propriétés
non-fonctionnelles
Dans un premier temps, il s'agit donc de définir
clairement les propriétés non-fonctionnelles qui sont les
plus importantes pour une architecture répartie adaptable, puis
pour chaque propriété, de définir quels sont les attributs
et les valeurs que cette propriété peut prendre.
Notons enfin que toutes ces propriétés
devront être définies d'une façon aussi orthogonale
que possible, mais dans les cas d'inter-dépendances inévitables,
des régles de cohérences devront être définies.
2) Fournir des primitives d'accès (API)
aux propriétés non-fonctionnelles
Une fois que les propriétés non-fonctionnelles
listées ci-dessus seront clairement définies, cette seconde
phase s'attaquera à la définition de primitives d'accès
(API) aux propriétés non-fonctionnelles.
Ces primitives permettront leur utilisation,
par exemple au niveau de containers, ou encore dans la partie générique
de la configuration des applications.
3) Implémenter les primitives non-fonctionnelles
Enfin, dans le cadre de ce projet exploratoire,
nous réaliserons une maquette d'implémentation de ces primitives
non-fonctionnelles en utilisant l'architecture réflexive définie
dans le sous-projet 1.
-
Critères d'évaluation
du résultat et de décision de poursuite du sous-projet
Le déroulement de ce sous-projet (sp 2) se
fera de la manière suivante :
-
sp 2.1 : définition d'un ensemble de propriétés
non-fonctionnelles
-
sp 2.2 : primitives d'accès aux propriétés
non-fonctionnelles
-
sp 2.3 : mise en oeuvre
| |
T0 |
T0+3 |
T0+6 |
T0+9 |
T0+12 |
T0+15 |
T0+18 |
T0+21 |
T0+24 |
T0+27 |
T0+30 |
T0+33 |
| sp 2.1 |
|
|
|
|
|
|
|
|
|
|
|
|
| sp 2.2 |
|
|
|
|
|
|
|
|
|
|
|
|
| sp 2.3 |
|
|
|
|
|
|
|
|
|
|
|
|
Les fournitures de ce sous-projet seront :
-
D2.1 : définition de l'ensemble des propriétés
non-fonctionnelles à appliquer aux composants et rentrant dans le
domaine de l'étude (T0+15 : document interne)
-
D1.2 : validation du mécanisme d'extention
de la plate-forme choisi dans le sous-projet 1 (cf document D1.3) en fonction
des propriétés non-fonctionnelles choisies (T0+24 : document
d'architecture - document interne)
-
D2.3 : document de mise en oeuvre (T0+30 : interne
- T0+36 : public)
Il existe différents critères d'évaluation
de ce sous-projet.
Le premier est sans-doute l'aspect flexible et
dynamiquement configurable des propriétés définies.
Le sous-projet 4 devrait permettre le teste de la plate-forme réalisée.
D'autres critères ont trait à l'efficacité
obtenue, en lien avec le sous projet 1, nous serons vigilant au fait que
l'extensibilité et l'adaptabilité ne devront pas être
mis en oeuvre au détriment de l'efficacité..En particulier,
on essaiera d'obtenir, pour la communication point à point fréquemment
utilisée, une efficacité comparable à des systèmes
classiques (communication RMI, CORBA ou EJB par exemple). L'équipe
DTL/ASR de France Telecom Recherche et Développement ayant déjà
mené différentes campagnes d'évaluatio de middleware.
Dans certain cas particulier, on pourra même
espérer un gain d'efficacité. Par exemple, dans le domaine
de la mobilité, peu de travaux ont été réalisés
pour évaluer les gains de performances apportés par la migration
par rapport à des approches plus traditionnelles.
Enfin, le dernier aspect à évaluer
est la présence ou non de contraintes statiques rédhibitoires,
c'est à dire l'aspect vraiment dynamique ou non de la configuration
obtenue.
Sous-projet 3 : Ajout dynamique
de propriétés non-fonctionnelles aux objets de liaison (Responsable
: Rainbow - Partenaires : Oasis, Sirac, ESLO)
Ce sous projet doit permettre de valider
l'architecture réflexive pour mettre en oeuvre des propriétés
liées à la communication (communication de groupe, coordination,
interaction)
-
Description du sous-projet et des
partenaires
Le développement d’applications distribuées
met en jeu des communications entre objets ou composants distants. Des
outils tels que CORBA, EJB, COM+ masquent les aspects réseaux et
fournissent des langages d’interfaces pour spécifier les méthodes
distantes accessibles sur ces objets. Cependant au delà de l'aspect
uniquement réseaux, toute une sémantique est associée
de par l'application visée à une communication : les interactions
et la coordination entre composants sont souvent clairement exprimables
au moment de la conception soit par le biais de diagrammes de séquences
ou d'états UML, soit via l'utilisation de certains Design Patterns.
Par contre cette information est perdue lors de l'implémentation
et difficilement réutilisable et exploitable par la suite.
Avec l'évolution des applications distribuées,
expliciter la sémantique des communications, coordinations ou interactions
entre les composants devient indispensable. En effet, l'assemblage ou le
desassemblage de composants (par l'ajout ou le retrait d'un composant)
implique indubitablement d'expliciter comment le composant va collaborer
avec les composants en présence ou comment les composants restant
vont poursuivre leur communication et donc de mettre en oeuvre ou de retirer
différents schémas de communication. De même, en explicitant
les coordinations entre composants, l'adaptation de l'application
au cours de son exécution (changement de comportements dynamiquement)
est grandement facilitée. Les outils actuels ne permettent pas
d'extérioriser la sémantique de la communication et contraignent
la modification du code existant pour lier des composants qui n’étaient
pas destinés à l’être. Or, l'évolutivité
et l'adaptabilité d'un système réparti passe
en grande partie par sa capacité à interagir avec les autres
composants de son environnement et ce de façon dynamique. Les approches
classiques par envoi de message répondent mal à ce besoin.
Ce sous-projet vise donc à adjoindre aux
modèles de composants, un modèle d'interaction/coordination
afin de permettre la définition dynamique d'interactions entre des
composants sans aucune modification de ces derniers et ceci bien sûr
de façon réversible. Pour ajouter à la plate-forme
visée toute la puissance souhaitée d'extensibilité
et d'adaptabilité, il est important de pouvoir dynamiquement modifier
le type de communication initialement prévu entre des composants
et de réutiliser le même type de communication pour des composants
différents. Nos objectifs sont de donner une sémantique claire
à la communication entre composants et à sa gestion
et d'offrir un formalisme directement exécutable. Les interactions
sont définies dans les termes des interfaces des objets liés,
c'est à dire des messages qui peuvent leur être adressés.
Ce travail qui présente dans les termes des objectifs similaires
à ceux développés par l’OMG avec CORBA les complète
en distinguant très nettement une expression de la communication
entre les objets à l’extérieur de ceux-ci et par le souci
de pouvoir dynamiquement adapter les caractéristiques de celle-ci.
Cela pourrait entrainer la soumision d'un service d'interactions à
l'OMG.
La définition d'un modèle de communication
a été abordé dans les travaux du projet Sirac
sur les ADL et du projet Rainbow sur ISL (Interaction Specification Language).
La synergie attendue d'un rapprochement autour de ce projet devra permettre
la mise en oeuvre des propriétés liées à la
communication (communication de groupe, coordination, interaction)
indépendamment des composants concernés en décrivant
la sémantique de la communication en terme de réactions comportementales.
L' objectif visé est de faciliter l'implémentation
d'applications de type travail coopératif (collecticiel) en gardant
les avantages de la méthodologie objet (conception, encapsulation,
réutilisation, évolutivité). Pour cela, l'expérience
de l'équipe ESLO et du projet RAINBOW sur la réflexivité
des langages vont être exploitées pour intégrer les
interactions au langage Java et donc à la plate forme visée.
Ceci permettra de pallier la rupture technologique entre trois domaines
très porteurs de l'informatique à savoir la technologie des
réseaux, la méthodologie objet et la concurrence. Le modèle
proposé doit s'intégrer aux concepts objets tout en permettant
une gestion des principales propriétés des environnements
concurrents et distribués. D'autre part, les travaux du projet OASIS
sur les preuves et la vérification de programmes doivent être
exploités afin de valider et de vérifier statiquement les
graphes d'interactions potentiels à une application.
Responsable et partenaires
La responsable technique du sous-projet
3 sera Anne-Marie Pinna - Maître de Conférences à l'Université
de Nice-Sophia Antipolis
Le projet Rainbow s'intéresse principalement
à l'expression d' objets de liaisons et aux nouveaux moyens de communication
fournis par les plates-formes distribuées. Ce travail s'appuie à
la fois sur des techniques de méta-programmation par objets et
sur les nouvelles approches de la programmation telles les aspects ou sujets.
Dans ce contexte, des travaux sont menés sur la mise en oeuvre des
interactions entre des composants issus de langages différents (interprétes
et compilés tels Smalltalk, Java et C++) et implantés sur
des plate-formes hétérogènes (Corba, COM+, RMI).
Les autres partenaires seront l'équipe
ESLO (Équipe Systèmes et Langages à Objets) du département
informatique de l'École des Mines de Nantes, le projet Oasis (Univ
Nice/INRIA) et le projet Sirac (Univ Grenoble/INRIA).
Ce sous projet a deux objectifs bien précis
:
-
Définition et mise en oeuvre du modèle
de communication dans Java (fournir le langage de description des interactions
entre composants et mettre en place les mécanismes de base
de la gestion automatique de ces communications)
-
Intégration dans la plate-forme de développement
avec des tests à la fois sur l'apport en extensibilité, adaptabilité
à la plate-forme, et sur l'efficacité de la mise en oeuvre.
Un aspect à prendre en compte à ce niveau est la fiabilité
des communications définies et dans ce contexte l'intégration
d'un outil de preuve.
-
Détail des réalisations
et échéances
Pour atteindre les 2 objectifs pré-cités
nous avons déterminé les grandes étapes suivantes
:
-
Définition du modèle d'interaction.
-
Mise en oeuvre du modèle dans le langage Java
et sur la plate-forme Jonathan.
-
Vérification et validation des interactions.
-
Expérimentation.
1. La définition du modèle se situe
dans la lignée des travaux des projet Rainbow et Sirac. Il
devra entre autres respecter le contrat suivant :
- faciliter l’expression et la gestion des interactions
entre composants distribués.
- autoriser dynamiquement la définition,
l'ajout et la suppression d'interactions
- favoriser la réutilisation des définitions
d'interactions.
- être indépendant des langages
objets et des plates-formes visées.
Le modèle doit permettre d'exprimer les communications
en terme de spécifications du même niveau d'abstraction que
les IDL Corba afin de pouvoir être à terme facilement réutilisées
et plongées dans des environnements de programmation autres que
Java. Cet aspect devrait pouvoir nous amener à proposer un service
d'interaction à l'OMG.
Cette partie sera élaborée en étroite
collaboration entre les équipes Rainbow et Sirac.
2. La mise en oeuvre du modèle impose de
prendre en compte des techniques de programmation distribuée et
de méta-programmation .
Dans un premier temps, cette mise en oeuvre sera
basée sur la plate-forme ObjectWeb et visera à intégrer
des composants Java. Ce travail sera mené à la fois dans
un souci d'adaptabilité dynamique des objets de liaison, de consistance
des interactions (des transactions devraient être prises en compte
lors des propagations) et d'efficacité dans les communications.
Néanmoins de par à la fois, les
expérimentations antérieures, les volontés et les
capacités des différentes technologies à supporter
l'hétérogénéité, la mise en oeuvre du
modèle intégrera dans un deuxième temps d'autres plates-formes
telles Corba et COM+ ainsi que d'autres langages (C++, Smalltalk) . Ce
travail devrait pouvoir bénéficier conjointement de l'expérience
en méta programmation des équipes ESLO et Rainbow.
3. De par la définition claire des
objets de liaisons, il devient possible d'envisager de valider la cohérence
d'un graphe d'objets interagissants. Détecter des éventuels
deadlocks, les cycles, les incohérences de façon statique
sera pris en charge par le projet OASIS.
4. La mise en oeuvre du modèle pour l'application
visée doit offrir aux utilisateurs de la plate-forme une bibliothèque
d'objets de liaison adaptée à leur problème.
Ils pourront dynamiquement associer ou non à un groupe de composants
de leur choix des schémas de communication et ainsi la communication
entre ses composants sera automatiquement prise en charge par la plate
forme sous jacente.
Cette bibliothèque sera bien entendu extensible
afin de permettre aux utilisateurs de définir si besoin de nouvelles
formes de communication.
Les étapes 1 et 2 se dérouleront
dans un premier temps de façon correlée sur des prototypes
incrémentaux du modèle proposé dans le sous-projet
1.
L'étape 3 pourra intervenir en terme de
réflexion de concert avec les étapes 1 et 2 mais sera validée
seulement en synchronisation avec le 4.
L'étape 4 sera la validation expérimentale
du modèle de communication fourni . Ceci permettra de reboucler
sur les premières étapes afin en cas de nécessité
d'affiner le modèle.
Suite à ces différentes étapes,
un service d'interaction devrait pouvoir être proposé à
l'OMG.
-
Critères d'évaluation
du résultat et de décision de poursuite du sous-projet
De par l'imbrication des différentes étapes
et les acteurs en présence, la solution choisie est d'avoir des
prototypes incrémentaux qui suivent l'évolution du modèle
des objets de liaison. Chaque prototype sera évalué en mettant
incrémentalement en place la bibliothèque d'objets de liaison
adéquate à l'application visée. Cette validation par
l'expérimentation nous parait essentielle pour que l'intégration
des résultats de ce sous projet à la plate-forme se fasse
naturellement et que le modèle choisi pour exprimer la communication
entre composants réponde bien aux exigences des applications.
Le prototypage incrémental est également
une garantie de l'extensibilité et de l'adaptabilité qu'apporteront
l'expression des objets de liaison (interaction, coordination,...) à
la plate-forme.
Le déroulement de ce sous-projet (sp 3)
se fera de la manière suivante :
-
sp 3.1 : définition du modèle d'interaction
-
sp 3.2 : mise en oeuvre dans le langage Java et sur
la plate-forme ObjectWeb
-
sp 3.3 : vérification et valisation des interactions
-
sp 3.4 : expérimentation
| |
T0 |
T0+3 |
T0+6 |
T0+9 |
T0+12 |
T0+15 |
T0+18 |
T0+21 |
T0+24 |
T0+27 |
T0+30 |
T0+33 |
| sp 3.1 |
|
|
|
|
|
|
|
|
|
|
|
|
| sp 3.2 |
|
|
|
|
|
|
|
|
|
|
|
|
| sp 3.3 |
|
|
|
|
|
|
|
|
|
|
|
|
| sp 3.4 |
|
|
|
|
|
|
|
|
|
|
|
|
Les fournitures de ce sous-projet seront :
-
D3.1 : document "spécification d'un modèle
d'interaction" (T0+18 - document interne - T0+24 - document à soumettre
pour publication, si possible auprès d'un organisme de normalisation)
; retour sur le document d'infrastructure D1.3
-
D3.2 : spécification de mise en oeuvre (T0+21
: interne - T0+24 : document public)
-
D3.3 : démonstration de test mettant en évidence
différents protocoles d'interaction (T0+21)
-
D3.4 : démonstration complète qui sera
intégrée à la démonstration du sp 4 qui porte
sur l'administration d'applications (T0+20)
Les critère d'évaluation seront essentiellement
ceux employés par les sous-projets sp 2, 3 et 4 à savoir
: adéquation de l'infrastructure à être extensible
et à supporter de manière efficace l'exécution de
composant adaptable. L'application de démonstration choisie sera
le support d'administation de l'application. Celle-ci devra mettre en évidence
la capacité d'extension permettant de déployer des composants
non prévue initialement, d'ajouter dynamiquement de nouvelles fonctionnalités
à la plate-forme et d'adapter le comportement des composants.
Un effort particulier sera mis en oeuvre pour
mettre en évidence les différents modèles d'intéraction
nécessaire au déploiement d'application.
Sous projet 4 : supervision et
configuration dynamique (Responsable Rainbow - Partenaires : DTL/ASR, INP
Grenoble/Sirac)
Ce sous projet a un double rôle
-
permettre l'administration de la plate-forme extensible
et des applications à base de composants qui l'utilise
-
servir d'application de démonstration pour
valider l'apport de l'ensemble dans le cadre d'application ayant une longue
durée de vie (impossibilité d'arrêt pour une mise à
jour de ses différents composants).
-
Description du sous-projet, du responsable
et des partenaires
Ce sous projet doit proposer pour la plate-forme
spécifiée dans le sous-projet 1 et réalisée
dans les sous-projets 2 et 3, un ensemble d'outils permettant la définition
d'architecture d'applications réparties et d'administration de ces
applications. Ces outils reposent sur la description d'une application
à l'aide d'un langage déclaratif de description d'architecture
(ADL) ou d'un langage de script. Une telle description est exploitée
pour aider à la conception, au déploiement et à l'administration
du cycle de vie d'une application répartie.
Cette ensemble d'outils pourra lui même
être construit sous la forme d'un assemblage de composants devant
être étendu et adapté à la nature changeante
de l'environnement.
Responsable et partenaires
Le responsable technique du sous-projet
4 sera Michel Riveill - Professeur à l'Université de Nice
- Sophia Antipolis, membre du projet Rainbow
L'objectif du projet Sirac est de concevoir et
de réaliser des services et outils pour le développement
et l'exécution d'applications réparties. Son champ d'activité
couvre la construction d'applications réparties adaptables et le
support système pour les serveurs en grappes. L'adaptation peut
prendre différentes formes (changement de structure, de contenu,
de localisation des programmes ou des données, etc.), et peut être
statique ou dynamique. Des exigences de réactivité imposent
souvent une adaptation dynamique. En particulier le projet SIRAC a déjà
développé pour un langage de description d'architecture particulier
(ADL OLAN) un premier prototype permettant le déploiement et l'administration
d'une application répartie écrite sous la forme de composants
assemblés.
Les partenaires de ce sous-projet seront l'équipe
DTL/ASR de France Télécom R&D et les projets Sirac (INRIA/INP
Grenoble/UJF) Rainbow (Univ Nice/I3S).
Le projet Sirac possède déjà
un ensemble d'outils pour la définition de l'architecture d'applications
réparties et d'administration de ces applications. Ces outils reposent
actuellement sur la description d'une application à l'aide du langage
déclaratif de description d'architecture OLAN. Cette approche ne
fait pas l'unanimité et par exemple l'OMG propose un langage de
script pour décrire l'assemblage de l'application. Une telle description
est exploitée pour aider à la conception, le déploiement
et l'administration du cycle de vie d'une application répartie.
L'objectif de ce sous-projet est proposer un
ensemble de service permettant l'administration de la plate-forme extensible
et des composantes configurables qui l'utilisent.
1) description de la configuration logicielle
à déployer
Il sera nécessaire de caractériser
les composants logiciels pour faire émerger une hiérarchie
de typage de ces composants, reflet d'une représentation des connaissances
dans ce domaine. Cette hiérarchie doit ensuite être enrichie
des actions de configuration possibles de ces composants. Par configuration,
on entend ici :
-
les actions de déploiement avec vérification
de la présence des ressources matérielles et systèmes
nécessaires au bon fonctionnement avec une qualité de service
donnée. Ces actions permettent donc l'installation des composants
logiciels lorsque ceux-ci doivent être lancés pour la fourniture
du service.
-
les actions de configuration qui permettent de dialoguer
avec les composants logiciels pour qu'ils s'adaptent à l'application
à laquelle ils participent (établissement de liens entre
composants, choix des protocoles, prise en compte de profils, etc.).
-
les actions de supervision qui permettent de placer
des observateurs sur les composants logiciels. Le rôle de ces observateurs
est de vérifier la correction de contraintes de configuration lors
de l'exécution et d'avertir l'infrastructure globale d'actions de
reconfiguration nécessaires.
-
les actions de reconfiguration permettant d'avertir
les composants logiciels de modification de la configuration et des actions
qu'ils doivent entreprendre en conséquence (préparation en
vue de déplacement, changement de protocoles et/ou de liens, etc.).
Une application de service aux usagers peut être
vue comme un assemblage de composants logiciels qu'il est nécessaire
de décrire. Ce sous-projet doit fournir un modèle de description
d'une application de service en vue de piloter ensuite à l'exécution
les actions de reconfiguration nécessaires pour prendre en compte
l'évolution de l'application et de son environnement d'exécution.
Le résultat de cette première phase est donc une description
de l'architecture générique de l'application, en termes de
composants, de propriétés non-fonctionnelles (mobilité,
placement, sécurité, etc.), et d’interactions (schémas
de communication entre composants).
2) déploiement d'une configuration logicielle
Dans un deuxième temps, cette description
est "compilée" pour produire une représentation interne de
la structure de l'application qui servira de support au pilotage des diverses
opérations de configuration des différents composants logiciels
: déploiement, configuration des composants pris individuellement
(association des propriétés non fonctionnelles choisies),
supervision des composants. Par rapport à des approches existantes
dans lesquelles les actions de configuration ne concernent que des composants
individuels, le fait de disposer d'une représentation globale de
l'application constitue une valeur ajoutée significative car cela
permet d'exécuter globalement un ensemble d'actions portant de façon
cohérente sur les composants d'une même application.
On peut distinguer trois tâches complémentaires
dans la mise en oeuvre de ce sous-projet.
Une première tâche consiste à
définir un formalisme pour la description de l'architecture de l'application.
Le point de départ de ce travail est l'étude des langages
de description d'architecture (ADL), dont les limites actuelles sont bien
connues pour prendre en compte d'une part les aspects dynamiques (création/destruction
de composants, mobilité, etc.), des langages de script et des propriétés
non-fonctionnelles associées aux composants et à leurs liens
de communication. Le résultat de cette tâche est une forme
étendue des formalismes existants qui soit mieux adaptée
à prendre en compte la dynamicité des applications de service.
Ce formalisme, que nous noterons sous le vocable DADL (pour Dynamic Architecture
Description Langage) dans la suite, intègre les notions suivantes
:
-
la description des composants (interfaces et mise
en oeuvre),
-
la description des dépendances fonctionnelles
et des modes de communication entre composants,
-
la description des propriétés non-fonctionnelles
associées aux composants, parmi lesquelles on peut citer :
-
les paramètres de configuration physique :
placement/regroupement de composants,
-
les paramètres de sécurité :
authentification, protection d'accès au composant, communication
chiffrée entre composants, etc.
-
les paramètres de fiabilité : persistance
de l'état du composant en des points de contrôle spécifiés
par l'utilisateur ou décidés par le système ; exécution
transactionnelle de certains composants, réplication d'un composant
et politique de mise en cohérence des copies.
-
les paramètres de performance : cette propriété
fait référence à des aspects quantitatifs de qualité
de service en fonction par exemple des capacités du réseau
et du terminal usager.
-
les paramètres propres au profil de l'usager
: préférences, conditions de facturation, etc.
La deuxième tâche consiste à
définir le format d'une représentation interne (on dit aussi
représentation pivot) de l'application. Cette description est générée
à partir du modèle de l'application, défini à
l'aide du formalisme DADL, en utilisant des outils conçus à
cet effet dans le cadre du sous-projet. Outre les aspects décrits
ci-dessus à propos du modèle d'une application globale, la
représentation interne de l'application inclut également
des informations contextuelles sur l'état courant et possiblement
aussi sur l'historique de l'application. Ces informations sont indispensables
en certains cas pour reconstituer une configuration opérationnelle
de l'application dans les situations de reconnexion d'un usager après
mobilité. Pour différentes raisons (portabilité, réutilisation
d'outils existants) il est envisagé d'utiliser un format de codage
standard pour la mise en oeuvre de la représentation pivot (par
exemple le formalisme XML). Le stockage de la représentation pivot
d'une application de service est un problème ouvert pour lequel
plusieurs approches sont envisageables. Nous étudierons en particulier
les solutions adoptées dans d'autres projets ayant les mêmes
préoccupations (RNRT CESURE).
La troisième tâche du sous-projet
concerne l'utilisation de la représentation pivot de l'application
pour mettre en oeuvre les opérations de déploiement, de supervision
présentées dans le sous-projet 2. De façon plus générale,
les informations nécessaires à la réalisation de ces
opérations se situent pour partie dans la représentation
pivot de l'application, et pour partie dans les composants eux-mêmes
sous forme de fonctions de rétro-action (call-back) à exécuter
par le composant lorsque certaines conditions sont remplies. Il n'est pas
exclus non plus qu'une partie de ces opérations soit prise en charge
de façon implicite par l'infrastructure système. L'accès
aux données de la représentation pivot est donc un premier
élément à fournir. Par ailleurs, le résultat
de ces opérations peut induire dans certains cas des modifications
de propriétés des composants et/ou de la structure globale
de l'application (c'est le cas en particulier des opérations
de reconfiguration). Il est donc nécessaire d'une part de contrôler
la conformité de ces modifications par rapport à l'architecture
de l'application et d'autre part de répercuter ces modifications
dans la représentation pivot..
3) reconfiguration dynamique de la plate-forme
et adaptation des composants
Cette troisième étape, qui constituera
la démonstration elle-même, devra mettre en évidence
les apports de l'approche choisie. Celle-ci devra permettre de modifier
les propriétés de l'infrastructure sans perturber l'exécution
des composants en cours d'exécution. En particulier, nous viserons
les propriétés suivantes : ajout ou remplacement d'un service
de persistance, de sécurité, de mobilité ou de disponibilité
et leur prise en compte par les composants en cours d'exécution.
Dans un premier temps, l'application visée
sera issue des recommandations de l'équipe de France Télécom
R&D. Dans une seconde étape, nous souhaitons associer à
ce travail des partenaires exterieurs, avec lesquels nous avons déjà
des collaborations et qui possèdent des applications démonstratives
: Dassault Systèmes et le Centre Scientifique et Techniques du Bâtiment.
-
Détail des réalisations
et échéances
Le déroulement de ce sous-projet (sp 4) se
fera de la manière suivante :
-
sp 4.1 : description de la configuration logicielle
-
sp 4.2 : déploiement d'une configuration logicielle
-
sp 4.3 : reconfiguration dynamique d'une configuration
logicielle et adaptabilité des composants
|
T0 |
T0+3 |
T0+6 |
T0+9 |
T0+12 |
T0+15 |
T0+18 |
T0+21 |
T0+24 |
T0+27 |
T0+30 |
T0+33 |
| sp 4.1 |
|
|
|
|
|
|
|
|
|
|
|
|
| sp 4.2 |
|
|
|
|
|
|
|
|
|
|
|
|
| sp 4.3 |
|
|
|
|
|
|
|
|
|
|
|
|
Les fournitures de ce sous-projet seront :
-
D4.1 : synthèse des différentes approches
permettant la description d'une configuration logicielle (T0+24 : document
interne - T0+30 : document à soumettre pour publication)
-
D4.2 : spécification des différents
services pour le déploiement d'une configuration logicielle (T0+27 : interne)
-
D4.3 : démonstration mettant en évidence
les capacités de la plate-forme (T0+30 : interne - T0+36 : public)
-
Critères d'évaluation
du résultat et de décision de poursuite du sous-projet
Les critères d'évaluation de ce sous-projet
seront ceux retenus pour les sous-projets 2 et 3, à savoir :
-
adéquation de l'infrastructure de supervision
et de configuration proposé à la nature extensible de la
plate-forme d'exécution
-
flexibilité de l'infrastructure de supervision
et de configuration pour pouvoir être déployée dynamiquement
et permettre ultérieurement l'installation de nouveaux composants
Les résultats de ce sous-projet seront validés
de deux manières :
-
sur le plan fonctionnel par la mise en œuvre de scénarios
d'application dans le cadre de ce sous-projet. La réalisation d'applications
devrait permettre d'évaluer l'intérêt (et les limites)
d'une approche fondée sur un langage de description d'architecture
étendu pour la construction d'applications complexes à base
de composants configurables. Les aspects de réutilisation et de
configuration "à la carte" feront l'objet d'une attention toute
particulière.
un effort particulier pour que l'étude
se fasse en lien avec les travaux de l'OMG (et d'ObjectWeb) afin diffuser
les résultats obtenus dans le cadre des actions de normalisation
proposé dans le cadre de l'OMG qui vient de normaliser un modèle
de composants et un langage de script permettant la description d'une application
à base de composants.
Sous projet 5 : intégration
et évaluation de la plate-forme, diffusion des résultats
(Responsable France Télécom R&D - Partenaires : tous)
-
Description du sous-projet, du responsable
et des partenaires
Le rôle de ce sous-projet est d'assurer la
diffusion de l'ensemble des résultats obtenus auprès des
communautés scientifiques et industrielles. Le canal de communication
choisi est la plate-forme ObjectWeb (http://www.objectweb.org - réalisée
en partie dans le cadre du projet RNRT Parol). Cette plate-forme constitue
aujourd'hui une base pour l'intégration de différentes technologies
de type middleware : plate-forme CORBA, plate-forme EJB, etc.
Les travaux réalisés par les différents
partenaires devront permettre dans un premier temps de compléter
la plate-forme existante pour la rendre extensible et permettre l'adaptabilité
des composants. Dans un second temps, les expérimentations réalisées
et les résultats obtenus devront permettre la définition
de nouveaux services ou de nouvelles API à intégrer dans
les plates-formes CORBA ou EJB.
Responsable et partenaires
Le responsable technique du sous-projet
5 sera Pascal Dechamboux - Ingénieur dans l'équipe DTL/ASR
de France Télécom Recherche & Développement
Les travaux de recherche du département
"Architecture des Systèmes Répartis'' (ASR) de la Direction
des Techniques Logicielles (DTL) de France Télécom Recherche
& Développement, sont directement motivés par les grands
défis techniques posés par l'utilisation des systèmes
répartis ouverts comme fondements d'une architecture de réseaux
d'information : passage à l'échelle, disponibilité,
flexibilité, tolérance aux fautes, sécurité.
En particulier, l'équipe DTL/ASR est à l'origine de la plate-forme
ObjectWeb qui servira de base à la diffusion des résultats
du projet.
Tous les autres partenaires participeront aux
efforts d'intégrations au sein de la plate-forme ObjectWeb et de
diffusion des résultats auprès des organismes de normalisation.
En parallèle aux investigations de nature
conceptuelle, aux expérimentations menées dans les sous-projets
2, 3 et 4, une intégration des différentes technologies réalisées
dans le cadre de ce sous-projet, il est nécessaire d'évaluer
de manière précise les apports et les limites des technologies
proposer et de faire un effort important pour diffuser les résultats
acquis auprès des communautés académiques et industrielles.
Dans ce domaine, où le déploiement de nouvelles plates-formes
va souvent plus vite que le développement des principes sous-jacents,
nous avons choisi d'utiliser de façon prioritaire la plate-forme
ouverte ObjectWeb soutenue par France Télécom Recherche &
Développement, L'AFNOR et l'INRIA. Cette base fédératrice
et ouverte permet une expérimentation sans contrainte (licence de
type ``logiciel libre'', code source disponible), une comparaison entre
les différents prototypes et facilite la diffusion des résultats.
Pour mémoire il faut savoir que tous les
logiciels sont écrits en Java et s'appliquent donc plus particulièrement
(mais pas exclusivement) au développement d'applications réparties
à objets en Java. Un autre signe encourageant de cette plate-forme
est le nombre de contacts spontanés que nous avons eus avec des
PME-PMI effectuant du business autour des logiciels libres (il est intéressant
de constater que c'est un type de business qui se développe très
rapidement aujourd'hui, comme le succès de RedHat peut en témoigner).
Parmi ces contacts, on peut citer ExOffice (PME française) et surtout
Lutris, une société basée en Californie qui anime
une communauté de développement de logiciel libre autour
de XML (Enhydra) et qui fait du business dans le domaine des serveurs d'applications.
Nous pensons qu'une plate-forme extensible pour
composants adaptables, du type de ObjectWeb, a un sens sur le plan industriel
pour plusieurs raisons. D'une part il n'existe pas aujourd'hui d'offre
globale intégrant les différents middleware existants (bus
RMI, bus Corba complet et serveur de composants EJB). Les offres commerciales
sont partielles et très chères dès lors qu'il s'agit
de Corba. Cela s'explique en partie par l'effort de développement
rendu nécessaire pour produire ces logiciels, d'où l'intérêt
de mutualiser les efforts d'une communauté pour atteindre cet objectif.
Ceci rend ces offres plus crédibles aux yeux des utilisateurs.
En particulier, nous souhaiterons qu'au dela des
différents travaux prospectifs menés dans les différents
sous-projets, nous puissions intégrer à la plate-forme ObjectWeb
:
-
Des mécanismes de base pour l'extensibilité
et l'adaptabilité, avec en particulier le support d'un ensemble
d'outils permettant d'administrer dynamiquement les configurations déployées.
-
D'utiliser les mécanismes précédents
pour intégrer différentes extensions utilisables par les
composants. En particulier nous offrirons des extensions pour la mobilité,
la gestion d'objets dupliqués, la sécurité.
-
D'effectuer une études des apports et du coût
de la réflexivité : Les applications de l'Internet et des
télécoms mobiles ont très souvent un aspect ouvert;
cela se traduit par exemple par une variation dynamique, des utilisateurs,
des fonctionnalités, du code, des machines physiques ou virtuelles.
En réponse à ces contraintes, les techniques de réflexivité
et les protocoles à méta-objet (meta-object protocol, MOP)
prennent actuellement une importance de plus en plus évidente dans
ce type de logiciel --- cf. par exemple l'API standard d'introspection
de la plate-forme Java. Les participants ont une expertise reconnue dans
ce domaine. Nous nous proposons d'étudier l'apport de ces techniques
au domaine des télécommunications, mais également
de quantifier le coût de la réflexivité en terme d'efficacité,
tout en prenant en compte les techniques de spécialisation de programmes
qui sont à même de diminuer ces coûts de manière
significative. Mais il est un autre aspect qui semble tout aussi important
: le coût de cette réflexivité en terme d'analyse statique.
En effet, les techniques d'analyse statique supportent en général
relativement mal les aspects dynamiques et la flexibilité apportée
par la réflexivité. Il faudra donc tenter de préciser
quel type de réflexivité tend à rendre inopérante
telle technique d'analyse statique.
Les travaux réalisés dans cette tâche
seront essentiellement des travaux d'intégration à la plate-forme
ObjectWeb, l'essentiel du travail de spécification et d'expérimentation
devant avoir été mené dans les sous-projets 2, 3 et
4.
Un dernier aspect, concernera la diffusion des
résultats. Outre la mise en ligne, sur le site du code en licence
source (selon les termes de la license ObjectWeb), des actions seront menés
dans le cadre de ce consortium auprès des groupes de travail nationaux
(groupe de travail AFNOR) pour participer à la définition
de prochain services normatifs (Corba, EJB, etc.).
-
Détail des réalisations
et échéances
Le déroulement de ce sous-projet (sp 5) se
fera de la manière suivante :
-
sp 5.1 : intégration des mécanismes
de base
-
sp 5.2 : bibliothèque d'extension
-
sp 5.3 : évaluation
-
sp 5.4 : diffusion des résultats
|
T0 |
T0+3 |
T0+6 |
T0+9 |
T0+12 |
T0+15 |
T0+18 |
T0+21 |
T0+24 |
T0+27 |
T0+30 |
T0+33 |
| sp 5.1 |
|
|
|
|
|
|
|
|
|
|
|
|
| sp 5.2 |
|
|
|
|
|
|
|
|
|
|
|
|
| sp 5.3 |
|
|
|
|
|
|
|
|
|
|
|
|
| sp 5.4 |
|
|
|
|
|
|
|
|
|
|
|
|
Les fournitures de ce sous-projet seront :
-
D5.1 : mise en ligne sur le serveur ObjectWeb du
code source liés à la plate-forme extensible (T0+18)
-
D5.2 : mise en ligne sur le serveur ObjectWeb du
code source lié aux extensions choisie (T0+27)
-
D5.3 : rapport final de réalisation mettant
en évidence les apports et les limites de l'approche choisie (T0+30
- interne ; T0+36 - public)
-
D5.4 : activités diverses pour la diffusion
des résultats : participation aux groupes de travail de l'AFNOR,
organisation d'une conférence à T0+18 et T0+36 sur les thèmes
de travail du consortium
-
Critères d'évaluation du résultat
et de décision de poursuite du sous-projet
Ce sous-projet cloture l'ensemble du travail. Le
travail réalisé peut être évalué de différentes
manières :
-
impact académique : publications acceptées,
organisation de workshop et de conférence.
-
impact industriel : utilisation effective des résultats
intégrés au sein de la plate-forme ObjectWeb et apport ultérieur
fait par d'autres contibuteurs.
Les équipes postulantes ont par le passé
fait un effort important pour valoriser leurs travaux : écoles,
conférences, workshop et deux d'entre-elles sont à l'origine
de la communauté ObjectWeb qui ralie peu à peu de nombreuses
équipes universitaires et académiques. Nous souhaitons que
ce projet puisse nous permettre d'être plus efficace dans la diffusion
de nos travaux. |