République Algérienne Démocratique et Populaire
Ministère de l’Enseignement Supérieur et de la Recherche Scientifique
Univ...
Remerciements
Nous tenons à remercier en premier lieu notre Dieu qui nous a
donné la santé, la force et le courage pour me...
Résumé
Un des plus grands challenges de cette décennie est sans aucun doute le bureau distant car il
s’articule autour de ...
Abstract
One of the biggest challenges of this decade is undoubtedly the remote desktop because it
revolves around several...
Table des matières
I
Table des matières
INTRODUCTION GENERALE ...............................................................
Table des matières
II
3.3.1. Interface ......................................................................................
Table des matières
III
3.3. CONFIGURATION DE MODULE HOTE ....................................................................
Liste des figures et des tableaux
I
Liste des figures
Figure 1.1 -Les Applications du bureau distant 4
Figure 1.2 -Echange...
Liste des figures et des tableaux
II
Figure 4.24 - Gain de la compression en pourcentage (%) 69
Figure 4.25 - Transfert de...
Introduction générale
1
Introduction Générale
« Fort heureusement, chaque réussite est l'échec d'autre chose. »
Jacques Pr...
Introduction générale
2
Le bureau distant présente une solution idéale pour offrir une assistance à distance
rapide et aid...
CHAPITRE I Le bureau distant
3
Chapitre I
Le bureau distant
« C'est le commencement exact de notre fine »
William Shakespe...
CHAPITRE I Le bureau distant
4
Ces différents points montrent l'importance du bureau à distance notamment dans un réseau é...
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 t...
CHAPITRE I Le bureau distant
6
§ communication et organisation plus efficace.
On distingue parmi les différents types de r...
CHAPITRE I Le bureau distant
7
1. Module Admin (comme administrateur, appelé aussi "client", "visualisateur" (viewer) ou
l...
CHAPITRE I Le bureau distant
8
6.1. Problématiques et solutions appropriées
Plusieurs facteurs peuvent empêcher l'établiss...
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 (p...
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.2...
CHAPITRE I Le bureau distant
11
Figure 1.5 - Diverses fonctionnalités d'echoServer
6.2.4. Tunnel http
C’est une technique ...
CHAPITRE I Le bureau distant
12
8. Comparer des différents logiciels de bureau à distance
Il existe déjà plusieurs logicie...
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...
CHAPITRE II Outils et technologies utilisés
17
Vous pouvez ainsi envoyer et recevoir
des emails, surfer sur le web, éditer...
CHAPITRE II Outils et technologies utilisés
18
Chapitre II
Outils et technologies utilisés
« Chaque mot est un préjugé »
F...
CHAPITRE II Outils et technologies utilisés
19
1. La mémoire dans Java est être allouée et libérée automatiquement. Vous n...
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é ...
CHAPITRE II Outils et technologies utilisés
21
Par conséquent, la compréhension de RMI réside dans le fait que les interfa...
CHAPITRE II Outils et technologies utilisés
22
3.3.2.3. Couche Transport
La couche transport est basée sur les connexions ...
CHAPITRE II Outils et technologies utilisés
23
Figure 2.2 – les opérations de communication
3.4. Processus de développemen...
CHAPITRE II Outils et technologies utilisés
24
Figure 2.3 – Invocation d’une méthode distante et renvoie de la valeur de r...
CHAPITRE II Outils et technologies utilisés
25
g- Lancement de l’application cliente
Il est maintenant possible d’exécuter...
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. Foncti...
CHAPITRE II Outils et technologies utilisés
27
Figure 2.5 – Étapes d’établissement des connections SSL
Comme vous pouvez l...
CHAPITRE II Outils et technologies utilisés
28
4.2. Java et SSL
Java implémente SSL dans un package appelé JSSE (Java Secu...
CHAPITRE II Outils et technologies utilisés
29
La licence de NetBeans permet de l'utiliser gratuitement à des fins commerc...
CHAPITRE III Modélisation et Architecture
28
Chapitre III
Modélisation et Architecture
« Qui veut construire d’abord étudi...
CHAPITRE III Modélisation et Architecture
29
2. Modélisation
Dans ce qui suit, on va présenter le diagramme de cas d'utili...
CHAPITRE III Modélisation et Architecture
30
Voici un diagramme de classe simplifiée du système (Cf. Figure 3.2):
Figure 3...
CHAPITRE III Modélisation et Architecture
31
L'application (sous forme d'un paquetage) est composée de 2 sous systèmes Vie...
CHAPITRE III Modélisation et Architecture
32
3. Architecture de l'application
Dans ce qui suit, on va présenter l'architec...
CHAPITRE III Modélisation et Architecture
33
Parce que l'application est distribuée, et utilise la technologie RMI pour la...
CHAPITRE III Modélisation et Architecture
34
Figure 3.6 - Diagramme de paquetage
3.2. Architecture RMI
La communication en...
CHAPITRE III Modélisation et Architecture
35
Figure 3.7 – Architecture RMI du jrdesktop
Tandis que les classes stub et le ...
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...
CHAPITRE III Modélisation et Architecture
37
Figure 3.9 – L'architecture interne du module Viewer
Dans ce qui suit on va v...
CHAPITRE III Modélisation et Architecture
38
§ (7) : Les statistiques sont gérées par la classe « ConnectionInfo », à chaq...
CHAPITRE III Modélisation et Architecture
39
§ (1): Outre la communication et la gestion des visualisateurs connectés, la ...
Étude et réalisation d’une application de contrôle d’un PC à distance en JAVA - jrdesktop
Étude et réalisation d’une application de contrôle d’un PC à distance en JAVA - jrdesktop
Étude et réalisation d’une application de contrôle d’un PC à distance en JAVA - jrdesktop
Étude et réalisation d’une application de contrôle d’un PC à distance en JAVA - jrdesktop
Étude et réalisation d’une application de contrôle d’un PC à distance en JAVA - jrdesktop
Étude et réalisation d’une application de contrôle d’un PC à distance en JAVA - jrdesktop
Étude et réalisation d’une application de contrôle d’un PC à distance en JAVA - jrdesktop
Étude et réalisation d’une application de contrôle d’un PC à distance en JAVA - jrdesktop
Étude et réalisation d’une application de contrôle d’un PC à distance en JAVA - jrdesktop
Étude et réalisation d’une application de contrôle d’un PC à distance en JAVA - jrdesktop
Étude et réalisation d’une application de contrôle d’un PC à distance en JAVA - jrdesktop
Étude et réalisation d’une application de contrôle d’un PC à distance en JAVA - jrdesktop
Étude et réalisation d’une application de contrôle d’un PC à distance en JAVA - jrdesktop
Étude et réalisation d’une application de contrôle d’un PC à distance en JAVA - jrdesktop
Étude et réalisation d’une application de contrôle d’un PC à distance en JAVA - jrdesktop
Étude et réalisation d’une application de contrôle d’un PC à distance en JAVA - jrdesktop
Étude et réalisation d’une application de contrôle d’un PC à distance en JAVA - jrdesktop
Étude et réalisation d’une application de contrôle d’un PC à distance en JAVA - jrdesktop
Étude et réalisation d’une application de contrôle d’un PC à distance en JAVA - jrdesktop
Étude et réalisation d’une application de contrôle d’un PC à distance en JAVA - jrdesktop
Étude et réalisation d’une application de contrôle d’un PC à distance en JAVA - jrdesktop
Étude et réalisation d’une application de contrôle d’un PC à distance en JAVA - jrdesktop
Étude et réalisation d’une application de contrôle d’un PC à distance en JAVA - jrdesktop
Étude et réalisation d’une application de contrôle d’un PC à distance en JAVA - jrdesktop
Étude et réalisation d’une application de contrôle d’un PC à distance en JAVA - jrdesktop
Étude et réalisation d’une application de contrôle d’un PC à distance en JAVA - jrdesktop
Étude et réalisation d’une application de contrôle d’un PC à distance en JAVA - jrdesktop
Étude et réalisation d’une application de contrôle d’un PC à distance en JAVA - jrdesktop
Étude et réalisation d’une application de contrôle d’un PC à distance en JAVA - jrdesktop
Étude et réalisation d’une application de contrôle d’un PC à distance en JAVA - jrdesktop
Étude et réalisation d’une application de contrôle d’un PC à distance en JAVA - jrdesktop
Étude et réalisation d’une application de contrôle d’un PC à distance en JAVA - jrdesktop
Étude et réalisation d’une application de contrôle d’un PC à distance en JAVA - jrdesktop
Étude et réalisation d’une application de contrôle d’un PC à distance en JAVA - jrdesktop
Étude et réalisation d’une application de contrôle d’un PC à distance en JAVA - jrdesktop
Étude et réalisation d’une application de contrôle d’un PC à distance en JAVA - jrdesktop
Étude et réalisation d’une application de contrôle d’un PC à distance en JAVA - jrdesktop
Étude et réalisation d’une application de contrôle d’un PC à distance en JAVA - jrdesktop
Étude et réalisation d’une application de contrôle d’un PC à distance en JAVA - jrdesktop
Étude et réalisation d’une application de contrôle d’un PC à distance en JAVA - jrdesktop
Étude et réalisation d’une application de contrôle d’un PC à distance en JAVA - jrdesktop
Étude et réalisation d’une application de contrôle d’un PC à distance en JAVA - jrdesktop
Étude et réalisation d’une application de contrôle d’un PC à distance en JAVA - jrdesktop
Étude et réalisation d’une application de contrôle d’un PC à distance en JAVA - jrdesktop
Étude et réalisation d’une application de contrôle d’un PC à distance en JAVA - jrdesktop
Étude et réalisation d’une application de contrôle d’un PC à distance en JAVA - jrdesktop
Étude et réalisation d’une application de contrôle d’un PC à distance en JAVA - jrdesktop
Étude et réalisation d’une application de contrôle d’un PC à distance en JAVA - jrdesktop
Étude et réalisation d’une application de contrôle d’un PC à distance en JAVA - jrdesktop
Étude et réalisation d’une application de contrôle d’un PC à distance en JAVA - jrdesktop
Étude et réalisation d’une application de contrôle d’un PC à distance en JAVA - jrdesktop
Étude et réalisation d’une application de contrôle d’un PC à distance en JAVA - jrdesktop
Étude et réalisation d’une application de contrôle d’un PC à distance en JAVA - jrdesktop
Étude et réalisation d’une application de contrôle d’un PC à distance en JAVA - jrdesktop
Étude et réalisation d’une application de contrôle d’un PC à distance en JAVA - jrdesktop
Étude et réalisation d’une application de contrôle d’un PC à distance en JAVA - jrdesktop
Étude et réalisation d’une application de contrôle d’un PC à distance en JAVA - jrdesktop
Étude et réalisation d’une application de contrôle d’un PC à distance en JAVA - jrdesktop
Étude et réalisation d’une application de contrôle d’un PC à distance en JAVA - jrdesktop
Étude et réalisation d’une application de contrôle d’un PC à distance en JAVA - jrdesktop
Étude et réalisation d’une application de contrôle d’un PC à distance en JAVA - jrdesktop
Étude et réalisation d’une application de contrôle d’un PC à distance en JAVA - jrdesktop
Étude et réalisation d’une application de contrôle d’un PC à distance en JAVA - jrdesktop
Étude et réalisation d’une application de contrôle d’un PC à distance en JAVA - jrdesktop
Étude et réalisation d’une application de contrôle d’un PC à distance en JAVA - jrdesktop
Étude et réalisation d’une application de contrôle d’un PC à distance en JAVA - jrdesktop
Étude et réalisation d’une application de contrôle d’un PC à distance en JAVA - jrdesktop
Étude et réalisation d’une application de contrôle d’un PC à distance en JAVA - jrdesktop
Étude et réalisation d’une application de contrôle d’un PC à distance en JAVA - jrdesktop
Étude et réalisation d’une application de contrôle d’un PC à distance en JAVA - jrdesktop
Étude et réalisation d’une application de contrôle d’un PC à distance en JAVA - jrdesktop
Prochain SlideShare
Chargement dans…5
×

Étude et réalisation d’une application de contrôle d’un PC à distance en JAVA - jrdesktop

413 vues

Publié le

De nouvelles applications apparaissent chaque jour qui se déroulent à distance pour: vidéoconférence, assistance à distance (helpdesk), enseignement à distance, maintenance et télétravail. Le bureau distant garantissant: la sécurité de l’accès, la mobilité des utilisateurs et la mise à disposition des applications.

Java Remote Desktop (jrdesktop) est un logiciel multi-plateforme pour le contrôle de bureau à distance, l'assistance à distance et le partage de bureau, l'outil est utile pour les réseaux domestiques, help desk, l'administration du système et de la collaboration.

Publié dans : Formation
0 commentaire
0 j’aime
Statistiques
Remarques
  • Soyez le premier à commenter

  • Soyez le premier à aimer ceci

Aucun téléchargement
Vues
Nombre de vues
413
Sur SlideShare
0
Issues des intégrations
0
Intégrations
3
Actions
Partages
0
Téléchargements
10
Commentaires
0
J’aime
0
Intégrations 0
Aucune incorporation

Aucune remarque pour cette diapositive

Étude et réalisation d’une application de contrôle d’un PC à distance en JAVA - jrdesktop

  1. 1. 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
  2. 2. 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.
  3. 3. 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
  4. 4. 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.
  5. 5. 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
  6. 6. 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
  7. 7. 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
  8. 8. 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
  9. 9. 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
  10. 10. 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.
  11. 11. 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.
  12. 12. 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. · ...
  13. 13. 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.
  14. 14. 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;
  15. 15. 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 :
  16. 16. 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.
  17. 17. 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.
  18. 18. 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
  19. 19. 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.
  20. 20. 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.
  21. 21. 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
  22. 22. CHAPITRE I Le bureau distant 13 :disponible×:nondisponible Tableau1.1–Comparaisondesdiversesapplicationsdebureaudistant[4]
  23. 23. 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.
  24. 24. 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.
  25. 25. 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] :
  26. 26. 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].
  27. 27. 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.
  28. 28. 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.
  29. 29. 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).
  30. 30. 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.
  31. 31. 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")
  32. 32. 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] :
  33. 33. 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).
  34. 34. 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].
  35. 35. 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.
  36. 36. 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.
  37. 37. 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.
  38. 38. 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.
  39. 39. 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
  40. 40. 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
  41. 41. 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.
  42. 42. 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++).
  43. 43. 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
  44. 44. 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.
  45. 45. 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.
  46. 46. 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.
  47. 47. 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.
  48. 48. 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.

×