République Algérienne Démocratique et Populaire
Ministère de l’Enseignement Supérieur et de la Recherche Scientifique
Université AMAR TELIDJI Laghouat
FACULTE DES SCIENCES ET DE L’INGENIERIE
DEPARTEMENT DE GENIE INFORMATIQUE
Mémoire de fin d’études
Pour l’obtention du diplôme d’ingénieur d’état en informatique
Option : Systèmes Parallèles et Distribués (SPD)
Thème :
Étude et réalisation d’une application de
contrôle d’un PC à distance en
Réalisé par :
BENYAMI Bachir
HASSANI Mustapha
Suivi par :
Mr. BENSAAD Mohamed Lahcen
N° d'ordre; ….. 2008-PFD / DGI

Remerciements
Nous tenons à remercier en premier lieu notre Dieu qui nous a
donné la santé, la force et le courage pour mener à bien l’étude et
l'implémentation de ce projet.
Aussi, Nous remercions chaleureusement nos parents, qui nous
ont beaucoup aidé matériellement et moralement, depuis notre enfance
et jusqu’à ce que nous sommes arrivés à ce point là. Sans oublier aussi
nos sœurs, nos frères et nos familles.
Nous tenons à remercier notre encadreur Mr. Mohamed Lahcen
BENSAAD pour son dévouement et la confiance qu’il nous a accordé
pour la réalisation de ce travail. Sa persévérance, son enthousiasme et
sa générosité nous ont été d’un grand soutien dans notre travail.
Nous tenons à remercier tous nos enseignants qui ont contribué à
notre formation, particulièrement Mr. Youcef OUINTEN, Mr. Kamel
BOUKHALFA, Mr. Taher ALLAOUI.
Nous remercions le président du jury Mr. LAGRAA Nacereddine
et l'examinatrice Mademoiselle BELABASSI Amel pour leurs acceptation
d'examiner ce mémoire.
Nous tenons enfin à remercier toutes les personnes qui nous ont
aidé de prés ou de loin à compléter ce travail notamment Mr. Yacine
DOUAG et Toufik FEKHAR qui nous ont aidé dans la phase du test du
jrdesktop sur Internet.
Ce travail est dédié à la mémoire de notre ami Bachir KERROUCHI.

Résumé
Un des plus grands challenges de cette décennie est sans aucun doute le bureau distant car il
s’articule autour de plusieurs points notamment le contrôle, la maintenance, la sécurité et
l’évolutivité. Ces différents points montrent l'importance du contrôle à distance dans un réseau
étendu composé de plusieurs réseaux locaux. Au niveau professionnel, le bureau à distance paraît
un outil indispensable pour maintenir la rapidité, l'efficacité et la sécurité d'un réseau étendu. Le but
de ce projet de fin d’étude est de concevoir et de réaliser une application de bureau à distance pour
des diverses utilisations qui s exécutent à distance via le réseau local ou mondial tel que la
télémaintenance, la téléintervention et la formation à distance, etc. Pour ce faire, nous découpons
l'architecture conceptuelle de notre système en quatre volets majeurs. Le bureau distant représente
le premier volet fournissant une étude générale sur la description, le fonctionnement, la mise en
place et les domaines d’utilisation. Le second volet concerne le langage de programmation Java,
ainsi les outils et les technologies qu’on a utilisés durant la réalisation de notre application. Le
troisième volet est consacré à la description, la conception et l’implémentation de notre système
surnommé « jrdesktop » en utilisant le langage de modélisation UML. Le dernier volet assure le
déploiement du système conçu, dont on montre la vue générale de l’IHM et comment utiliser le
système, on montre aussi une étude de qualité du logiciel, ainsi des tests et les résultats de ces tests
qui ont été faits sur le transfert des données entre le contrôleur et le contrôlé. On finit par
représenter une vue générale sur les sites web qui ont publié notre logiciel et des statistiques de
téléchargement de notre application hébergée sur le site web de jrdesktop.sourceforge.net.
Mots clés : Bureau distant, VNC, RDP, RMI, SSL, jrdesktop

Abstract
One of the biggest challenges of this decade is undoubtedly the remote desktop because it
revolves around several points in particular control, maintenance, safety and evolutionary. These
various points show the importance of remote control in a wide area network composed of several
local area networks. At the professional level, the remote desktop seems an indispensable tool for
maintaining the speed, efficiency and safety of a wide area network. The aim of this final project
study is to conceive and implement an application of remote desktop for various uses that are made
remotely via the local network or wide such as remote maintenance, the intervention at a distance
and training distance, etc To do this, we cut conceptual architecture of our system into four major
parts. The remote desktop represents the first phase providing a general study on the description,
operation, establishment and the fields of use. The second part concerns the Java programming
language and the tools and technologies that are used during the realization of our application. The
third part is devoted to the description, design and implementation of our system nicknamed
"jrdesktop" using the modeling language UML The last component ensures the deployment of the
designed system, which shows the general view of the GUI and how to use the system, it also shows
a study of software quality, and testing and results of these tests which were made on the transfer
data between the controller and controlled. It eventually represents an overview on the websites that
have published our software and the statistical software and download our application hosted on the
jrdesktop.sourceforge.net web site.
Key words: Remote desktop, VNC, RDP, RMI, SSL, jrdesktop.

Table des matières
I
Table des matières
INTRODUCTION GENERALE ................................................................................................................................. 1
1. INTRODUCTION.................................................................................................................................................... 3
2. PRESENTATION DU BUREAU DISTANT.......................................................................................................... 4
3. TERMES LIES AU BUREAU DISTANT ............................................................................................................... 5
4. DISPOSITIFS DE BUREAU DISTANT ................................................................................................................. 5
4.1. LE FACTEUR MATERIEL............................................................................................................................................... 5
4.2. LE FACTEUR RESEAU .................................................................................................................................................. 5
4.3. LE FACTEUR LOGICIEL ................................................................................................................................................ 6
4.4. LE FACTEUR SECURITE................................................................................................................................................ 6
4.5. LE FACTEUR MATERIEL............................................................................................................................................... 6
5. LE FONCTIONNEMENT DU BUREAU DISTANT.............................................................................................. 6
6. MISE EN PLACE .................................................................................................................................................... 7
6.1. PROBLEMATIQUES ET SOLUTIONS APPROPRIEES.......................................................................................................... 8
6.1.1. PC derrière un pare-feu ..................................................................................................................................... 8
6.1.2. PC derrière un routeur....................................................................................................................................... 8
6.1.3. Pas de connexions entrantes .............................................................................................................................. 8
6.1.4. Adresse IP dynamique........................................................................................................................................ 8
6.2. TECHNIQUES D'AIDE POUR ACCES A DISTANCE............................................................................................................ 8
6.2.1. DNS dynamique.................................................................................................................................................. 8
6.2.2. Redirection des ports.......................................................................................................................................... 9
6.2.3. Relai (ou répéteur) ........................................................................................................................................... 10
6.2.4. Tunnel http........................................................................................................................................................ 11
7. L'UTILISATION DU BUREAU DISTANT...........................................................................................................11
8. COMPARER DES DIFFERENTS LOGICIELS DE BUREAU A DISTANCE....................................................12
9. INCONVENIENTS DU BUREAU DISTANT........................................................................................................16
10. ADMINISTRATION ET CONTROLE PAR MOBILE.......................................................................................16
11. CONCLUSION .....................................................................................................................................................17
1. INTRODUCTION...................................................................................................................................................18
2. LE LANGAGE JAVA.............................................................................................................................................18
2.1. LES AVANTAGES DE JAVA......................................................................................................................................... 18
2.2. JAVA STANDARD EDITION 6 ..................................................................................................................................... 19
3. LA TECHNOLOGIE RMI (REMOTE METHOD INVOCATION).....................................................................19
3.1. APPLICATIONS DISTRIBUEES ..................................................................................................................................... 19
3.2. OBJECTIFS DE RMI ................................................................................................................................................... 20
3.3. L'ARCHITECTURE RMI............................................................................................................................................. 20
CHAPITRE I : LE BUREAU DISTANT
CHAPITRE II : OUTILS ET TECHNOLOGIES UTILISÉS

Table des matières
II
3.3.1. Interface ........................................................................................................................................................... 20
3.3.2. Les différentes couches de RMI........................................................................................................................ 21
3.4. PROCESSUS DE DEVELOPPEMENT D’UNE APPLICATION RMI .................................................................................... 23
4. LE PROTOCOLE DE SECURITE SSL ................................................................................................................25
4.1. DEFINITION DU PROTOCOLE...................................................................................................................................... 25
4.2.1. Architecture du SSL.......................................................................................................................................... 25
4.2.2. Fonctionnement du SSL.................................................................................................................................... 26
4.2. JAVA ET SSL............................................................................................................................................................. 28
4. NETBEANS ............................................................................................................................................................28
5. CONCLUSION .......................................................................................................................................................29
1. INTRODUCTION..............................................................................................................................................28
2. MODELISATION..............................................................................................................................................29
2.1. DIAGRAMME DE CAS D'UTILISATION................................................................................................................... 29
2.2. DIAGRAMME DE CLASSE..................................................................................................................................... 29
2.3. DIAGRAMME DE COMPOSANT............................................................................................................................. 30
2.4. DIAGRAMME DE DEPLOIEMENT .......................................................................................................................... 31
3. ARCHITECTURE DE L'APPLICATION ........................................................................................................32
3.1. ARCHITECTURE GENERALE................................................................................................................................. 32
3.2. ARCHITECTURE RMI.......................................................................................................................................... 34
3.3. COMMUNICATION ENTRE MODULES.................................................................................................................... 35
3.4. ARCHITECTURE DES MODULES ........................................................................................................................... 36
3.5. FONCTIONNALITES DE BASE ............................................................................................................................... 39
3.5.1. Transfert de données................................................................................................................................. 39
3.5.2. Serveur multihome .................................................................................................................................... 42
3.5.3. Multisessions............................................................................................................................................. 42
3.5.4. Sécurité ..................................................................................................................................................... 42
3.5.5. Capture d'écran ........................................................................................................................................ 43
3.5.6. Application des événements clavier et souris............................................................................................ 45
3.5.7. Qualité d'image JPEG .............................................................................................................................. 45
3.5.8. Compression de données........................................................................................................................... 46
3.5.9. Configuration............................................................................................................................................ 46
4. CONCLUSION...................................................................................................................................................46
1. INTRODUCTION...................................................................................................................................................47
2. ENVIRONNEMENT DE DEVELOPPEMENT.....................................................................................................48
3. UTILISATION DU SYSTEME ..............................................................................................................................48
3.1. PROCEDURE D'OBTENTION DE JAVA REMOTE DESKTOP............................................................................................ 48
3.2. INTERFACE UTILISATEUR (VUE GENERALE DE L’IHM).............................................................................................. 49
3.2.1. Fenêtre principale de jrdesktop........................................................................................................................ 49
3.2.2. Icône de la barre des tâches............................................................................................................................. 50
3.2.3. Menu contextuel ............................................................................................................................................... 51
3.2.4. Fenêtre de contrôle de l’application jrdesktop ................................................................................................ 51
CHAPITRE III : MODELISATION ET ARCHITECTURE
CHAPITRE IV : DEPLOIEMENT DU SYSTEME

Table des matières
III
3.3. CONFIGURATION DE MODULE HOTE ......................................................................................................................... 58
3.4. CONNEXION AU MODULE HOTE DEPUIS LE MODULE ADMIN ..................................................................................... 59
3.5. CONNEXIONS ACTIVES.............................................................................................................................................. 60
3.6. TRANSFERT DE DONNEES.......................................................................................................................................... 61
3.6.1. Transfert du contenu du presse-papiers........................................................................................................... 61
3.6.2. Transfert de fichiers et de dossiers................................................................................................................... 61
3.7. UTILISATION PAR LIGNE DE COMMANDE................................................................................................................... 62
3.8. MESSAGES D'ERREUR................................................................................................................................................ 63
4. ETUDE DE QUALITE DU LOGICIEL (EVALUATION)....................................................................................64
4.1. AVANTAGES DU LOGICIEL : ...................................................................................................................................... 64
4.2. LIMITATIONS DU LOGICIEL : ..................................................................................................................................... 65
4.3. TESTS ET RESULTATS DU TRANSFERT DE DONNEES ................................................................................................... 66
4.3.1. Envoie des données par le module Admin........................................................................................................ 66
4.3.2. Réception des données par le module Hôte...................................................................................................... 68
4.3.2. Transfert de fichiers ......................................................................................................................................... 69
4.4. COMPARAISON DU JRDESKTOP AVEC D’AUTRES LOGICIELS : .................................................................................... 70
5. JRDESKTOP SUR LE NET...................................................................................................................................74
5.1. SITE WEB DU PROJET JRDESKTOP SUR SOURCEFORGE.NET........................................................................................ 74
5.2. SITE WEB OFFICIEL DU PROJET .................................................................................................................................. 75
5.3. JRDESKTOP SUR WIKIPEDIA ....................................................................................................................................... 76
5.4. JRDESKTOP SUR GOOGLE CODE HOSTING PROJECT .................................................................................................. 77
5.5. JRDESKTOP SUR OHLOH ............................................................................................................................................ 78
5.6. JRDESKTOP SUR FREEBSD........................................................................................................................................ 78
6. CONCLUSION .......................................................................................................................................................78
CONCLUSION GENERALE.....................................................................................................................................79
GLOSSAIRE
ANNEXE A: TABLEAU DE BORD DU SITE WEB DU JRDESKTOP
ANNEXE B: DESCRIPTION DU DIAGRAMME DE CLASSE
BIBLIOGRAPHIE

Liste des figures et des tableaux
I
Liste des figures
Figure 1.1 -Les Applications du bureau distant 4
Figure 1.2 -Echange de données entre les module Admin et Hôte 7
Figure 1.3 -Accès à plusieurs serveurs VNC à l’aide d’un seul port 9
Figure 1.4 - Relai établit des connexions entre visualisateurs et serveurs VNC 10
Figure 1.5 - Diverses fonctionnalités d'echoServer 11
Figure 1.6 - Communication à l'aide d'un tunnel http 11
Figure 1.7 -Administration par mobile à l'aide de RDM + 15
Figure 2.1 -Architecture RMI 19
Figure 2.2 -les opérations de communication 21
Figure 2.3 -Invocation d’une méthode distante et renvoie de la valeur de retour 22
Figure 2.4 -SSL et ces sous protocoles dans le modèle TCP/IP 24
Figure 2.5 -Étapes d’établissement des connections SSL 25
Figure 2.6 -Interface de L’IDE NetBeans 6.0 27
Figure 3.1 - Diagramme de cas d'utilisation 29
Figure 3.2 - Diagramme de classe 30
Figure 3.3 - Diagramme de composants 30
Figure 3.4 - Diagramme de déploiement 31
Figure 3.5 -Schéma général d'une application de bureau distant 32
Figure 3.6 - Diagramme de paquetage 34
Figure 3.7 -Architecture RMI du jrdesktop 35
Figure 3.8 - Flux de données échangés entre modules 36
Figure 3.9 -L'architecture interne du module Viewer 37
Figure 3.10 - La structure interne du module Server 38
Figure 3.11 -Organigramme du transfert de données 40
Figure 4.1 -Apparence la fenêtre principale de jrdesktop 49
Figure 4.2 -Apparition de l’icône sur de la barre des tâches 50
Figure 4.3 -Le menu contextuel de jrdesktop 51
Figure 4.4 -Aperçu général de la fenêtre de contrôle à distance de l’utilisateur Admin 52
Figure.4.5 -barre d’outils de l’application 52
Figure 4.6 -Infos bulle explicative 53
Figure 4.7 -La sélection est en cours 54
Figure 4.8 -Après la sélection 54
Figure 4.9 -Affichage en plein écran 55
Figure 4.10 -Vue minime d'écran (échelle 1/2) 55
Figure 4.11 -Transfert d'une image à l'aide du presse-papiers 58
Figure 4.12 -Boîte de dialogue de configuration de module Hôte 59
Figure 4.13 -Etablissement des détailles pour connecter au module Hôte 59
Figure 4.14 -Consultation des PC Admin connectés en cours 60
Figure 4.15 -Détails de la connexion 60
Figure 4.16 -Propriétés de l'ordinateur distant 61
Figure 4.17 -La fenêtre du transfert de fichiers 61
Figure 4.18 -Affichage du l'aide du jrdesktop par la ligne de commande 63
Figure 4.19 -Exemple d'un message d'erreur 64
Figure 4.20 - PC sous Mac OS X 10.5.3 contrôle un PC sous Windows Vista 65
Figure 4.21 - L'effet de la compression sur les données envoyées 67
Figure 4.22 - Gain de la compression en pourcentage (%) 67
Figure 4.23 - Effet de la qualité de la compression d'image JPEG 68

Liste des figures et des tableaux
II
Figure 4.24 - Gain de la compression en pourcentage (%) 69
Figure 4.25 - Transfert de fichiers 70
Figure 4.26 -jrdesktop sur SourceForge 74
Figure 4.27 -Statistiques sur les téléchargements de jrdesktop 75
Figure 4.28 -Site web officiel du projet 76
Figure 4.29 -jrdesktop sur wikipedia.org 77
Liste des tableaux
Tableau 1.1 -Comparaison des diverses applications de bureau distant 13
Tableau 1.2 -Quelques applications de contrôle à distance par mobile 15
Tableau 3.1 - Diverses associations 33
Tableau 4.1 -Les différentes infos bulle inadéquates les divers événements 50
Tableau 4.2 -Les déférents changements de l’icône de la barre des tâches 51
Tableau 4.3 -Les composants de la barre d’outils et leurs activités 53
Tableau 4.4 -Comparaison des différentes palettes de couleurs 56
Tableau 4.5 -Comparaison de la qualité de la compression d'image JPEG 57
Tableau 4.6 -Les messages d'erreurs les plus fréquentés du jrdesktop 64
Tableau 4.7 -Comparaison générale 72
Tableau 4.8 -Comparaison détaillés 73
Tableau 4.9 -Statistiques sur les sources d'accès au site officiel du jrdesktop 75

Introduction générale
1
Introduction Générale
« Fort heureusement, chaque réussite est l'échec d'autre chose. »
Jacques Prévert.
Pendant ces dernières années, on a assisté à un développement fulgurant et une
prolifération d’applications spécialisées pour réseau dans la transmission de données par
Internet. Chaque jour apparaissent de nouvelles applications qui se déroulent à distance pour:
vidéoconférence, helpdesk, enseignement à distance, maintenance, reconfiguration,
télétravail, réparation, aide ...etc. La liste est longue et ne cesse de grandir. Les conditions de
service associées à ces applications diffèrent de celles des applications dites « élastiques »
(email, web, partage de fichier,...) car les exigences de service de ces applications multimédia
reposent sur deux axes: la synchronisation et la tolérance à la perte de données. Le bureau à
distance (ou Remote Control en anglais) fait partie de ces applications multimédia.
Aujourd'hui, la grande majorité des responsables informatiques ont pris conscience de
l'intérêt des dispositifs de bureau distant. En effet, pour que les entreprises répondent à leurs
défis surtout en ce qui concerne la continuité de l’activité et la rentabilité, elles doivent
dorénavant s’orienter vers cette approche stratégique qui répondra à la demande croissante
des utilisateurs, soutient les initiatives stratégiques et garantit la réactivité informatique,
indispensable à toute organisation efficace. Le bureau distant est une solution puissante
garantissant la sécurité de l’accès, la mobilité des utilisateurs et la mise à disposition des
applications à tout moment et à n’importe quel endroit.
Dans ce contexte, notre objectif est de réaliser une application de bureau à distance
qui soit capable d’apporter un aide quelconque à un utilisateur se trouvant dans le réseau local
(LAN), ou dans un autre lieu de la planète, et ce par le biais de l’internet comme si vous étiez
à sa place. Autrement dit, si vous êtes sur un poste et votre collègue sollicite votre aide, vous
pouvez, par le biais du réseau local, lui apporter votre aide grâce à cette application, en
installant celle-ci du côté serveur (le poste de votre collègue) appelé aussi hôte (ou host), et
sur le côté client (votre poste) appelé Admin (appelé aussi "guest") ainsi vous avez une accès
dans une fenêtre de l'écran distant où vous pouvez utiliser clavier et/ou souris sans problème
en vue d’intervenir sur le poste distant.

Introduction générale
2
Le bureau distant présente une solution idéale pour offrir une assistance à distance
rapide et aider vos clients, vos collègues, vos amis, ou toute autre personne, même s'ils sont à
l'autre bout du monde.
Ce mémoire est composé de 4 chapitres :
Dans le premier chapitre, nous avons défini le bureau distant et nous avons étudie ses
dispositifs, son fonctionnement et sa mise en place ainsi que ses utilisations. Dans le second
chapitre, on a intéressé à présenter le langage de développement Java et on a défini quelques
outils et technologies utilisés durant la réalisation de projet de fin d’étude. Le troisième
chapitre est consacré à la description, la conception et l’implémentation de notre système
bureau distant. Enfin, dans le dernier chapitre, nous avons présenté le système conçu pour
décrire l’environnement de développement, la manière d’utilisation du système, l’étude de
qualité et un aperçu sur les sites web qui ont publié notre logiciel surnommé « jrdesktop ».
Enfin nous avons présenté sous forme d’annexe une analyse faite par « Google
Analytics » sur le site officiel du notre logiciel jrdesktop.sourceforge.net, et un autre annexe
pour la description du diagramme de classe du notre projet.

CHAPITRE I Le bureau distant
3
Chapitre I
Le bureau distant
« C'est le commencement exact de notre fine »
William Shakespeare, le songe d'une nuit d'été. Acte V, scène I, ligne 111.
1. Introduction
Dans les années 90, les entreprises ont commencé à percevoir les avantages d’un accès distant à
leurs ressources, via le Web, pour leurs employés et partenaires. Pour parvenir à offrir un accès via
le Web, elles se sont alors tournées vers le bureau à distance qui est alors un moyen très efficace et
surtout pour les entreprises hautement informatisées.
Au niveau professionnel, le bureau distant paraît un outil indispensable pour maintenir le bon
fonctionnement d'un réseau étendu sans déplacement et aux moindres coûts.
Aujourd'hui, la grande majorité des responsables informatiques a pris conscience de l'intérêt des
dispositifs de bureau à distance.
Le bureau distant est un sujet assez vaste qui s'articule autour de plusieurs points :
· L'administration.
· Le contrôle.
· La maintenance.
· La sécurité.
· La mise à jour.
· ...

CHAPITRE I Le bureau distant
4
Ces différents points montrent l'importance du bureau à distance notamment dans un réseau étendu
composé de plusieurs réseaux locaux.
Dans ce chapitre on explique le bureau distant et on donne quelques termes liés à ce dernier. Puis,
nous allons étudier l'utilisation du bureau distant. Ensuite, on donne une comparaison des différents
logiciels de bureau à distance, ainsi, on cite quelques inconvénients. On finit par représenter
l’administration et le contrôle par mobile.
2. Présentation du bureau distant
Le bureau distant (ou bureau à distance) est un moyen qui permet l'observation et la prise de
contrôle d'un ordinateur distant (via Internet ou un réseau local) depuis l'écran d'un ordinateur local
dans l’objectif de maintenir, dépanner à distance, former et aider en ligne …etc. (Cf. Figure 1.1).
Figure 1.1 – Les Applications du bureau distant
Le bureau à distance vous permet d'utiliser votre écran, votre clavier et votre souris pour voir et
piloter l'ordinateur distant. Tous les mouvements de la souris et les signaux du clavier sont
transférés de l'ordinateur local directement à l'ordinateur à distance via le réseau LAN (local area
network), WAN (Wide area Network) ou Internet, relayant l'écran graphique, des mises à jour de
retour dans l'autre sens. Cela signifie que vous pouvez travailler et accéder à toutes les applications,
à tous les fichiers et à toutes les ressources réseau comme si vous étiez assis devant cet ordinateur à
distance, où que vous soyez. Le bureau distant permet aussi de piloter simultanément plusieurs
ordinateurs distants, depuis n'importe où dans le monde.
Le bureau distant prend en charge les connexions réseau sur un réseau local (LAN), un réseau
étendu (WAN) ou Internet. Il prend également en charge les connexions modem à modem et les
connexions directes (d'ordinateur à ordinateur) via un port série ou parallèle.

CHAPITRE I Le bureau distant
5
3. Termes liés au bureau distant
Il y a d’autres termes qui peuvent être confondu avec le terme bureau distant, chaque terme à sa
propre définition, son domaine d'utilisation et ses applications, parmi ces termes on cite :
§ Accès à distance ;
§ Contrôle à distance (ou commande à distance) ;
§ Administration à distance ;
§ Partage du bureau (en anglais Desktop Sharing).
4. Dispositifs de bureau distant
Le bureau distant s'effectuer simplement après avoir installé et configuré l'application. Mais pour le
faire efficacement et correctement, plusieurs facteurs sont indispensables pour savoir quels
matériels et quels outils sont nécessaires.
Le choix d'une solution par rapport à une autre se fera selon les besoins, les possibilités, les
avantages et surtout selon le coût [1].
4.1. Le facteur matériel
Un modem (modulateur-démodulateur), est un équipement réseau servant à communiquer avec des
utilisateurs distants.
Depuis la fin des années 90, de nombreuses normes de télécommunications sont apparues et, donc
autant de nouveaux types de modems : RNIS (Réseau Numérique à Intégration de Services), ou
ISDN (Integrated Services Digital Network), ADSL (Asymmetrical Digital Subscriber Line),
modem câblé, GSM (Groupe Spécial Mobile ou Groupe Système Mobile), GPRS (General Packet
Radio Service), Wi-Fi (WIreless FIdelity)…etc.
Parmi les technologies existantes de connexion à l'Internet, on cite [2] :
§ La connexion classique, par modem sur la ligne téléphonique : appelée 'RTC';
§ La connexion par ligne téléphonique haut-débit, de type RNIS;
§ La connexion par ligne téléphonique haut-débit, de type DSL : (Digital Subscriber Line,
abonnement téléphonique numérique);
§ La connexion par câble ;
§ La connexion par Wi-Fi.
4.2. Le facteur réseau
Les réseaux permettent de standardiser les applications, elles permettent aussi à plusieurs personnes
de travailler en réseau (Par exemple, la messagerie électronique et les applications de bureau
distant). Voici les avantages qu'offrent de tels systèmes :
§ diminution des coûts grâce aux partages des données et des périphériques;
§ standardisation des applications;
§ accès aux données en temps utile;

CHAPITRE I Le bureau distant
6
§ communication et organisation plus efficace.
On distingue parmi les différents types de réseau les LAN, MAN et WAN :
· Les LAN : local area network, sont les réseaux locaux. Les ordinateurs sont reliés dans une
petite zone géographique (soit avec des fils, soit sans fils).
· Les MAN (Metropolitan area Network) : permettent de connecter plusieurs LAN proches
entre eux.
· Les WAN : qui signifie réseau étendu, permettent de connecter plusieurs LAN éloignées
entre eux.
4.3. Le facteur logiciel
Une bonne application bureau distant demande de bonnes conditions pour qu’elle puisse fonctionne
efficacement. Ces conditions dépendent de type de modem utilisé (technologie de la connexion à
Internet), ainsi le type de réseau LAN, MAN ou WAN.
4.4. Le facteur sécurité
La plupart des fournisseurs de services proposent donc, en complément de la fourniture d'accès
permanents au réseau, des produits et des services pour protéger le réseau local. Les combinaisons
du filtrage, du chiffrement (pour la confidentialité et la sécurité des opérations), de
l'authentification et du contrôle d'accès aux outils et applications permettent de lutter sur l'ensemble
des points sensibles. Ces protections sont souvent basées sur le choix de technologies 'Firewall', qui
combinent ces différentes technologies [3].
La sécurité dans le bureau distant est très indispensable, car une application bureau distant peut
provoquer un espionnage pour le contrôleur contre le contrôlé au lieu que ce dernier devrait être
servi par aide ou dépannage.
4.5. Le facteur matériel
Un ordinateur puissant est mieux qu'un ordinateur moins puissant dans les applications d’accès à
distance notamment le bureau à distance dont la nécessité de l'envoi des captures d’écran en temps
réel de la part de poste contrôlé (Server), et l’envoi des touches claviers et mouvements souris de
la part de contrôleur (Viewer). La puissance est exprimée surtout en terme de vitesse de processeur
et de RAM (Random Access Memory).
5. Le fonctionnement du bureau distant
Pour la démarche de fonctionnement, vous devez avoir deux ordinateurs (ou plus) connectés à
travers le réseau local ou par Internet, et il faut installer l'application pour le bureau distant sur
chaque ordinateur.
La plupart des applications du bureau distant offrent en plus une connexion de type boucle de
retour (loopback).
Une application de type bureau distant est composée essentiellement de deux modules :

CHAPITRE I Le bureau distant
7
1. Module Admin (comme administrateur, appelé aussi "client", "visualisateur" (viewer) ou
l'ordinateur contrôleur) qui affiche le bureau et prend le contrôle de l'ordinateur distant en utilisant
le plan écran (ou une simple fenêtre), le clavier, et la souris de l'ordinateur local. En général, ce
module est installé uniquement sur le poste de l’utilisateur qui veut contrôler.
2. Module Hôte (appelé aussi "serveur", ou l'ordinateur contrôlé) qui exécute les commandes en
provenance du Module Admin et lui envoie l'état de son écran. Ce module doit être installé sur tous
les ordinateurs que l'on souhaite contrôler (ou même sur tous les ordinateurs du réseau local).
Le module Hôte peut agir comme un serveur http (HyperText Transfer Protocol), le module est mi
en écoute sur un port spécifique, le client utilise un navigateur en tapant l’adresse du serveur avec
le port associé (par exemple: http://192.168.1.221:5800), à l'établissement de la connexion, une
applet est envoyée au client, pour lui permettre de communiquer avec le module Hôte. Les deux
modules (Hôte et Admin) utilisent des commandes http (comme: connect, send, get) pour échanger
les mises à jour de l'écran et les évènements clavier / souris (Cf. Figure 1.2).
Figure 1.2 – Echange de données entre les module Admin et Hôte
Il y a une différence entre les deux notions client-serveur de l'ordinateur contrôlé depuis
l'ordinateur qui contrôle avec la notion habituelle de client/serveur lié au Web comme un internaute
qui navigue (client) sur un site Web (serveur), ou un client qui utilise des services fournis par un
FAI (Fournisseur d' Accès à l'Internet).
Dans la plupart des cas, c'est le client distant qui lance la connexion. L'application concernée doit
fournir les informations requises pour une connexion à l'ordinateur hôte. Vous pouvez également
sélectionner des options permettant d'améliorer la sécurité et d'optimiser les performances.
Pour établir une connexion, l'ordinateur hôte doit être configuré pour attendre les connexions
entrantes. L'utilisateur hôte peut sélectionner le type de périphérique à utiliser pour les connexions
de type TCP/IP (Transmission Control Protocol / Internet Protocol) et les options de sécurité
permettant de contrôler et de limiter l'accès à l'ordinateur hôte.
6. Mise en place
Nous discutons sur quelques problèmes qui peuvent être rencontrés et qui empêchent ou réduisent
les performances et on va voir des solutions appropries pour éliminer ou réduire l'effet produit par
ces problèmes.

CHAPITRE I Le bureau distant
8
6.1. Problématiques et solutions appropriées
Plusieurs facteurs peuvent empêcher l'établissement de la connexion entre les deux modules Admin
et Hôte, parmi aux on distingue :
6.1.1. PC derrière un pare-feu
Le pare-feu doit laisser les connexions entrantes et sortantes sur les adresses et les ports utilisés par
le bureau distant, ainsi; il ne doit pas bloquer les modules Hôte et Admin.
Si l'utilisateur ne peu pas autoriser ces modules à agir librement; et si les connexions entrantes et
sortantes sont interdites alors il est obligé d'utiliser des outils tel qu'un tunnel http s’il est autorisé.
6.1.2. PC derrière un routeur
Si un ordinateur se trouve dans un réseau local, et celui là est derrière un routeur, alors il n'est pas
accessible, la technique de la redirection des ports peut être utile pour le rendre accessible à
condition que les connexions entrantes sont autorisées; si non l’application du tunnel http peut
résoudre le problème.
6.1.3. Pas de connexions entrantes
Par mesure de sécurité; Certains FAI, routeurs et/ou pare-feux bloquent les connexions entrantes (le
trafic entrant), c'est-à-dire si un ordinateur est dans un réseau local alors il n'est pas accessible,
donc, nous ne pouvons pas le contrôler.
La solution de ce problème consiste à utiliser un relai (appelé aussi un répéteur).
6.1.4. Adresse IP dynamique
Se dit d'une adresse affectée à une machine au moment de sa connexion au réseau. Étant donné que
cette adresse n'est pas fixée d'avance et qu'elle peut donc être différente d'une session à l'autre, elle
est appelée dynamique par opposition à une adresse statique. Cette adresse est attribuée par le
fournisseur d'accès à l’Internet (FAI) lorsqu'on connecte à Internet. Elle est temporaire et sera
reprise par un autre utilisateur après votre déconnexion. D'où la difficulté particulière d'appeler un
poste précis en téléphonie sur Internet. Comme solution de ce problème certains FAI proposent en
option une adresse statique. Une autre solution, c'est le service d'adressage dynamique. (voir la
technique : DNS Dynamique).
6.2. Techniques d'aide pour accès à distance
Dans cette partie, on va présenter quelques techniques qui peuvent être utiles, pour faciliter la tâche
à l'utilisateur afin d'accéder à son ordinateur quelque soit sa situation et son emplacement.
6.2.1. DNS dynamique
Ce service permet à quelqu'un n'ayant pas d'adresse IP (Internet Protocol) fixe d'avoir une entrée
DNS (Domain Name Server) afin de pouvoir lancer un serveur Web par exemple. La façon de faire
la plus courante est d'avoir un client qui mémorise votre adresse IP à des intervalles spécifiques et
qui vérifie si elle correspond à la base de données DNS du serveur que vous utilisez. Sinon, il met à
jour cette base tout simplement.

CHAPITRE I Le bureau distant
9
No-IP.com à mis un service gratuit (Free Dynamic DNS) qui permet d'associé un nom d'hôte (par
exemple jrdesktop.no-ip.org) avec une adresse IP de la machine (par exemple 41.221.16.145), un
logiciel appelé No-IP DUC (Dynamic Update Client) est fourni gratuitement (sous Windows, Unix
et Mac) est utilisé pour faire la vérification et la mise à jour de l'adresse IP chaque fois que la
machine est connectée à l'Internet, l'utilisateur peut bénéficier à tout moment de ce nom d'hôte pour
accéder à sa machine.
6.2.2. Redirection des ports
Cette technique est fournie avec la plupart des routeurs, elle consiste à rediriger des paquets
réseaux reçus sur un port donné d'un ordinateur (ou d'un équipement réseau) vers un autre
ordinateur (ou équipement réseau) sur un port donné. Cela permet entre autre de proposer à des
ordinateurs extérieurs à un réseau d'accéder à des services répartis sur plusieurs ordinateurs de ce
réseau.
PortForward.com fournit des guides détaillés concernant la configuration des routeurs pour
l'utilisation de la redirection des ports.
A l'aide de cette technique, on peut par exemple accéder à notre machine par la redirection du port
3389 (par défaut) de "Connexion Bureau à Distance" de Windows. Même chose avec le port 5900
(par défaut) de RealVNC.
La redirection des ports peut être utilisée avec une extension d'UltraVNC appelé Repeater pour
accéder à plusieurs hôtes en utilisant un seul port.
Le routeur est configuré pour rediriger des paquets reçus sur le port 5901 vers l'adresse IP
10.10.10.11, ce dernier est équipé d'un répéteur (Repeater) et d'un serveur VNC (Cf. Figure 1.3).
Figure 1.3 – Accès à plusieurs serveurs VNC à l’aide d’un seul port
Le visualisateur (VNC Viewer) peut accéder à tous les PCs d’un réseau distant qui sont équipés
d'un serveur VNC (VNC Server), il suffit d'indiquer (dans la boite de dialogue de la connexion de

CHAPITRE I Le bureau distant
10
Viewer) l'adresse IP du réseau avec le port de redirection comme un répéteur
(41.200.207.242:5901), et l'adresse du PC (Personal Computer) avec le port (par défaut) comme un
serveur VNC (10.10.10.12:5902).
6.2.3. Relai (ou répéteur)
Si les connexions entrantes sont interdites, alors la solution c’est d’utiliser un programme (un
serveur) appelé "relai" qui agit comme une passerelle entre les deux modules. Ces deux derniers
deviennent des clients communiquant avec ce serveur (le relai). Le rôle de ce relai est d’échanger
les paquets entre les clients connectés (Cf. Figure 1.4).
Figure 1.4 - Relai établit des connexions entre visualisateurs et serveurs VNC
Le relai utilise une base de données pour stocker des informations concernant les serveurs VNC
connectés, en introduisant l'identifiant et le mot de passe d'un serveur VNC, un visualisateur peut se
connecter à ce dernier sans savoir son adresse IP.
La solution EchoVNC propose un module intégré appelé echoWare (Cf. Figure 1.5), ce module
permet à toutes les applications point à point ou client/serveur: bureau distant, VoIP (Voice Over
IP), chat vidéo, …etc, d'utiliser un relai afin de réaliser une, chat vidéo, …etc.) d'utiliser un relai
afin de réaliser une connection sécurisée de bout en bout sans adaptation aux pare-feux, proxy ou
aux routeurs NAT. Via echoWare toutes les connexions apparaissent au réseau comme des
connexions sortantes vers le même port TCP du echoServer.

CHAPITRE I Le bureau distant
11
Figure 1.5 - Diverses fonctionnalités d'echoServer
6.2.4. Tunnel http
C’est une technique par la quelle les communications s'effectuent à l'aide des différents protocoles
TCP/IP encapsulés sous le protocole http qui joue le rôle de couverture d'un canal de
communication caché derrière un tunnel. Le canal caché avec le flux de données est appelé tunnel
http.
Cette technique est établit par un logiciel client/serveur qui gère la communication (Cf. Figure 1.6).
Figure 1.6 - Communication à l'aide d'un tunnel http
7. L'utilisation du bureau distant
Le bureau distant peut servir à plusieurs utilisations, on cite les suivantes :
· Maintenance, Téléintervention, réparation et aide ;
· Administration des serveurs ;
· Télétravail ;
· Assistance à distance ;
· Formation à distance ;
· Transfère des fichiers entre ordinateurs.

CHAPITRE I Le bureau distant
12
8. Comparer des différents logiciels de bureau à distance
Il existe déjà plusieurs logiciels de gestion à distance d'ordinateur disponible sur le marché. Par
ailleurs, les dernières versions des systèmes d'exploitation incluent désormais l’application à
distance et des outils d'aide et d'assistance à distance tel que Win XP.
Voici un tableau comparatif (Cf. Tableau 1.1) de quelques populaires solutions d'accès et de
contrôle à distance

CHAPITRE I Le bureau distant
13
:disponible×:nondisponible
Tableau1.1–Comparaisondesdiversesapplicationsdebureaudistant[4]

CHAPITRE II Outils et technologies utilisés
16
D'après le tableau précédant, on déduire que le logiciel le plus performant est celui qui fonctionne sur
plusieurs plateformes et qui offre plusieurs fonctionnalités: le cryptage, transfert de fichiers, sessions
multiples…etc. alors c'est le Sun Secure Global Desktop Software (SGD) qui utilise le protocole
AIP et qui fonctionne sur Microsoft Windows, Mac OS et Linux. Ainsi le Symantec PcAnywhere et
le Citrix Presentation Server qui est un produit de la société Citrix systems basé sur le protocole
Independent Computing Architecture (ICA), il est considéré comme un concurrent de SGD. Puis il y
a le Remote Desktop Connection de Microsoft qui utilise le protocole RDP, et RealVNC
Enterprise qui se servir de protocole VNC.
9. Inconvénients du bureau distant
Lorsqu'on utilise le Bureau distant on est confronté à des inconvénients qui sont :
1. L’uni-plateforme :
Cet inconvénient n’est pas pour toutes les applications de bureau distant, l’uni-plateforme l’opposé
de multiplateforme, signifie que l’application ne fonctionne que sur un seul système d’exploitation
comme Apple Remote Desktop qui marche uniquement sur Mac OS, par contre Real VNC
Enterprise n’a pas cet inconvénient.
2. Occupation de la bande passante :
Cet inconvénient dépend de la compression de données que le bureau distant l’utilise, notamment
au niveau de visualisation de l’écran de contrôlé. S’il n y a pas de compression des images envoyés
par le Hôte ou parfois même s’il y a une compression mais qu’elle n’est pas parfaitement
optimisée, ainsi, si l’utilisation des couleurs n’est pas réduite (ex. couleurs 24-bits) alors
l’occupation de la bande passante sera élevée particulièrement dans un réseau WAN, ce qui influe
sur la performance du bureau distant (rendre moins rapide que prévue).
10. Administration et contrôle par mobile
L'administration par mobile a récemment commencé à apparaître sur les appareils sans fil tels que
le BlackBerry, Pocket PC et Palm, ainsi que certains téléphones mobiles.
En général, ces solutions n'offrent pas le plein accès à distance comme VNC ou TerminalServices,
mais ne permettent pas aux administrateurs d'effectuer une variété de tâches, tel que le redémarrage
des ordinateurs, la réinitialisation des mots de passe, et l'affichage des journaux d'événements
système, ce qui réduit, voir même supprimer la nécessité pour les administrateurs système à avoir
un ordinateur portable ou de se trouver à la portée de son bureau.
RDM + (Remote Desktop for Mobiles) est un exemple de ces logiciels qui vous permet d'avoir
accès à votre poste de travail ou de votre ordinateur portable à partir d'un téléphone mobile utilisant
Java.

CHAPITRE II Outils et technologies utilisés
17
Vous pouvez ainsi envoyer et recevoir
des emails, surfer sur le web, éditer des
documents sous Word, gérer des
fichiers et des dossiers (Cf. Figure 1.7).
Le contrôle à distance par mobile, à
récemment vu la lumière à l'aide de la
technologie Bluetooth, plusieurs
applications disponibles permettant de
contrôler entièrement la machine, ou
quelques applications spécifiques, par
exemple, à l'aide du mobile, on peut
montrer une présentation, contrôler un
lecteur multimédia, verrouiller
l'ordinateur, …etc. (Cf. Tableau 1.2)
Figure 1.7 – Administration par mobile
à l'aide de RDM +
Nom du logiciel Lien Licence TCP/IP Bluetooth
RDM+ (Remote
Desktop for
Mobiles)
http://www.rdmplus.com/ Propriétaire ü ×
MRC (Mobile
Remote Control)
https://mobile-remote-control.dev.java.net/
OSS (Open
Source
Software)
ü ×
Mobile Desktop http://sourceforge.net/projects/mobiledesktop/ OSS ü ü
Rove Mobile
Desktop
http://www.rovemobile.com/products/
remoteaccess/mdt/features/
Propriétaire
ü ×
Amora
(A mobile remote
assistant)
http://code.google.com/p/amora/ OSS × ü
Bluetooth Remote
Control
http://www.bluetoothshareware.com/
bluetooth_remote_control.asp
Propriétaire × ü
anyRemote http://anyremote.sourceforge.net/ OSS ü ü
PuppetMaster http://www.lim.com.au/PuppetMaster Propriétaire ü ü
Tableau 1.2 – Quelques applications de contrôle à distance par mobile
11. Conclusion
D'une manière générale, de plus en plus d'entreprises et des particuliers utilisent le bureau distant
pour la maintenance de leurs parcs informatiques. De plus, beaucoup d'éditeurs développement des
logiciels qui répondent au maximum aux besoins des entreprises et des administrateurs systèmes.

CHAPITRE II Outils et technologies utilisés
18
Chapitre II
Outils et technologies utilisés
« Chaque mot est un préjugé »
Friedrich Nietzsche.
1. Introduction
Dans ce chapitre, on va présenter le langage Java qu'on a utilisé pour le développement de notre
application de bureau distant à l'aide du l’éditeur NetBeans.
Ainsi, on va montrer un mécanisme permettant l’appel des méthodes entre objets distribués
développés par Sun Microsystems, ce protocole est connu sous l’acronyme RMI (Remote Method
Invocation).
Par la suite, on va présenter comment sécuriser la communication à l’aide du protocole SSL. On
montre ensuite que l’éditeur NetBeans est assez puissant et qui a de grande importance.
2. Le langage Java
Le langage Java permet d'exprimer des concepts, il deviendra un moyen d'expression
considérablement plus simple et plus souple que n'importe quelle alternative, alors même que les
problèmes augmentent en taille et en complexité. C’est un langage à objets qui permet d’écrire de
façon simple et claire des programmes portables sur la majorité des plates-formes. Lié à l’essor du
World Wide Web. Il a été conçu par l’équipe de James Gosling en fonction des multiples exigences
des développements informatiques actuels [5].
2.1. Les avantages de Java
Le primordial avantage de ce langage de programmation réside dans le fait que la syntaxe de java est
analogue à celle de C++, ce qui le rend économique et professionnel. Java est un langage "à objets",
tous les éléments de Java, à l'exception de quelques types de base tels que les nombres, sont des
objets. La conception orientée objet présente de nombreux avantages pour les projets sophistiqués,
elle a remplacé les techniques structurées antérieures. On distingue ces 4 principaux avantages [6] :

CHAPITRE II Outils et technologies utilisés
19
1. La mémoire dans Java est être allouée et libérée automatiquement. Vous ne risquez pas de pertes
de mémoire.
2. Ils ont éliminé l'arithmétique des pointeurs introduisant du même coup une vraie gestion de
tableau. La notion de référence sur une zone mémoire remplace avantageusement celle de "
pointeur", car elle supprime la possibilité d'écraser toute zone mémoire à cause d'un compteur
erroné.
3. Ils ont éliminé toute possibilité de confusion entre une affectation et un test d'égalité dans une
instruction conditionnelle. L'instruction if (n = 3) ne pourra pas franchir l'étape de la compilation.
4. Ils ont supprimé l'héritage multiple en le remplaçant par une nouvelle notion d'interface dérivée
d'Objective C. Les interfaces vous offrent tout ce que vous pouvez obtenir à partir de l'héritage
multiple, sans la complexité de la gestion de hiérarchie d'héritage multiple.
2.2. Java Standard Edition 6
C'est été le lundi de 11 décembre 2006 quand Sun a officiellement publié la version 6 de Java
Platform standard Edition (Java SE) en mettant en avant les améliorations de performances de sa
dernière JVM (Java Virtual Machine) ainsi que les progrès effectués en termes de supervision et de
support des langages de scripting tiers.
3. La technologie RMI (Remote Method Invocation)
Remote method invocation. Invocation ou plus simplement « appel » de méthode distante, plus connu
sous l'acronyme RMI est une API (Application Programming Interface) Java développée par e par
Sun à partir du JDK 1.1 (Java Development Kit 1.1) permettant de manipuler des objets distants
(objet qui existe dans un autre espace adresse soit dans la même machine soit dans une machine
différente) de manière transparente pour l'utilisateur, c'est-à-dire de la même façon que si l'objet était
sur la machine virtuelle. L'utilisation de cette API nécessite l'emploi d'un registre RMI sur la machine
distante hébergeant ces objets que l'on désire appeler au niveau duquel ils ont été enregistrés.
RMI facilite le développement des applications distribuées en masquant au développeur la
communication client / serveur. La machine sur laquelle s'exécute la méthode distante est appelée
serveur. L'appel coté client consiste à obtenir une référence sur l'objet distant puis simplement
appeler la méthode à partir de cette référence.
3.1. Applications distribuées
Une application distribuée est une application dont les classes sont réparties sur plusieurs machines
différentes. Dans de telles applications, on peut invoquer des méthodes à distance. Il est alors
possible d'utiliser les méthodes d'un objet qui n'est pas situé sur la machine locale.
"Déjà dans le langage C, il était possible de faire de l'invocation à distance en utilisant RPC (Remote
Procedure Calls). RPC étant orienté "structure de données", il ne suit pas le modèle "orienté objet ".
RMI va plus loin que RPC puisqu'il permet non seulement l'envoi des données d'un objet, mais aussi
de ses méthodes. Cela se fait en partie grâce à la sérialisation des objets. Il est également possible de
charger le byte-code des classes dynamiquement. "[7].

CHAPITRE II Outils et technologies utilisés
20
3.2. Objectifs de RMI
Le but de RMI est de créer un modèle objet distribué Java qui s'intègre naturellement au langage Java
et au modèle objet local. Ce système étend la sécurité et la robustesse de Java au monde applicatif
distribué. RMI permet aux développeurs de créer des applications distribuées de manières simples
puisque la syntaxe et la sémantique restent les mêmes que pour les applications habituelles. RMI
permet de:
1- Rendre transparent l’accès à des objets distribués sur un réseau:
Avec RMI, les méthodes de certains objets (appelés objets distants) peuvent être invoquées depuis
des JVM différentes (espaces d’adressages distincts) de celles où se trouvent ces objets, y compris
sur des machines différentes via le réseau. En effet, RMI assure la communication entre le serveur et
le client via TCP/IP et cela de manière transparente pour le développeur.
2- Faciliter la mise en œuvre et l’utilisation des objets distants Java:
Il utilise des mécanismes et des protocoles définis et standardisés tels que les sockets et RMP
(Remote Method Protocol). Le développeur n'a donc pas à se soucier des problèmes de niveaux
inférieurs spécifiques aux technologies réseaux.
L'architecture RMI définit la manière dont se comportent les objets, comment et quand des
exceptions peuvent se produire ? comment gérer la mémoire ? et comment les méthodes appelées
passent et reçoivent les paramètres ?
3- Préserver la sécurité (inhérent à l’environnement Java):
RMI préserve la sécurité inhérente à l’environnement Java notamment grâce à :
· la classe RMISecurityManager, elle vérifie la définition des classes et autorise seulement les
passages des arguments et des valeurs de retour des méthodes distantes et ne prend pas en
compte les signatures éventuelles des classes.
· et au DGC (Distibuted Garbage Collector).
3.3. L'Architecture RMI
En RMI la transmission de données se fait à travers un système de couches, basées sur le modèle OSI
afin de garantir une interopérabilité entre les programmes et les versions de Java. Quant aux
connexions, elles sont effectuées grâce à un protocole propriétaire JRMP (Java Remote Method
Protocol) basé sur TCP/IP sur le port 1099 par défaut [8].
A partir de Java 2 version 1.3, les communications entre client et serveur s'effectuent grâce au
protocole RMI-IIOP (Internet Inter-Orb Protocol) [9].
3.3.1. Interface
L’interface est le cœur de RMI. L’architecture RMI est basée sur un principe important : la définition
du comportement et l'exécution de ce comportement sont des concepts séparés.
RMI permet au code qui définit le comportement et au code qui implémente ce comportement de
rester séparé et de s’exécuter sur des JVM différentes. La définition d’un service distant est codée en
utilisant une interface Java. L’implémentation de ce service distant est codée dans une classe.

CHAPITRE II Outils et technologies utilisés
21
Par conséquent, la compréhension de RMI réside dans le fait que les interfaces définissent le
comportement et les classes définissent l'implémentation.
RMI supporte deux types de classe qui implémente la même interface. La première est
l'implémentation du comportement et s'exécute du côté serveur. La deuxième agit comme un proxy
pour le service distant et s'exécute sur le client.
Un programme client crée des appels de méthodes sur le proxy, RMI envoie la requête à la JVM
distante et la transfère à l'implémentation. Toutes les valeurs de retour fournies par l'implémentation
sont retournées au proxy puis au programme client [7].
3.3.2. Les différentes couches de RMI
RMI est essentiellement construit sur une abstraction en trois couches: La couche de Stubs et
Skeletons, la couche RRL (Remote Reference Layer) et la couche Transport. La Figure 2.1 ci-
dessous montre l'architecture de RMI :
Figure 2.1 – Architecture RMI
3.3.2.1. Stubs et Skeletons
Cette première couche intercepte les appels de méthodes lancées par le client à l'interface de
référence et redirige ces appels à un service RMI distant. Le stub et le skeleton, respectivement sur le
client et le serveur, assurent la conversion des communications avec l'objet distant.
3.3.2.2. RRL
Cette couche comprend comment interpréter et gérer les références faites du client vers les objets du
service distant. Elle permet l’obtention d’une référence d’objet distant à partir de la référence locale
(le stub). Elle est assurée par le package java.rmi.Naming. On appelle cette couche généralement
registre RMI car elle référence les objets. Ce service est assuré par le lancement du programme
rmiregistery.

CHAPITRE II Outils et technologies utilisés
22
3.3.2.3. Couche Transport
La couche transport est basée sur les connexions TCP/IP entre les machines. Elle fournit la
connectivité de base entre les 2 JVM, elle permet d'écouter les appels entrants ainsi que d'établir les
connexions et le transport des données sur le réseau.
De plus, cette couche fournit des stratégies pour passer les firewalls. Elle suit les connexions en
cours. Elle construit une table des objets distants disponibles. Elle écoute et répond aux invocations.
Cette couche utilise les classes Socket et SocketServer. Elle utilise aussi un protocole propriétaire
RMP (Remote Method Protocol).
En utilisant une architecture en couche, chaque couche peut être augmentée ou remplacée sans
affecter le reste du système.
Ainsi, une application client-serveur basée sur RMI met ainsi en œuvre trois composantes :
§ une application cliente implémentant le stub.
§ une application serveur implémentant le skeleton (squelette).
§ une application médiatrice (le registre RMI) servie par un processus tiers (rmiregistry).
Lorsqu'un client désire invoquer une méthode d'un objet distant, il effectue les opérations suivantes
(Cf. Figure 2.2) [8] :
1- Il localise l'objet distant grâce à un service d’annuaire (Registry), le registre de RMI ;
2- Il obtient dynamiquement une image virtuelle de l'objet distant (stub). Le stub possède exactement
la même interface que l'objet distant ;
3- Le stub transforme l'appel de la méthode distante en une suite d'octets, c'est ce que l'on appelle la
sérialisation, puis les transmet au serveur instanciant l'objet sous forme de flot de données. On dit que
le stub "marshalise" (réalise le pliage) les arguments de la méthode distante ;
4- Le Skeleton instancié sur le serveur "désérialise" les données envoyées par le stub (on dit qu'il les
"démarshalise" c.-à-d il réalise le dépliage), puis appelle la méthode en local ;
5- Le Skeleton récupère les données (les résultats) renvoyées par la méthode (type de base, objet ou
exception) puis les marshalisent ;
6- Le stub démarshalise les données provenant du Skeleton et les transmet au client (l'objet faisant
l'appel de méthode à distance).

CHAPITRE II Outils et technologies utilisés
23
Figure 2.2 – les opérations de communication
3.4. Processus de développement d’une application RMI
Les principales étapes nécessaires à la mise en place d’un service de type RMI sont [7] :
a- Définir l'interface
La première étape consiste à créer une interface distante qui décrit les méthodes que le client pourra
invoquer à distance. Pour que ces méthodes soient accessibles par le client, cette interface doit hériter
de l'interface Remote. Cette interface devra être placée sur les deux machines (serveur et client).
b- L’implémentation de l'interface
Il faut maintenant implémenter cette interface distante dans une classe. Par convention, le nom de
cette classe aura pour suffixe Impl. Notre classe doit hériter de la classe
java.rmi.server.RemoteObject ou de l’une de ses sous-classes. La plus facile d’utilisation étant
java.rmi.server.UncicastRemoteObject.
C’est dans cette classe que nous allons définir le corps des méthodes distantes que pourront utiliser
nos clients. Evidement, il est possible d’ajouter d’autres méthodes mais les clients ne pourront pas y
accéder et donc ne pourront pas les utiliser.
c- Générer les classes Stubs et Skeletons (rmic)
Lorsque notre client fera appel à une méthode distante, cet appel sera transféré au stub. Le stub est un
relais du côté client. Il devra donc être placé sur la machine cliente.
C’est le représentant local de l’objet distant. Il « marshalise » (emballe) les arguments de la méthode
distante et les envoie dans un flux de données. D’autre part, il « démarshalise » (déballe) la valeur ou
l’objet de retour de la méthode distante. Il communique avec l’objet distant par l’intermédiaire du
skeleton (Cf. Figure 2.3).
Le skeleton est lui aussi un relais mais du côté serveur. Il devra être placé sur la machine servant de
serveur. Il « démarshalise » les paramètres de la méthode distante, les transmet à l’objet local et «
marshalise » les valeurs de retours à renvoyer au client.
Les stubs et les skeletons sont donc des intermédiaires entre le client et le serveur qui gèrent le
transfert distant des données.
On utilise le compilateur rmic pour la génération des stubs et des skeletons. C’est un utilitaire fournie
avec le JDK.

CHAPITRE II Outils et technologies utilisés
24
Figure 2.3 – Invocation d’une méthode distante et renvoie de la valeur de retour
d- Lancement de registre RMI (service d’annuaire RMI)
Les clients trouvent les services distants en utilisant un service d'annuaire activé sur un hôte connu
avec un numéro de port connu. RMI peut utiliser plusieurs services d'annuaire, y compris Java
Naming and Directory Interface (JNDI). Il inclut lui-même un service simple appelé Registry
(rmiregistry).
Le registre est exécuté sur chaque machine qui héberge des objets distants (les serveurs) et accepte
les requêtes pour ces services, par défaut sur le port 1099.
Un serveur crée un service distant en créant d'abord un objet local qui implémente ce service.
Ensuite, il exporte cet objet vers RMI. Quand l'objet est exporté, RMI crée un service d'écoute qui
attend qu'un client se connecte et envoie des requêtes au service. Après l'exportation, le serveur
enregistre l'objet dans le registre de RMI sous un nom public qui devient accessible de l’extérieur.
Le client peut alors consulter le registre distant pour obtenir des références à des objets distants.
e- Lancement de l'application serveur (Server)
Notre serveur doit enregistrer auprès du registre RMI l’objet local dont les méthodes seront
disponibles à distance. Cela se fait grâce à l’utilisation de la méthode statique bind() de la classe
Naming. Cette méthode permet d’associer (enregistrer) l’objet local avec un synonyme dans le
registre. L’objet devient alors disponible par le client.
ObjetDistantImpl od = ObjetDistantImpl()
Naming.bind("serveur", od)
f- Créer le programme client (Client)
Le client peut obtenir une référence à un objet distant par l’utilisation de la méthode statique lookup()
de la classe Naming. Il peut ensuite invoquer des méthodes distantes sur cet objet. La méthode
lookup() sert au client pour interroger un registre et récupérer un objet distant. Elle prend comme
paramètre une URL qui spécifie le nom d'hôte du serveur et le nom du service désiré. Elle retourne
une référence à l’objet distant. La valeur retournée est du type Remote.
ObjetDistant od = (ObjetDistant) Naming.lookup("//172.16.X.X/serveur")

CHAPITRE II Outils et technologies utilisés
25
g- Lancement de l’application cliente
Il est maintenant possible d’exécuter l’application. Cela va nécessiter l’utilisation de trois consoles.
La première sera utilisée pour activer le registre. Pour cela, vous devez exécuter l’utilitaire
rmiregistry.
Dans une deuxième console, exécuter le serveur. Celui-ci va charger l’implémentation en mémoire,
enregistrer cette référence dans le registre et attendre une connexion cliente.
Vous pouvez enfin exécuter le client dans une troisième console.
4. Le protocole de sécurité SSL
La question du cryptage de données échangées via Internet est plus large et plus complexe qu'il n'y
apparaît. Il ne s'agit pas seulement de sélectionner un algorithme efficace, il est de plus nécessaire de
le sécuriser. Notamment le protocole de transmission des données, ou encore le système
d'identification et notamment les mots de passe.
4.1. Définition du protocole
Secure Socket Layer (SSL) est un des protocoles les plus connus de sécurisation des échanges sur
Internet, développé à l'origine par Netscape (SSL version 2 et 3). Il a été renommé en Transport
Layer Security (TLS) par l'IETF (Internet Engineering Task Force) [4].
SSL fonctionne suivant un mode client/serveur. Il fournit quatre objectifs de sécurité importants:
· l'authentification du serveur ;
· la confidentialité des données échangées (ou session chiffrée) ;
· l'intégrité des données échangées ;
· l'authentification du client avec l'utilisation d'un certificat numérique (optionnelle).
Pour toutes applications existantes (HTTP, FTP, SMTP, etc.), il peut exister une application utilisant
SSL correspondante. Par exemple, l'application HTTPS (Secured HTTP) correspond à HTTP au
dessus de SSL.
La plupart des navigateurs web gèrent parfaitement SSLv2, SSLv3 et TLS v0.1.
4.2.1. Architecture du SSL
SSL est un protocole en couches et se compose de quatre sous protocoles (Cf. Figure 2.4) :
· SSL Handshake Protocol
· SSL Change Cipher Spec Protocol
· SSL Alert Protocol
· SSL Record Layer
SSL se situe dans la couche application du modèle TCP/IP (et dans la couche session du modèle
OSI). Voici une illustration du modèle TCP/IP [10] :

CHAPITRE II Outils et technologies utilisés
26
Figure 2.4 – SSL et ces sous protocoles dans le modèle TCP/IP
4.2.2. Fonctionnement du SSL
Théoriquement SSL est simple, il négocie les algorithmes de cryptographie et les clés entre les deux
faces d'une communication (généralement client et serveur), et établit un tunnel chiffré (sécurisé)
grâce à laquelle d'autres protocoles (comme HTTP) peuvent être transportés. En option, SSL peut
également authentifier les deux parties de la communication grâce à l'utilisation des certificats [10].
Mais comment fonctionne t-il ? La Figure 2.5 diagramme ci-dessous montre (d’une façon simplifiée),
étape par étape processus de mise en place d’une nouvelle connexion SSL entre le client
(généralement un navigateur web) et le serveur (généralement un serveur web SSL).

CHAPITRE II Outils et technologies utilisés
27
Figure 2.5 – Étapes d’établissement des connections SSL
Comme vous pouvez le voir sur le schéma précèdent, le processus de création de chaque nouvelle
connexion SSL commence avec l'échange de paramètres de chiffrement et puis en option
d'authentification des serveurs (en utilisant le protocole SSL Handshake). Si la poignée de main est
couronnée de succès et les deux parties d'accord sur une série commune de chiffrement et des clés de
chiffrement, les données d'application (généralement HTTP, ou un autre protocole) peuvent être
envoyés par un tunnel de chiffrement (en utilisant le protocole SSL Record Layer). En réalité le
processus montré précédemment est très compliqué [10].

CHAPITRE II Outils et technologies utilisés
28
4.2. Java et SSL
Java implémente SSL dans un package appelé JSSE (Java Secure Socket Extension), ce package
contient des outils permettant de faire communiquer un serveur HTTPS (serveur sécurisé par SSL)
avec une application cliente en Java.
SSL (aujourd'hui en version 3.0) permet d'utiliser des sockets sécurisés en manipulant des clés
publiques pour l'authentification et des clés privées pour le cryptage. L'API JSSE fournit les classes
permettant de programmer tout ceci en Java: on les trouve dans les paquets javax.net, javax.net.ssl et
javax.security.cert dont les principales classes sont les suivantes [11] :
· SSLSocket et SSLServerSocket ;
· SocketFactory et ServerSocketFactory;
· SSLSocketFactory et SSLServerSocketFactory.
Puisque notre application utilise RMI comme un support de transmission ; les classes
correspondantes sont SslRMIClientSocketFactory et SslRMIServerSocketFactory.
SSL peut être utilisé avec RMI pour assurer :
· L’authentification du serveur et des clients (optionnelle).
· La protection d’accès au RMI Registry : refus des requêtes des clients envoient des certificats
non sécurisées.
· La confidentialité et l’intégrité des données échangées entre le client et le serveur RMI.
L'authentification est réalisée au moyen d'une paire de clés (une clé publique/une clé privée) et d'un
certificat. On peut créer ces clés avec un certificat auto-signé au moyen de keytool, un utilitaire
disponible avec JDK:
keytool -genkey keyalg RSA -alias duke -keypass dukekeypasswd
Quelques autres données peuvent être fournies en paramètre, tel que l’algorithme de cryptage (ici est
RSA), l’alias (ici est "duke") et le mot de passe (ici est "dukekeypasswd").
L’appellation de ces clés se fait par l’invocation (par notre application) des propriétés système :
javax.net.ssl.trustStore et javax.net.ssl.keyStore, et les mots de passe par des propriétés :
javax.net.ssl.trustStorePassword et javax.net.ssl.keyStorePassword.
4. NetBeans
NetBeans est IDE (Integrated Development Environment) pour Java réunissant tous les outils
nécessaires à la création d'applications, aussi complexes qu'elles soient. NetBeans est un
environnement multi plate-forme développé et placé en open source par Sun Microsystems en juin
2000 sous licence CDDL (Common Development and Distribution License). En plus de Java,
NetBeans permet également de supporter différents autres langages, comme Python, C, C++, XML et
HTML. Il comprend toutes les caractéristiques d'un IDE moderne (éditeur en couleur, projets multi-
langage, refactoring, éditeur graphique d'interfaces et de pages web).
Conçu en Java, NetBeans est multilingue disponible sous Windows, Linux, Solaris (sur x86 et
SPARC), Mac OS X et OpenVMS.

CHAPITRE II Outils et technologies utilisés
29
La licence de NetBeans permet de l'utiliser gratuitement à des fins commerciales ou non. Elle permet
de développer tous types d'applications basées sur la plateforme NetBeans. Les modules que vous
pourriez écrire peuvent être open-source comme ils peuvent être closed-source, Ils peuvent être
gratuits, comme ils peuvent être payants [12].
La version 6.0 inclut des améliorations importantes et de nouvelles fonctionnalités, notamment un
éditeur complètement réécrit l'infrastructure, le soutien à d'autres langues, de nouvelles
fonctionnalités de productivité, et un processus d'installation simplifié qui vous permet d'installer et
de configurer l'IDE pour répondre à vos besoins précis (Cf. Figure 2.6).
Figure 2.6 – Interface de L’IDE NetBeans 6.0
Pour autant, il y a aussi beaucoup de nouveautés. En particulier l'éditeur de code a été complètement
réécrit pour permettre de meilleurs refactorisation, le support de nombreux langages au delà de Java
et une utilisation d'écritures imbriqués (JavaScript dans JSP, Java dans PHP, ...). Il y a aussi le
support de nouveaux langages et en particulier pour Ruby et/ou JRuby on Rails. JavaScript, PHP,
Groovy et d'autres ne sont pas loin derrière [13].
5. Conclusion
Le choix d’un langage de développement, un environnement de tests et des
technologies indispensables en général semblent très primordial pour développer une
application d'un bureau distant. L’utilisation de Java représente un intérêt parfait
notamment la portabilité, la robustesse et le multithreading qu’il offre et qui inclue
comme package RMI. Ce dernier est simple à mettre en œuvre dont un objet
distribué se manipule comme tout autre objet Java. SSL en tant que protocole de cryptage
peut être utilisé avec RMI pour assurer une sécurisation d’échange de données et d’authentification.
L'éditeur NetBeans présente un avantage grâce aux fonctionnalités intéressantes qu’il offre.

CHAPITRE III Modélisation et Architecture
28
Chapitre III
Modélisation et Architecture
« Qui veut construire d’abord étudie le terrain, puis fait un tracé du projet. »
William Shakespeare.
1. Introduction
La production et la maintenance de composants logiciels de qualité est faisable et aisé en suivant des
méthodologies adaptées au ingénierie logicielle, tel que le génie logiciel, qui est définie comme un
"ensemble des connaissances, des procédés et des acquis scientifiques et techniques mis en
application pour la conception, le développement, la vérification et la documentation de logiciels,
dans le but d'en optimaliser la production, le support et la qualité." [14]
La modélisation par objets est une technique permet d'obtenir une représentation abstraite du
système. L'approche objet consiste à représenter le système en un ensemble d'entités. L'entité
regroupe des caractéristiques principales (par exemple taille, couleur ….etc.) et des opérations sur ces
caractéristiques (par exemple changer la taille, mélanger les couleurs…etc.).
La démarche suivie dans notre projet est la suivante :
§ Collection, étude et sélection des besoins d'utilisation et des fonctions distinctives offertes par
divers logiciels de bureau à distance existants (listés dans le tableau 1.1).
§ Consultation des cours et des tutoriaux et de la documentation API du Java [15].
§ Exploration du code source des projets open source de bureau à distance développés en Java
(listés dans les tableaux 4.7 et 4.8) pour savoir comment les besoins sont-ils répondus.
§ Essais des différents algorithmes et des techniques (communication par RMI, cryptage,
compression de données, conversion de couleurs…etc.) disponibles sur le net.
§ Développement incrémental de l'application et effectuation des tests en parallèle.
§ En cas de problèmes ; consultation et participation aux divers forums de discussion [16].
§ Hébergement et suivi du notre application sur le net.

CHAPITRE III Modélisation et Architecture
29
2. Modélisation
Dans ce qui suit, on va présenter le diagramme de cas d'utilisation, de classe, de composants et le
diagramme de déploiement de notre application.
2.1. Diagramme de cas d'utilisation
Les cas d'utilisation (en anglais use cases) permettent de représenter le fonctionnement du système
vis-à-vis de l'utilisateur, c'est donc une vue du système dans son environnement extérieur [9].
Le diagramme suivant montre les principaux cas d'utilisation du système developpé (Cf. Figure 3.1):
Figure 3.1 - Diagramme de cas d'utilisation
2.2. Diagramme de classe
Le diagramme de classe est le point central dans un développement orienté objet. En analyse, il a
pour objectif de décrire la structure des entités manipulées par les utilisateurs, et en conception,
le diagramme de classes représente la structure du code source.

CHAPITRE III Modélisation et Architecture
30
Voici un diagramme de classe simplifiée du système (Cf. Figure 3.2):
Figure 3.2 - Diagramme de classe
L'annexe B présente la description détaillée de toutes les classes du notre application jrdesktop.
2.3. Diagramme de composant
Ce diagramme (Cf. Figure 3.3) décrit l'architecture physique de l'application, en terme de modules:
fichiers source, librairies, exécutable…etc [17].
La relation d'utilisation (uses) peut être une des opérations suivantes: lecture, écriture ou mise à jour
sur le fichier. Tous les fichiers utilisés sont de type data (données) dont :
§ config: fichier de la configuration du l'application.
§ server.config: fichier de la configuration du serveur.
§ viewer.config: fichier de la configuration du visualisateur.
§ keystore et truststore: clés de sécurité (requérable par le protocole SSL).
Figure 3.3 - Diagramme de composants

CHAPITRE III Modélisation et Architecture
31
L'application (sous forme d'un paquetage) est composée de 2 sous systèmes Viewer et Server. Les
composants (sous forme d'un fichier de données) sont soit propre au système tout entier, soit relié à
un sous système spécifique.
Les fichiers de configuration seront crées de nouveau à leurs première utilisation, si l'utilisateur
supprime un de ces fichiers, ils sont récrées dans leur prochaine appels (avec des paramètres par
défaut).
Les clés de sécurité sont nécessaires pour les communications sécurisées avec SSL, si elles sont
supprimées, elles seront automatiquement extraites du fichier archive jrdesktop.jar
2.4. Diagramme de déploiement
Le diagramme de déploiement montre la disposition physique des matériels qui composent le
système, et la répartition des composants sur ces systèmes [17].
Le diagramme (Cf. Figure 3.4) est constitué de deux nœuds matériels de même type (un ordinateur de
bureau).
JRE (Java Runtime Execution) ou simplement la mémoire virtuelle (JVM) représente l'enivrement
d'exécution du notre application qui est implémenté à chaque machine.
A Chaque JVM; une instance de jrdesktop est en exécution, l'une des instances représente le
visualisateur et l'autre le serveur jrdesktop. Le visualisateur dispose d'une interface client pour
faciliter à l'utilisateur l'observation et/ou le contrôle. Ainsi, Plusieurs visulisateurs peuvent connectés
à un server jrdesktop.
TCP/IP représente le support de communication qui relie les visualisateurs avec le serveur distant.
Figure 3.4 - Diagramme de déploiement

CHAPITRE III Modélisation et Architecture
32
3. Architecture de l'application
Dans ce qui suit, on va présenter l'architecture générale et le fonctionnement de notre application
jrdesktop.
Au moins deux modules de base (Admin et Hôte) sont nécessaires pour établir le bureau distant. Ces
modules sont liés par un réseau TCP/TP (LAN, MAN ou WAN).
Tandis que le module Hôte fait à touts moment des impressions de son écran; la fenêtre principale du
module Admin enregistre la trace de tous les événements clavier et souris générés par l'utilisateur du
système.
D'une façon simplifiée, deux flots de données passent entre les deux modules d'une manière
permanente grâce à l'exécution des boucles infinies utilisées par des threads implémentés aux
modules, ces flots sont: le transfert des événements clavier et souris vers l'Hôte vis-à-vis la
récupération des captures d'écran par l'Admin (Cf. Figure 3.5).
Figure 3.5 – Schéma général d'une application de bureau distant
3.1. Architecture générale
Puisque jrdesktop est entièrement développé en Java; il hérite alors tous les avantages du Java, tel
que la portabilité. jrdesktop peut être exécuté dans n'importe quelle plateforme où Java est installé.
jrdesktop est une application portable qui n'a pas besoin d'un module d'installation. Le visualisateurs
et le server sont regroupés en une seule application dans un seul fichier exécutable. Tous les fichiers
nécessaires au fonctionnement de l'application (fichiers binaires, images, fichiers de configuration et
de sécurité) sont stockés dans le fichier archive (porte l'extension .jar) de l'application qui a une taille
inférieur à 300 KB.
La structure de l'application est hiérarchique; elle est composée d'un ensemble de sous-paquetages
imbriqués; chaque paquetage peut contenir un ensemble de classes. Les paquetages sont les suivants:
+ jrdesktop: paquetage principal;
+ jrdesktop.viewer: paquetage visualisateur;
+ jrdesktop.viewer.main: paquetage principal du visualisateur;
- jrdesktop.viewer.FileMng: paquetage de la gestion de fichiers;
- jrdesktop.viewer.rmi: paquetage RMI du visualisateur;
+ jrdesktop.server: paquetage serveur;
- jrdesktop.server.main: paquetage principal du serveur;
- jrdesktop.server.rmi: paquetage RMI du serveur;
- jrdesktop.utilities: paquetage utilitaire;
- jrdesktop.images: paquetage d'images.

CHAPITRE III Modélisation et Architecture
33
Parce que l'application est distribuée, et utilise la technologie RMI pour la communication; elle est
divisée en deux modules – de base - Viewer et Server. Les paquetages jrdesktop, utilities et images
sont partagés entre les deux modules, de plus, chaque module à ses propres paquetages: main et rmi.
Voici les différentes associations utilisées dans le diagramme de paquetage (tableau 3.1):
DescriptionAssociation
Association à navigabilité restreinte
(association directionnel)
le serveur est le propriétaire du robot
Association bidirectionnelle
Relation de réutilisation
ServerInterface est une classe réutilisable
(représente le comportement visible du ServerImpl)
Relation d'inclusion
ImageSelection est incluse dans ClibprdUtility
Tableau 3.1 - Diverses associations
Le schéma suivant (Cf. Figure 3.6) présente le diagramme de paquetage du jrdesktop, le diagramme
est automatiquement généré par l'outil Reverse Engineering qui permet d'obtenir les différents
diagrammes UML à partir d'un code source écrit par un langage objet (tel que Java et C++).

CHAPITRE III Modélisation et Architecture
34
Figure 3.6 - Diagramme de paquetage
3.2. Architecture RMI
La communication entre les modules se fait par l'invocation de méthodes distantes en utilisant RMI
(Remote Method Invocation). Les modules (serveur et visualisateur) représentent des objets distants
communiquent entre eux (d'une façon transparente par l'utilisateur). RMI facilite l'échange des
messages entre objets distribués.
L'application du jrdesktop est constituée de deux sous systèmes (Viewer et Server). Chaque module
est constitué d'un ensemble de sous modules communiquant par messages entre eux.
Le visualisateur et à travers un objet instancié du classe ServerInterface fait appel à des méthodes
distants du ServerImpl (implémenté du ServerInterface). A son tour; ServerImpl exécute les
méthodes serveurs et renvoie optionnellement des valeurs.
Le schéma suivant (Cf. Figure 3.7) présente les couches RMI et la correspondance avec le modèle
TCP/IP

CHAPITRE III Modélisation et Architecture
35
Figure 3.7 – Architecture RMI du jrdesktop
Tandis que les classes stub et le skeleton (générés par l'utilitaire rmic du JDK) assurent la conversion
des communications avec l'objet distant; Le registre RMI (ou bien la couche RRL) traduit et gère les
références vers les objets distant.
3.3. Communication entre modules
Avant d'étudier l'architecture des modules du jrdesktop, on s'intéresse sur la nature des données
échangées entre les modules.
La communication entre le visualisateur et le serveur est gérée par le protocole JRMP (Java Remote
Method Protocol). Le passage de données est par défaut non sécurisé. Le protocole SSL peut être
utilisé en conjonction avec JRMP pour établir une connexion sécurisée entre les deux modules.
Les flux de données échangés entre modules sont :
§ Authentification : demande de la connexion ou de la déconnexion d'un visualisateur à un
serveur jrdesktop. Si l'opération a échouée, une erreur est signalée. Ce flux peut contenir
plusieurs informations tel que : l'adresse IP et le port du serveur, le nom et le mot de passe
d'utilisateur et le type de connexion (sécurisée ou non).
§ Transfert des entrées-sorties: passage des événements clavier et souris (comme entrées) et
des imprimes d'écran (sorties). Ce transfert s'effectue d'une manière permanente.
§ Transfert des paramètres: transférer des options sélectionnées du visualisateur vers le
serveur pour être appliqués dans le transfert de données, tel que: l'activation de la
compression, le passage du contenu du presse-papiers…etc.
§ Transfert de fichiers: opération de la copie des fichiers (de petites tailles) listés dans le
presse-papiers d'un PC vers la mémoire de stockage de l'autre PC, ou par un glissement des
fichiers sur la fenêtre de la visualisation pour les transmettre au serveur.
Sauf dans le cas d'envoi des paramètres; le passage de tous les flux est bidirectionnel. Ainsi, tous ces
flux passent d'une façon facultative et seulement à la demande, excepte celui d'entrées-sorties.

CHAPITRE III Modélisation et Architecture
36
Voici un schéma (Cf. Figure 3.8) présente les types de flux de données échangés entre le
visualisateur et le serveur.
Figure 3.8 - Flux de données échangés entre modules
Ces flux sont établis par appel de méthodes distantes depuis le visualisateur, et - optionnellement - la
récupération du résultat des méthodes appelées. Les méthodes sont les suivantes:
§ startViewer et stopViewer pour l'authentification ;
§ updateData : pour le transfert d'entrées-sorties ;
§ updateOptions : pour l'envoi des paramètres ;
§ sendFile et receiveFile : pour la transmission des fichiers.
3.4. Architecture des modules
Après avoir vu comment les données sont transférées entre modules, on s'intéresse maintenant à
l'architecture interne de chaque module.
Chaque module dispose d'un ensemble d'outils pour prendre le contrôle des ressources tel que:
clavier, souris, écran, presse-papiers et un ensemble de structures (objets, listes, tableaux…etc.).
Dans ce qui suit, on essaye d'expliquer le rôle et le fonctionnement de chaque outil et structure.
Les outils de contrôle de clavier, souris et écran sont partagées à tous les visualisateurs, les structures
sont particulières, chaque visualisateur dispose ses propres structures. Les structures particulières
(dans les deux modules) sont crées juste après l'authentification et détruites lorsque la session est
terminée.
a. Module Viewer (Admin) :
Ce module (Cf. Figure 3.9) est responsable de la visualisation, à travers une interface utilisateur
(GUI); l'utilisateur peut facilement observer ou contrôler l'ordinateur distant. Plusieurs
fonctionnalités sont à leur disposition, tel que la possibilité de suspendre et de reprendre la
visualisation, changer la taille et le zoom d'écran, régler le niveau de la compression et choisir la
palette de couleurs souhaitable….etc.
Le module est construit d'un ensemble de paquetages, classes, fenêtres, objets…etc.

CHAPITRE III Modélisation et Architecture
37
Figure 3.9 – L'architecture interne du module Viewer
Dans ce qui suit on va voir les principaux sous composants du module qu’on a appelé « Viewer » qui
désigne le visualisateur ou le contrôleur.
§ (1) : La classe principale est « Viewer », cette classe est responsable de la communication avec le
serveur. Lorsque on veut envoyer ou recevoir une donnée, le visualisateur cherche dans le registre
RMI l'objet désiré, lorsque sa référence est récupérée, la méthode distante est invoquée (et
optionnellement, cette méthode renvoie une valeur en retour).
§ (2) : La configuration de la connexion de ce module est gérée par une classe spéciale surnommée
« Config » où on trouve un ensemble de paramètres configurables tel que: l'adresse IP et le port
du serveur, le nom et le mot de passe d'utilisateur et l'activation (ou non) de la sécurité. L'intérêt
de cette classe est d'éviter l'insertion des paramètres à chaque nouvelle session, car ils sont
récupérés du fichier de la configuration qui est situé sur le disque dur.
§ (3) : « Recorder » est une classe (sorte de processeur) qui gère le module tout entier, on trouve à
cette classe la définition de l'ensemble des ressources, la boucle permanente qui est responsable
d'émission et de réception des données et les opérations de lancement et d'arrêt du système.
§ (4) : L'interface utilisateur « ViewerGUI » permet au visualisateur de contrôler la visualisation
toute entière. C'est une fenêtre où il y a des boutons, cases à cochés, listes déroulantes...etc.
§ (5) : « ScreenPlayer » est un sous composant de GUI (de type JPanel) où on observe et on
contrôle l'ordinateur distant par l'affichage des captures d'écran reçues, la récupération et puis
l'envoi de la position du curseur et touches appuyées.
§ (6) : Le presse-papiers (clipboard en anglais) est administré par une classe utilitaire nommée
« ClipbrdUtility », son rôle est l'observation du contenu, et la récupération de ce contenu à la
demande. Le contenu peut être des textes, images ou listes de fichiers et/ou des dossiers.

CHAPITRE III Modélisation et Architecture
38
§ (7) : Les statistiques sont gérées par la classe « ConnectionInfo », à chaque transfert de données,
la classe est appelée pour faire une mise à jour des données suivantes: la durée de transmission,
taille des données émises et reçues et vitesse de transfert.
§ (8) : « FileManager » est responsable de la communication avec la mémoire morte (disque dur)
par le placement des fichiers et/ou des dossiers reçus du serveur, ou la récupération des fichiers
et/ou des dossiers pour être transférés à l'ordinateur distant.
§ (9) : Les paramètres de la visualisation sont gérés par la classe « ViewerData », tel que le niveau
de compression, palettes des couleurs utilisées, taille de l'écran, niveau de qualité d'image
JPEG…etc. Une copie entière de ces paramètres est dans la possession du serveur pour assurer
une gestion efficace de tous les visualisateurs connectés.
Outre les présidents composants, ce module contient d'autres fenêtres de dialogue, et d'autres classes.
(La structure de chaque classe est détaillée dans l'annexe B).
La structure objet du jrdesktop donne la possibilité d'utiliser autant de visualisateurs (dans la même
machine) sans avoir une interférence entre eux.
b. Module Server (Hôte) :
Ce module (Cf. Figure 3.10) est responsable de la production des captures d'écran et d'application des
événements clavier et souris reçus par les visualisateurs. L'utilisateur peut facilement lancer, arrêter
ou bien configurer le serveur. Ainsi, le module dispose d'une interface graphique qui permet de gérer
les visualisateurs connectés.
Figure 3.10 - La structure interne du module Server
Par l'exécution de jrdesktop, une seule instance de ce module peut être crée.
Le module est construit d'un ensemble de paquetages, classes, fenêtres, objets…etc. Dans ce qui suit
on va voir les principaux sous composants de ce module.

CHAPITRE III Modélisation et Architecture
39
§ (1): Outre la communication et la gestion des visualisateurs connectés, la classe « Server »
est responsable du lancement et d'arrêt du serveur RMI. Ainsi la construction du Registre RMI.
§ (2): « robot » est une classe hérité du Robot du Java (cette classe est originalement développée
pour la génération des tests automatisés des applications Java). robot est responsable de la
production des événements d'entrées (clavier + souris) virtuels, c'est-à-dire le déplacement du
curseur sur l'écran et la réponse aux touches appuyées par le visualisateur. L'utilisation de cette
classe est partagée avec tous les visualisateurs connectés.
§ (3): La configuration de la connexion de ce module est gérée par une classe spéciale où on trouve
un ensemble de paramètres configurables tel que: l'adresse IP local et le port par défaut, le nom
d'utilisateur et le mot de passe et l'activation (ou non) de la sécurité, l'utilisation (ou non) d'un
serveur multihome. L'intérêt de cette classe est d'éviter l'insertion des paramètres à chaque
lancement du serveur, car ils sont récupérés du fichier de la configuration qui est situé sur le
disque dur.
§ (4): La même classe utilisée dans le visualisateur (même fonctionnement).
§ (5): Les données des clients connectées sont stockées dans une liste tabulaire (de type ArrayList),
cette liste permet de traiter les besoins de chaque visualisateur séparaient, chaque entrée de cette
liste est un objet de type ViewerData (voir le composant 9 du visualisateur).
§ (6): De même, Les statistiques des visualisateurs sont gérées par la classe ConnectionsInfo (sous
forme d'une liste tabulaire). A chaque transfert de données; la classe est appelé pour faire une
mise à jour des données suivantes: la durée de la transmission, taille des données émises et reçues
et vitesse de transfert. Chaque entrée de cette liste est un objet de type ConnectionInfo (voir le
composant 7 du visualisateur).
§ (7): FileManager est responsable de la communication avec la mémoire morte (le disque dur par
exemple) par le placement des fichiers et/ou des dossiers reçus à partir du visualisateur. Ainsi, la
récupération des fichiers et/ou des dossiers pour être transférés à l'ordinateur distant.
Outre les présidents composants, le module contient d'autres fenêtres de dialogue, et d'autres classes.
(La structure de chaque classe est détaillée dans l'annexe B).
Contrairement au module Viewer; une seule instance de ce module peut être lancée dans une
exécution de l'application jrdesktop.
3.5. Fonctionnalités de base
Après avoir vu l'architecture générale du jrdesktop et la structure des modules Viewer et Server et la
manière de communication entre eux; on va présenter dans cette partie quelques aperçues du code
source on inspirant à faciliter la tache aux lecteurs de comprendre le fonctionnement de l'application.
3.5.1. Transfert de données
Dans cette partie, on va présenter la nature des données transférées entre les modules, le transfert ce
fait par appel des méthodes distants par le visualisateur, et la réception optionnelle des valeurs en
retour.