Vendredi 30 mars

Liste des participants 

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

mail majordomo@essi.fr
subscribe arcad <email>

• voir les publications du projet
• RNTL MARVEL : Livrable D2.0 - Modèle de traitement Marvel
• RNTL PHENIX : Livrable D1.1/D2.1 - Analyse de l'état de l'art 

L'essentiel de la réunion a été consacré à :

• une présentation détaillée des différents 'packages' d'ObjectWeb (www.objectweb.org) qui sont la cible potentielle du travail d'ARCAD. Notre contribution à l'ensemble des travaux du consortium est souhaitée et en particulier notre présence au groupe de travail sur l'architecture est attendue. Pour être informé des différentes évolutions, réunions et autres : cf la page d'accueil du site Web.
• travail sur le délivrable D1.1 (Thomas est le coordonateur du document), proposition de plan :

Etat de l’art sur l’adaptabilité

I. Introduction

A. Définition concise de l'adaptabilité

B. Plaidoyer pour l’adaptabilité

1. Pourquoi ? besoins d'adaptabilité

a) Scénario : le nomadisme

2. Comment ? mécanismes de base pour l'adaptabilité

a) Conception modulaire

b) Configuration/reconfiguration

c) Réflexion

3. Quand ? statique vs dynamique

II. Approches hardware et systèmes

A. Approches hardware

FPGA

B. Systèmes d’exploitation modulaires

Modules Linux, DLL Windows

C. Systèmes d’exploitation extensibles

1. Exo-noyaux

Aegis (MIT)

2. Nano-noyaux

µ-Choices (U. Illinois)

3. Autres

Spin (U. Washington)

D. Systèmes d'exploitation spécialisables

Fluke, MVV (SOR)

E. Systèmes d’exploitation réflexifs

Apertos (Sony)

III. Approches Middleware

A. Modèles industriels et de référence

COM+, EJB, ODP, CORBA

B. Middleware réflexifs

OpenORB (U. Lancaster), JavaPod (Sirac), 2K (U. Illinois), FlexiNet (APM), OpenCorba (EMN), DART (Sony)

C. Autres

Jonathan, JonAS (ObjectWeb), Jini (SUN)

IV. Approches langages

A. Approches spécialisables

1. Technologie objet et ses extensions

polymorphisme, late binding, interactions (ESSI)

2. Autres

conditionnelle, DLL

B. Technologies de compilation

Tempo, Harissa, adaptation classes (IRISA), HotSpot (Sun Microsystems),

C. Langages réflexifs

1. Versions réflexives de Java

Javassist, OpenJava (Tokyo Institute of Technology), metaXa, Kava, ProActive (OASIS), Reflex/RAM (EMN), Correlate, JAC (CNAM)

2. Autres

CodA (U. de Tokyo), OpenC++ (Tokyo Institute of Technology), Classtalk (EMN), Iguana (Trinity College)

D. Advanced Separation of Concerns

1. Aspect-oriented programming

AspectJ (Xerox)

2. Autres

adaptive programming (Northeastern), composition filters (U. Twente), hyperspaces, subject-oriented programming (IBM Watson)

V. Approches architectures

A. ADL

1. Langages de description d’architecture

UniCon, Acme

2. Langages de configuration

Darwin, Olan (Sirac)

3. Langages de description dynamique

Rapide, Wright

4. Autres

DEA A. Senart

B. Patterns

1. Design patterns

Strategy, Observer (GoF), Role Object, Dynamic Composite Adapter (Mezini)

2. Patterns d’architecture

MVC

C. Frameworks

concepts de frameworks (hot spots), MolèNE (IRISA), projet 2K (U. Illinois)

VI. Approches modèles

A. Méta-modélisation

MOF (OMG), Adaptive Object-Model (U. Illinois)

VII. Synthèse

A. Vers une classification

1. Différents types d’adaptabilité

Flexibilité (ou adaptabilité) = configuration, adaptation, extensibilité (cf. Boinot, IRISA)

2. Classification des systèmes d’adaptation

cf. thèse M.T. Segarra (IRISA)

B. Conclusion

• travail sur le délivrable D1.2 (Michel est le coordonateur du document). Quelques éléments pour le document qui doit contenir ce que nous souhaitons faire :
  • Ce que l'on veut :
    • construire, déployer et administrer une application à base de composants, être capable de la faire évoluer
    • toute l'architecture y compris les services non-fonctionnels doivent pouvoir s'exprimer sous la forme de composants
  • Composants
    • Objet : interface ODP
    • Réification des liaisons entre objets
    • Partage d'information entre Object Adapteur et Support de la persistance
  • Modèle de programmation commun
    • généralisation du modèle EJB / CCM
    • convenir à la vision du modèle de boîte
    • est-ce que le conteneur doit exister ? 
    • sous quelle forme a-t-on les deux formes : contrôleur / contrôlé
  • Approche de l'adaptation
    • adaptation dynamique et statique sont complémentaires et partage le même modèle de composition
    • il faut être capable de passer d'une vision dynamique à une vision statique, il faudrait être capable de faire l'inverse
  • Approche de la composition / fusion
    • composition des services (des aspects) est le problème essentiel
    • les services sont des composants
    • Que faut-il réifié : le conteneur ou les outils de production du conteneur, un objectif pouvant être d'étendre Jonas plus simplement qu'aujourd'hui
    • travailler sur la composition d'aspects indépendants
    • définir un framework de composition afin que chaque nouveau service soit défini sous la forme d'un composant... qui se compose avec les composants de l'application
    • deux pistes :
      • composition statique (synchrone)
      • composition dynamique (réactive - junior)
  • Limitation / cadre de l'étude
    • on travaille dans le monde Java
    • extension conservatrice des modèles existants (valeur explicative : EJB/CCM/COM et ADL) + des extensions
    • diffusion des résultats via ObjectWeb, il faut insérer les résultats dans l'une des briques technologiques, exemple d'objectif : obtenir un Jonas plus ouvert avec le même niveau de performance
      • Permettre la description des technologies d'object web sous la forme de composants interconnectable, la composition doit être statique ou dynamique, on doit passer de l'un à l'autre
      • fonctions méta : interposition, superposition intrusive
    • Identifier les synergies, travailler autant que possible en synergie (éliminer le plus possible la concurrence)
    • deux lignes de travail
      • approche expérimentale : MOP dans Jonas
      • approche modélisation : remettre à plat le modèle de composant d'ObjectWeb, quelle adaptation, quelle modularité