return NJN_SUCCESS;
}
// Sur LP2 (localhost:2002) NJN_DEF_COMPONENT(C5){
njn_new(self, "var", "receive", NJN_INPUT,
NJN_SOCKET("C5_receive"));
...
return NJN_SUCCESS;
}
Les prises sont déclarées par l'intermédiaire du paramètre de configuration NJN_SOCKET. Elles doivent comporter une étiquette qu'elles sont seules à porter sur le processus logique. Dans notre exemple, la variable receive du composant C5 correspond à la prise C5_receive du processus logique lp2.
Une fiche n'est pas visible sur le réseau. On la déclare par le paramètre de configuration NJN_PLUG. On peut alors la connecter à une prise par la commande njn_plugin. Il faut dans ce cas fournir la référence du processus logique obtenu grâce à la bibliothèque CABLES1 et le nom de la prise sur laquelle elle se connecte. La déconnexion est réalisée par un appel à njn_unplug.
4.2 Distribution – Les composants et leur ombre
La distribution de composants est un peu plus adaptée au travail de répartition de charge. L'opération est un peu plus transparente vis-à-vis de l'application. Elle consiste à héberger un composant entier sur un processus logique distant.
Localement, l'ombre du composant (shadow component) permet de manipuler l'instance distante comme si elle était instanciée localement.
NJN_DEF_COMPONENT(C6){
njn_ref_t a = njn_new(self, "var", "a");
njn_ref_t b = njn_new(self, "var", "b");
njn_ref_t lp3 = cables_get_host(njn_get_cables(self), "localhost:2003");
njn_new(self, "inst3", "C3", 1 Voir page 157.
126 - Chapitre 5
NJN_ASSIGN("in", a), NJN_ASSIGN("out", c), NJN_HOST(lp3));
...
return NJN_SUCCESS;
}
Outre le paramètre de configuration NJN_HOST qui précise le processus hôte du composant instancié, la création du composant est identique à une instanciation classique. Les connexions entre ports et variables sont établies à travers le réseau, en utilisant les primitives d’envoi de messages d'NJN. Le constructeur njn_new crée localement un composant ombre sur lequel on pourra opérer les opérations classiques de manipulation d’objets : connexion ou déconnexion de variables de port, destruction de l'instance, etc. Ces opérations seront répercutées sur le composant réel.
Figure 52. Une application distribuée.
La distribution peut être opérée dynamiquement. Il suffit pour cela de détruire l'instance à déplacer par un appel à njn_delete et de la reconstruire sur un autre processus logique en fournissant au constructeur njn_new le paramètre de configuration NJN_HOST correspondant.
Pour que l'instanciation se déroule correctement, la bibliothèque où est situé le modèle du composant doit être disponible sur la machine hôte car seule la référence du modèle et les informations d'instanciations sont communiquées au processus d'hébergement.
*
* *
Nous venons de passer en revue les différents aspects de la reconfigurabilité dynamique et de la distribution dans NJN.
A partir de modèles de composants compilés dans des bibliothèques et rangés dans des paquetages, une application NJN peut créer dynamiquement des instances de composants. Par défaut, les objets ainsi créés ont la même durée de vie que leur conteneur.
Le modèle de reconfigurabilité et le modèle de distribution - 127 Mais nous avons vu qu'il existait des mécanismes de reconfigurabilité dynamiques qui permettaient d'appliquer d'autres règles. Deux mécanismes complémentaires existent. Le première concerne des manipulations directes de la structure de l’application. Lorsque les objets sont déclarés dynamic, ils peuvent être modifiés ou détruits dynamiquement. On peut connecter des variables entre elles ou les déconnecter, ajuster les paramètres des tâches, etc. Le second mécanisme repose sur la définition de schémas structurels génériques qu'NJN va pouvoir adapter automatiquement aux besoins de l'application.
La distribution d'une application est une chose relativement simple à réaliser. A partir du moment où les différents processus logiques d'hébergement sont connus et référencés, il ne reste plus qu'à préciser où doit être instancié quel composant et quelle variable doit être connectée à quelle autre. La mise en œuvre des communications est faite par le noyau d'NJN qui s'appuie pour cela sur le protocole de synchronisation vu précédemment. En définitive, dès lors qu'on dispose d'un protocole de synchronisation adapté, les concepts exposés ci-dessus sont relativement simples à mettre en œuvre.
La réelle difficulté de la reconfiguration dynamique et de la distribution réside dans l'implémentation du protocole de synchronisation qui permet à toutes ces manipulations d'objets de subir des retours arrière. Cette implémentation sera abordée dans la prochaine partie de ce manuscrit.
Notons d'ores et déjà que l'implémentation actuelle d'NJN ne supporte pas toutes les constructions décrites dans ce chapitre. Tant qu'il ne s'agit pas de vecteurs, la reconfigurabilité est fonctionnelle dans l'implémentation actuelle d'NJN. Les manipulations structurelles par vecteur ont fait l'objet d'un démonstrateur écrit en langage Ruby qui a permis de valider le concept mais elles ne sont pas encore implémentées dans la version actuelle de la plateforme. Concernant la distribution, nous avons préféré mettre l'accent sur ce qu'NJN propose de plus original. Ainsi la distribution de composants est implémentée. En revanche, les connexions point-à-point ne sont pas encore fonctionnelles mais ce concept n'étant pas nouveau, il ne pose aucun problème particulier d'implémentation.
C HAPITRE 6
É TUDE DE CAS : L E PROJET C ORE B OTS
Le projet CoreBots a été développé en parallèle du projet AROS. L'équipe CoreBots participe à un défi de robotique organisé par la DGA et l'ANR. Il s'agit de concevoir un robot d'exploration et de cartographie autonome.
Nous avons choisi d'exploiter les avancés du projet AROS dans la conception du robot CoreBot M qui concourt à ce défi car la conception logicielle du robot sollicite potentiellement presque tous les principes exposés dans les chapitres précédents. Ce choix a été à la fois un fort catalyseur pour le projet AROS et une très forte contrainte en termes de complexité d'application et de respect des délais.
Au-delà de la conception d'un prototype, il s'agissait de gagner une compétition.
Ce chapitre présente la conception de l'architecture logiciel du robot CoreBot M. Il montrera comment NJN facilite la réalisation d'exécutifs temps-réel distribués complexes en prenant en charge les problèmes de synchronisation des données et de distribution des tâches. La première partie présente le défi CAROTTE, l'équipe et l'architecture matérielle du robot CoreBot M. La seconde partie porte sur son architecture logicielle, indépendamment de tout choix d'implémentation. Enfin, la dernière partie propose une solution d'implémentation exploitant le framework NJN.
130 - Chapitre 6