CONSTRUCTION DES OBJETS, DISTRIBUTION ET GESTION

CONSTRUCTION DES OBJETS, DISTRIBUTION ET GESTION

La structure d’une application NJN n’est pas nécessairement figée. Le modèle de reconfigurabilité permet, partant d’une page blanche, de construire une application, de la modifier, d’en adapter les paramètres, etc., pendant que la plateforme est en fonctionnement, sans qu’il ne soit jamais nécessaire d’en arrêter l’exécution. De même, le modèle de distribution permet d’ajuster dynamiquement, en cours d’exécution, la répartition de charges entre les différentes cibles de l’application.Concernant la reconfigurabilité, deux grandes approches sont proposées par NJN. La première est assez rudimentaire. L’API fournit les fonctions nécessaires pour créer des composants, les détruire, interconnecter des variables entre elles, configurer les paramètres des tâches, etc. La seconde repose sur la notion de vecteur d’objets et permet de décrire des structures répétitives qu’NJN va pouvoir adapter automatiquement aux besoins de l’application. La première partie de ce chapitre explique les mécanismes de création d’objet et la manière dont sont organisés les modèles. La seconde porte sur les mécanismes de reconfigurabilité dynamiques standards. Dans la troisième partie, nous aborderons les structures génériques et les vecteurs. Enfin dans la dernière partie sera traité le modèle de distribution.La nature de l’objet construit est décrit par un modèle. Pour construire l’objet, le constructeur a besoin de connaitre également la portée locale dans laquelle créer l’objet (premier argument), son nom (troisième argument) et une liste de paramètres destinés à le configurer (quatrième argument et suivants). Le modèle renferme toutes les caractéristiques communes aux objets d’une même classe : la classe proprement dite, les paramètres de configuration acceptés, la procédure d’initialisation à appeler, etc.

Le chemin d’accès peut également être relatif. La recherche d’un modèle commence en effet dans les paquetages correspondant à la portée local. Il s’agit du paquetage d’où est issu le modèle de l’objet accueillant la future instance. Par exemple, si le modèle de composant instancié (helloworld) est déclaré dans le même paquetage que le composant conteneur (test_helloworld), le constructeur njn_new() se contentera du nom du modèle à instancier.Le chargement de la bibliothèque est effectué par la commande NJN_LIBRARY. Tous les paquetages qu’elle contient sont alors chargés dans le gestionnaire de modèles d’NJN. On peut de cette façon s’assurer que les bibliothèques dont pourrait avoir besoin un paquetage particulier sont bien chargées.Selon la nature de la tâche observée, la notion du temps peut être extrêmement différente. Le chapitre 2 a éclairci ce point. Pour une tâche temps-réel, le temps est assez semblable au sens commun. Pour une tâche temps-virtuel, la politique d’ordonnancement d’une part, et le protocole de synchronisation d’autre part, font qu’il en va tout autrement. Le temps propre d’une tâche temps-virtuel avance de façon croissante jusqu’à ce qu’elle soit concernée par un retour arrière. Les conséquences sur la gestion structurelle de l’application sont problématiques.

Premier problème, le même objet peut être « vu » par plusieurs tâches au même instant (du point de vue de l’horloge murale) à des dates différentes (du point de vue du temps propre des tâches). NJN doit donc conserver l’état de la structure de l’application correspondant à toutes ses dates possibles d’observation et fournir aux différentes tâches la vision structurelle de l’application qui correspond à son temps propre.Second problème, les modifications structurelles de l’application sont opérées par des tâches temps-virtuel dont l’exécution peut être remise en cause par un retour arrière. Les modifications opérées doivent dans ce cas être effacées de la structure de données de l’application, comme si elles n’avaient jamais été effectuées. Il faut donc conserver la trace des relations causales entre l’exécution des tâches et les opérations structurelles pour pouvoir revenir sur les opérations correspondantes.Ainsi chaque objet de la structure hiérarchique de l’application est associé à un signal particulier, sa ligne de vie, dont le rôle est de dire si l’objet existe ou non à l’instant d’observation. Ce signal est visible à travers la propriété lifeline de chaque objet. Il contrôle le comportement de l’objet tout au long de sa durée de vie. Une variable ne peut être reliée à une autre que si elle existe bel et bien à la date d’observation. La connexion elle-même peut être active ou non en fonction du temps. Lorsque l’objet considéré est une tâche, celle-ci ne peut être exécutée que lorsque sa ligne de vie est valide. Etc.