Int´ egration de Jini dans les solutions actuelles
Sommaire
8.1 Motivation . . . 71
8.2. IMPLANTATION D’UNE INTERFACE DE PROGRAMMATION VISUELLE INT ´EGRANT JINI
Compte tenu de la quasi-universalit´e de cette approche, la r´ealisation d’un syst`eme d’instrumentation distribu´ee au moyen de quelque technique que ce soit, y compris Jini, se doit donc de s’int´egrer tant que possible dans les mod`ele offerts par ces logiciels.
Nous tenterons de prouver dans les sections qui suivent qu’il est possible d’int´egrer totalement Jini dans les solution existantes, tel LabVIEW, sans recourir `a une modification en profondeur du code. Ainsi, il est possible d’exploiter dans un futur proche les appareils utilisant Jini en installant sur le logiciel client une couche de gestion de Jini en relation avec les ´el´ements de programmation visuelle.
8.2 Implantation d’une interface de programmation visuelle int´ egrant Jini
La r´ealisation d’une telle interface, en imposant la contrainte de ne pas avoir `a re-penser le logiciel existant, nous a conduit `a int´egrer la gestion de Jini dans un logiciel annexe, existant en parall`ele du premier, et `a d´efinir un ensemble minimal de messages entre cette couche et le logiciel. Ces messages sont au nombre de deux : ajouter ou sup-primer un p´eriph´erique. Le fait que le nombre de message soit tr`es petit rend plus ais´ee l’implantation de l’adaptateur entre l’application et Jini mais impose donc qu’un traite-ment cons´equent soit effectu´e `a l’interface entre le logiciel local et le r´eseau.
L’adaptateur Jini veillera `a d´ecouvrir les instruments pr´esents sur le bus, g`erera les
´ev`enement ´emis par les services ou le lookup et t´el´echargera tous les proxy des appareils afin de les mettre `a disposition de l’utilisateur. L’introspection dynamique des classes per-met de pr´eparer les icˆones, les habillant, liant chaque connecteur `a une m´ethode particuli`ere de l’objet proxy, avant de les placer dans la boite `a outils.
Afin de prouver la faisabilit´e de ce concept, qui est crucial pour la viabilit´e d’une solution bas´ee sur Jini dans la cadre de l’instrumentation, nous avons r´ealis´e une application l´eg`ere semblable `a LabVIEW. Celle-ci est pr´esent´ee `a la figure 8.1 et est constitu´e de quatre
´el´ements principaux :
– une barre de fonctions, visible sur le dessus, contenant les fonctions mises `a disposition de l’utilisateur. La fonction principale est un ´el´ement graphique indiquant le nombre pr´esent´e `a son entr´ee sur un panneau ayant l’apparence d’un afficheur num´erique `a LEDs.
– une boite `a outils, situ´ee `a gauche, dans laquelle les appareils sont class´es selon trois cat´egories : les interfaces qu’ils r´ealisent, leurs localisations et leurs constructeurs.
Cet ´el´ementest l’adaptateur Jini ; celui-ci communique avec le panneau de program-mation par ajout ou retrait d’appareils `a la demande de l’utilisateur.
– le panneau de programmation, au centre, sur lequel l’utilisateur dispose les icˆones et les connecte afin de sp´ecifier le programme de mani`ere graphique
– le panneau d’affichage, en bas, qui pr´esente les param`etres `a l’utilisateur. Il servira par exemple ici `a afficher la tension mesur´ee.
Fig. 8.1 – L’application JINILab qui pr´esente la mˆeme interface que LabVIEW
Au lancement de l’application, une couche de gestion du bus Jini est instanci´ee en pa-rall`ele. Celle-ci s’int`egre dans le logiciel mettant `a disposion un navigateur d’instruments.
Elle initie son cycle de vie par la recherche du lookup local, au moyen de paquets de pro-pagation envoy´es sur le sous-r´eseau, et collecte les proxy de tous les instruments pr´esents sur le bus `a cet instant. Du point de vue de l’interrogation par le client que nous avons
´evoqu´ee dans le chapitre relatif `a Jini, il s’agit de trouver tous les proxy implantant l’inter-face g´en´eriqueInstrumentationDevice. Comme il s’agit de l’interface dont d´erivent tous les instruments, nous avons l’assurance que le lookup renverra l’ensemble de appareils dont il a connaissance.
8.2. IMPLANTATION D’UNE INTERFACE DE PROGRAMMATION VISUELLE INT ´EGRANT JINI
Commence alors un travail d’introspection syst´ematique du comportement du proxy.
Nous avons choisi d’en isoler les interfaces qu’il implante mais ´egalement deux sous-classes de la classe Entry qu’il contiendra ´eventuellement : les classes Location et Vendor qui per-mettent d’avoir une connaissance de la localisation ainsi que du nom du constructeur. Le proxy est alors ins´er´e dans les trois arbres – comportement, lieu et vendeur – du navigateur.
L’utilisateur peut d´ecider d’utiliser les fonctionalit´es particuli`eres de l’appareil en cli-quant `a droite et en acc´edant ainsi `a un menu construit lors de la phase d’introspection.
Ce menu permettra d’instancier, le cas ´ech´eant, une des interfaces graphiques convoy´ees avec le proxy, mais il permettra ´egalement de placer l’icˆone de l’instrument sur le plan de programmation. La figure 8.3 montre que l’int´egration de l’interface de l’appareil s’int`egre parfaitement avec le logiciel de base.
Une fois l’icˆone plac´ee sur le bureau, il est possible de raccorder un de ses connecteur avec un ´el´ement existant du plan de programmation. Dans la cas pr´esent´e `a la figure 8.4 il s’agit de l’entr´ee d’un afficheur graphique pr´esentant sur le panneau de visualisation la valeur de mise `a ses bornes. Ce composant a ´et´e s´electionn´e dans les outils standards du logiciel pr´esents sur la barre du haut. La valeur `a pr´esenter est obtenue en connectant au moyen d’un fil l’entr´ee de l’afficheur avec la borne de prise de tension de l’icˆone mod´elisant ici un multim`etre Hewlett-Packard HP34401A. Notons ici que les connecteurs pr´esent´es par le composant graphique sont eux aussi cr´e´es par introspection. Il ne faut donc `a aucun moment installer un quelconque gestionnaire ou ensemble d’icˆones particuliers pour acc´eder
`a toutes les fonctionalit´es offertes par l’instrument.
La gestion des erreurs
La gestion des exceptions se fait `a deux niveaux : dans le logiciel, lors de l’appel d’une m´ethode sur l’objet distant et au niveau de la couche de gestion de Jini, lorsqu’un
´ev`enement est propag´e.
les ´ev`enements propag´es par le lookup concernent la modification de la composition du bus ( match to no match, no match to match ) ou le changement de comportement d’un objet d´ej`a connu du client. Le changement d’attribut ou l’apparition d’un p´eriph´erique modifiera l’arbre de pr´esentation dynamique des instruments alors que la disparition d’un
´el´ement du bus entrainera l’envoi d’un message `a destination du logiciel de programma-tion graphique. Il s’agit du message relatif au retrait d’une icˆone de l’ensemble de celles accessibles. Un message d’erreur accompagnera ´eventuellement cette action.
Dans la cas ou l’activation de la m´ethode distante ´echoue, un message est produit afin d’avertir l’utilisateur et l’exp´erimentation est suspendue. Comme il s’agira plus que pro-bablement d’un appareil ayant subit une panne, il y a de fortes chances que cette premi`ere alerte sera suivie d’un retrait de l’icˆone, lorsque le lookup aura confirm´e l’invalidation du bail du proxy. A titre examplatif et pour clore cette description de notre logiciel, la figure 8.5 pr´esente une session typique de pr´esentation d’erreur.