Conception et réalisation d'un syst`eme d'instrumentation ... - CoDE

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
Piggyback
Cables
Talk, Listen
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.
2.2.1 IDL
Client Server
Server Object Reference
getVoltage() method
ORB ORB
IIOP
Server Object
Implémentation
Fig. 2.1 – Éléments de base d’une architecture CORBA
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
A cat instance
Animal
Cat
Client Server
Marshalling Marshalling
Client
Dynamic Stub Invocation
ORB
HTTP upload of
Cat’ s class bytecode
RMIbus RMIbus
IIOP
Server
Dynamic Skeleton Invocation
ORB
A cat instance
Cat
An Animal Instance
Animal
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
Web server
Server Object
Client Virtual Machine Server Virtual Machine
Client
Web server
Server’ s Stub
Aks for location of the Stub
Server Object
RmiRegistry
Web server
RmiRegistry
Web server
Server’ s Stub
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
Provider
discovery discovery
Lookup
Service
Consumer
announcement announcement
L
Fig. 4.1 – Découverte du Lookup par les Clients et les Services.
Consumer Provider
Lookup
Service
Consumer
L L
L
register
Lookup
Service
Provider
discovery discovery
Lookup
Service
Consumer
announcement
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
announcement
L L
lookup
L
register
Lookup
Service
Provider
discovery discovery
Lookup
Service
Consumer
announcement
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
announcement
lookup
discovery
3
S
event
usage
usage
4
2
register
register
Lookup
Service
Provider
Lookup
Service
Consumer
discovery
1
announcement
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 Provider
Lookup
Service
Consumer
lookup
discovery
L
unregister
Lookup
Service
Provider
Lookup
Service
Consumer
discovery
Fig. 4.5 – Le service annonce son intention de quitter
Consumer L usage Provider
Lookup
Service
Consumer
announcement
lookup
discovery
S
event
register
Lookup
Service
Provider
Lookup
Service
Consumer
discovery
announcement
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
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
lookup
discovery
S
event
usage
???
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