V. APPLICATION CLIENTE. MobileRobots MobileEyes, MobileSim, Mapper 3Basic, PeopleBot

V. APPLICATION CLIENTE

Comme je l'ai déjà dit plus haut, le comportement du robot est de type Client/Serveur. Il est donc possible de commander le robot à partir d'une application cliente.

Cette application peut être lancée à partir d'un poste client, ou directement à partir du système d'exploitation embarqué. Il également envisageable d'avoir une structure mixte dans laquelle nous avons 2 applications clientes, l'une sur un poste distant et l'autre sur le robot, communicante entre elles et gérant des fonctionnalités différentes du robot.

1) ARIA

Pour réaliser cette application, on dispose d'un environnement de développement Open-

Source nommé Aria (Activmedia Robotic Interface for Applications) qui permet de créer une interface efficace avec le robot et ses accessoires.

La librairie qu'elle contient est codée en langage C++. Il est cependant possible de programmer en d'autres langages tel que Java ou Python.

En plus de gérer les commandes du robot, la librairie Aria dispose également de différents classes génériques sur la gestions des sockets, des threads, etc...Ces classes génériques reposent sur des fonctions répondant à la norme POSIX : les programmes développés à partir de ces classes pourront donc être indifféremment compilés sous Linux que sous Microsoft Windows.

La librairie ARIA est "open source", autrement dit elle est livrée avec l'ensemble des sources qui ont permis de la créer. Il est donc possible de modifier une de ses sources, ou même de rajouter une classe, puis de recompiler la librairie.

2) CYCLE DE FONCTIONNEMENT

A) Principe

L'application cliente développée avec Aria exécute un cycle de fonctionnement, autrement dit un ensemble de processus qu'elle lance les uns à la suite des autres de façon synchrone.

En effet, comme le montre le schéma ci-contre, il est à noter que la récupération, l'interprétation et la restitution des mesures à l'application cliente font partie intégrante du cycle.

Ainsi, si une tâche synchrone, une fonction ou une boucle, bloquent le cycle, alors l'application n'est plus renseignée des changements éventuels des mesures des capteurs. (Cf TP

Commande de la Pince)

B) Déclenchement

Par défaut, ce cycle est déclenché à chaque fois que l'application reçoit un SIP (Server Information Packet, c'est-àdire l'ensemble des données provenant des capteurs) de la part du robot. L'application possède également son propre temps de cycle (100 ms par défaut) : si au bout de 2 temps de cycle, aucun paquet n'est arrivé du robot, alors elle relance le cycle automatiquement.

Ce procédé permet d'effectuer les actions désirés sur le robot ou un de ces périphériques en temps réel, autrement dit en fonction des informations les plus récentes envoyées par les capteurs.

C) Modes de Fonctionnement

Le cycle peut être lancé soit de façon synchrone (ArRobot::run()), ou en tant que nouvelle tâche de fond (ArRobot::runAsync()). Dans les deux cas, le cycle est arrêté par la méthode

ArRobot::stopRunning()).

De plus, le cycle peut très bien fonctionner sans se connecter au robot (Cf TP Pointeur de

fonction). Dans ce cas, le cycle n'est déclenché que par le temps de cycle propre à l'application.

On peut enfin forcer le robot à n'exécuter le cycle qu'une seule fois, en sachant que l'on ne pourra alors récupérer et utiliser les valeurs des capteurs.

Utiliser le cycle de fonctionnement est la façon la plus simple pour créer une application

3) DEPLACEMENTS

On peut considérer qu'il y a 3 méthodes différentes pour gérer les déplacements :

– par décomposition des mouvements,

– suivi de lignes de couleur,

– par position.

A) Décomposition des mouvements

On peut décomposer les déplacements mouvement par mouvement.

On peut en effet faire avancer ou reculer le robot d'une distance précisé en millimètres. On peut également modifier l'orientation du robot exprimée en degrés.

Pour cela, la classe ArRobot dispose de plusieurs méthodes qui autorisent une gestion simple et basique des mouvements.

B) Suivi de lignes de couleur

Grâce à sa caméra embarquée, le robot est capable de suivre de façon autonome des lignes de couleur tracées au sol.

Pour plus de précision, se reporter au Chapitre IV.

C) Positions

Il est possible de faire déplacer le robot d'une position à une autre.

Les positions, définies par leur ordonnées, abscisses et orientations, peuvent être déterminées de façon absolue ou relative.

Pour la position absolue, la position initiale du robot est pris comme point de référence. La position courante du courant est alors calculée à partir de cette position à l'origine.

Quant à la position relative, la position courante est calculée par rapport à la position précédente.

4) ACTIONS

A) Principe

Les actions permettent de pouvoir contrôler les déplacements du robot en fonction de son environnement. En effet, chaque action stipule le comportement que doit avoir le robot à un instant t selon les valeurs des capteurs reçues.

En pratique, une action est une classe dérivée de la classe ArAction. Une fois les spécifications de l'action implémentée dans la méthode virtuelle fire(), l'action est rajoutée au cycle de fonctionnement de l'application par la méthode addAction() de la classe ArRobot.

A l'intérieur d'un cycle, une action est spécifiée par un nom unique, sous la forme d'une

chaîne de caractères, et un ordre de priorité, de 0 à 100.

Bien entendu, on peut ajouter plusieurs actions dans un même cycle, chaque action décrivant une réponse à une situation différente (suivi d'un itinéraire, bloquage des roues, évitement d'un obstacle...).

Cependant, pour être prise en compte dans le cycle, l'ensemble des actions doit être ajouté avant le démarrage du cycle. On peut alors désactiver une action inutile (méthode deactivate() de la classe ArAction) pour la réactiver par la suite (méthode activate()) lorsque la situation l'exigera.

B) Types d'actions

On peut distinguer trois types d'actions, bien qu'il n'existe pas de classes pour les différencier :

–

–

– les actions de mouvements, les actions de limitations, les actions mixtes.

Les actions de mouvements stipulent les paramètres des mouvements à adopter pour atteindre un but précis : suivre une ligne, aller à un point précis...

A l'inverse, les actions de limitations assurent quant à elles la sécurité du robot en fixant des limites aux mouvements, évitant ainsi des collisions ou des accélérations et décélération trop brusques.

Enfin, les actions mixtes, généralement plus efficace, permettent de définir une trajectoire à adopter tout en s'assurant de la sécurité du robot.

Il est recommandé d'allouer une priorité plus élevé aux actions de limitations afin de s'assurer qu'un mouvement est sans risque avant de l'effectuer.

C) Action désirée

Tout changement que l'on souhaite dans les déplacements du robot se traduit en pratique par la modification des paramètres contenus dans la classe ArActionDesired, qui sont ensuite transmis au robot.

Parmi ces paramètres, on trouve :

– la vitesse ;

– le cap relatif (delta heading), c'est-à-dire l'angle entre la position actuelle du robot et la position désirée ;

– le cap absolu (heading), c'est-à-dire l'angle entre la position initiale du robot et la position désirée ;

–

–

– la vitesse maximum en marche avant ; la vitesse maximum en marche arrière ; la vitesse maximum en rotation.

D) Asservissements

Afin de contrôler que ces paramètres soient bien respectés, le robot dispose d'un PID interne pour assurer l'asservissement en translation et en rotation du robot.

Les paramètres du PID peuvent être modifiés par l'envoi de paquets de commandes.

E) Actions prédéfinies

La librairie ARIA propose initialement une série d'actions prédéfinies que l'on peut utilisées en l'état et dont voici une liste non exhaustive :

ArActionAvoidFront/ArActionAvoidSide. : évitement d'un obstacle frontal ou latéral.

ArActionColorFollow : déplacement du robot vers une couleur située dans son champ de vision.

ArActionGoto : déplacement du robot vers une position pré-établie

ArActionRecover : série de tentatives effectuées lors du bloquage d'une des roues.

ArActionStop : arrêt du robot

Bien que souvent rudimentaires, ces actions constituent un bon exemple de la création et l'utilisation des actions.

5) TACHES UTILISATEURS

A) Principe

Autant les actions servent à effectuer une tâche rudimentaire correspondant à une situation donnée, les tâches utilisateurs permettent d'effectuer les modifications nécessaires au comportement du robot, de façon à effectuer une tâche complexe. Par exemple : récupérer un objet et le rapporter.

La modification du comportement du robot se traduit simplement par l'activation et la désactivation des actions appropriées.

Il est possible d'ailleurs de définir plusieurs tâches utilisateurs, chacune d'elles pourra ainsi correspondre à un cas d'utilisation, principal ou secondaire du système.

Ainsi, c'est en général à l'intérieur des tâches utilisateurs que sera contenu le squelette de l'application.

B) Intégration dans le cycle

A l'instar des actions, les tâches utilisateurs doivent être intégrées dans le cycle, par la méthode addUserTask() de la classe ArRobot. Elles possèdent également un nom unique ainsi qu'un priorité.

Le fait qu'une tâche utilisateur soit incorporée au cycle présente quelques contraintes : en effet, au lieu d'être exécutée de façon linéaire comme cela se passe traditionnellement pour toute application, la tâche est relancé à chaque redémarrage du cycle, soit environ toutes les 100 ms.

De ce fait, pour qu'une tâche puisse conserver une valeur d'un cycle sur l'autre, il faut impérativement que la variable soit globale, ou – de façon plus élégante – que la tâche et la variable soit une méthode et un attribut d'une même classe.

Pour cette même raison, il faut s'assurer que la tâche n'initialise qu'une seule et unique fois ses variables, sinon elles seront réinitialisées à chaque cycle.

Enfin, les tâches utilisateurs ne disposent pas comme les actions des méthodes activate() et

deactivate() : il est donc impossible de les désactiver une fois placées dans le cycle. Dès lors, il faut veiller à « neutraliser » une tâche si celle-ci n'est plus ou pas encore utile.

C) Automate à Etats Finis

Définition.

Une des solutions possibles pour décrire un cas d'utilisation dans une tâche utilisateur est de définir le système comme un automate à états finis.

Un automate (ou machine) à états finis permet de décrire simplement le comportement d'un système en le décomposant en un nombre fini d'états distincts, reliés entre eux par des transitions.

Les transitions peuvent éventuellement être soumis à une condition évaluée : position atteinte, réception d'un signal...

Chaque état peut correspondre alors à un ensemble d'activités afin d'atteindre un ou plusieurs objectifs (atteindre une position, démarré un système...), ou à un état précis du système

(système en veille ou arrêter).

On notera qu'il est primordiale d'avoir un et un seul état initial, généralement définis dans le constructeurs de la classe. En revanche, il est tout à fait possible d'avoir plusieurs états finaux.

.

Représentation.

Le diagramme UML d'états/transitions est, avec le réseau de Pétri, un diagramme qui permet de représenter au mieux un automate à états finis.

Etats particuliers.

Certains états sont à remarqués plus particulièrement, du fait de leur utilité et de leur présence récurrente dans les automates à états finis :

–

–

–

– l'état INIT : état dans lequel se fait l'initialisation des variables nécessaires à la tâche, l'état PAUSE : état qui permet de neutraliser la tâche jusqu'à son activation, l'état FIN : état qui stipule que le but de la tâche est accompli, l'état ERREUR : état qui indique que la tâche n'a pu se dérouler normalement.

Les états INIT ou PAUSE pourront l'un ou l'autre constituer l'état initial de l'automate à états finis. De même, l'automate pourra avoir les états FIN et ERREURS comme états finaux.

Implémentation.

Pour implémenter une tâche en utilisant le principe d'un automate à états finis, on a besoin de 2 éléments :

–

– une variable statut qui conservera l'état actuel de la tâche ; une structure conditionnelle de type switch, qui, à chaque lancement de la tâche, exécute le code associé à l'état actuel du système.

Exemple : void MaTache()

{

//Condition sur l'état

switch(statut)

{

case INIT : //Initialisation des paramètres

break;

case TACHE_EN_COURS : //code pour satisfaire la tâche à accomplir

break;

}

}

L'ensemble des états possibles pourra être énuméré dans une variable de type enum, ou défini comme constantes grâce au mot clés #define. (La seconde possibilité est à préférée si cette liste d'états est vouée à s'agrandir.)

Exemple : enum état {INIT, PAUSE,ERREUR}

ou

#define INIT 0

#define PAUSE 1

#define ERREUR 2

Structures Multitâche

Lorsque l'on décompose l'application en plusieurs tâches utilisateurs, il existe 3 structures possibles pour les implémenter (la liste suivante est non-exhaustive) :

– structure parallèle,

– structure hiérarchique,

– structure mixte.

Dans une structure parallèle, les tâches sont toutes actives et utilisent la même variable

statut. Ainsi, la modification de la variable par une des tâches à une incidence sur les autres tâches.

Cette structure peut par exemple permettre de décomposer la tâche en plusieurs tâches au rôle bien précis, une tâche correspondant à un et un seul état. (dans ce cas, la structure conditionnelle switch peut être remplacée par une simple structure if.)

Un exemple est donné dans le TP Commande de la pince d'un robot. Dans ce TP, toutes les tâches sont en fait les méthodes d'un même objet et partagent le même attribut statut.

Dans une structure hiérarchique, seule la tâche principale est toujours active, et peut, selon la situation, activer ou désactiver des tâches secondaires. Dans ce cas, chaque tâche possède une variable statut propre, indépendante des autres. Cette structure peut permettre de décomposer le système en cas ou sous-cas d'utilisation.

La librairie Aria ne proposant des fonctions pour activer ou désactiver une tâche utilisateur, on utilisera un état PAUSE durant laquelle la tâche n'a aucune activité. (Pour les tâches secondaires, l'état PAUSE sera généralement l'état initial.)

En revanche, il faut prévoir des fonctions qui permettent à la tâche principale de gérer ses tâches secondaires : activer, désactiver, savoir si le but de la tâche est atteint...

Le diagramme ci-dessus est une représentation possible d'une application structurée hiérarchiquement, avec une tâche principale et une tâche secondaire. On peut ainsi voir que chaque tâche possède sa propre variable d'état, qui évolue donc de façon différente.

Les flèches en pointillés représentent les différentes interactions entre les 2 tâches et les termes en italique les conditions nécessaires pour que la transition s'opère.

Ces interactions permettent de montrer de quelle façon la tâche principale est en mesure de contrôler la tâche secondaire. Il est à noter que dans cet exemple, la tâche principale est en attente

de la fin de la tâche secondaire. Or, du fait de leur exécution en parallèle, il est également envisageable que la tâche principale puisse continuer de réaliser d'autres activités pendant que se déroule la tâche secondaire.

D'autre part, ce diagramme ne représente qu'une seule tâche secondaire, mais on pourrait concevoir des structures plus complexes avec plusieurs tâches secondaires : ces tâches pourraient

être activées les unes après les autres ou simultanément, ou bien même appelées par une autre tâche secondaire.

Ce diagramme montre enfin un bon exemple de tâche que l'on peut appelé plusieurs fois lors d'une même exécution. En effet, on peut constater que l'évolution de l'état de la tâche secondaire est cyclique et permet ainsi d'être à nouveau activée après s'être terminée une première fois. Il est alors possible de créer des fonctions qui modifient les paramètres de la tâche entre deux activations : modification de la position, du niveau à atteindre...

En dernier lieu, on peut avoir une structure mixte avec une tâche principale et des tâches secondaires, qui seront ensuite elles-mêmes décomposées en tâches parallèles.

6) COMMUNICATION TCP/IP

A) Pont TCP/Série

Les communications avec ARCOS se font par défaut via le port série, qu'il soit externe ou bien interne.

Ainsi, si une application cliente veut communiquer avec

ARCOS via le protocole TCP/IP, elle est obligée de passer par un pont logiciel entre TCP/IP et le port série.

La librairie ARIA fournit à ces fins, dans le répertoire

/usr/local/Aria/examples, le code de l'application IPTHRU, application qui se comporte en serveur TCP et retransmet les informations reçus sur le port série interne. Cette application n'est pas lancée par défaut au démarrage du robot, et doit donc être lancée manuellement ou rajoutée à inetd.

Le port par défaut est 8101.

B) Choix du protocole de Transport

La librairie ARIA propose les 2 protocoles UDP et TCP comme protocoles de la couche

Transport, le protocole TCP étant par défaut.

Cependant, le protocole TCP n'est pas forcément le plus adapté pour une application temps réel. En effet, les QoS proposées par TCP ont pour conséquence un ralentissement dans la transmission.

Par exemple, si un paquet est perdu (ce qui n'est pas forcément important dans l'application cliente), le protocole TCP va alors redemander ce paquet. Or le temps de le redemander et que le paquet soit ré-acheminé, les valeurs qu'il contient sont peut-être devenues obsolètes.

En revanche, le protocole UDP qui ne propose aucune QoS, est de fait plus rapide.

Néanmoins, ce protocole n'assure pas l'ordonnancement des paquets transmis. Ce problème peut se produire lorsque les paquets sont acheminés via Internet et transitent par des serveurs différents.

Dans le cas d'un réseau local, le problème ne se pose.

Si on souhaite toutefois utiliser le protocole UDP au travers d'Internet, il est possible le protocole RTP (Real-time Transfert Protocole) situé sur la couche Session. Ce protocole, utilisé pour la transmission temps réel de sons et de vidéos, permet le séquencement des paquets et d'y ajouter un marqueur temporel.

7) COMPILATION

A) Compilation sous LINUX

Sous Linux, il est possible de compiler un projet grâce au compilateur g++ ou gcc. Il faut veiller à la compilation de bien préciser l'emplacement de la bibliothèque Aria, notamment lors de l'édition de liens.

Voici un exemple de fichier Makefile, permettant de compiler un projet basé sur la librairie

Aria :

%: %.cpp Robot.o CommandePince.o

g++ -g -Wall -D_REENTRANT -fno-exceptions -Iinclude Robot.o

CommandePince.o -o $@ $< -L/usr/local/Aria/lib -lAria -lpthread -ldl

Robot.o: Robot.cpp Robot.h

g++ -g -Wall -D_REENTRANT -fno-exceptions -Iinclude -c Robot.cpp

CommandePince.o : CommandePince.cpp CommandePince.h

g++ -g -Wall -D_REENTRANT -fno-exceptions -Iinclude -c CommandePince.cpp

Le projet de cet exemple comprend un fichier principal - où se trouve la fonction main() - fichier qui fait lui-même référence deux « include » : Robot.cpp et CommandePince.cpp

Dans ce fichier MakeFile, le nom du fichier principal n'est pas précisé (remplacé par le symbole %), ce qui permet de le choisir librement. Pour compiler, on doit alors exécuter l'instruction make nom_pgme, où nom_pgme est le nom du fichier sans l'extension.

Ex: > make Client

Les instructions de compilation, basées sur le compilateur g++, s'exécutent après vérification que les fichiers aient subis des modifications depuis la dernière compilation.

Le paramètre -Iinclude permet d'inclure les fichiers contenu dans le dossier include, alors que les paramètres -L/usr/local/Aria/lib -lAria permettent d'établir le lien avec la librairie Aria.lib situé dans le répertoire /usr/local/Aria/lib.

B) Compilation sous MICROSOFT WINDOWS

Microsoft Visual C++ .NET 2003

Pour pouvoir compiler un projet se servant de la librairie Aria, il est indispensable que le projet soit correctement configuré :

Créer tout d'abord un nouveau projet (File->New->Project...) en choisissant "Console

Application".

Aller modifier les propriétés en allant dans Project->Properties.

Dans le champ "Configuration" (en haut à gauche), choisir "All Configurations".

Cliquer sur "Linker"

Dans la section "General", au niveau de "Additional Librairy Directories", ajouter le chemin de la librairie Aria (C:\Program Files\ARIA 2.4-0\lib).

Dans la section "Input", dans "Additionnal Dependancies", ajouter les librairies suivantes :

"Aria.lib winmm.lib wsock32.lib"

Cliquer sur C/C++

Dans la section "General", au niveau de "Additional Include Directories", ajouter le chemin du fichier Aria.h (C:\Program Files\ARIA 2.4-0\include).

Dans la section "Precompiled Headers", au niveau de "Create/Use Precompiled Header", choisir "Not Using Precompiled Headers".

Aller à la section "Code Generation".

Changer le champ "Configuration" sur "Debug", puis à la rubrique "RunTime Librairy", choisir "Multi-threaded Debug".

Changer à nouveau le champ "Configuration" sur "Release", puis à la rubrique "RunTime

Librairy", choisir "Multi-threaded".

Microsoft Visual C++ EXPRESS 2005

Le compilateur Microsoft Visual C++ EXPRESS 2005 a comme avantage par rapport à la version précédente d'être en téléchargement gratuit pendant un an. En contrepartie, il ne gère ni les

MFC et ni les ATL, et ne dispose pas de la plate-forme SDK par défaut. (Celle-ci peut cependant

être installer séparément.)

Ainsi, la configuration du compilateur est la même que la précédente mais avec la nécessité de rajouter les chemins pour la libraire SDK.

Dans la section "C/C++ → General", au niveau de "Additional Include Directories", ajouter le chemin C:\Program Files\Microsoft SDK\include.

Dans la section "Linker → General", au niveau de "Additional Librairy Directories", ajouter le chemin C:\Program Files\Microsoft SDK\Lib.

Si vous compiler, vous pouvez apercevoir des warnings provenant de la librairie Aria. On peut en éliminer un bon nombre en ajoutant en début du programme la définition suivante :

#define _CRT_SECURE_NO_DEPRECATE

C) Compilation de la bibliothèque dynamique.

Etant donné que la librairie Aria.dll est open source, il est possible de recompiler entièrement la librairie.

Ceci peut se révéler utile en cas de modifications d'une partie du code ou de l'adaptation de la librairie au système d'exploitation.

8) JAVA

Comme je l'ai déjà précisé, il est possible d'utiliser ARIA sous différents langages de programmation - et notamment sous JAVA.

A) JNI

Pour pouvoir utiliser la librairie ARIA codée en C++ à l'intérieur d'une application JAVA, les développeurs ont utilisé la technologie JNI (JAVA Native Interface).

Grâce à JNI, il est possible d'appeler des méthodes dites "natives" codée en C++ à partir de prototype JAVA. Ceci permet de développer en JAVA, et de coder certaines méthodes en C++ quand ce langage se trouve être le plus adapté (programmation bas niveau, temps réel...). En contre partie, le code JAVA généré dépend maintenant du code C++ et perd en portabilité. (On risque de trouver ainsi des dysfonctionnements si on désire développer une applet reposant sur la librairie

ARIA.)

Il est cependant à noter que la librairie sous JAVA n'est pas autant testé que celle sous C++, et donc que des erreurs peuvent être générées par la librairie.

B) Limitation

Il est à noter que l'utilisation de JNI entraîne une perte de certaines caractéristiques de la librairie ARIA. En outre, il n'est pas possible de surcharger en JAVA les méthodes virtuelles.

Ceci a pour conséquence l'impossibilité de créer de nouvelles actions à partir de la classe

ArAction. Si cette création est cependant nécessaire, il faut créer cette nouvelle classe en C++, l'incorporer à la librairie et générer enfin son interface JAVA.

C) Compilation

Pour la compilation en Java, on peut tout simplement utiliser l'environnement Java 2 SDK

(Standard Edition version 1.4.2), disponible sous Linux ou Windows et développé par Sun

Microsystems (TM).

Ce kit de développement propose un compilateur un mode lignes de commande :

– le programme java permet de transformer les classes en fichiers objets ;

– le programme javac quant à lui, réalise un exécutable à partir des fichiers objets.

9) CREATION D'UNE IHM

Bien que ce soit un langage rapide, adapté aux applications matérielles, le langage C++ ne permet de créer facilement une Interface Homme-Machine ergonomique.

Cependant, il est possible de réaliser des ponts entre l'application cliente destinée à commander le robot et une IHM écrite dans un autre langage, plus adapté à la création d'interfaces.

A) Les pages Web dynamiques

Le langage de présentation HTML (HyperText MetaLanguage) a été initialement créé pour réaliser facilement des pages, consultables sur Internet et pouvant recevoir des contenus variés : textes, images, sons, vidéos...Ces pages se trouvent sur un serveur HTTP et sont par conséquent accessibles par tout ordinateur situé sur le même réseau.

Le langage interprété PHP (Preprocessor ) permet, quant à lui, de récupérer et de traiter les informations envoyées depuis un formulaire HTML, de les transmettre à l'application cliente, puis de modifier les pages HTML en fonction des informations retournées par l'application.

De plus les programme PHP dispose de modules efficaces pour dialoguer avec une base de données (MySQL par exemple) afin de stocker certains paramètres ainsi que les échanges entre l'IHM et l'application cliente.

B) Un interface JAVA

Il ne s'agit plus d'écrire tout le programme en JAVA comme au paragraphe V.8, mais uniquement l'IHM, le coeur de l'application cliente demeurant en C++. Nous créons ainsi une application répartie, en utilisons dans chaque domaine le langage de programmation le plus adapté :

C++ pour la partie matérielle, JAVA pour l'IHM.

Le problème réside à présent dans le dialogue bi-directionnnel entre deux applicatifs, écrits dans deux langages différents. La solution que je propose est d'utiliser un middleware (de middle = milieu et software = logiciel), un logiciel intermédiaire entre deux processus.

CORBA

Créé par l'OMG (également inventeur de l'UML), CORBA (Common Object Request

Broker Architecture) est un middleware qui permet de créer des objets distribués entre plusieurs applications, écrits en langages différents et/ou s'exécutant sous des environnements différents.

CORBA repose sur une architecture Client/Serveur : le serveur instancie un ou plusieurs objets, puis les met à la disposition d'applications clientes au travers d'un ORB (Object Request

Broker). Les clients peuvent donc se connecter à l'ORB et faire ensuite appel aux méthodes de l'objets.

Cette technologie a été normalisée, et par conséquent, toutes les bibliothèques (gratuites et payantes) qui l'implémentent sont compatibles entre elles. Pour preuve, on peut utiliser dans notre cas le compilateur IDL fourni avec le Java SDK 2, et pour la partie C++ l'ORB gratuit MICO.

IDL

Le langage IDL (Interface Definition Language) est, comme son nom l'indique, un langage permettant de définir l'interface qui sera utilisé par la partie cliente et implémentée par la partie serveur;

En effet, pour que le client connaisse les méthodes susceptibles d'être appeler pour un objet considérer, ces méthodes doivent être au préalable définies dans une interface. Les méthodes appelées étant exécutées côté serveur, le serveur se doit d'implémenter la classe selon l'interface définie.

Le schéma ci-dessous montre les différentes étapes à réaliser pour créer une application répartie entre un serveur en C++ et un client en JAVA, tous deux utilisant un même objet :