Conception et réalisation d un système d instrumentation distribuée basé sur l architecture Jini

UNIVERSITE LIBRE DE BRUXELLES Faculté des Sciences appliquées Ecole Polytechnique Année académique 2000-2001 Conception et réalisation d un système d instrumentation distribuée basé sur l architecture Jini Promoteurs : Prof. Francis Grenez Prof. Hugues Bersini Philippe De Doncker Travail de fin d études présenté par Jean-Michel Dricot en vue de l obtention du grade d ingénieur civil informaticien

Remerciements Je tiens à remercier ici tout ceux qui de près ou de loin ont contribué à la réalisation de ce mémoire. Même si ce travail est avant tout l oeuvre d une seule personne, je n aurais pu aboutir sans les conseils avisés et les encouragements de mes promoteurs. J aimerais d abord remercier tout particulièrement le Professeur Francis Grenez ainsi que Mr. Philippe De Doncker pour leur aide, leur disponibilité et le soutien dont ils ont fait part tout au long de cette année. J ai été fort touché par leurs initiatives à mon égard et leurs encouragements qui ont permis la publication et la présentation de ce travail, m offrant de par là même un atout considérable au moment d entamer une carrière académique. Je voudrais également remercier le Professeur Hugues Bersini de m avoir offert la possibilité de découvrir la technologie Jini, marriant si subtilement l Informatique à l Electronique. Je tiens à remercier personellement Mr. Esteban Zimányi, à la fois Professeur et ami, qui a su prendre le temps de me conseiller à de nombreuses reprises quant la redaction de cet ouvrage. Il va sans dire que je remercie les membres du Service d Electricité Générale pour leur sympathie et leur acceuil chaleureux, une année durant, dans leurs locaux. J ai une pensée pour tous mes camarades de promotion dont l optimisme, la bonne humeur et la fraternité m ont permis de vivre pendant toutes ces années une amitié extraordinairement épanouissante. Je ne voudrais pas non plus oublier mon Amoureuse qui a toujours trouvé la force et la patience de me soutenir lorsque j en avais besoin. Enfin, j aimerais faire plus que de simples remerciements à mes Parents qui ont traversé avec moi toutes ces années d étude à l Université. Les épreuves que j ai traversées ont été les leurs également, et la moindre des choses que je puisse faire pour leur prouver ma gratitude est de leur dédier ce mémoire. 1

Table des matières I Étude théorique 6 1 Instrumentation Virtuelle 7 1.1 Introduction et Motivation........................... 7 1.2 Le contrôle local des appareils de mesure................... 9 1.2.1 GPIB.................................. 9 1.2.2 La programmation visuelle....................... 12 1.3 Instrumentation distribuée........................... 14 1.3.1 Introduction............................... 14 1.3.2 IEEE 1451................................ 15 1.3.3 GPIB-Enet............................... 16 1.3.4 Limitations............................... 18 2 CORBA 20 2.1 Introduction................................... 20 2.2 Architecture................................... 21 2.2.1 IDL................................... 22 2.2.2 l ORB et l IIOP............................. 23 2.2.3 Le mécanisme de marshallisation................... 25 2.2.4 Les Objets standards.......................... 27 2.3 Conclusion.................................... 28 3 JAVA et RMI 29 3.1 Introduction................................... 29 3.2 La technologie Java............................... 30 3.3 RMI....................................... 32 3.3.1 Le modèle proposé par Java : RMI.................. 33 3.3.2 Le transfert dynamique de code mobile................ 34 3.4 Java hardware : le PicoJAVA......................... 36 4 Architecture Jini 38 4.1 Introduction................................... 38 4.2 Architecture et principe............................ 39 4.3 Le modèle d interaction dynamique...................... 42 2

4.3.1 Interrogation du Lookup par les clients................ 42 4.3.2 Le concept de Leasing......................... 44 II Réalisation d un système d instrumentation distribuée 48 5 Positionnement de JINI par rapport aux solutions actuelles 49 5.1 CORBA..................................... 50 5.1.1 Introduction............................... 50 5.1.2 Aspects communs............................ 50 5.1.3 Éléments de distinction......................... 51 5.1.4 Conclusion................................ 52 5.2 UPNP...................................... 52 5.2.1 Introduction............................... 52 5.2.2 Principes................................ 52 5.2.3 Éléments de distinction......................... 53 5.3 IEEE 1451.................................... 53 5.4 Conclusion.................................... 54 6 Contrôle local des instruments de mesure en Java 55 6.1 Contrôle local des instruments GPIB..................... 55 6.2 l interface standard IEEE 488 pour Java................... 56 7 Utilisation de JINI dans le cadre de l instrumentation virtuelle 61 7.1 Introduction................................... 61 7.2 Interfaçage des instruments de mesure.................... 62 7.2.1 Interfaces standardisées......................... 62 7.2.2 Introspection dynamique des capacités des instruments....... 65 7.3 Exploitation du réseau............................. 67 7.3.1 Les domaines.............................. 67 7.3.2 Instrumentation distante........................ 67 7.4 Les apports propres à Jini........................... 68 7.4.1 Robustesse................................ 68 7.4.2 Interfaces graphiques.......................... 69 8 Intégration de Jini dans les solutions actuelles 71 8.1 Motivation.................................... 71 8.2 Implantation d une interface de programmation visuelle intégrant Jini... 72 8.3 Conclusions................................... 75 9 Conclusion et perspectives 80

Introduction Contexte de travail Le développement et l utilisation des instruments de mesure programmables sont actuellement largement exploités, tant dans le monde académique que dans les industries, menant à des résultats et à des mises en oeuvre prometteuses. Ceci découle principalement de la possibilité d utilisation d architectures programmables présentant actuellement des performances élevées à un coût raisonnable. En particulier, la capacité de modifier le processus de prise de mesure en repensant uniquement l algorithme exécuté par l ordinateur de contrôle et ce, sans remplacer la moindre pièce matérielle, rend l expérimentation plus modulaire, réutilisable et flexible. Le développement de composants d acquisition de mesure génériques et réutilisables, notamment par une approche orientée objet, a permis de réduire drastiquement les coûts de développement et de mise à niveau des laboratoires de mesure. Un certain nombre de standards existent afin de permettre le contrôle de senseurs ou d actuateurs depuis des stations de travail ordinaires. A ces standards éléctriques sont associés des outils logiciels facilitant la mise en oeuvre, souvent fastidieuse, de ces appareils. Problématique L introduction de cette approche et l élaboration des moyens logiciels qui les accompagne remonte à près de vingt ans. L Informatique et l Electronique ont connu, au cours de ces deux dernières décénies, des évolution majeures. Les ordinateurs présentent des puissances de calcul croissantes et sont actuellement presque toujours intégrés dans des réseaux locaux ou globaux, à l instar d Internet. De telles capacités, en terme de traitement des mesures, de stockage de données issues d interaction entre appareils, sont peu ou pas utilisées dans le cadre de l instrumentation. Les modèles mis en oeuvre dans les solutions actuelles ne peuvent tirer un bénéfice de cette explosion de nouvelles technologies, privant ainsi l ingéniérie de la mesure et du signal d outils précieux. 4

Contributions Le présent travail tente d apporter une solution à ce problème sous la forme de l utilisation d un nouvelle technologie connue sous le nom de Jini. Jini propose un modèle d interaction dynamique tirant bénéfice de la plateforme orientée objet Java. Ainsi, nous avons été à même de créer un réseau d instrumentation distribué dans lequel les appareils, actuateurs ou senseurs, sont à même d interragir entre eux et avec des logiciels clients de manière totalement transparente. Les contraintes de robustesse, vis-à-vis des pannes ou de la qualité du réseau, ont pu être intégrées dans cette technologie au moyen d une étude de Jini attachée spécifiquement à répondre aux besoins de l instrumentation. Une intégration de cette solution dans les logiciels existants, tels que LabVIEW, est également possible. Cheminement de l exposé Le présent manuscrit comporte deux parties. Une introduction théorique initie le cheminement. Dans un premier temps nous situerons le contexte de la prise de mesure ainsi que les technologies utilisées jusqu à présent pour réaliser celle-ci. Nous exposerons ensuites certaines techniques d interaction entre objets à travers le réseau qui nous permettrons dans le début de la seconde partie de justifier le choix de Jini comme solution à la problématique spécifique des instruments distribués. Nous poursuivrons en détaillant la réalisation complète d un système d instrumentation distribuée se basant sur la plateforme Java et l architecture Jini. Enfin, il sera montré comment il est possible d intégrer la solution proposée dans les logiciels existants. Un cédérom complète le présent travail. Il contient l ensemble des annexes,le programme de contrôle JiniLab ainsi que le code source des services Jini développés. Ce média a été remis au Professeur Grenez et est conservé dans la bibliothèque du Service d Electricité Générale.

Première partie Étude théorique 6

Chapitre 1 Instrumentation Virtuelle Sommaire 1.1 Introduction et Motivation..................... 7 1.2 Le contrôle local des appareils de mesure............ 9 1.2.1 GPIB................................. 9 1.2.2 La programmation visuelle..................... 12 1.3 Instrumentation distribuée..................... 14 1.3.1 Introduction............................. 14 1.3.2 IEEE 1451.............................. 15 1.3.3 GPIB-Enet.............................. 16 1.3.4 Limitations.............................. 18 1.1 Introduction et Motivation Le concept d instruments virtuels [26] a été introduit à la base pour simplifier la conception, l implantation et l utilisation de systèmes d instrumentation programmables en adoptant une interface visuelle. La programmation visuelle permet une réalisation avant tout conceptuelle du processus de prise de mesure, permettant ainsi aux personnes peu versées dans la programmation de mettre au point rapidement des algorithmes performants. Le programme y est décrit de manière graphique en sélectionnant et en assemblant des blocs fonctionnels présents dans des bibliothèques de développement. Ce type d approche, présentant des interfaces graphiques ressemblant aux instruments réels, rend ainsi l utilisation et la compréhension de l instrumentation virtuelle plus aisée pour les personnes expertes en expérimentation réelle. 7

1.1. INTRODUCTION ET MOTIVATION l utilisation du réseau a depuis peu été incorporée aux processus de prise de mesure avec beaucoup de succès. Cette nouvelle approche fonctionnelle permet en effet non seulement d interconnecter des instruments entre eux, mais également de créer des zones de post-traitement des données, comme des bases de données ou des logiciels de DSP. Cette configuration est particulièrement rentable, tant d un point vue économique que du point de vue de l utilisation efficace des ressources disponibles sur le réseau local du laboratoire, mais peut également se révéler nécessaire lorsque les points de mesure sont fortement disséminés ou distants et qu il deviendrait donc financièrement inabordable d y adjoindre un post-traitement informatique. Fig. 1.1 l utilisation de l instrumentation virtuelle permet l exploitation d une large variété de ressources, notamment celles fournies par les ordinateurs de contrôle et plus récemment, l intégration des réseaux locaux industriels ou de l Internet Enfin, le développement de systèmes embarqués présentant des puissances de calcul pour un coût acceptable et l émergence de technologies d interconnexion permettant de créer spontanément des réseaux nomades offrent des possibilité nouvelles qui permettent l introduction efficace d une composante logicielle à même le système ou situé dans un proche voisinage. 8

1.2. LE CONTRÔLE LOCAL DES APPAREILS DE MESURE 1.2 Le contrôle local des appareils de mesure Les systèmes classiques de contrôle local des appareils par un PC offrent l avantage de pouvoir confiner en un même lieu les composants matériels d expérimentation chargés de l acquisition ainsi que les éléments chargés du contrôle des instruments et de la mise à jour des données. Toutes les opérations relatives à la prise de la mesure sont effectuées par un logiciel spécialisé. Ce schéma de conception et de déploiement a conduit à standardiser les cartes d entrées/sorties dévolues à l acquisition et la mise à jour du signal, tout en diminuant le coût global du processus entier d expérimentation (e.g. l acquisition, la maintenance mais aussi le développement logiciel et la prise en charge de la formation des techniciens). De nombreuses initiative relatives à la standardisation et l interfaçage ont été entreprises depuis longtemps par les industriels. Cependant, l analyse des solutions existantes sur le marché montre qu il n existe pas de standard ouvert universellement adopté mais uniquement deux systèmes propriétaires embrassés par une partie extrêmement importante des utilisateurs. Il s agit d une part de l utilisation du bus GPIB afin de permettre la connexion cohérente d appareils de mesure et d appareils de contrôle, PC par exemple. d autre part, du point de vue de l interfaçage et de la programmation visuelle, LabVIEW de la société National Instruments sera évoqué ici afin de bien montrer comment on peut utiliser les concepts proposés par le modèle de l instrumentation virtuelle. 1.2.1 GPIB Le bus GPIB, standardisé sous les références IEEE 488.1 et IEEE488.2 est un système d interconnexion des instruments imaginé par Hewlett-Packard en 1975. Anciennement connu sous la dénomination HPIB, ce modèle de bus est constitué d un certain nombre d éléments standardisés : 1. une interface électrique permettant l envoi d information et du statut actuel des périphériques de la ligne. 2. la possibilité de connecter des appareils sans les différencier au vu de leur rôle spécifique : envoi ou réception de données. Chaque appareil est vu comme un noeud du système à même d émettre ou de recevoir une information à un moment donné. 3. un modèle de communication basé sur l envoi de messages entre les appareils sous forme de chaînes de caractères. Chaque appareil est capable de répondre aux sollicitations par renvoi d un message et par l ajustement du statut de la ligne afin de refléter l état actuel du bus ou signaler une erreur. Notons enfin que 14 appareils sont ainsi connectables sur un bus GPIB sur une longueur totale ne dépassant pas 20 mètres. Le concept du contrôleur et des périphériques proposé par le IEEE 488.1 est illustré aux figures 1.2 et 1.3. Les contrôleurs ont la capacité d envoyer des commandes, de présenter 9

1.2. LE CONTRÔLE LOCAL DES APPAREILS DE MESURE des données sur le bus et d écouter les messages envoyés par les périphériques. Le contrôle du bus peut passer à tout moment du Contrôleur en Charge (CIC : Controller In Charge) actif à n importe quel autre périphérique ayant la capacité d être un contrôleur. Un et un seul contrôleur du système est défini comme étant le Contrôleur Système global (System Controller) est sera désigné à l instant initial comme Contrôleur en Charge. Controller Device #1 Control, Talk, Listen Talk, Listen Piggyback Cables Device #n Talk, Listen Fig. 1.2 Schématisation du bus IEEE 488.1 Fig. 1.3 Le chaînage des appareils IEEE 488.1 sur le bus s effectue sans disposition particulière. Les périphériques sont identifiés sur la chaîne via un adresse unique qu ils doivent posséder lors de la mise en service de l appareil. Cette adresse est usuellement imposée par l expérimentateur au moyen du panneau frontal de l appareil. Les adresses sont faites de deux parties : un adresse primaire, comprise entre 0 et 31 et une adresse secondaire utilisée pour adresser des éléments particuliers internes à l appareil considéré. Par exemple, un appareil utilisé pour interfacer plusieurs ports série aura une adresse secondaire pour 10

1.2. LE CONTRÔLE LOCAL DES APPAREILS DE MESURE chaque canal de transmission contrôlé. Notons que bien que 31 adresses soient disponibles, GPIB limite à 14 le nombre d appareils adressables sur un même bus à un moment donné. Lors de l utilisation, certains appareils sont dédiés uniquement à écouter et d autre à parler. On parle de modèle talker listener. Ceci permet de réaliser une communication sans nécessiter l existence d un contrôleur global pour tout le système : lorsqu un appareil parle, tous les autres écoutent. Lorsqu un appareil désire parler, il le signale sur le bus et devient l unique Contrôleur en Charge du bus. Lorsqu un instrument émet, les messages peuvent êtres envoyés pour toute la ligne ou adressés à un appareil particulier. IEEE 488.1 : Interface électrique L interface électrique présentée par les appareils compatibles GPIB repose sur un modèle de transmission des informations en parallèle. Les 16 lignes utiles sur le connecteur se divisent comme suit : 8 bits sont alloués à la transmission bidirectionnelle des informations, 3 au handshake et 5 permettent la signalisation de l état du bus et l envoi d évènements. Cette interface est largement décrite dans les documents [6], notons seulement qu il est toujours possible de réinitialiser un périphérique ou le bus entier via une des lignes ainsi que détecter les erreurs éventuelles par le changement d état de la ligne correspondante. IEEE 488.2 : Messages La normalisation IEEE 488.1 décrit un modèle de mise en oeuvre d un bus d interconnexion pour les instruments mais ne fournit aucune information quant à la normalisation des messages entre appareils. Certains détails, tels l utilisation ou non du retour à la ligne comme fin de communication, pouvait mettre à mal l interopérabilité voulue par GPIB. De même, les commandes les plus utiles ou les plus courantes (remise à zéro, extinction, identification,etc. ) ont souvent été implantées par les constructeurs de manière non uniforme, mettant ainsi au point un set de commande propre à chaque compagnie, voire à chaque appareil. Afin de standardiser la mise au point de logiciels de contrôle, Tektronix a proposé en 1985 une formalisation standard qui fût adoptée en 1987 sous la norme IEEE 488.2. Le nouveau standard spécifie un format unique d envoi de messages, un set de commandes de base commun ainsi qu une structure générique permettant d interroger l appareil sur son statut. Par exemple, l envoi de la commande *IDN? indique à l appareil qu il doit renvoyer son identification. Conclusion L utilisation d un standard électrique et la définition d un format commun d envoi de messages ont permis la mise au point de bibliothèques de fonctions accélérant ainsi le développement de logiciels de contrôle. Ces bibliothèques existent en accès libre [2] et ont ainsi pu servir de base au contrôle des instruments utilisés pour la mise en oeuvre et la commande des appareils, selon un schéma décrit dans la seconde partie de l ouvrage. 11

1.2. LE CONTRÔLE LOCAL DES APPAREILS DE MESURE 1.2.2 La programmation visuelle l idée même de développer des outils de programmation visuelle afin d asservir des systèmes de mesure a été introduite en 1985 par la firme National Instruments. Son logiciel LabVIEW est actuellement largement utilisé par nombre de milieux académiques et industriels. Il a pour but de faciliter la mise en oeuvre de l acquisition et du post-traitement des mesures prises en laboratoire. Il utilise à cette fin les capacités graphiques des ordinateurs d entrée de gamme actuels. Les interfaces graphiques qu il met en oeuvre sont basées sur un ensemble organisé de fenêtres et d icônes interagissant entre elles afin de présenter à l utilisateur une schématisation du processus expérimental ainsi qu un certain nombre de grandeur de sortie. Fig. 1.4 Une session LabVIEW standard présentant le résultat d une acquisition sous forme d un graphe 12

1.2. LE CONTRÔLE LOCAL DES APPAREILS DE MESURE Sur la fenêtre de base d une telle application se trouvent des représentations graphiques (icônes) de contrôleurs conventionnels (e.g. boutons, sélecteurs, potentiomètres) et d indicateur de sortie (e.g. oscillogrammes, lumières, valeurs numériques) familiers des expérimentateurs. La présentation sélective et organisée des données et des commandes offre le double avantage de spécifier les interactions avec les appareils et de minimiser les informations présentées à l utilisateur, le laissant ainsi se focaliser pleinement sur les éléments importants de la prise de mesure. l utilisateur agit sur l icône comme il agirait sur l instrument réel, en particulier, l utilisation de la souris permet d agir avec des composants symboliques de la même manière que les doigts de la main agiraient sur des boutons présents sur la face de l appareil. l utilisation d un modèle de programmation graphique, que nous avons déjà évoqué, fut importé de l informatique théorique afin de simplifier la conception des procédures d expérimentation en se basant sur des concepts fortement orientés-objet. Il est ainsi possible de décrire le processus de mesure sans devoir passer par un langage conventionnel de programmation procédurale. Dans un langage classique, les séquences d opération sur les données doivent être spécifiées selon une syntaxe peu accessible et souvent réservée aux seuls informaticiens ou ingénieurs. En programmation visuelle, les données et les opérations sont représentées par des icônes. Le programme lui-même est obtenu en dessinant un diagramme procédural restant à un niveau fort conceptuel. Les noeuds de ce graphe sont des opérations de haut niveau, typiquement du traitement de signal, des opérations arithmétiques, mais ils peuvent également être associées à des opérations de visualisation des données ou à un contrôle des instruments de mesure. Chaque noeud a des connecteurs d entrées et des connecteurs de sortie auxquels il suffit d attacher les bons fils afin de réaliser une opération donnée. Les éléments de base étant trop simples pour la plupart des expérimentations, des diagrammes préétablis peuvent être importés aisément, menant ainsi à une conception modulaire des programmes et à la mise à disposition de larges bibliothèques d instrumentation virtuelle appelées VI (Virtual Instrumentation element). Il existe des VI pour à peu près tous les instruments contrôlables depuis un PC. Ces VI servent donc bien souvent de gestionnaire de périphérique quasi-universels pour autant que l instrument soit connectable au PC de contrôle via un connecteur de type RS-232, parallèle ou GPIB. Notons enfin que l utilisation massive d une telle technique a un impact psychologique important sur la catégorie d utilisateurs amenés à utiliser ce produit : en effet, relier un appareil à un affichage présentant le résultat de la mesure prise par cet appareil revient simplement à tirer un fil de la sortie de l icône de l appareil et à le connecter sur une borne d entrée de l icône représentant l afficheur ; c est pourquoi les systèmes d instrumentation virtuels sont devenus aujourd hui un élément incontournable lorsqu il s agit d intégrer les techniques informatiques à la prise de mesure. 13

1.3. INSTRUMENTATION DISTRIBUÉE 1.3 Instrumentation distribuée 1.3.1 Introduction Tant dans la littérature [21] [7] [15] que dans la pratique, de nombreux exemples montrent l utilisation des réseaux afin d étendre les capacités de mesure et de traitement des systèmes de mesure exploités dans des environnements d instrumentation virtuelle. Ce besoin découle d un certain nombre de limitations inhérentes à l utilisation des architectures mettant en oeuvre des ordinateurs. La première limitation provient souvent du nombre de signaux qu il faut acquérir simultanément. Il arrive souvent en effet que le nombre d entrées des cartes d acquisition sur une même machine ne soit pas suffisant ou que la machine ne puisse fournir à elle seule la puissance nécessaire à la prise de mesure. l utilisation du réseau permet ici le déploiement de sous-systèmes de mesure, étendant ainsi la capacité de traitement de l unité d expérimentation. Des standards tels que Fastbus, GPIB, etc. ont été proposés il y a longtemps et sont maintenant utilisés à grande échelle dans l industrie, tout particulièrement lorsque des systèmes et des processus complexes doivent pouvoir être vérifiés et contrôlés en temps réel. Une seconde restriction découle de l aire d opération accessible par une même unité de traitement. Il suffit de penser par exemple aux fabriques chimiques ou pétrolières dont les différents processus sont disséminés sur une superficie élevée et présentant un besoin de sécurité globale important. Quel que soit l environnement, les senseurs et les cartes d acquisition ne peuvent être situés trop loin d une source, sous peine de voir le signal entaché de fortes perturbations. De même, le contrôle local d appareil impose une distance maximale entre l appareil et l unité en charge du traitement : typiquement 20 mètres pour GPIB. Si le signal doit être acquis sur une source distante, l exploitation d un réseau permet de rapprocher les instruments, les sources et les sous-systèmes d expérimentation, garantissant ainsi une qualité optimale pour le signal acquis de la source. Enfin, une troisième limitation est liée au traitement qui sera effectué sur le signal. Plus la complexité de calcul de l algorithme de post-traitement sera élevée, plus grandes seront les ressources prélevées sur le PC, rendant éventuellement impossible tout contrôle en temps réel. Pour palier à cela, des cartes de traitement de signal (DSP) sont adjointes au processeur de base, augmentant ainsi le coût ou la gamme de processeur requis. Une autre solution consiste à utiliser massivement les machines présentes sur le réseau pour distribuer les besoins de calcul et optimiser l utilisation des possibilité de traitement local. La promiscuité des interconnexions rend les communications entre noeuds de mesure quasi instantanées. Pour un réseau dédié uniquement à l acquisition, le trafic global généré sur un réseau commercial de faible coût (e.g. 10Mbps) est assez peu élevé, et il en résulte que pratiquement aucun retard n est introduit suite à une éventuelle contention. 14

1.3. INSTRUMENTATION DISTRIBUÉE 1.3.2 IEEE 1451 IEEE 1451 [15] est une nouvelle norme dont le but est de fournir un cadre cohérent et ouvert permettant la mise en relation d appareillages de faible capacité mémoire et dont les possibilités se réduisent à opérer des prises de mesure en un point donné. La philosophie générale du développement de ce standard repose sur la création d une volonté d uniformiser les interfaces des appareils et ce en ajoutant, de manière incrémentale, des capacités à celles déjà existantes, tout en conservant le coût de la transition accessible à tous les vendeurs de l industrie. Le standard envisagé propose également l indépendance vis-à-vis de la couche réseau mise en oeuvre ainsi que l indépendance vis-à-vis du type de microprocesseur embarqué sur le système. La famille 1451P consiste en la proposition et le développement de 4 standards : 1. IEEE 1451.1, Network Capable Application Processor (NCAP) 2. IEEE 1451.2, Transducer to Microprocessor and Transducer Electronic Data Sheet (TEDS) Format 3. IEEE 1451.3, Digital Communication and Transducer Electronic Data Sheet (TEDS) Format for Distributed Multidrop Systems 4. IEEE 1451.4, Mixed Mode Communication Protocols and TEDS Formats La figure 1.5 présente les différents composants présents dans un système de transducteurs compatibles avec la spécification que nous venons d évoquer. Fig. 1.5 Architecture d un système de transducteurs IEEE 1451. Le premier groupe de travail (1451.1) a été chargé de définir un modèle d information pour la mise en réseau de transducteurs intelligents. Il définit également les spécifications 15

1.3. INSTRUMENTATION DISTRIBUÉE de l interface logique. Le second groupe a défini le TEDS ainsi que l interface et les protocoles de communication à mettre en oeuvre afin de permettre la communication entre le transducteur et le contrôleur responsable de la prise en charge de la composante réseau. Le TEDS est stocké dans une EEPROM 1 et contient des champs décrivant complètement le type, les opérations accessibles, la calibration et les attributs secondaires du transducteur. La taille typique que peut représenter ces informations en mémoire est de l ordre de 256 octets. LE TEDS doit être physiquement relié au transducteur, réalisant ainsi un ensemble toujours cohérent et rendant donc conceptuellement l auto-identification sur le réseau possible, sans risque d erreur possible ; ce qui aurait été plus caduque si un tiers participant avait à se charger de cette opération ou si un opérateur devait manuellement définir les propriétés de l appareil à chaque mise en service. Le fait également de considérer que ce bloc est séparé de celui en charge de la couche réseau permet le remplacement ou la mise à jour de l instrument par le simple remplacement du transducteur et de son TEDS associé. Cependant, il est parfois peu aisé, voire impossible, de déployer en un même lieu le TEDS et le senseur proprement dit : c est pourquoi le document 1451.3 précise-t-il comment on peut connecter en un même noeud des transducteurs physiques multiples et le TEDS de description associé. Cette configuration permet de réaliser un micro-réseau interne au transducteur, tout en conservant une même interface externe. Enfin, nous avons supposé jusqu à présent que les communications externes tant qu internes se passent sur base d une transmission digitale. Certains groupes d appareils (piézoélectriques, capteurs de contraintes,etc.) tirent un meilleur parti de la transmission interne de l information sous forme de signaux analogiques. Ce besoin a induit la formation d une dernière recommandation, IEEE 1451.4, relative à la standardisation de l envoi, en interne, de signaux analogiques avant conversion en digital pour présentation sur le réseau. La taille fort réduite de l EEPROM contenant la description du TEDS ainsi que l interopérabilité voulues ont poussé le groupe de standardisation à évoquer l utilisation de langages semi-structurés ou peu structurés, comme XML, afin d offrir une flexibilité, une interopérabilité maximales lors de l implantation des descriptions des fonctions standards ou plus spécifiques des capteurs. Notons qu actuellement aucune forme de message standard n a été avancée comme finale, seule l existence de messages sous forme de texte semble avoir la préférence du groupe de travail dévolu à cette tâche. 1.3.3 GPIB-Enet Une solution proposée pour le contrôle réseau des instruments de mesure est l utilisation d une extension de GPIB connue sous le nom de GPIB-Enet. GPIB-Enet est un appareillage électronique portable se connectant sur le réseau et permettant de prendre en charge jusqu à 14 appareils compatibles GPIB. La Figure 1.6 illustre l architecture typique des réseaux hybrides GPIB / Ethernet. 1 Electricly Erasable Read Only Memory 16

1.3. INSTRUMENTATION DISTRIBUÉE Fig. 1.6 Architecture et déploiement typique d une installation utilisant GPIB-Enet. Le réseau se subdivise en 2 composantes principales : le Thin Ethernet global, à large rayon d action, et les bus locaux GPIB qui forment les noeuds du réseau global. GPIB-Enet se déploie typiquement sur des LAN ou des WAN via une interface 10Base- T Thin Ethernet ou 100Base-T. l exploitation du protocole IPX est également possible, bien que dans la pratique, seul le protocole IP soit utilisé. Chaque concentrateur GPIB possède donc une adresse unique qui doit être fixée dès la mise sur réseau. Pour se faire deux scénarios sont possibles. Le premier scénario de configuration consiste en l utilisation d un ordinateur tiers. Celuici adressera l instrument au moyen des adresses MAC qu il sait être présentes à un moment donné sur le réseau. Le PC procède par une approche d essais erreur jusqu à ce qu il trouve un appareil valide. Ayant reconnu les instruments disponibles sur le sous-réseau local, il peut communiquer avec eux au moyen d un protocole de bas niveau et imposer une configuration reflétant la structure du réseau local : adresse IP, passerelle, etc. Une deuxième approche consiste à laisser l appareil interroger un serveur DHCP présent sur le sous-réseau et laisser celui-ci lui fournir des données valides permettant l autoconfiguration. La technique DHCP a été mise au point afin d apporter une solution au problème de la configuration des paramètres réseau d une machine mise soudainement en connexion sur ce dernier. La machine apparaissant émet des paquets de propagation (broadcast packets) signalant sa présence et comportant une information faisant part de 17

1.3. INSTRUMENTATION DISTRIBUÉE son souhait de bénéficier de l aide d un serveur DHCP pour se configurer. Si une telle machine est présente à ce moment, elle établira, en fonction de règles de décision quant à la gestion du lot d adresses disponibles, une liste de paramètres qu elle renverra à la machine demandeuse. Ces informations sont notamment : une adresse IP, celle de la passerelle du réseau, l adresse du serveur de nom utilisable, le masque de sous-réseau, ainsi qu un temps de prêt au bout duquel il faudra recontacter le DHCP afin de renouveler les informations. La combinaison hybride ainsi obtenue en mettant en oeuvre des noeuds GPIB-Enet sur un réseau de type Thin Ethernet permet des débits pratiques d information maximum de l ordre de 800 kb/s depuis un élément de la chaîne GPIB jusqu à un autre noeud réseau. Un tel débit est relativement équivalent à ce que l on peut observer entre un appareil et une carte dédiée d une chaîne GPIB purement locale. Il apparaît donc que l utilisation des concentrateurs GPIB-Enet est totalement transparente pour autant que le réseau soit fort peu sollicité par d autres types d activité, non liées à la prise de mesure. Il est donc évident qu il y a un manque de maîtrise du débit maximal d information qui va pouvoir être acquis en temps réel depuis la source. L ampleur du réseau local ainsi que son architecture conditionneront grandement la disposition des appareils et l étendue maximale utile de l expérimentation. Notons enfin qu aucun mécanisme ne nous permet de garantir l état de bon fonctionnement des éléments du réseau GPIB-Enet. Seuls des mécanismes logiciels supplémentaires, intégrés par dessus la couche matérielle, permettraient de fournir à tout moment des renseignements relatifs au bon état de marche des appareils. Cette solution générant du trafic supplémentaire, croissant exponentiellement avec le nombre de noeuds à contrôler, réduit d autant plus la largeur de bande passante disponible au transport de l information, détériorant la qualité globale du système. 1.3.4 Limitations l utilisation de réseaux d instruments, quoique résolvant un nombre non négligeable de problèmes soulevés par l instrumentation locale et intégrant efficacement cette nouvelle dimension de l informatique que sont les intranets et l Internet, fait apparaître des problèmes de mise en oeuvre spécifiques. En effet, la latence fort faible présentée par les réseaux locaux peut s avérer critique lors de la généralisation de la mise en oeuvre d expériences d instrumentation à distance telles que celles décrites dans [21], [5] et [16]. Cette utilisation des possibilités de l Internet n est en fait qu une généralisation ou plutôt une globalisation des techniques sous-tendant l instrumentation locale. Lors d une telle expérience, la latence induite par le transfert de l information ainsi que l apparition asynchrone des résultats prohibent la conception d un système de mesure en temps de réel. Une solution efficace [17] consiste à segmenter l installation en cellules de traitement et à assigner le contrôle de chacune de celles-ci à une unité de traitement spécialisée. Ces unités servent d interface avec les éléments distants du système et sont à même de prendre en charge les décisions et une partie du post-traitement, rendant ainsi le contrôle en temps réel possible dans chacune des 18

1.3. INSTRUMENTATION DISTRIBUÉE cellules et préparant les données pour envoi vers les machines lointaines. Il n empêche que les données arrivant des contrôleurs de cellules n en restent pas moins peu cohérentes dans le temps et donc peu exploitables à distance. On perçoit donc bien ici le besoin de disposer d une composante logicielle forte dans les cellules de prise de mesure, composante logicielle qui serait éventuellement induite localement pour les seuls besoins de l expérimentation. L utilisation tant d un réseau local que global présuppose que chaque acteur prenant part à l expérience est à même de s identifier sur ce réseau. Ceci signifie, par exemple pour un réseau TCP/IP, que chaque machine doit disposer d une adresse IP unique mais également avoir connaissance du routeur local permettant le branchement le cas échéant au réseau global. De plus, le contrôle des expériences par réseau suppose une géométrie relativement statique au vu du manque d interopérabilité des appareils. En effet, chaque appareil pris en charge par un ordinateur aura nécessité l installation et la configuration d un gestionnaire propriétaire, quel que soit le système actuel utilisé, e.g. GPIB-Enet. Modifier un appareil, changer un voltmètre par un autre provenant d un constructeur différent, ou déplacer les appareils impose de réévaluer une partie non négligeable de la configuration. La robustesse du système de mesure est un élément également souvent peu ou pas intégré à l architecture de l expérimentation. Il faut donc parallèlement mettre en oeuvre un ensemble de techniques permettant l évaluation de l état courant des appareils. Un tel système sera donc forcément peu réutilisable et interopérable avec d autres systèmes de surveillance du bus, puisqu il s agit de mettre en oeuvre des solutions commerciales ou développées sur mesure. Enfin, le désir de faire communiquer des instruments et des ordinateurs selon un schéma homogène et portable impose l utilisation de protocoles standardisés qui présentent le double désavantage de ne pouvoir évoluer dans le temps et de ne pas tirer bénéfice des techniques de développement actuelles, notamment l utilisation de langages de très haut niveau orientés-objet et de techniques de mise en oeuvre d objets distribués. Constituer des points de mesures mobiles, dynamiques voire collaboratifs est donc actuellement fort peu aisé, voire impossible au vu de ces limitations. 19

Chapitre 2 CORBA Sommaire 2.1 Introduction............................. 20 2.2 Architecture............................. 21 2.2.1 IDL.................................. 22 2.2.2 l ORB et l IIOP........................... 23 2.2.3 Le mécanisme de marshallisation.................. 25 2.2.4 Les Objets standards......................... 27 2.3 Conclusion.............................. 28 Nous détaillerons brièvement dans ce chapitre les concepts et les mécanismes mis en oeuvre par la Common Object Request Broker Architecture (CORBA) afin de mieux la positionner par rapport à Jini. Nous présentons également dans le chapitre cinq, lors de la justification du choix de l architecture utilisée pour la réalisation du système d instrumentation distribuée, une comparaison des mécanismes utilisés par CORBA d une part et la combinaison RMI/Jini d autre part. 2.1 Introduction Les systèmes d objets distribués sont actuellement incontournables pour le développement et le déploiement de logiciels par dessus une couche réseau de plus en plus importante. Leurs avantages découlent de l utilisation de langages de programmation orientés objet : ces systèmes en tirent une réusabilité de code accrue, ce qui était quasi impossible dans une logique fortement protocolisée, mais également une transparence complète quant à la localisation des objets lors du déploiement. Un système distribué développé en un langage de haut niveau offre l avantage d être,à peu de choses près, conçu comme s il devait être 20

2.2. ARCHITECTURE exécuté en local. De nombreux procédés existent afin de mettre en oeuvre des objets distribués et le plus connu de tous est sans nul doute CORBA, la solution de prime abord la plus efficace et la plus standardisée à ce jour. CORBA est avant tout une norme [25] [27], c est-à-dire un ensemble de spécifications et de recommandations émises par l Object Management Group (OMG) [4]. l OMG est un groupe de travail indépendant au sein duquel siègent plus de sept cent partenaires issus de tous horizons : développeurs de logiciels, fabricants de matériel et grands utilisateurs. l objectif de CORBA est avant tout d assurer une interopérabilité entre des applications orientées objet hétérogènes tant du point du vue de leur langage de développement que du système d exploitation sur lesquels celles-ci seront amenées à être déployées. Ces applications reposent sur un modèle de mise en relation d objets distribués sur un réseau et interopérant entre eux de manière totalement transparente du point de vue de l utilisateur. Pour parvenir à ses fins, CORBA définit et implémente plusieurs concepts. Tout d abord un modèle de communication entre les objets distribués à travers le réseau. Ensuite, elle définit une couche de transport commune à tous les logiciels : l ORB (Object Request Broker). l OMG met également à disposition un langage de description des interfaces présentées par chacun des acteurs du bus d objets distribués : l IDL (Interface Definition Language). Enfin, des services et des objets élémentaires sont introduits afin de faciliter le déploiement et l utilisation de CORBA : il s agit, entre autres, des Common Object Services, des CORBA Facilities et des Domain Interfaces. Chacun des éléments formant le bus est simplement spécifié par l OMG et celle-ci n impose donc aucun langage ni aucune plateforme lors de l implantation et du déploiement final. La plupart des langages actuels sont à même d exploiter les standards de l OMG et bon nombre de constructeurs ont développé leur ORB, offrant ainsi une diversité quant aux possibilités accessoires que chacune des implantations offre, mais autorisant également la réalisation d application hautement interopérables. Seule la fonction et la nature même des applications développées forcera le choix de tel ou tel autre logiciel CORBA. 2.2 Architecture Les interactions entre objets sur un bus CORBA suivent un modèle classique client serveur. Les applications clientes émettent des requêtes vers les objets serveurs, ceux-ci les exécutent de leur côté et enfin ils renvoient le résultat éventuel à l appelant. Ce modèle présuppose que la méthode invoquée et implantée dans le serveur soit connue du client et que celui-ci possède tout le matériel nécessaire à la prise de contact avec le serveur et l envoi des paramètres. A cet effet, quatre éléments importants sont mis en jeu : l Interface reprenant toutes méthodes accessibles sur l objet distant. Cette interface est implantée par le serveur et connue du client. L IDL offre une formalisation de la définition de cette interface, de manière indépendante du langage mais selon une 21

2.2. ARCHITECTURE structure fortement inspirée de l orienté objet. Le Stub conservé par le client. Il est obligatoirement cohérent avec l interface du serveur puisqu il s agit de la partie d un objet délégué par le serveur et à même de prendre en charge de manière totalement transparente la communication avec l objet lointain. Le Skeleton situé côté serveur. Il s agit ici de l implantation proprement dite des méthodes déclarées au moyen de l interface et activées à travers le stub. l ORB qui est la couche de transport des requêtes et des références sur le bus CORBA. Il s agit d un middleware situé entre l application et la plateforme. Celui-ci doit donc être implanté pour chacune des plateformes existantes. La figure 2.1 indique le positionnement relatif de chacun des éléments d une architecture CORBA de base. L IIOP (Internet Inter Orb Protocol) permet de connecter deux ORB de vendeurs éventuellement différents à travers l Internet. Il est important de noter ici que les flèches ne représentent pas un mouvement de données du client vers le serveur, mais modélisant le jeu de pointeurs qui permet de référencer chaque objet en CORBA. En effet, CORBA fait abondamment usage de références distantes ou locales tant pour les objets serveurs que pour les arguments des méthodes. Ces arguments sont donc toujours passés par référence et non par valeur, bien que ceci semble changer dans les versions de CORBA ultérieures à la deuxième. Client Server Server Object Reference getvoltage() method Server Object Implémentation ORB IIOP ORB Fig. 2.1 Éléments de base d une architecture CORBA 2.2.1 IDL Le langage de définition d interface est un élément clef du bus de distribution d objets CORBA. IDL est utilisé afin de décrire formellement chacun des objets selon des conventions non liées au langage final utilisé pour l implantation. Ces interfaces seront ensuite développées au moyen d un outil approprié afin de fournir un squelette d application pou- 22

2.2. ARCHITECTURE vant servir de base à la réalisation concrète du système distribué, aussi bien client que serveur. De plus, IDL masque complètement les processus de communication entre objets, rendant ainsi le développement de l architecture client-serveur totalement transparente. Il s agit donc ici de définir ce que l objet est à même de proposer comme service en le situant dans une hiérarchie de services ainsi qu en énumérant les méthodes qu il met à disposition. L exemple suivant présente une définition réalisé au moyen de IDL. Il s agit ici de créer un module, semblable à la notion de package en Java, contenant un objet Ammeter et un objet Voltmeter. Chacun de ces objets implante des méthodes qui seront accessibles via le Stub généré par les outils de compilation spécifique à chaque langage. module TestModule interface Ammmeter void reset(); float getcurrent(); ; interface Voltmeter void reset(); float getvoltage(); ; ; Il est important ici de noter cette structure fortement hiérarchisée de packages disposés selon un arbre. Cet élément sera fondamental dans la comparaison que nous offrons de CORBA vs. JINI dans le chapitre 5. Le langage IDL propose également un mécanisme d héritage entre et depuis les interfaces. Cet héritage peut être simple, multiple ou répété. La notion d héritage répété a été introduite en raison de la possibilité d implanter un héritage multiple tout en respectant la contrainte de non répétition des noms. Cette contrainte spécifie qu au sein d un même module, la surcharge c est-à-dire définir plusieurs méthodes dont la signature est différente mais dont le nom est identique est interdite. 2.2.2 l ORB et l IIOP L ORB est le composant central de la répartition des objets sur le bus CORBA. Il assure le transport des requêtes entre les clients et les serveurs ou, pour être plus précis, entre les stubs des clients et les implantations correspondantes présentes dans les skeleton des objets serveurs. Il s agit d un middleware qui se déploie entre la couche application proprement dite où vivent les objets et le système d exploitation qui gère les fonctionnalités réseau du 23

2.2. ARCHITECTURE système local. Son existence marque la volonté de s abstraire de l hétérogénéité qui existe entre différentes implantations d un même objet, hétérogénéité qui puise sa source dans le choix du langage de programmation, du système d exploitation retenu pour le déploiement final ou encore dans le formalisme de représentation de données des machines. Les stubs désireux d effectuer une requête l adressent premièrement à l ORB qui se charge de la poursuivre jusqu au skeleton correspondant. Du point de vue du serveur, l ORB accueille les invocations distantes et les traduit en des appels de méthodes sur des objets locaux. L ORB comporte neuf blocs fonctionnels, présentés à la figure 2.2, permettant de réaliser pratiquement les interconnexions nécessaires entre objets. Afin de ne pas entrer dans les détails du fonctionnement de l ORB, seuls 3 éléments fondamentaux pour la suite de l exposé seront abordés ici. Fig. 2.2 Structure de l ORB. Les référentiels des interfaces et des implantations gardent trace des objets mis à disposition sur le bus. L interface d invocation statique L interface d invocation statique est le résultat de la projection des descriptions IDL dans le langage d implantation. A travers la SII (Statical Invocation Interface), les stubs clients peuvent invoquer les méthodes sur les objets distants de manière totalement transparente : la SII se charge du transfert de l invocation à l objet distant via la couche de communication réseau constituée par le coeur de l ORB (Core ORB). Son principal désavantage est sa staticité intrinsèque : le stub doit impérativement être fourni au programme client, ce qui implique que tout changement dans le contexte de déploiement du client (langage, 24

2.2. ARCHITECTURE hardware) requiert la génération d un nouveau stub, compatible avec la nouvelle configuration. Le référentiel des interfaces Le référentiel des interfaces garde trace des objets déployés sur l ORB en utilisant la description de l Interface Definition Language. Cette base de données contient les modules, méthodes, attributs, exceptions, types de données accessibles et facilite ainsi l introspection de l ORB afin de permettre pratiquement le mise en relation des références des stubs clients et de leur skeleton correspondant. L interface d invocation dynamique L interface d invocation dynamique offre une plus grande souplesse dans l envoi de requêtes vers les serveurs. Son mécanisme est plus flexible et consiste à localiser dans un premier temps l objet distant désiré en spécifiant le nom de la méthode devant être invoquée, les paramètres désirés ainsi que la classe d objet que l on désire ainsi adresser. Suite à cette requête, et pour peu qu un tel objet existe, un stub et un skeleton sont générés respectivement du côté client et du côté serveur, permettant l appel de méthodes distantes, au moyen de mécanismes similaires à ceux d une invocation statique. Chaque implantation de l ORB, avec plus ou moins de possibilités annexes, est laissée à la discrétion des vendeurs. Afin de rendre possible l exploitation de CORBA sur des réseaux de grande échelle ou dans des environnements où sont déployés des implantations différentes de l ORB, l OMG définit un certain nombre d adapteurs inter-orb dont le plus important est IIOP : Internet Inter-Orb Protocol. IIOP définit simplement comment un ORB est à même d échanger des informations avec un autre ORB. 2.2.3 Le mécanisme de marshallisation L activation de méthodes distantes suppose la possibilité de fournir à ces méthodes et de recevoir de celles-ci des objets. IDL définit deux modes de transfert des objets : IN et OUT, un objet IN allant du stub vers le skeleton et un objet OUT représentant une valeur de retour. Ce transfert d objet, totalement transparent pour l utilisateur, s effectue au moyen d un mécanisme dit de marshallisation. 25

2.2. ARCHITECTURE La marshallisation est le procédé par lequel l état d un objet ou un objet même est transformé afin d être transféré sur le bus d objet distribué. Dans le cas de CORBA, les objets arguments ne pouvant être passés par valeur, l ORB devra gérer un jeu de références permettant d un côté de la transaction d énumérer les valeurs des attributs d un objet et, à l autre bout du transport, de reconstituer un objet cohérent à l interface IDL de l objet marshallisé et présentant le même état, à savoir : les mêmes attributs. L objet transféré n est pas réellement transporté dans son intégralité, comme c est le cas, nous le verrons plus loin, lors de l utilisation du modèle RMI de Java. La marshallisation n induit donc pas un vrai polymorphisme en ce sens que si un objet dérivé d une classe donnée est transféré sur un canal du bus dévolu au transport d un membre de la classe mère ; il commencera le processus comme objet dérivé de la classe mère et sera reconstitué plus tard comme un objet membre de la classe mère. En effet, l autre côté du canal est à même de reconstruire des objets de la classe mère, au vu de sa spécification IDL, et n aucune connaissance de ce qu il s agit en fait d un objet dérivé qui a en réalité transité sur l ORB. Fig. 2.3 CORBA ne permet pas l exploitation d un vrai polymorphisme. Pour prendre un exemple plus ludique et plus simple (Fig. 2.3), imaginons une classe Chat, dérivant d Animal, et qu il existe un objet serveur dont nous désirons activer une méthode. Cette méthode accepte en argument un membre de la classe Animal. Si nous envoyons un Chat, ce qui est cohérent du point de vue de l IDL de la classe distante, le serveur recevra en fait, après reconstitution, un Animal car le processus de marshallisation examinera les attributs du Chat, vu comme un Animal, pour reconstituer un Animal du côté serveur, dégradant ainsi l information. Ce point de vue peut se justifier par le fait que la spécialisation en Chat de l objet Animal peut n être connu que par le client seul. 26

2.2. ARCHITECTURE Nous verrons que ceci n est pas du tout le cas de RMI, et donc de Jini, car un mécanisme supplémentaire, appelé code mobile, permet la mise en commun des classes entre le client et le serveur, y compris celles qui ne sont connus que par un de deux protagonistes. Dans ce cas, l envoi d une sous-classe permettra de récupérer un membre de cette sous-classe en bout de marshallisation même si à l origine seule la super-classe est connue du serveur. 2.2.4 Les Objets standards L OMG a spécifié un ensemble d objets standardisés à même d être déployés sur le bus CORBA de manière à offrir des services spécifiques à de nombreux scénarios d utilisation. Il s agit d abstractions aux fonctions systèmes de base, telles que la dénomination (Naming Service), la persistance des objets, le cycle de vie, la sécurité, la gestion des licences d utilisation des objets,les événements, etc. L ensemble formé de ces services ne sont pas toujours implémentes de manière complète par les ORB disponibles actuellement. Dans le cadre de la réalisation de réseaux de terrains et d instrumentation distribuée, seuls trois services importants sont à même de remplir des fonctionnalités clés dans les processus d interaction et de coopération intervenant entre les appareils d une part et les clients logiciels d autre part. Il s agit des Naming Service, Trader Service et Event Service. Le Naming Service Ce service fournit un système de désignation permettant d obtenir les références des objets répondant à un nom d enregistrement donné. Les noms sont structurés selon un graphe de contextes de dénominations interconnectées, permettant ainsi la création d un espace de nom réparti et éventuellement fort vaste. A l intérieur de chaque contexte, chaque nom symbolique doit être unique, mais un même objet peut utiliser plusieurs noms. Ceci permet aux objets de s enregistrer multiplement : sur base de noms différents ou dans des contextes différents. Ce mécanisme est en réalité assez pauvre dans un cadre dynamique, car un nom seul ne peut refléter les capacités des objets et rien ne précise si un objet se présentant sous un nom donné est susceptible d implanter une interface recherchée. Le Trader Service Le Trader Service présente un mécanisme plus puissant et plus exploitable que le Naming Service. Les serveurs s y enregistrent en détaillant l ensemble des propriétés qui les caractérisent, sous forme d un ensemble d associations clef-valeur, ainsi qu en fournissant l interface IDL qu ils implantent. Les clients utilisent ce service en indiquant le type d interface recherchée et des critères annexes : type des objets arguments, nombre d arguments,etc. Le Trader Service résout les requêtes en parcourant l ensemble du référentiel des enregistrements qu il a collectés. Le client ayant obtenu ainsi l ensemble des références des objets qu il désire utiliser, la transaction peut commencer avec le serveur, par exemple en exploitant la Dynamic Invocation Interface. 27

2.3. CONCLUSION l Event Service Notons enfin l existence d un service de gestion des événements basé sur un modèle producteur consommateur. Ce service permet une propagation asynchrone des événements au moyen d un canal réservé : le canal évènements. Les objets peuvent jouer deux rôles dans cette interaction : ils sont soit producteurs et génèrent des évènements, soit consommateurs et cherchent à les acquérir. Les évènements sont transmis selon deux modes sur le canal : pull et push. Le mode de dépôt (push) est utilisé par les producteurs pour envoyer un événement vers les consommateurs. Les objets consommateurs concernés sont dès lors avertis de la présence d un nouvel événement disponible sur le canal. Le mode de retrait (push) permet à un objet consommateur d interroger le canal événement quant à l existence d un nouvel événement. Ainsi, par un mécanisme de scrutation, un objet peut avoir une connaissance à tout moment de l état actuel de la pile événements du canal local. 2.3 Conclusion L exploitation des mécanismes de base de CORBA, combinée aux services standards d invocation dynamique, de collaboration avec le Trader Service et le Event Service permet la réalisation de systèmes distribués sur un modèle service consommateur. Nous verrons plus loin dans ce mémoire que Jini propose la même démarche mais portée cette fois dans le monde de Java. Il nous faut cependant apporter un bémol à cette vision idyllique de CORBA en constatant qu actuellement aucun vendeur d ORB ne fournit simultanément l ensemble des services requis pour le déploiement d un système d instrumentation flexible et présentant une fiabilité élevée. 28

Chapitre 3 JAVA et RMI Sommaire 3.1 Introduction............................. 29 3.2 La technologie Java......................... 30 3.3 RMI.................................. 32 3.3.1 Le modèle proposé par Java : RMI................. 33 3.3.2 Le transfert dynamique de code mobile.............. 34 3.4 Java hardware : le PicoJAVA................... 36 La solution que nous proposons pour l implantation de réseaux d instruments distribués est l utilisation d un nouveau modèle d architecture distribuée connue sous le nom de Jini. d un point de vue logiciel, Jini est une sur-couche de la plateforme Java et utilise massivement le système d objets distribués de Java : RMI. Afin de présenter au mieux les possibilités étendues d utilisation que permet Jini, nous nous devons dans un premier temps de détailler ce qu est la plateforme Java ainsi que de présenter de manière détaillée les mécanismes présents dans RMI. 3.1 Introduction Le développement de la plateforme Java [13] est certainement une des grandes révolution de l informatique actuelle. Le langage Java est apparu en 1995. Il est le fruit des recherches des ingénieurs de Sun Microsystems, désireux de mettre en oeuvre un langage de haut niveau afin de programmer des périphériques embarqués. Très rapidement confrontés aux limitations de langages orientés objets tels que C++ et ADA, ceux-ci ont opté pour le développement d un nouveau langage baptisé Oak, extrêmement lisible, purement orientéobjet et surtout indépendant autant que possible du matériel sur lequel il serait amené à être déployé. 29

3.2. LA TECHNOLOGIE JAVA 3.2 La technologie Java La technologie Java regroupe deux concepts : Java est à la fois un langage de programmation et une plateforme. La plupart des langages permettent soit leur interprétation, soit leur compilation sur une machine donnée en vue de réaliser une exécution. Java a cela de singulier qu il est à la fois compilé et à la fois interprété dans la plus grande majorité des cas. Avec le compilateur, il est possible de transformer le code écrit en langage Java en bytecode. Le bytecode Java est un code indépendant de la plateforme qui sera injecté dans un interpréteur présent sur le système local. La compilation n est requise qu une fois, alors que l interprétation aura lieu à chaque fois que le programme est exécuté. La figure 3.1 illustre ce mécanisme. Fig. 3.1 Schéma classique de mise en oeuvre de Java. Le code est compilé sous un format indépendant de la plateforme et est ensuite exécuté sur un interpréteur lié au système. La génération d un bytecode qui sera par la suite interprété permet de développer des applications sans se soucier de la plateforme finale de déploiement : il suffit en effet qu un interpréteur Java, connu sous le nom de Java Virtual Machine, soit présent sur la plateforme cible. De tels interpréteurs existent actuellement pour quasi toutes les combinaisons de système d exploitation et de composante matérielle : du PC sous Windows jusqu à la station multi-processeurs utilisant des CPU SPARC en passant par toutes les versions de Linux (x86,alpha,sparc, etc.). La figure 3.2 illustre le déploiement d une application compilée en bytecode Java. On comprend donc tout l intérêt d un tel langage dans un environnement hétérogène de machines interconnectées entre elles au moyen d une couche réseau. Nous verrons également dans le chapitre suivant que l existence sur chaque machine d un code commun, le bytecode, ouvre des perspectives nouvelles quant à l utilisation d objets distribués et aux possibilités de transfert de code d une machine virtuelle à une autre. Enfin, un autre aspect non négligeable de nos jours est la possibilité de réaliser de manière extrêmement facile des interfaces graphiques (GUI : Graphical User Interfaces) au moyen d un ensemble de classes prédéfinies en Java. On peut ainsi réduire drastiquement le temps consacré à l élaboration de l interface homme-programme puisque le canevas d élaboration est le même quelle que soit la plateforme, évitant ainsi de devoir recourir à des bibliothèques propriétaires peu portables et souvent fort lourdes à maîtriser. 30

3.2. LA TECHNOLOGIE JAVA Fig. 3.2 Le bytecode produit par la compilation pourra être interprété sur une JVM sans se soucier des composantes matérielles du système. Portabilité Le choix du langage Java pour le développement des applications d instrumentation distribuée est souvent mis en évidence dans la littérature [22] [23]. En effet, de telles architectures sont caractérisées par la mise en présence de systèmes d exploitation forts différents selon qu il s agisse de stations client conviviales ou de machines noeuds du système de mesure choisies plutôt pour leur robustesse. Java permet de réaliser des applications portables, interopérables entre toutes ces machines en utilisant un même modèle de développement, les mêmes outils et surtout en faisant appel à des compétences semblables, quel que soit l aspect du problème abordé : client ou serveur. De plus, l exploitation de techniques propres à Java, telles que les applets, permet d enrichir encore l expérimentation, permettant ainsi aux utilisateurs d accéder à des présentation des résultats via leur navigateur Internet habituel. Rappelons ici que les applets sont de petites applications graphiques qui peuvent être exécutées dans un navigateur Internet pour autant que celui-ci intègre une Java Virtual Machine. l utilisateur, en se connectant sur le site contenant l applet, initie le chargement puis l exécution de celle-ci dans le navigateur, permettant ainsi d obtenir une présentation des données ou d envoyer des commandes à un système distant. Interfaçage de code natif C ou C++ Un autre aspect important du langage Java est sa capacité à pouvoir interagir avec du code natif de manière totalement transparente [19]. On entend par code natif tout type de code binaire compilé spécifiquement pour une machine donnée tournant sous un système d exploitation donné. On pourrait citer comme exemple n importe quel programme compilé sous Windows/Intel ou n importe quelle bibliothèque mise à disposition sous Linux/Intel. Le langage d origine du code natif n a pas d importance puisqu il s agit d adresser du code relogeable ; néanmoins les outils mis couramment à disposition couramment ciblent plus particulièrement les langages C et C++. 31

3.3. RMI Il faut être conscient qu il s agit en quelque sorte d une entorse faite au principe de portabilité mais la volonté de rester compatible avec les programmes existant auparavant explique ce qui a motivé les concepteurs de Java à développer cette interface native connue sous le nom de JNI (Java Native Interface). Exploitation du code natif Le code natif a principalement deux utilités : l exploitation des ressources locales de la machine au moyen d un code plus rapide, plus puissant et le désir de pouvoir mener des actions sur des éléments du système qui ne sont pas repris dans la plateforme Java. A titre d exemple, il pourrait s agir dans le premier cas de routines ultra-rapides de traitement digital du signal et pour le second de l écriture dans les registres des cartes matérielles présentes sur l ordinateur. Comme nous le verrons plus tard, cette dernière technique a été mise en oeuvre dans le présent travail afin de permettre la prise de contrôle du bus GPIB par un programme Java au moyen des bibliothèques standard fournies par le constructeur de la carte. Notons que l utilisation du langage C ou C++ standard jumelé avec un code soigné du point de vue de la portabilité, permet néanmoins de déployer assez facilement de code natif venant de pair avec une application Java. De plus, dans le cas présent de l instrumentation, des bibliothèques fortement standardisées existent pour un grand nombre de plateformes natives utilisant le langage C. Ce dernier point, plus propre à la réalisation pratique du système d instrumentation sera traité dans la seconde partie de ce travail. Les extensions de la plateforme Java Une autre particularité de la plateforme Java est l existence d un grand nombre d extensions, permettant par exemple l utilisation des ports de communication série ou parallèle, le déploiement sur des stations mobiles légères (PDA ou GSM), ou l implantation de Java dans des systèmes embarqués peu coûteux et présentant des ressources mémoire et calcul limitées. Ce large éventail d ajouts à la plateforme commune permet de considérer que l utilisation de Java est un choix excellent et durable dans le temps, tant du point de vue de l exploitation de l électronique embarquée, de plus en plus présente autour de nous, que du point de vue du programmeur d applications complexes orientées utilisateur. 3.3 RMI Nous avons exposé dans le chapitre 2 le système d objets distribué CORBA. Les concepts introduits par l OMG dans le cadre de la mise en oeuvre de CORBA découlant de principes généraux relatifs à la mise en oeuvre d objets distribués, ceux-ci sont également le fondement de la Remote Methode Invocation (RMI) de Java [3]. Nous présenterons dans un premier temps le modèle RMI, puis nous exposerons une technique de partage de classes entre le client et le serveur connue sous le nom de chargement dynamique du code mobile. 32

3.3. RMI 3.3.1 Le modèle proposé par Java : RMI Comme nous l avons évoqué, la Remote Method Invocation (RMI) de Java s apparente au schéma classique de distribution d objets sur un bus réseau, à cette exception près que le but recherché n est pas ici d interfacer tous les langages possibles mais bien de concevoir des applications distribuées issues d un même langage : Java. Ces applications seront donc ameneés à résider sur des machines virtuelles [14] différentes et non sur des plateformes différentes. Cette différence apparaîtra fondamentale dans le paragraphe suivant. La figure 3.3 présente les éléments d une application écrite au moyen de RMI. Fig. 3.3 Protocoles mis en oeuvre par RMI Dans un premier temps, Le serveur appelle le registry afin d associer un nom symbolique avec l objet qu il met à disposition sur le bus. Le client peut alors entamer un processus de recherche et interroger le registry sur la présence ou non d un nom de service disponible. En cas de succès, il obtient alors une référence sur l objet correspondant et est à même d invoquer sur ce dernier une méthode particulière. L ensemble des méthodes disponibles auprès du serveur est décrite au moyen d une interface connue du client et du serveur. Cette approche est semblable à celle proposeé par CORBA au travers de l IDL. Rappelons à cet effet qu une interface est un formalisme énonçant le comportement d une objet, mais ne réalisant pas l implémentation de la classe. Il s agit donc d un contrat que s engage à remplir la classe implémentant l interface, dont la réalisation finale est discrétionnaire. Comme nous le verrons dans la section suivante, des serveurs Web sont également utilisés par RMI afin de permettre le transfert de bytecode entre le client et le serveur. Insistons bien ici sur le fait qu il ne s agit pas de la marshallisation proprement dite d objets, tels que les paramètres des méthodes activées, mais bien de transférer, le besoin échéant, des classes depuis un intervenant jusqu à l autre. Ce mécanisme n a pas d équivalent en CORBA et est appelé transfert dynamique de code mobile. 33

3.3. RMI 3.3.2 Le transfert dynamique de code mobile Le transfert dynamique de code mobile permet de transférer du bytecode, ou plus simplement du code Java, d une instance d une classe qui n est pas définie sur la machine virtuelle recevant ce code depuis la machine virtuelle qui fait référence à ce code. Ainsi, les interfaces, les comportements accessibles uniquement sur une plateforme sont rendus accessibles sur une autre plateforme, éventuellement distante. L exploitation de cette technique permet à RMI la conservation d un vrai polymorphisme tout au long du dialogue client-serveur, ce qui n était pas possible en CORBA. On entend par vrai polymorphisme le fait que la manipulation de la classe à travers des processus de généralisation et/ou de spécialisation ne dégrade pas son comportement. Une classe ayant subit une généralisation en un membre de sa classe mère peut toujours être vu comme un élément de sa classe d origine. Ceci n est pas possible dans d autres langages, tels que C++. Reprenons ici l exemple du Chat envoyé à travers un ORB qui est à même de marshalliser un Animal. Cette transaction est exposée sur la figure 3.4. Si nous effectuons cette opération au moyen de RMI, le comportement Chat n étant pas connu de la machine distante, celle-ci entamera un transfert de code mobile avec la machine d origine de la transaction afin d obtenir le bytecode lui permettant d avoir une connaissance de la classe Chat. Ce transfert est totalement transparent et automatique, l utilisateur n ayant aucune intervention à fournir lors de l exécution ou de la programmation. Notons enfin que l utilisation de la technique de transfert dynamique de code mobile permet la même flexibilité que l interface d invocation dynamique de CORBA, en ce sens que si un client désire invoquer des méthodes sur un serveur dont il n a pas connaissance a priori, il pourra obtenir la référence du stub du serveur auprès du rmiregistry et entamer un téléchargement du code de ce dernier (fig. 3.5). Ayant acquis le stub, il pourra alors l utiliser tout le temps de la transaction avec le serveur. Insistons sur le fait, crucial pour la compréhension des mécanismes implantés par Jini, que contrairement à CORBA, il ne s agit pas ici de construire dynamiquement le stub du côté client mais bien d en déplacer une copie depuis le serveur Web de l objet distant. 34

3.3. RMI A cat instance Animal Cat HTTP upload of Cat s class bytecode A cat instance Cat Client Marshalling Server Marshalling RMIbus RMIbus A cat instance Animal Cat An Animal Instance Animal Client Dynamic Stub Invocation ORB Server Dynamic Skeleton Invocation ORB IIOP Fig. 3.4 RMI (au-dessus) conserve le comportement d une classe marshallisée contrairement CORBA (dessous). Ceci est rendu possible par le transfert du bytecode de la classe Chat de la machine client à la machine serveur. Client Virtual Machine Server Virtual Machine Client RmiRegistry Server Object Server s Stub Web server Web server Client Virtual Machine Server Virtual Machine Client Server s Stub Aks for location of the Stub Server Object RmiRegistry Web server Web server Fig. 3.5 Une copie du stub du serveur est transférée dans un premier temps auprès du rmiregistry. Le client utilise alors la référence du stub afin d en obtenir une instance locale par téléchargement du bytecode. 35

3.4. JAVA HARDWARE : LE PICOJAVA 3.4 Java hardware : le PicoJAVA L existence de machines virtuelles logicielles sur un nombre important de plateformes ne doit pas nous faire perdre de vue que Java n est pas qu un langage. En effet, le produit de la compilation d un objet Java n est autre qu un fichier binaire composé d une suite de symboles appelés bytecode. Ce code binaire est progressivement lu par le logiciel d interprétation et induit des actions dans une machine virtuelle. Cette machine a la structure d un système à microprocesseur : elle comprend une pile, des registres, une mémoire, des compteurs, etc. De ce point de vue, les symboles binaires du bytecode se comportent donc comme les instructions élémentaires qu un processeur est amené à lire séquentiellement. On comprend aisément qu une telle machine logicielle peut être réalisée de manière matérielle : c est le but de la spécification PicoJAVA [12]. Cette spécification remplace la machine virtuelle par un système à processeur réalisant, matériellement, les mémoires, pointeurs et piles décrits par la spécification de la machine virtuelle Java (Java Virtual Machine). L existence de telles machines permet donc la réalisation de systèmes embarqués complexes destinés à exécuter du code développé sur la plateforme Java. Des prototypes complets existent déjà, implantant les dernières spécification Java et livrés avec les outils sur lesquels sont classiquement basés le développement de tels systèmes : environnement de débogage, logiciel d optimisation, sonde JTAG pour l analyse des signaux du processeur, etc. Les figures 3.6 et 3.7 présentent un boîtier réalisé par la société Ajile. De tels composants pourraient à court terme être utilisés dans des PDA, des appareils de mesure ou même être intégrés dans des routeurs afin de remplir certaines fonctionnalités que requièrent, comme nous le verrons plus tard, tout réseau basé sur l architecture Jini. Notons enfin que les performances de ces appareils sont plus que satisfaisantes, grâce à un décodage d instructions réalisé en hardware. 36

3.4. JAVA HARDWARE : LE PICOJAVA Fig. 3.6 Le AJ-80 est un processeur PicoJAVA implantant la dernière spécification Java. Réalisé par Ajile, il convient parfaitement à l utilisation de Java en milieu industriel et mobile. Fig. 3.7 Le AJ-80 peut être assemblé sur carte de faible taille afin de lui adjoindre des ports d entrée/sortie standard ainsi qu un connecteur réseau. 37

Chapitre 4 Architecture Jini Sommaire 4.1 Introduction............................. 38 4.2 Architecture et principe...................... 39 4.3 Le modèle d interaction dynamique............... 42 4.3.1 Interrogation du Lookup par les clients.............. 42 4.3.2 Le concept de Leasing........................ 44 4.1 Introduction L architecture Jini [9] [18] a été introduite par Sun Microsystem Laboratories en 1999 et complète la vision de la plateforme Java dont l idée première était de créer un environement à même de permettre à des systèmes embarqués de communiquer et d échanger des données entre eux de manière flexible et transparente afin de bâtir des infrastructures de services orientés consommateur. Jini se présente sous la forme d une extension de la plateforme Java, disponible librement sur l Internet. Compte tenu de la jeunesse de cette technologie, de nouvelles implémentations sont régulièrement mises à disposition sur le site officiel de Jini, mais les concepts et les classes clés sont quant à eux finalisés et gelés de manière à permettre au développeurs d exploiter cette technologie dès maintenant, sans crainte d apparition d incomptatibilités dans le futur. Jini se veut avant tout une spécification pour l interopérabilité dynamique entre plateformes Java distribuées sur réseau, n imposant par là même auncun choix quant au proto- 38

4.2. ARCHITECTURE ET PRINCIPE cole final utilisé pour l implémentation des éléments de communication. Néanmoins, l utilisation de RMI comme moyen d exploitation des objets distribués rend le développement et le déploiement du code plus aisé, c est pourquoi les deux versions de Jini disponibles actuellement (1.0 et 1.1) utilisent, elles, abondament RMI. N oublions pas à cet effet que Java permet l exploitation du bus CORBA, largement utilisé dans l industrie, et donc que Jini n apparait en rien comme fermé des standards actuels. Des recherches ont permis de montrer qu il était possible de présenter de manière totalement transparente des services CORBA comme étant des services Jini, permettant ainsi à cette technologie d encapsuler l architecture CORBA. 4.2 Architecture et principe Jini repose sur un modèle d interaction faisant apparaître un certain nombre de rôles et de mécanismes clés. On distinguera de manière simplifiée trois acteurs constituant le bus Jini : 1. Le Service. Il s agit d un objet distribué qui est capable d accomplir un travail donné. Le Service propose ses capacités et invite les autres à les exploiter. Il peut être vu comme un fournisseur de comportement, de méthodes. 2. Le Client cherche à utiliser un Service spécifique, répondant à ses besoins sur le moment. Il se pose en consommateur des ressources disponibles. 3. Le Lookup qui orchestre les dialogues entre Clients et Services, garde trace des Services disponibles sur le réseau et permet au client des interrogations afin de chercher le Service le plus adéquat. Il gère également toute la dynamicité du réseau : disparition des Services, apparition de nouveaux membres sur le bus, modification de rôle d un des membres, etc. En plus de ces éléments de base, des concepts accessoires viennent se greffer afin, par exemple, d enrichir la définition des Services, de gérer la robustesse des transactions ou encore d introduire des mécanismes d envoi d évènements. Ils seront vu dans les sections qui suivent. L architecture Jini repose sur un modèle d interaction entre Services et Clients orchestré par un Service particulier appelé Lookup. Dans un premier temps, un ensemble de Services et de Clients sont disposés sur le réseau et cherchent à interagir. Pour ce faire, ils doivent tout d abord découvrir un ou plusieurs Service de Lookup. Soit ils possèdent l adresse IP de ce service et ils peuvent donc prendre contact avec lui sans difficulté, soit ils peuvent utiliser une technique d envoi de paquets en multicast, pour tout le sous-réseau, et attendre la réponse d un éventuel Lookup présent (Fig. 4.1). Pendant cette transaction, les Clients comme les Services agissent en temps que consommateurs du Service de Lookup. On constatera tout au long du détail des mécanismes de Jini que chaque intervenant n est pas amené à jouer un rôle unique, mais se présentera tantôt comme client, tantôt comme service. 39

4.2. ARCHITECTURE ET PRINCIPE Consumer Provider Lookup Service Consumer L L Lookup Service Consumer announcement announcement discovery L Lookup Service Provider discovery Fig. 4.1 Découverte du Lookup par les Clients et les Services. Consumer Provider Lookup Service Consumer L L Lookup Service Consumer announcement register discovery L Lookup Service Provider discovery Fig. 4.2 mise à disposition du Proxy par le service Dans un second temps, ayant connaissance du Lookup, le service met en dépôt chez le Lookup une portion de code appelée proxy (Fig 4.2). Il s agit simplement d une instance d un objet RMI qui est téléchargé du service vers le Lookup. Le transfert de code s effectue selon les mécanismes implantés par RMI (chargement dynamique du code mobile) au 40

4.2. ARCHITECTURE ET PRINCIPE Consumer Provider Lookup Service Consumer L L Lookup Service Consumer announcement announcement lookup register discovery L Lookup Service Provider discovery Fig. 4.3 Recherche des proxys du Lookup par le client moyen du serveur Web présent sur la plateforme du service. Le ou les clients se posent en consommateur des services présents sur le bus et peuvent entrer en contact avec ceux-ci à l aide du Lookup. Leur but est d obtenir une copie du Proxy mis en dépôt par le service dont ils désirent exploiter les possibilités. Pour ce faire, ils fournissent au Lookup un ensemble de désidératas qui permettront de déterminer quels sont les proxys qui peuvent se révéler utiles (Fig 4.3). A nouveau, les mécanismes exposés dans le chapitre traitant de RMI seront mis en oeuvre afin de télécharger une copie du proxy depuis le Lookup jusqu au Client. Nous n avons jusqu à présent toujours pas précisé la nature même du proxy, à savoir sa fonctionnalité finale. Comme nous l avons dit, le Proxy est un morceau de code qui se déplace de manière transparente de la machine virtuelle du Service jusqu à la machine virtuelle du Client. En soi, aucune contrainte n est imposée sur celui-ci, si ce n est qu il doit être capable d effectuer ce déplacement en utilisant RMI et donc être développé comme un objet distribué au sens de RMI. Trois types d approches sont dès lors possibles par rapport au proxy : il est le service recherché par le Client. Auquel cas il s agit d un morceau de bytecode pris comme un programme complet. il est un moyen de recontacter le service qui l a mis à disposition. Dans ce cas, le proxy est un Stub servant de pont de communication entre le Client et le Service. Il est hybride : à la fois stub et application. Un tel proxy peut par exemple servir à 41

4.3. LE MODÈLE D INTERACTION DYNAMIQUE partager les besoins en ressources entre la machine client, plus puissante, et acquérir des informations auprès du service, plus léger. Cette approche laisse bien entendu une très grande liberté quant au rôle final que le proxy remplira. Quand bien même sa signification pourrait être fixée, une latitude très large est laissée à l implantation finale. 4.3 Le modèle d interaction dynamique 4.3.1 Interrogation du Lookup par les clients Nous avons puisque les Clients pouvaient effectuer des requêtes auprès du ou des lookup afin d obtenir une copie du Proxy des services qui les intéressent. Alors que CORBA permet d effectuer des recherches sur base d un nom symbolique ou de l énumération d un certain nombre de propriétés (méthodes, attributs), Jini proposé un modèle basé sur les comportements des objets Proxy. Ainsi, les Clients formulent leurs requêtes en présentant une ou plusieurs interfaces que les Proxy recherchés devront implémenter. Afin d affiner encore plus la recherche, une ou plusieurs classes d attributs secondaires dérivées par convention de la classe Entry peuvent être fournis. Les proxy qui implémenteront toutes les interfaces fournies par le Client et dont les Entry auront exactement les mêmes attributs que les Entry fournies par le Client seront alors retournés. Ce mécanisme impose donc que le client et le service conviennent des interfaces communes. On parlera ici de well known interfaces : les interfaces connues de tous. Notons enfin que l utilisation d interfaces pour la recherche permet l exploitation de toutes les techniques sous-jacentes à la conception par les méthodes des objets. Ainsi, si un proxy implémente une interface qui est une sous-classe de celle fournie par le client, le lookup considérera le proxy comme un résultat valide pour la requête. Pour prendre un exemple plus parlant, si un client cherche un instrument de mesure et qu un voltmètre est présent sur le bus à ce moment, celui-ci sera retourné car l interface voltmètre est une sous-classe d instrument de mesure et donc le voltmètre aura le comportement recherché par le client. Cette logique puissante peu sembler fort contraignante a priori, vu que toutes les interfaces doivent être normalisées entre les constructeurs avant l exploitation des possibilités Jini. Les différences mais donc également les spécificités que peuvent apporter les constructeurs semblent diminuées. Nous montrerons dans la section 7.2.2 qu il n en est rien si nous combinons le mécanisme de recherche de Jini avec les capacités d instropection dynamique des classe offerte par Java. Terminons ce paragraphe en signalant que le client peut s enregistrer auprès du lookup afin de recevoir des événèments liés au changement d état des services disponibles. Ces services sont bien entendu ceux qui répondent au désidératas exprimés client, i.e. ceux qui 42

4.3. LE MODÈLE D INTERACTION DYNAMIQUE réalisent les interfaces requises par celui-ci. La terminologie Jini fait état de trois transitions différentes. On parlera de transition 1. no match to match lorsqu un nouveau service, non connu jusqu à présent, s enregistre auprès du lookup et correspond aux demandes du client. 2. match to no match si un service connu venait à disparaître, soit intentionnellement, soit par expiration du délai de bail de son proxy. 3. match to match portant sur un service déjà existant mais dont le proxy s est modifié. Il s agit par exemple de la mise à disposition d une nouvelle classe proxy ou de la modification des attributs secondaires les Entry associés à ce proxy. La figure 4.4 montre que l apparition d un nouveau fournisseur de service entraine la réexécution du schéma que nous avons détaillé plus haut. Consumer L Provider Lookup Service Consumer usage usage 4 Lookup Service Consumer announcement event announcement lookup 3 2 register register 1 discovery S Lookup Service Provider discovery Fig. 4.4 A l apparition d un nouveau service, le lookup génère un évènement auprès du client afin que celui-ci puisse bénéficier du nouveau proxy. 43

4.3. LE MODÈLE D INTERACTION DYNAMIQUE 4.3.2 Le concept de Leasing Le transfert du proxy effectué, les compétences des services présents sur le bus peuvent être librement exploitées par les clients possédant les proxy qu ils requiéraient. Mais cette distribution de code à travers le réseau soulève la problématique de la robustesse de l architecture ainsi mise en place. La plupart des approches relatives à la conception et à la mise en oeuvre de systèmes distribués, faisant intervenir des objets ou non, postulent que le réseau est transparent. Transparent signifie ici qu il n est pas un paramètre critique de l interaction entre client et serveur : la latence est faible ou inexistante, les machines sont stables et sont peu susceptibles de présenter une panne ou de disparaître soudainement du réseau, les méthodes invoquées sur les objets distants n échouent pas. Force est de constater qu à long terme ces préceptes se révèlent être faux. L interaction dynamique entre noeuds d une communauté d appareils hétérogènes implique que ceux ci peuvent apparaître ou disparaître à tout moment. l activation d une méthode sur un objet distant peut potentiellement échouer ; il suffit de penser par exemple à l appel d une méthode de mesure du potentiel dans un calibre largement supérieur à celui que pourrait supporter le voltmètre. Jini intègre cette vision en offrant deux mécanismes afin d assurer la robustesse des interactions. Le premier mécanisme permet de traiter avec la partie relative à l activation des méthodes sur un objet serveur. En cas d échec de l appel à la méthode ou en cas de problème lors de la réalisation de la méthode, une exception est jetée. Ainsi le client sera non seulement averti de l insuccès de l invocation distante, mais il sera de plus obligé de traiter l exception éventuelle. En effet, les mécanismes syntaxiques du langage Java imposent, lorsqu une méthode est déclarée comme pouvant potentiellement jeter une exception, de prévoir une portion de code qui sera inconditionnellement exécutée. C est donc la responsabilité du développeur d agir en conséquence. Le second mécanisme,plus subtil, assure une connaissance continue des objets présents dans la communauté Jini. Fondamentalement, un Service peut quitter le réseau local de deux manières : soit proprement, en faisant part de son départ, soit suite à un impondérable (crash matériel, déconnexion du réseau). Un Service quittant le réseau proprement le fera en annonçant son intention au Lookup en charge de son ou ses Proxy (Fig. 4.5). Le Lookup décidera alors d invalider les Proxy mis en dépôt par le Service et avertira, au moyen d évènement distribués, les Clients faisant usage de ces Proxy qu il ne convient plus de les utiliser plus longtemps (Fig 4.6). Les Clients pourront alors envisager de détruire ou non les Proxy invalides. Le deuxième mécanisme est utilisé afin de prévenir qu un Service disparaisse du réseau local, sans avertir de son départ, mettant ainsi l équilibre de l architecture en péril. Ce mécanisme est connu sous le nom de Leasing. Lors de la mise en dépôt du Proxy, le Service et le Lookup conviennent du temps pendant lequel le Proxy sera mis à disposition ainsi que d une fréquence à laquelle ils prendront régulièrement contact. La transaction prend la 44

4.3. LE MODÈLE D INTERACTION DYNAMIQUE forme d un dialogue au cours duquel chacun des acteurs expose ses désidératas ; la décision finale revenant au Lookup seul. Pour fixer les idées, le service de Lookup fourni par Sun autorise qu un Proxy soit mis en dépôt pour un temps infini, pour autant que le Service puisse être recontacté au plus tard toutes les cinq minutes. Si, le délai passé, le Service ne peut être contacté ou qu il ne désire plus renouveller le bail de son Proxy, ce dernier sera détruit et les clients avertis de l invalidité manifeste des Proxy liés à ces Services. (Figs. 4.7 et 4.8). Enfin, un dernier mécanisme important permet aux clients de s assurer que le Service offre le même comportement. Si le Service venait à changer la configuration de son Proxy en fournissant un nouveau au lookup par exemple ou d une de ses Entry, un évènement spécifique est envoyé par le Service au Lookup et celui-ci le propagera à tous les clients utilisant le Proxy. 45

4.3. LE MODÈLE D INTERACTION DYNAMIQUE Consumer Lookup Service Consumer Provider Lookup Service Consumer lookup unregister discovery L Lookup Service Provider discovery Fig. 4.5 Le service annonce son intention de quitter Consumer L usage Provider Lookup Service Consumer Lookup Service Consumer announcement event announcement lookup register discovery S Lookup Service Provider discovery Fig. 4.6 L annonce est répercutée auprès des clients consommateurs du service 46

4.3. LE MODÈLE D INTERACTION DYNAMIQUE Consumer Lookup Service Consumer usage??? announcement lookup discovery Lookup Service Provider Fig. 4.7 Le service disparaît de manière impromptue mais son Proxy vit toujours sur la plateforme du Lookup Consumer L Lookup Service Consumer announcement event lookup discovery S Lookup Service Provider Fig. 4.8 Le lookup, ne pouvant renouveler le bail du proxy, l invalide et avertit les clients 47

Deuxième partie Réalisation d un système d instrumentation distribuée 48

Chapitre 5 Positionnement de JINI par rapport aux solutions actuelles Sommaire 5.1 CORBA................................ 50 5.1.1 Introduction............................. 50 5.1.2 Aspects communs.......................... 50 5.1.3 Éléments de distinction....................... 51 5.1.4 Conclusion.............................. 52 5.2 UPNP................................. 52 5.2.1 Introduction............................. 52 5.2.2 Principes............................... 52 5.2.3 Éléments de distinction....................... 53 5.3 IEEE 1451............................... 53 5.4 Conclusion.............................. 54 Les chapitres précédents ont longuement exposé la problématique des systèmes d instrumentation actuels ainsi que les différentes techniques utilisables actuellement pour la réalisation d applications distribuées exploitant les possibilités des langages de haut niveau. Dans ce chapitre, nous nous efforcerons de comparer la technologie Jini, préconisée comme solution, aux technologies existantes afin d en faire ressortir les éléments novateurs et d affirmer l intérêt de Jini dans le cadre de la réalisation d un système hybride instrument de mesure PC. 49

5.1. CORBA 5.1 CORBA 5.1.1 Introduction Les mécanismes de CORBA ont été détaillés dans le deuxième chapitre. Il y a été essentiellement question des processus de découverte dynamique des objets présents sur le bus ainsi que de la possibilité d interfacer dynamiquement les objets serveurs. De toutes les solutions actuelles, CORBA est celle qui se rapproche le plus de Jini : celles-ci partagent une optique globalement commune et des mécanismes à peu de choses près similaires. Certaines différences, plus subtiles, laissent penser que l utilisation de Jini offre des possibilités plus vastes et plus riches que ce que permet CORBA actuellement. Nous présenterons dans un premier temps les aspects communs des deux technologies pour enfin isoler les éléments clés qui constituent la différence de mise en oeuvre que propose chacune des deux approches. 5.1.2 Aspects communs Jini, à l instar de CORBA, est une architecture basant ses mécanismes d interaction dynamique sur la séparation de compétences en un certain nombre de services. Jini met en oeuvre principalement deux services : le démon 1 d activation RMI et le Lookup. Le démon d activation RMI sert à assurer la sécurité des transactions sur le réseau d objets distribués. Des règles peuvent être définies par l utilisateur qui serviront à valider ou invalider toute exploitation des objets distants. De plus, ce programme est à même d assurer un persistence des objets : c est lui qui conserve l ensemble des proxy collectés par le lookup mais il peut servir, le cas échéant, de mécanisme de sérialisation d un objet afin de le réactiver ultérieurement. On parle d objet activable que l on met en veille. Pour rapprocher ce démon des mécanismes de CORBA, on peut dire qu il remplit à la fois le rôle du service de persistence et du service de sécurité. Le lookup interagit avec le démon RMI et est quant à lui chargé de la détection des services et de désservir les recherches des clients. Il agit de ce point de vue un peu comme le Naming Service ou le Trader Service de CORBA : les clients peuvent y effectuer des requêtes et accéder ainsi aux objets serveurs. Seule l implantation finale de la mise en oeuvre de ces recherches montre des différences fondamentales entre le point de vue adopté par CORBA et celui de Jini. Enfin, l utilisation d évènements est présent dans les deux architecures. Jini impose qu une exception soit traitée lors de l activation d une méthode distante alors que CORBA propose l envoi d évènements via le Event Service. Néanmoins, une approche raisonnable 1 le démon est largement utilisé afin de traduire le mot anglais daemon. Ce terme peut paraitre relativement peu approprié pour celui qui ne le côtoie pas régulièrement et doit être vu comme un programme agent vivant en tâche de fond et dont le but est d assister le système dans la gestion des tâches. 50

5.1. CORBA du point de vue de l implantation des objets CORBA, consiste à imposer que chaque méthode jette une exception lorsqu une erreur prend place. De plus, en demandant au service d évènements de distribuer directement aux clients concernés les messages envoyés par les serveurs, on arrive au même niveau de robustesse que ce que Jini propose pour l interaction client-service. 5.1.3 Éléments de distinction Les différences fondamentales entre Jini et CORBA tiennent essentiellement au modèle de déploiement totalement duaux que proposent ces architectures. CORBA suppose un déploiement sur des machines hétérogènes, présentant des langages différents et des modèles de données incompatibles. Jini existe par dessus la plateforme Java et permet l interaction d objets Java distribués sur des machines virtuelles Java. C est donc l exploitation de ce langage et de cette plateforme unique pour tous les acteurs qui rend Jini fortement différent de CORBA. La notion d objet distribué de CORBA est intimement liée à la présence massive de pointeurs. Les objets, qu ils soient locaux ou distants sont accessibles via ces pointeurs. Un objet serveur utilisé par un client ne vit donc pas sur la machine locale. En Jini, le mécanisme est contraire : les services mettent à disposition des proxy qui sont transportés de manière transparente jusque sur la plateforme du client. L objet vit donc sur la machine virtuelle du client et devient ainsi un objet local. Il peut donc être sérialisé sur les périphériques de stockage de masse du client et être réexploité même après disparition du service qui l a émis. Ce phénomène est rendu possible grâce à l utilisation de RMI comme modèle pour les objets distribués et serait complètement impossible à réaliser en CORBA. Le système de bail (leases) utilisé dans Jini contribue à la stabilité et la propreté du système tout entier. Un serveur disparaissant dans CORBA ne se révellerait invalide qu au moment d un appel infructueux. Auncun mécanisme ne garantit le suivi des objets distants en terme d existence ou de possibilité de les atteindre. Les références de ces objets ne sont également pas nettoyées sur le bus tout entier. Jini offre un manière flexible de conserver le contact avec les services. Ceux-ci ne peuvent s enregistrer pour une durée illimitée auprès du lookup et toute disparition d un service entraîne automatiquement la propagation d évènements à travers tout le bus afin d avertir les clients consomateurs de ce service que les proxy qu ils possèdent pourraient mener à un comportement erroné. Le système est donc sous contrôle permanent et se nettoie régulièrement. Notons à charge de Jini qu il n y a actuellement aucun regroupement de services sous formes de sphères de compétences comme il existe dans CORBA pour chaque corps de métier. Notons que de tels objets pourraient se développer dans des versions utlérieures de Jini sous la pression des compagnies désireuses d exploiter les possibilités nouvelles de cette technologie. 51

5.2. UPNP 5.1.4 Conclusion CORBA et Jini présentent fondamentalement les mêmes aspirations pour l interaction entre objets sur un bus distribué. Seuls les modèles d implantation et de déploiement marque la différence entre les technologies. Jini tire bénéfice de son utilisation dans un environement fortement dynamique et mobile, mais exclusivement constitué de plateformes Java. Jini et CORBA ne sont cependant pas incompatibles en ce sens que le modèle RMI de Java permet d interfacer IIOP de CORBA [24] permettant la présentation de serveurs CORBA sous forme de services Jini. [20] 5.2 UPNP 5.2.1 Introduction Le modèle Universal Plug and Play [10] a été introduit par la société Microsoft en 1999. Nous l évoquons ici car il fait partie, au même titre que IEEE 1451, d une nouvelle vague de standards pour l exploitation flexible et transparente des appareils dans le monde informatique. Nous présentons ici de manière succinte les principes de cette nouvelle norme et apportons un bref point de comparaison avec la technologie Jini. 5.2.2 Principes UPNP a pour seul but de permettre une forme d interaction légère entre appareils d une part et entre ordinateurs d autre part. Il s agit d une version plus globale du standard très connu Plug and Play permettant de connecter tout type d appareillage informatique sans besoin de configuration préalable. Un périphérique compatible UPNP est à même de s insérer dans un réseau, d obtenir une adresse IP, de propager ses capacités et de découvrir celles des autres appareils également présents. Enfin, le périphérique est à même de quitter le réseau aisément, sans laisser d état incertain derrière lui. UPNP utilise principalement des techniques et des standards issus de la technologie Internet : IP, TCP, UDP, HTTP et XML. Comme il est courant sur l Internet, les interactions sont basées sur des protocoles déclaratifs, exprimés en XML et publiés via HTTP. Un autre avantage de UPNP est la disparition complète de la notion de gestionnaire de périphérique. Ces derniers sont remplacés par des protocoles communs et connus de tous, indépendants du langage et du système d exploitation. Certains périphériques plus évolués et plus puissants devraient être à même d incorporer une composante Web, permettant ainsi d accéder à certaines fonctionnalités, par exemple de configuration, à travers un navigateur Internet. 52

5.3. IEEE 1451 5.2.3 Éléments de distinction La notion d interface est plus contraignante ici que celle définie par Jini. En effet, les proxy de Jini étant des instances de classes, une analyse plus fine peut être réalisée par le client en utilisant le mécanisme d introspection de Java. Ainsi, les proxy sont-ils plus évolutifs car même s ils utilisent une interface connue, donc si on est assuré d y voir implémenté un ensemble minimum de possibilités connues, il est toujours possible d augmenter ces possibilités en les découvrant au vol. Les proxy sont déplacés du service vers le client, permettant ainsi une approche hybride où le code est exploité à la fois du côté PC et du côté appareil. Dans le cas par exemple du DSP (Digital Signal Processing), on peut réaliser des proxy prenant les points de mesure sur l appareil, en réseau, et implantant sur le PC l algorithme de post-traitement. Une telle approche n est pas possible avec UPNP car les périphériques sont seulement capables d énumérer leurs caractéristiques. Enfin, UPNP spécificie un standard permettant d intégrer les appareils PNP actuels et connectés sur un PC via USB par exemple. Une telle approche, connue sous le nom de surrogate, est également envisagée en Jini, afin de permettre aux appareils les plus anciens de participer à la communauté d appareils Jini. Il s agit en fait simplement d incorporer dans les gestionnaires de périphériques existant sur le PC un service contrôlant l appareil et le proposant sur le réseau. C est ce principe qui sera appliqué dans le cadre du présent travail, lors de l implantation du système de mesure. On peut dire en conclusion que UPNP a une vision à plus court terme et plus réduite en terme d implantation de code associé au périphérique. UPNP offre l avantage de requérir peu de ressources et d être plus directement en contact avec les standards existants, tel que PNP. 5.3 IEEE 1451 La proposition en cours de normalisation IEEE 1451, a été détaillée au point 1.3.2. de ce travail. Celle-ci met en oeuvre un modèle basé sur l échange de messages entre actuateurs et noeuds de contrôle afin d énumérer l ensemble des possibilités de l appareil. Une telle approche ne présente aucun aspect objet et est semblable à celle adoptée par UPNP. Nous pouvons donc adopter la même approche que celle nous avons détaillée pour UPNP et nous rendre à l évidence que cette technologie est importante mais a une vision moins large que Jini. 53

5.4. CONCLUSION 5.4 Conclusion Pour palier aux limitations actuelles d interfaçage des instruments de mesure ou des appareils en général, de nouveaux standards émergent et sont actuellement en cours de normalisation. Les architectures telles que Jini et CORBA offrent des possibilités plus intéressantes, puisque basées sur la technique des objets en adoptant une mise en oeuvre différente. Dans le cas très spécifique des systèmes d instrumentation distribuées, Jini nous semble présenter un réel avantage sur CORBA, de par la possibilité d incorporer du code mobile dans l appareil afin de réaliser les opérations de post-traitement ou de fournir une interface graphique spécifique à l appareil. Enfin, comme nous le verrons, Jini est la seule technologie offrant une approche réaliste des environements de terrain, en intégrant les aspects relatifs à la connexion ou la déconnexion brusque des appareils et en permettant la mise au point de stratégies efficaces dans le but d assurer la stabilité de l architecture déployée. 54

Chapitre 6 Contrôle local des instruments de mesure en Java Sommaire 6.1 Contrôle local des instruments GPIB.............. 55 6.2 l interface standard IEEE 488 pour Java............ 56 La réalisation du système d instrumentation virtuelle basé sur Jini et Java repose sur un modèle de développement incrémental : il s agira dans un premier temps de réaliser le contrôle purement local des instruments de mesure au moyen de bibliothèques standards et de code écrit en C. Ce code natif sera ensuite interfacé avec des classes Java au moyen de la Java Native Interface (JNI) dont les principes ont été détaillés dans la première partie de ce travail. On adjoint enfin ces classes de contrôle à un service Jini, complétant ainsi notre approche et réalisant pratiquement la distribution de l instrument sur le réseau local ou global. 6.1 Contrôle local des instruments GPIB Le contrôle local des instruments GPIB se base sur une bibliothèque de fonctions de très bas niveau mis à disposition librement par National Instruments. Cette bibliothèque existe tant pour Windows que pour l ensemble des plateformes Unix et Linux. Le code ainsi réalisé sur cette base restera hautement portable pour peu qu on prenne soin à n utiliser que des fonctions basiques. Il existe deux modes principaux d exploitation du bus GPIB : l initialisation du bus et des instruments ainsi que l envoi de messages et l attente de réponses vers et depuis les instruments proprement dits. 55

6.2. L INTERFACE STANDARD IEEE 488 POUR JAVA 6.2 l interface standard IEEE 488 pour Java Le bus IEEE488 pouvant être considéré comme un port de communication à part entière, nous avons rapproché tant que possible notre modèle de description et d utilisation du bus en Java de celui proposé dans l extension standard relative au ports d entrée/sorties. Cette extension, connue sous le nom de Java Communication API (JavaComm) offre actuellement la possibilité de traiter avec les ports séries et parallèles de n importe quel système. l approche retenue par Sun consiste à 1. énumérer tous les ports présents au moyen d une classe d énumération gardant trace de tous les ports trouvés 2. les initialiser 3. permettre d instancier une classe par port repris dans l énumération du premier point et d ainsi prendre le contrôle d un instrument présent sur le bus 4. mettre à disposition des méthodes dans la classe du port relatives à l exploitation de ses capacités (envoi, écoute, création d un stream pour y injecter des données, etc. ) Nous avons adopté exactement la même approche afin de nous conformer au standard de la JavaComm et de proposer ce gestionnaire de périphérique comme complément à l extension existante. Notre implantation comporte 5 classes qui sont décrites ci-dessous ainsi que sur la figure 6.1. GPIBDeviceIdentifier.java Cette classe est la première à devoir être instanciée. Elle se charge de prendre le contrôle du bus GPIB et de le réinitialiser. Dans un second temps, elle détecte et énumère tous les périphériques présents et, pour chaque appareil, garde trace de toutes les informations connues (identification, position sur le bus,etc.). Il s agit ici d une réprésentation passive de l instrument vu que celui-ci ne peut être encore contrôlé à ce point. On peut obtenir un instance de la classe GPIBDevice, représentant un périphérique GPIB, par l appel à la méthode open(). GPIBDevice.java Chaque instance de cette classe représente un périphérique présent sur le bus IEEE488. Via les méthodes de cette classe, nous sommes à même d envoyer des messages à l appareil ou d obtenir des mesures. GPIBDriver.java La réalisation de certaines méthodes requiert l utilisation de code natif comme nous l avons vu. Cette classe abstraite décrit les fonctionnalités que tout gestionnaire natif du bus doit implémenter. Un fichier de configuration placé dans un lieu standard permet de spécifier le nom d une classe à charger, celle-ci implémentera le gestionnaire natif du bus sur le système local. WindowsGPIBDriver.java Sous-classe de GPIBDriver, cette classe implémente les méthodes natives permettant l initialisation et l envoi de messages sur le bus. C est la seule qui comporte du code natif. La figure 6.2 présente le modèle suivant lequel l utilisateur a accès à un appareil spécifique. La prise en charge du bus GPIB par le code Java, au travers de la carte 56

6.2. L INTERFACE STANDARD IEEE 488 POUR JAVA contrôleur présente sur le PC, est initiée dès l instantiation de la classe GPIBDeviceIdentifier. Le constructeur de cette classe débute le dialogue avec le bus par la création d une instance d une classe implantant l interface GPIBDriver. Cette classe, e.g. WindowsGPIB- Driver, comporte tout le code natif nécessaire afin d interagir avec le bus. C est vers cette classe que seront concentrés les appels de bas niveaux aux instruments du bus. Une classe d énumération, associée à la classe d identification, permet de passer en revue l ensemble des périphériques qui auront été détectés lors de l initialisation du bus IEEE 488 par le GPIBDriver. Le périphérique est présenté au travers de la classe GPIBDeviceIdentifier, ce qui permet d obtenir des renseignements sans devoir réellement prendre le contrôle du périphérique. Enfin, la prise en charge proprement dite du dit périphérique se fera par l instanciation d une classe GPIBDevice. Créer une instance de cette classe initialise et prend le contrôle de l appareil correspondant, mais prend également en charge tous les appels nécessaires à la gestion des états d erreur éventuel de l appareil (e.g. erreurs de timeout). La classe GPIBDevice offre des méthodes permettant de communiquer efficacement avec l instrument qu elle représente. A cet effet, plusieurs types de messages sont disponibles : demande de fermeture du port de communication réinitialisation de l instrument envoi d un chaîne de caractères et acquisition du message de réponse Cette interface réduite découle des principes mêmes de l utilisation du bus GPIB : seuls des messages et des textes sont transférés sur les fils. Les changements d état du bus sont traités de manière totalement transparente pour l utilisateur : des exceptions sont levées lors de la communication afin d effectuer une correspondance cohérente entre le changement d état d un fil d erreur et le modèle événementiel de Java. La figure 6.3 présente un diagramme de séquence montrant une utilisation de cette interface afin de recueillir la tension aux bornes d un voltmètre numérique. Il est ici important de noter que demander la tension n a aucun sens dans le modèle GPIB. Il faut donc, pour tout modèle d appareil, mettre en correspondance les méthodes que conceptuellement tout voltmètre pourrait présenter avec le code de la chaîne de caractère à envoyer sur le bus de manière à réaliser la demande proprement dite. Ainsi, demander la tension se dira VOLT :10 :100 dans le langage de l appareil repris sur la figure. 57

6.2. L INTERFACE STANDARD IEEE 488 POUR JAVA 58 Fig. 6.1 Classes utilisées pour la mise en oeuvre d une interface de communication relative au bus GPIB

6.2. L INTERFACE STANDARD IEEE 488 POUR JAVA Fig. 6.2 Modèle d initialisation du bus GPIB en Java 59

6.2. L INTERFACE STANDARD IEEE 488 POUR JAVA Fig. 6.3 Envoi de commandes à destination de l instrument au moyen de la classe GPIB- Device 60

Chapitre 7 Utilisation de JINI dans le cadre de l instrumentation virtuelle Sommaire 7.1 Introduction............................. 61 7.2 Interfaçage des instruments de mesure............. 62 7.2.1 Interfaces standardisées....................... 62 7.2.2 Introspection dynamique des capacités des instruments...... 65 7.3 Exploitation du réseau....................... 67 7.3.1 Les domaines............................. 67 7.3.2 Instrumentation distante....................... 67 7.4 Les apports propres à Jini..................... 68 7.4.1 Robustesse.............................. 68 7.4.2 Interfaces graphiques......................... 69 7.1 Introduction Afin de montrer également que notre approche peut parfaitement s intégrer dans un environnement de prise de mesure actuel, tel que LabVIEW, nous avons réalisé une application offrant les mêmes possibilités de programmation visuelle, d interfaçage utilisateur, etc. que présentent les logiciels disponibles sur le marché. Cette application présente un module de gestion prenant entièrement en charge le bus Jini et interagissant avec celui-ci au moyen d un nombre extrêmement restreint de méthodes. Ainsi, nous montrerons que l intégration de Jini dans les solutions existantes ne requiert pas la reconversion complète ou partielle de l application et qu il est réellement envisageable de développer une sorte 61

7.2. INTERFAÇAGE DES INSTRUMENTS DE MESURE de plugin intégré à l application lui permettant de tirer avantage des futurs instruments compatibles Jini. 7.2 Interfaçage des instruments de mesure 7.2.1 Interfaces standardisées Nous avons exposé dans la première partie de ce travail le besoin d un ensemble commun d interfaces permettant de décrire et donc de posséder une connaissance a priori sur les capacités de chacun des services présents dans une architecture Jini. Nous proposons à cet effet une hiérarchie de classes propre à l instrumentation afin de représenter les possibilités de chaque appareil ainsi que la manière dont ils peuvent s organiser entre eux. Cette hiérarchie est présentée à la figure 7.1 et n est pas exhaustive, tant la diversité des appareils et des types de mesures est grande. Les possibilités de chaque appareil, relatives à son aptitude à gérer les différentes formes d ondes sont représentées à la figure 7.2. En adoptant de double modèle, basé sur une séparation des formes d ondes et des aptitudes, nous atteignons un niveau de flexibilité élevé. En effet, les possibilités de recherche s en trouvent enrichies : on pourra, par exemple, vouloir ne chercher que les instruments capables de traiter les signaux alternatif, ou visualiser tous les générateurs puis raffiner aux seuls capables de générer des formes d ondes particulières. Du point de vue informatique, il suffira que le proxy proposé par le service implémente chacune de ces interfaces. La figure 7.3 montre comment ces diverses interfaces peuvent se combiner afin de définir les possibilités d un appareil donné. Il s agit ici d un multimètre Hewlett-Packard HP34401A qui est à même de mesurer des tensions, des courants,des impédances et des fréquences dans les modes continu autant qu alternatif. De plus, il implémente une logique de déclenchement (triggering). Le HP34401A réalisera donc chacune des interfaces relatives à ces capacités car il est la réunion de toutes ces compétences. 62

7.2. INTERFAÇAGE DES INSTRUMENTS DE MESURE Fig. 7.1 Diagramme de classes pour les interfaces standardisées entre appareils 63

7.2. INTERFAÇAGE DES INSTRUMENTS DE MESURE Fig. 7.2 Diagramme de classes pour les interfaces représentant les formes d ondes que chaque appareil est à même de traiter. 64

7.2. INTERFAÇAGE DES INSTRUMENTS DE MESURE Fig. 7.3 Exemple d appareil virtuel en Java. Le comportement de l appareil est défini comme étant la réunion de chacune de ses capacités de base, menant à une réalisation multiple d interfaces. 7.2.2 Introspection dynamique des capacités des instruments Comme nous l avions déjà évoqué dans l étude théorique de l architecture Jini, le besoin de normalisation des interfaces qu implémentera chaque appareil peut être vu comme fortement limitatif et peu évolutif, ne laissant pas de place aux spécificités que chaque constructeur pourrait être désireux d implémenter. Nous allons montrer qu en réalité ces interfaces n imposent qu une ébauche des capacités mises à disposition par les services et que, quoique nécessaire lors du processus de découverte, ces interfaces ne sont pas, à notre sens, une finalité en soi. l utilisation du mécanisme d introspection inhérent à la plateforme Java conjointement utilisée avec le modèle flexible d interfaces connues pour l instrumentation nous a permis de développer un utilitaire d exploration des instruments connectés au réseau. Cet outil présente les appareils selon trois modes de classification : le type de mesures qu ils sont capables d effectuer, leur localisation ainsi que le fabriquant du senseur ou de l actuateur. Pour rappel, l introspection est un mécanisme par lequel il est possible de connaître le nom d une classe, l ensemble des interfaces qu elle implémente ainsi que les méthodes qui nous sont accessibles. Ainsi, en cherchant tous les instruments de mesure présents sur le réseau, en cherchant à connaître les interfaces que leurs proxy implantent, nous 65

7.2. INTERFAÇAGE DES INSTRUMENTS DE MESURE pouvons établir une classification sans même nous soucier des interfaces standards que nous avons évoquées : l introspection nous énumérera les interfaces implémentées. De même, l énumération des attributs venant avec le proxy pourra-t-il faire apparaître ceux qui sont relatifs à la localisation et au nom du vendeur, et nous pourrons exploiter cette information pour la construction de la vue principale de notre explorateur, présentée sous forme d un arbre (Fig. 7.4). Fig. 7.4 L utilisation de l introspection dynamique permet d offrir à l utilisateur un vue très précise et confortable de tous les appareils disponibles sur le réseau local. Enfin, nous avons pu mettre en évidence que l introspection des méthodes accessibles sur le proxy permet également de construire une interface locale pour un instrument éventuellement plus riche que celle décrite par dans l interface connue. En effet, soit la classe proxy de l appareil implémentera simplement l interface, soit elle se conformera au standard et ajoutera certains membres propres au constructeur ou la gamme d appareil. Ces membres seront découverts sur le client par introspection en cours d exécution et, s il s agit par exemple d utiliser un mode de programmation visuelle similaire à LabVIEW, on pourra aisément modifier l icône et y ajouter les connecteurs relatifs à ces méthodes. L utilisation de ce mécanisme peut s avérer relativement coûteux en temps si on se place du point de vue du traitement des données en temps réel, mais il enrichit grandement les possibilités offertes par l utilisation de Jini comparativement à d autres modèles beaucoup plus statiques et moins évolutifs. Ce dernier point pourrait donc s avérer être un avantage décisif quant à un choix à long terme pour l établissement de mécanismes de communication entre appareils à grande échelle. 66

7.3. EXPLOITATION DU RÉSEAU 7.3 Exploitation du réseau 7.3.1 Les domaines Nous avons exploité la notion de domaine contrôlé par le Lookup Service afin de propager les services fournis par les appareils à travers un réseau plus large. Rappelons que le Lookup est en service et qu à ce titre il sera détecté par les autres Lookup sur le même sous-réseau que ce premier. Ainsi, le déploiement hiérarchique au sens du réseau des machines responsable de la prise en charge du Lookup local permet de créer des connexions de bout en bout entre deux sous-réseaux voisins mais non connectés directement. Les Lookup ainsi mis en présence mettent en commun l information qu ils ont collectée sur l ensemble des services qui se sont enregistrés auprès d eux. Cette information s échange ainsi de machine en machine, pour autant que celles-ci soient en charge du même domaine et que la politique de sécurité en vigueur pour chacun des services de Lookup le permette, ce que nous a permis de constituer par propagation une infrastructure de prise de mesure à grande échelle. L intérêt d une telle technique repose également sur la robustesse qu elle engendre. En effet, si une passerelle entre deux sous-réseaux venait à tomber en panne, ou même qu un service de lookup subisse une panne, l information pourrait toujours emprunter un chemin alternatif éventuellement placé de manière redondante à cet effet. Le déploiement des domaines, loin d être simplement vu comme un mécanisme de sécurité, doit être pris en considération lors de la mise en service du réseau local basé sur Jini. Nous avons pu constater que celui-ci nous garantira ainsi une robustesse ainsi qu une flexibilité accrues. 7.3.2 Instrumentation distante Les services et clients désireux de prendre part à la communauté Jini locale se doivent dans un tout premier temps d avoir connaissance d un ou plusieurs Lookup au travers desquels ils déposeront leur proxy s ils se posent en services ou effectueront leurs recherches s ils se posent en clients. A cette fin, nous avions vu qu il existe deux techniques : la détection dynamique sur le sous-réseau local et l attribution statique. La détection dynamique se basant sur un envoi de messages encapsulés dans des paquets UDP en propagation multicast, ceux-ci seront à même de mettre en contact le service avec tout Lookup présent dans le champ accessible à de tels paquets, c est à dire au minimum le sous-réseau local. Un propagation plus étendue dépend des directives appliquées lors du passage de chaque passerelle. Celle-ci peut décider de diminuer le temps de vie du paquet (TTL : Time To Live), le supprimant lorsque ce paramètre est nul, ou bien de le filtrer ou encore de ne pas le modifier. Nous exploitons cette technique d investigation dynamique de manière à filer un tissu local d instruments sans besoin de configuration. On parlera de réseau local d instrumentation [11] [8]. Le fait de pouvoir fournir l adresse d un lookup est une vue plus statique de l interaction services-clients. Cette approche permet par exemple d utiliser les capacités d un lookup 67

7.4. LES APPORTS PROPRES À JINI situé hors du sous-réseau local et éventuellement fort distant. De nombreuses expériences d instrumentation ont pour but d exploiter les réseaux à grande échelle et plus particulièrement l Internet afin de réaliser de l instrumentation à distance [16]. Nous voyons donc que Jini, de par sa capacité d utilisation des ressources locales et globales rejoint les deux exploitations actuelles qui sont faites du réseau dans le cadre de la prise de mesure assistée par ordinateur. Jini propose ainsi une solution utilisable quel que soit le modèle de déploiement final envisagé. 7.4 Les apports propres à Jini 7.4.1 Robustesse La robustesse d un système d actuateurs ou de capteurs est primordiale, voire critique dans certains cas. Il s agit d être à même d attester à tout moment l état de bon fonctionement des appareils. Si un capteur tombe en panne, est défectueux ou si la mesure demandée ne peut s effectuer, il est impératif d avoir connaissance du problème dans un délai approprié. Jini possède un mécanisme que nous pourrions utiliser à cet effet : il s agit de la gestion des exceptions distantes (remote exceptions) et de la notion de bail du proxy (leases). La gestion des exceptions distantes nous offre la possibilité d exécuter un segment de code spécifique lorsqu une méthode activée sur un objet distant a levé une exception. Cette méthode représentant en fait une commande envoyée à l instrument, nous nous assurons ainsi que celles-ci prennent place correctement dans le processus de mesure. Cette technique traitant la problématique du client, il nous reste à envisager la partie liée au service ; à savoir la détection de la disparition de l instrument pour quelque raison que ce soit. Le service de son côté peut subir deux types de déficiences principales : la panne du réseau sur lequel il est connecté et la panne de l appareil lui-même. Nous venons de montrer que les mécanismes d exception gèrent l envoi de commandes vers le service ainsi que sa réalisation. La panne de réseau n échappe pas à ce cas de figure et toute panne du réseau sera instantanément détectée. Seule subsiste la problématique de la disparition de l appareil et donc de l invalidation de sa disponibilité pour les clients chargés de la collection des mesures. Nous proposons comme solution l exploitation du mécanisme de bail. En ajustant correctement les paramètres de fréquence de vérification et de temps maximum de vie du proxy, on peut s assurer que le départ d un appareil ne laissera pas d incohérence quant aux éléments disponibles sur le réseau. Ces paramètres étant choisis par l utilisateur, il sera possible de s appuyer sur des modèles statistiques ou des simulations afin de déterminer les valeurs critiques assurant un sécurité optimale de l ensemble de l expérimentation. Jini présente intrinsèquement tous les mécanismes nécessaires à la réalisation d un système stable et sur lequel nous sommes à même d imposer les contraintes de robustesse que nous désirons. 68

7.4. LES APPORTS PROPRES À JINI 7.4.2 Interfaces graphiques Jini est basé sur la plateforme Java et utilise abondament RMI afin, par exemple, de transporter les proxy ainsi qu éventuellement toutes les classes requises sur la machine virtuelle du client afin d exploiter les capacités de ce dernier. Un groupe de travail issu de la société Artima [1] a proposé la mise au point d une approche unifiée permettant la mise en oeuvre d interfaces graphiques issues du service. Parallèlement à cela, de nombreux logiciels livrés avec les instuments de mesure proposent la visualisation des informations sous la forme d une interface interactive semblable au panneau frontal de l appareil. Ainsi, de la même manière qu il agirait manuellement sur les boutons de l appareil, l utilisateur peut agir avec sa souris sur l interface graphique, les deux approches menant au même résultat. Nous avons combiné ces deux techniques afin de proposer des interfaces graphiques spécifiques à chaque appareil, accessibles à travers Java et Jini et issues de l appareil. L interface graphique éventuelle apparait ainsi comme un attribut de l appareil, accompagnant le proxy dans son déplacement vers le client. Le client peut alors choisir à tout moment d instancier la ou les classes constituant l interface. En réalité, seul un constructeur d interface (User Interface Factory) est couplé avec le proxy afin de ne pas avoir à instancier celle-ci du côté service, ce qui serait coûteux en ressource. Les interfaces réalisées dans le cadre de ce travail permettent par exemple de configurer les attributs secondaires de l appareil localisation, commentaire spécifique à la mesure ou de présenter le panneau avant de ce dernier. Les figures 7.5 et 7.6 présentent deux interfaces permettant de configurer un voltmètre Hewlett-Packard HP-34401A. Le projet initié par les chercheurs de chez Artima propose uniquement un ensemble d interfaces afin de rendre possible la détection de la présence d une interface graphique attribut du proxy. Ces interfaces permettent d envoyer tous les types de primitives graphiques existant dans Java : du simple panneau à intégrer dans une application jusqu à une application complète. On peut ainsi imaginer d inclure dans chaque appareil des éléments qui s insèreraient dans les applications afin de rendre compte des interactions spécifiques avec chaque type d instrument. Ces éléments graphiques étant simplement des objets distribués, ils interagissent de manière totalement transparente avec l application client s intégrant alors très aisément dans tout type d application. On pourrait même imaginer la standardisation d un ensemble d interfaces qui seraient toujours présentes, quel que soit le type d instrument, et les incorporer d office dans les futurs logiciels client utilisant Jini. 69

7.4. LES APPORTS PROPRES À JINI Fig. 7.5 L interface graphique envoyée par le service Jini permet de présenter la face avant de l appareil Fig. 7.6 La configuration de l appareil peut s effectuer à l aide de l interface qu il met à disposition, s approchant ainsi tant que possible des aspects spécifiques au constructeur. 70

Chapitre 8 Intégration de Jini dans les solutions actuelles Sommaire 8.1 Motivation.............................. 71 8.2 Implantation d une interface de programmation visuelle intégrant Jini................................... 72 8.3 Conclusions.............................. 75 8.1 Motivation Dans le premier chapitre de ce travail nous avons largement exposé les intérêts de l instrumentation virtuelle et plus particulièrement de l utilité de disposer de logiciels permettant la réalisation de programmes complexes liés au traitement du signal. Afin de réduire au maximum les difficultés que soulève la programmation d interfaces de contrôle, la technique de la programmation par fils est utilisée. Le programme se présente alors sous la forme d une interface graphique faite de fils et d icônes disposées selon le flux de traitement des informations. De nombreux logiciels mettent en oeuvre ce type de programmation mais le plus universellement adopté est sans conteste LabVIEW. Il suffit pour s en convaincre de voir la place que lui réserve les industriels ainsi que les universités dans leurs programmes de formations. LabVIEW a cet avantage qu il est un logiciel ouvert permettant à l utilisateur d incorporer ses propres routines. Celles-ci peuvent être écrites dans le langage graphique de LabVIEW (G-Programming) ou résider dans une bibliothèque de fonction écrite dans un langage tel que C ou FORTRAN. 71

8.2. IMPLANTATION D UNE INTERFACE DE PROGRAMMATION VISUELLE INTÉGRANT JINI Compte tenu de la quasi-universalité de cette approche, la réalisation d un système d instrumentation distribuée au moyen de quelque technique que ce soit, y compris Jini, se doit donc de s intégrer tant que possible dans les modèle offerts par ces logiciels. Nous tenterons de prouver dans les sections qui suivent qu il est possible d intégrer totalement Jini dans les solution existantes, tel LabVIEW, sans recourir à 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 éléments de programmation visuelle. 8.2 Implantation d une interface de programmation visuelle intégrant Jini La réalisation d une telle interface, en imposant la contrainte de ne pas avoir à repenser le logiciel existant, nous a conduit à intégrer la gestion de Jini dans un logiciel annexe, existant en parallèle du premier, et à définir un ensemble minimal de messages entre cette couche et le logiciel. Ces messages sont au nombre de deux : ajouter ou supprimer un périphérique. Le fait que le nombre de message soit très petit rend plus aisée l implantation de l adaptateur entre l application et Jini mais impose donc qu un traitement conséquent soit effectué à l interface entre le logiciel local et le réseau. L adaptateur Jini veillera à découvrir les instruments présents sur le bus, gèrera les évènement émis par les services ou le lookup et téléchargera tous les proxy des appareils afin de les mettre à disposition de l utilisateur. L introspection dynamique des classes permet de préparer les icônes, les habillant, liant chaque connecteur à une méthode particulière de l objet proxy, avant de les placer dans la boite à outils. Afin de prouver la faisabilité de ce concept, qui est crucial pour la viabilité d une solution basée sur Jini dans la cadre de l instrumentation, nous avons réalisé une application légère semblable à LabVIEW. Celle-ci est présentée à la figure 8.1 et est constitué de quatre éléments principaux : une barre de fonctions, visible sur le dessus, contenant les fonctions mises à disposition de l utilisateur. La fonction principale est un élément graphique indiquant le nombre présenté à son entrée sur un panneau ayant l apparence d un afficheur numérique à LEDs. une boite à outils, située à gauche, dans laquelle les appareils sont classés selon trois catégories : les interfaces qu ils réalisent, leurs localisations et leurs constructeurs. Cet élément est l adaptateur Jini ; celui-ci communique avec le panneau de programmation par ajout ou retrait d appareils à la demande de l utilisateur. le panneau de programmation, au centre, sur lequel l utilisateur dispose les icônes et les connecte afin de spécifier le programme de manière graphique 72

8.2. IMPLANTATION D UNE INTERFACE DE PROGRAMMATION VISUELLE INTÉGRANT JINI le panneau d affichage, en bas, qui présente les paramètres à l utilisateur. Il servira par exemple ici à afficher la tension mesurée. Fig. 8.1 L application JINILab qui présente la même interface que LabVIEW Au lancement de l application, une couche de gestion du bus Jini est instanciée en parallèle. Celle-ci s intègre dans le logiciel mettant à disposion un navigateur d instruments. Elle initie son cycle de vie par la recherche du lookup local, au moyen de paquets de propagation envoyés sur le sous-réseau, et collecte les proxy de tous les instruments présents sur le bus à cet instant. Du point de vue de l interrogation par le client que nous avons évoquée dans le chapitre relatif à Jini, il s agit de trouver tous les proxy implantant l interface générique InstrumentationDevice. Comme il s agit de l interface dont dérivent tous les instruments, nous avons l assurance que le lookup renverra l ensemble de appareils dont il a connaissance. 73

8.2. IMPLANTATION D UNE INTERFACE DE PROGRAMMATION VISUELLE INTÉGRANT JINI Commence alors un travail d introspection systématique du comportement du proxy. Nous avons choisi d en isoler les interfaces qu il implante mais également deux sous-classes de la classe Entry qu il contiendra éventuellement : les classes Location et Vendor qui permettent d avoir une connaissance de la localisation ainsi que du nom du constructeur. Le proxy est alors inséré dans les trois arbres comportement, lieu et vendeur du navigateur. L utilisateur peut décider d utiliser les fonctionalités particulières de l appareil en cliquant à droite et en accédant ainsi à un menu construit lors de la phase d introspection. Ce menu permettra d instancier, le cas échéant, une des interfaces graphiques convoyées avec le proxy, mais il permettra également de placer l icône de l instrument sur le plan de programmation. La figure 8.3 montre que l intégration de l interface de l appareil s intègre parfaitement avec le logiciel de base. Une fois l icône placée sur le bureau, il est possible de raccorder un de ses connecteur avec un élément existant du plan de programmation. Dans la cas présenté à la figure 8.4 il s agit de l entrée d un afficheur graphique présentant sur le panneau de visualisation la valeur de mise à ses bornes. Ce composant a été sélectionné dans les outils standards du logiciel présents sur la barre du haut. La valeur à présenter est obtenue en connectant au moyen d un fil l entrée de l afficheur avec la borne de prise de tension de l icône modélisant ici un multimètre Hewlett-Packard HP34401A. Notons ici que les connecteurs présentés par le composant graphique sont eux aussi créés par introspection. Il ne faut donc à aucun moment installer un quelconque gestionnaire ou ensemble d icônes particuliers pour accéder à toutes les fonctionalités offertes par l instrument. La gestion des erreurs La gestion des exceptions se fait à deux niveaux : dans le logiciel, lors de l appel d une méthode sur l objet distant et au niveau de la couche de gestion de Jini, lorsqu un évènement est propagé. les évènements propagés 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éjà connu du client. Le changement d attribut ou l apparition d un périphérique modifiera l arbre de présentation dynamique des instruments alors que la disparition d un élément du bus entrainera l envoi d un message à destination du logiciel de programmation graphique. Il s agit du message relatif au retrait d une icône de l ensemble de celles accessibles. Un message d erreur accompagnera éventuellement cette action. Dans la cas ou l activation de la méthode distante échoue, un message est produit afin d avertir l utilisateur et l expérimentation est suspendue. Comme il s agira plus que probablement d un appareil ayant subit une panne, il y a de fortes chances que cette première alerte sera suivie d un retrait de l icône, lorsque le lookup aura confirmé l invalidation du bail du proxy. A titre examplatif et pour clore cette description de notre logiciel, la figure 8.5 présente une session typique de présentation d erreur. 74

8.3. CONCLUSIONS 8.3 Conclusions L intégration de Jini dans des logiciels existants, tels LabVIEW, est cruciale pour les industriels désireux d exploiter cette technologie. Nous avons montré à partir d un exemple simple qu il est possible d adopter un modèle pour l implantation et le déploiement d une couche logicielle se greffant sur les solution existantes. Cette couche prennant en charge toute la mise en oeuvre de Jini existe en parallèle du logiciel et communique avec celui-ci au moyen d une interface extrèmement réduite. Dès lors, peu ou pas de remodélisation ou de recompilation de l application n est nécessaire pour y intégrer harmonieusement Jini. 75

8.3. CONCLUSIONS Fig. 8.2 Instanciation de l interface graphique fournie par l appareil dans le contexte de l application. Cette interface est propre à chaque périphérique est générée par l appareil sur la plateforme du programme client. 76

8.3. CONCLUSIONS Fig. 8.3 Un autre exemple de panneau frontal fourni par l appareil et qui peut être incorporé dans l application client à la demande, sans besoin d installer le moindre programme utilitaire associé au périphérique. 77

8.3. CONCLUSIONS Fig. 8.4 Réalisation d une application simple présentant la tension au bornes d un voltmètre modélisé par l icône verte. 78

8.3. CONCLUSIONS Fig. 8.5 Les exceptions lors des appels de méthodes se doivent d être gérées en Jini, assurant que l utilisateur sera informé de la moindre erreur 79

Chapitre 9 Conclusion et perspectives L intégration des instruments de mesure dans les systèmes électroniques et informatiques requiert l intervention de technologies spécifiques liées à la problématique du contrôle des appareils distants. Les moyens mis en oeuvre actuellement n offrent pas de solution globale, tant du point de vue de l intégration des réseaux, que de celui de l interaction spontanée et dynamique d appareils entre eux. Nous avons établi dans un premier temps un état de l art en la matière montrant qu aucune des technologies présentes en instrumentation ne permettait une intégration des modèles basés sur les objets. De tels modèles sont une nécessité car ils permettent une réusabilité du code accrue ainsi que l adoption d un schéma de développement hautement flexible. Les extensions de ces modèles permettant le déploiement à travers le réseau et l interaction entre objets nous a semblé la meilleure approche pour le développement d un système d instrumentation distribuée. A ce moment, le choix d un formalisme d implantation conditionne la conceptualisation des éléments clés du système. Nous avons étudié deux grandes architectures actuelles de mise en oeuvre d objets distribués : CORBA et Jini. Quoique semblables en apparence et présentant des caractéristiques comparables, l approche de Jini nous a semblé la plus appropriée au vu des besoins spécifiques de l instrumentation de terrain intégrant une composante réseau. L architecture Jini permettant le déplacement de code du service vers le client, nous avons montré que lorsqu appliquée plus particulièrement aux instruments de mesure, elle était à même de permettre la construction de systèmes distribuant la puissance de calcul entre tous les prenants parts du bus et exploitant ainsi la puissance des PC présents. La notion de gestionnaire de périphérique disparaît également à partir du moment où l ensemble des logiciels de gestion de l instrument est intégré à même ce dernier. Des interfaces élaborées et conviviales peuvent ainsi être mises à disposition par le service afin que le client puisse affecter la configuration de l appareil, sans avoir recours à la mise en oeuvre 80

d un quelconque logiciel propriétaire. Le niveau d abstraction atteint permet également d interchanger les appareils entre eux sans besoin de reconfiguration, atteignant ainsi une flexibilité inexistante actuellement. Des mécanismes de protection et de robustesse faisant directement part intégrante du modèle Jini montrent combien cette technologie va à la rencontre des prérequis de mise en oeuvre de cette technologie dans des processus critiques. La possibilité d intégration d une telle solution dans les logiciels industriels d automation et de contrôle a été demontrée par la réalisation d un logiciel de pilotage de nos instruments. Un couche de gestion propre à Jini a été développée et mise en relation avec le logiciel, montrant qu il est possible de voir l architecture Jini comme un ajout déployable à côté des grands standards industriels, tel LabVIEW. Mais nous n avons assurément pas exploité toutes les possibilités liées à Jini et au déplacement dynamique de code entre noeuds du réseau. Le fait qu un appareil présente à la fois un comportement donné mais qu il puisse fournir du code propre à sa mise en oeuvre est déjà pour le moins une approche totalement nouvelle. Il est évident qu il serait extrèmement intéressant de compléter celle-ci par l ajout de services spécifiques, existant purement sous forme de logiciels distribués. De tels réseaux seraient constitués d une part des appareils connectés à ceux-ci instruments, PC, systèmes embarqués et d autre part d agents intelligents interagissant avec les services et les client de manière à former une configuration adaptative à même de répondre aux besoins locaux. 81

Bibliographie [1] Jini forum at artima. http ://www.artima.com/jini/. [2] National instrument s site in gpib. http ://www.ni.com/gpib. [3] Remote Method Invocation Specification. [4] Site officiel de l object management group. http ://www.ni.com/gpib. [5] V. Piuri A. Ferrero. A simulation tool for virtual laboratory expirements in a www environement. IEEE Transactions on Instrumentation and Measurement, 48(3), 1999. [6] S. Deering. Ieee-488 general purpose instrumentation bus manual. Technical report, Anthony J. Caristi, Feb. 1989. [7] B.E. Segee D.J. Rawnsley, D.M. Hummels. A virtual instrument bus using network programming. volume vol.1. [8] M. Dunbar. Plug-and-play sensors in wrireless networks. IEEE Instrumentation and Measurement Magazine, March 2001. [9] W. Keith Edwards. Core Jini 2nd edition. Java Series. second edition edition, 2001. [10] UPNP Forum. Universal Plug and Play Device Architecture, 8 June 2000. http ://www.upnp.org/download/upnpda10 20000613.htm. [11] L. Nigro G. Fortino, D. Grimaldi. Multicast control of mobile measurement systems. IEEE Transactions on Instrumentation and Measurement, 47(5), 1998. [12] Ben Brosgol Peter Dibble Steve Furr David Hardin Mark Turnbull Greg Bollella, James Gosling. The Real-Time Specification for Java. Addison Wesley, 2001. [13] Guy Steele Gilad Bracha James Gosling, Bill Joy. The Java Language Specification, Second Edition. Addison Wesley, 2001. [14] Troy Downing Jon Meyer. The Java Virtual Machine. O Reilly, 1997. [15] R. D. Shneeman K. B. Lee. Distributed measurement and control based on the ieee1451 smart tranducer interface standards. IEEE Transactions on Instrumentation and Measurement, 49(3), 2000. [16] F. Ferraris A. Ferrero C. Offeli M. Parvis V. Piuri L. Benetazzo, M. Bertocco. A web-based distributed virtual educational laboratory. IEEE Transactions on Instrumentation and Measurement, 49(2), 2000. [17] V. Piuri L. Cristaldi, A. Ferrero. Programmable instruments, virtual instruments and distributed measurement systems. IEEE Instrumentation and Measurement magazine. 82

BIBLIOGRAPHIE [18] Sing Li. Professional Jini. Programmer to Programmer. first edition edition, 2001. [19] Sheng Liang. The Java Native Interface Specification. Addison Wesley, 1999. [20] Jan Newmarch. Jan Newmarch s Guide to JINI Technologies, 26 August 2000. http ://pandonia.canberra.edu.au/java/jini/tutorial/jini.xml. [21] F. Cennamo P. Daponte P. Arpaia, A. Baccigaluppi. A distributed laboratory based on geographic network. [22] P. Daponte P. Arpaia, F. Cennamo and M. Savastano. A distributed measurement laboratory based on object oriented systems. [23] D. Grimaldi P. Daponte and L. Nigro. Distributed measurement systems : An object oriented architecture and a case study. Computer Standards Interfaces, 18(5). [24] Dan Harkey Robert Orfali. Client Server programming with Java and CORBA. Wiley Computing, 1998. [25] Jon Siegel. CORBA : Fundamentals and programming. Wiley Computing, 1996. [26] H. J. W. Spoedler. Virtual instruments and virtual environements. IEEE. Instrum. Meas. Mag., 2. [27] William A. Ruh Thomas J. Mowbray. Inside CORBA. Addison Wesley, 1997. 83