Réunion de lancement : mercredi 29 novembre 2000 - Sophia Antipolis

Lieu : ESSI - Salle du conseil (4ème étage)
Hébergement : Liste d'hotel
Accès : navettes Aéroport-Sophia Antipolis / horaires partiels

Planning (prévisionnel) :
 

9h00-9h15	Michel		Rappel rapide des différentes éléments du projet	michel.ppt
9h15-9h45	Pascal	ASR	ObjectWeb	pascal.ppt
9h45-10h00	Thierry	ASR	Travaux du département sur les composants	thierry.ppt
pause café
10h15-10h45	Vania	SIRAC	Scénario d'applications ayant besoin d'adaptabilité	vania.ppt
10h45-11h00	Pierre	OCM	MOP Java (objectifs de l'équipe OCM)	pierre.ppt
11h00-11h30	Thomas	OCM	Réflexion et Jonathan	thomas.ppt
pause repas
13h00-13h30	Jean-Marc	OCM	Scénario autour d'une application adaptable	jean-marc.ppt
13h20-14h10	Eric	SIRAC	Mécanisme pour l'adaptabilité, l'expérience de eJava au travers de l'application Baguerra	eric.ppt
14h10-15h00	Mireille	Rainbow	Interaction	mireille.ppt
pause café
15h40-16h20	Denis	Oasis	Proactive PDC - MOP - JOnAs - IC2D	denis.ppt
16h20-16h30	Olivier, Alex	Oasis	IC2D : démonstration
16h30-16h45	Laurent	Oasis	Intégration ProActive - EJB	laurent.ppt
16h45-17h30	Michel		bilan de la journée, agenda futur

 

	Listes des participants à cette réunion :	Autres membres du projets :
ASR	pascal.dechamboux@francetelecom.fr thierry.coupaye@francetelecom.fr jeanbernard.stefani@francetelecom.fr	mikael.beauvois@francetelecom.fr
OCM	Thomas.Ledoux@emn.fr Pierre.Cointe@emn.fr Jean-Marc.Menaud@emn.fr
OASIS	Isabelle.Attali@sophia.inria.fr Denis.Caromel@sophia.inria.fr Bernard.Serpette@sophia.inria.fr Francoise.Baude@sophia.inria.fr Julien.Vayssiere@sophia.inria.fr Ludovic.Henrio@sophia.inria.fr Alexandre.Bergel@sophia.inria.fr Olivier.Nano@sophia.inria.fr Mickael bartorel@essi.fr  Hélène maguin@essi.fr Nicolas guillier@essi.fr  Laurent vaills@essi.fr Alex guyot@essi.fr	Fabrice.Huet@sophia.inria.fr
SIRAC	eric.bruneton@inrialpes.fr vania.marangozova@inrialpes.fr aline.senart@inrialpes.fr olivier.charra@inrialpes.fr	fabienne.boyer@inrialpes.fr daniel.hagimont@inrialpes.fr
RAINBOW	Laurent berger@essi.fr Mireille blay@essi.fr Marcia pasin@essi.fr Anne-Marie pinna@essi.fr Audrey occello@essi.fr Pascal rapicaul@essi.fr Michel riveill@essi.fr	nono@essi.fr

Mailing list : arcad@essi.fr (non encore construite).
Pour s'abonner :

mail majordomo@essi.fr
subscribe arcad <email>

• quelques notes sur les exposés
• quelques documents cités au cours des exposés
• quelques prototypes cités au cours des exposés
• relevé de décisions

Rappel des principaux éléments du projets (Michel)

• Objectif :
• proposer un environnement réparti extensible pour l'exécution de composants logiciels adaptables
• un langage de programmation (Java et sa machine virtuelle)
• un middleware (Jonathan / JOnAs – http://www.objectweb.org)
• Durée : 3 ans, Début : T0 =  1 janvier 2001
• 5 sous-projets
• Sp 1 : Architecture d'une infrastructure réflexive à composants répartis - Thomas Ledoux (OCM)
• Sp 2 : Ajout dynamique de propriétés non-fonctionnelles aux composants - Denis Caromel (OASIS)
• Sp 3 : Ajout dynamique de propriétés non-fonctionnelles aux objets de liaison - Anne-Marie Pinna (RAINBOW)
• Sp 4 : Supervision et configuration dynamique - Michel Riveill (RAINBOW)
• Sp 5 : Intégration, évaluation de la plate-forme et diffusion des résultats - Pascal Dechamboux (DTL/ASR)
• Officiellement 4 partenaires
• Université de Nice (Rainbow)
• France Télécom R&D (DTL/ASR)
• INRIA (OASIS et SIRAC)
• École des Mines des Nantes (OCM)
• Budget : 16 MF de coût consolidé - 3,8 MF de subvention

• ObjectWeb
• Définir clairement les composants ObjectWeb
• Principes : identifier des composants de base et un modèle de composition
• Intérêt d'ObjectWeb dans ARCAD
• Travail sur la notion de conteneur et en particulier définir un environnement pour la construction des conteneurs : technique de compilation et d'assemblage permettant de construire sur demande les conteneurs.

• Construction itérative de systèmes complexes
• réflexions sur le modèle de composants et approche générale (SP 1)
• gestion des aspects techniques des composants (SP 2.1, SP 2.2)
• administration de la plate-forme (SP 4)
• application des principes dans objectweb (SP 5)
• Généralisation des mécanismes d'interception, puis comment composer les composants d'interception
• réflexivité, techniqus de compilation, AOP (avec des services techniques non indépendants)
• Application de cela aux conteneurs : COM, San Francisco, EJB, CCM
• composition de conteneurs, spécialisation de conteneurs, ...

• Présentation de deux scénarios
• gestion d'un agenda, mode déconnecté, protocole de réconciliation, intranet-internet, ...
• session multimédia adaptable : adaption sur le serveur au terminal du client, supporter des pannes, incrustation d'image
• Besoin d'adaptabilité...
• de l'application et du middleware
• comment ? définition d'un modèle de composants adaptables ou ce modèle dépend de la propriété à adapter...

• Intérêt pour ARCAD
• Produire un MOP Java incluant migration / sécurité
• Compilation par assemblage / tissage basé sur AOP + reflexivité + évaluation partielle
• réalisation d'une application adaptable pour PDA
• réutiliser des travaux que nous avons fait dans le cadre du projet EasyComp (plate-forme de composition)

• Evaluation de la plate-forme Jonathan
• difficulté de construire des objets de liaison (utilisation de l'API Jonathan et non pas "classe" objet de liaison
• sortir la "sémantique" invocation d'objets pour pouvoir la manipuler directement
• intercepter les invocations au niveau des stubs, l'invocation elle même est dans un méta-objet, plusieurs méta-objets (un par aspect) / approche symétrique du coté serveur avec le skeleton
• le conteneur permet de regrouper l'ensemble des méta-objets et défini la sémantique de composition (si on veut des sémantiques différentes on construit plusieurs conteneurs)
• proposition de pattern pour la meta-programmation
• Proposition d'une extension de la plate-forme Jonathan
• adaptabilité : l'environnement est à l'origine de l'adaptation du système
• auto-adaptabilité : le système est à l'origine de sa propre adaptation

• flux multimédia pour un utilisateur mobile utilisant un PDA
• besoin d'un environnement réflexif, car il permet une auto-observation et une auto-modification du système
• l'application doit accéder au méta-niveau (ce n'etait pas nécessairement le cas précédent)
• le profil de l'utilisateur est aussi important que la bande passante... notion de contexte d'exécution à prendre en compte.

• association de propriétés non-fonctionnelles
• persistance, protection : pas de problèmes
• mode déconnecté : pbs copie partielle / réconciliation dépend énormément de l'application... difficulté de séparer cela du code fonctionnel, résolution du pb à l'aide de deux upCall.
• pbs sur le tissage des propriétés (ordre d'exécution des extensions)
• regarder les résultats du projet SOR pour un GC en répartie
• pourquoi pas utilisation d'OpenJava (au lieu de Kopi) ?
• rappelle beaucoup le travail fait sur Clos (before, after, ...)

• présentation du service d'interraction
• Service d'interaction : pbs sur l'indépendance des langages (que valent les types déclaré en ISL : est-ce de l'IDL au sens CORBA ?)
• utiliser les interactions pour acceder des services présents (transaction, événements, ...)

• MOP de proactive : un troisième MOP interne à ARCAD... celui de Nantes, celui de Grenoble : travail de convergence à faire
• Utilisation du MOP pour construire des objets actifs (ProActive)
• IC2D : Moniteur de contrôle construit au dessus de ProActive permet de monitorer après coup une application
• EJB et migration (migration du bean sous la forme d'un objet actif, ou migration de la remote interface, ou migration de la home interface)
• quelles sont les motivations : régulation de charge au placement,
• inclure la migration dans le fichier de dépoyement JOnAs
• Besoin d'ouverture des containers

• rapport de DEA Nantes - Francois Sarradin
• rapport de DEA Grenoble - Olivier Charra
• rapport INRIA RR-3850 - JavaPods/eJava - Eric Bruneton

• ObjectWeb
• eJava, JavaPods
• ISL
• ProActive, IC2D

• prise en compte des nouveaux travaux de FT : composition statique vs composition dynamique
• architecture permettant d'avoir un "continuum de solutions" : statique (compilation ouvert), optimisation par évaluation partielle, dynamique
• langage de description de configuration / déployement utilisable avec les différents scénarios
• l'architecture doit être neutre vis à vis de ces choix
• justifier la nécessité de l'approche statique : performance, sécurité, apport de la vérification statique
• chantier object web :
• réingénierie du code JOnAs / JORM / ..., ce serait bien qu'ARCAD puisse participer, contribuer à ce travail
• lien architecture ARCAD et re-architecture JOnAS (ouvrir les containers EJB, gestion de la répartition, ...)
• regrouper SP 2, SP3 dans un premier temps pour avancer de concert
• Prochaine rencontre :
• 1 et 2 février 2001, Nantes : faire le point sur les MOP Java (interne et externe)
• 29 et 30 Mars 2001, Grenoble : contact avec ObjectWeb - OdJ à fixer
• mai, Nice