APPLICATION REPARTIE AVEC JAVA

REMOTE METHOD INVOCATION

(RMI)
Présenter par:
Professeur:
• DIAKITE PENNAVAYRE
SIDNEY • Dr ZOUNEME BORIS

• ANONKRE ANGE PARFAIT

 SOMMAIRE

I. INTRODUCTION

II. ARCHITECTURE DES APPLICATIONS DISTRIBUER OU REPARTIS AVEC JAVA RMI

III. LES PACKAGES DE JAVA RMI

IV. STRATEGIE DE SECURITE EN JAVA RMI

V. COMPARAISON DE JAVA RMI AUX AUTRES TECHNOLOGIES

CONCLUSION
I. INTRODUCTION
1. HISTORIQUE APPLICATION REPARTIE OU DISTRIBUE

L'histoire des applications réparties remonte aux débuts de l'informatique. Dans les années
1960, les entreprises ont commencé à utiliser des ordinateurs centraux pour stocker et traiter
des données pour leurs activités commerciales. Cependant, ces ordinateurs centraux étaient
souvent coûteux et nécessitaient beaucoup de ressources, ce qui limitait leur accessibilité.

Dans les années 1970, les chercheurs ont commencé à développer des réseaux informatiques
pour connecter les ordinateurs entre eux. Cela a permis de partager les ressources
informatiques et d'améliorer la communication entre les différents systèmes. Les premières
applications réparties ont alors vu le jour, notamment dans les domaines de la recherche
scientifique et militaire.

Dans les années 1980 et 1990, les applications réparties ont connu un essor avec le
développement de l'architecture client-serveur et l'avènement d'Internet. Les applications
réparties ont commencé à être utilisées dans le monde des affaires pour faciliter la
communication et la collaboration entre les employés, ainsi que pour stocker et gérer des
données à grande échelle.
Au cours des deux dernières décennies, l'avancement des technologies informatiques, telles que
les services Web, les conteneurs et les systèmes de gestion de données distribuées, ont permis
de rendre les applications réparties encore plus performantes et résilientes aux pannes. Les
applications réparties sont devenues un élément clé de l'infrastructure informatique pour de
nombreuses entreprises, notamment celles qui fournissent des services en ligne à grande
échelle, telles que les plateformes de réseaux sociaux, les systèmes de paiement en ligne et les
applications de stockage de données en nuage.
Dans notre exposer nous allons parler des applications repartis et plus précisement des
application repartis avec java RM (Remote method)
 2. DEFINTION D’UNE APPLICATION REPARTIE ET RMI

Une application répartie (ou application distribuée) est un type de logiciel qui est conçu pour
fonctionner sur un ensemble de machines interconnectées plutôt que sur une seule machine. Les
applications réparties sont généralement utilisées pour des systèmes nécessitant une haute
disponibilité, une scalabilité et une tolérance aux pannes.

Dans une application répartie, les différents composants logiciels sont exécutés sur plusieurs
machines différentes qui communiquent entre elles pour réaliser une tâche commune. Les
données sont également réparties entre les différentes machines du système pour améliorer les
performances et la disponibilité.

"Java RMI" RMI signifie "Remote Method Invocation", qui est une technologie Java permettant à
des programmes Java de communiquer à distance via le réseau. Il permet à un objet Java
d'appeler des méthodes sur un objet distant comme s'il s'agissait d'un objet local.

En d'autres termes, RMI fournit une communication client-serveur transparente et orientée objet
pour les programmes Java. Il est utilisé pour construire des systèmes distribués basés sur Java, tels
que des applications de serveur, des applications de middleware et des services Web.
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 reste lamême que pour les applications
habituelles. RMI est apparu dès la version 1.1 du JDK et a été étoffé pour la version 2.
II. ARCHITECTURE DES APPLICATIONS DISTRIBUER OU REPARTIS AVEC JAVA RMI

1. Interface

L’interface est le cœur de RMI. L’architecture RMI est basé 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(java virtual machine) 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. RMI supporte deux types de classe qui
implémentent 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 proxypour 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.
 2. LES DIFFERENTES COUCHES DE JAVA RMI

RMI est essentiellement construit sur une abstraction en trois couches.

• La première couche est celle des Stubs et Skeletons. Cette couche intercepte les appels de
méthodes lancés par le client à l’interface de référence et redirige ces appels à un service
RMI distant. Cette structure évite au programmeur de devoir communiquer explicitement
avec l’objet distant.

• Remote reference layer: 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). Dans le JDK 1.1, cette
couche connecte les clients aux objets du service distant qui sont exécutés et exportés sur
un serveur. Cette connexion est unicast (point à point). Dans le JDK 2, cette couche a été
améliorée pour soutenir l'activation des objets du service distant en sommeil via la classe
Remote Object Activation. Elle assure une référence persistante vers des objets distants
(reconnexion éventuelle).
La troisième couche est la couche transport est basée sur les connexions TCP/IP entre les
machines. Elle fournit la connectivité de base entre les 2 JVM. 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.
 3. UTILISATION DE JAVA RMI

Tout d’abord pour coder en Java RM, vous devez utiliser un environnement de développement
Java, tel que Eclipse, NetBeans ou IntelliJ IDEA.
Voici les étapes générales pour coder une application utilisant Java RM :
• Définir les interfaces distantes : Les interfaces distantes définissent les méthodes que les
clients peuvent appeler sur les objets distants. Les interfaces distantes doivent être définies
dans un fichier d'interface Java et doivent étendre l'interface java.rmi.Remote.

• Implémenter les interfaces distantes : Les implémentations des interfaces distantes sont les
objets réels qui fournissent les fonctionnalités que les clients peuvent appeler à distance. Les
implémentations des interfaces distantes doivent être des classes Java qui implémentent les
interfaces définies dans l'étape 1.

• Compiler et générer les stubs et les skeletons : Les stubs et les skeletons sont des classes Java
générées automatiquement qui facilitent la communication entre les processus distants. Les
stubs sont des objets côté client qui appellent les méthodes sur les objets distants, tandis que
les skeletons sont des objets côté serveur qui reçoivent les appels des clients et les
transmettent aux objets distants.
• Déployer l'application : Une fois que les classes ont été compilées et que les stubs et les
skeletons ont été générés, vous pouvez déployer l'application en exécutant le serveur et en
installant les classes et les fichiers de configuration nécessaires sur les clients.

• Exécuter l'application : Les clients peuvent utiliser l'application en instanciant les stubs et en
appelant les méthodes sur les objets distants à l'aide des interfaces définies.
III. LES PACKAGES DE JAVA RMI
1. INTERFACE REMOTE

L’interface Remotesert à identifier les interfaces dont les méthodes pourront être invoquées
depuis une JVM distante. Chaque objet distant doit implémenter cette interface directement ou
indirectement.Seules les méthodes spécifiées dans une interface distante sont disponibles à
distances.

Les classes d’implémentation peuvent implémenter plusieurs interfaces distantes et peuvent

hériter d’autres classes d’implémentation distantes. RMI fournit quelques classes dont les objets
distants peuvent hériter et qui facilitent la création d’objets distants (ex : la classe
UnicastRemoteObject).
 2. LES DIFFERENTES CLASSES D’IMPLEMENTATION

• La classe UnicastRemoteObject définit un objet non répliqué dont les références sont valides
seulement si le processus serveur est actif.

Elle fournit un support pour les références à des objets actifs utilisant des flux TCP/IP. Les objets
qui exigent un comportement distant doivent étendre de RemoteObject, typiquement via
UnicastRemoteObject.

Dans le cas contraire, ils doivent alors assumer eux-mêmes la responsabilité des méthodes
hashCode(), equals()et toString(). Il est donc plus simple d’utiliser la classe
UnicastRemoteObject, car vous n’avez pas à définir vous même ces méthodes.

Le constructeur par défaut utilise le port TCP 1099. Il est toutefois possible d’utiliser un autre
constructeur qui prend en paramètre un int correspondant au numéro de port à utiliser pour le
transfert des paquets TCP.
• La classe Naming

La classe Naming fournit des méthodes pour enregistrer et obtenir des références à des objets
distants dans un registre distant (comme rmiregistry). Chaque méthode de la classe Naming
prend comme argument une String de type URL comprenant les paramètres suivants :

•hôte correspond au nom (ou adresse IP) de la machine où est situé le registre •port est le
numéro de port sur lequel le registre écoute

•nom correspond au nom sous lequel l’objet distant est inscrit dans le registre Si hôte est omis, il
s’agira de la machine locale (localhost). Il en va de même pour le port, s’il est omis, ce sera le port
1099 qui sera utilisé par défaut. Il existe plusieurs façons d’écrire l’URL :

•rmi://host:port/nom
•//host:port/nom
•//host/nom (forme la plus courante)
• Bind

Cette méthode permet d’enregistrer un objet dans le registre en lui associant un nom. Elle prend en
argument une String désignant l’URL de l’objet et un objet de type Remote. S’il existe déjà un lien
pour cette URL dans le registre, une exception de type AlreadyBoundException sera levée.

• Rebind

Son utilisation est identique à la méthode précédente mais ellepermet d’associer un nouvel
objetdistant au nom spécifié en paramètre. Si ce nométait déjà associé à un objet, il sera remplacé.
On préférera utiliser cette méthode plutôt que la méthode bind() pour éviter les exceptions de
typeAlreadyBoundException.
• List

Cette méthode retourne un tableau de String correspondant à la liste des noms de tous les liens
vers des objets distants dans le registre dont l’URL est spécifiée en paramètre. L’URL spécifié est
de la forme //hôte:port.

• Lookup

La méthode lookup() est utilisée par les clients pour obtenir une référence à un objet distant.
L’objet retourné est de type Remote. Cette méthode prend comme paramètre une String
correspondant à l’URL de l’objet distant. Si le lien dans le registre n’existe pas, une exception de
type NotBoundExceptionsera levée
IV. STRATEGIE DE SECURITE EN JAVA RMI

La sécurité en Java RMI (Remote Method Invocation) est un sujet important pour les
applications distribuées car elle implique des communications entre des machines distantes.
Voici quelques points clés à considérer pour garantir la sécurité de vos applications Java RMI :

• Authentification : Il est important de s'assurer que les clients et les serveurs qui
communiquent via Java RMI sont authentiques. Pour ce faire, vous pouvez utiliser des
certificats numériques, des noms d'utilisateur et des mots de passe, ou des mécanismes
d'authentification personnalisés.

• Autorisation : La mise en place d'une autorisation efficace est essentielle pour empêcher les
utilisateurs non autorisés d'accéder aux ressources distantes. Il est important de définir des
politiques d'autorisation pour chaque objet distant, afin de s'assurer que seules les
personnes autorisées peuvent y accéder.
• Contrôle d'accès : Pour garantir que seules les personnes autorisées peuvent accéder aux
objets distants, vous pouvez définir des contrôles d'accès pour chaque objet distant. Les
contrôles d'accès permettent de déterminer les autorisations d'accès pour chaque
utilisateur.

• Pare-feu : L'utilisation d'un pare-feu peut limiter l'accès aux serveurs Java RMI en
n'autorisant que les adresses IP spécifiques à accéder aux serveurs RMI.

• Sécurité du code : Il est important de s'assurer que le code RMI est sûr en évitant les
vulnérabilités telles que les injections SQL, les dépassements de tampon et les attaques de
débordement de pile.

En appliquant ces mesures de sécurité, vous pouvez garantir que vos applications Java RMI sont
sûres et protégées contre les attaques malveillantes.
V. COMPARAISON DE JAVA RMI AUX AUTRES TECHNOLOGIES

Java RM (Remote Method Invocation) est l'une des nombreuses technologies de communication
interprocessus disponibles pour les développeurs. Voici quelques-unes des principales
différences entre Java RM et d'autres technologies similaires :

Java RM vs. Web Services : Les Web Services sont une technologie de communication
interprocessus basée sur des protocoles web standards tels que HTTP et XML. Contrairement à
Java RM, les Web Services sont indépendants du langage de programmation et peuvent être
utilisés avec différents langages de programmation. Les Web Services sont souvent utilisés pour
l'intégration de systèmes distribués hétérogènes, tandis que Java RM est souvent utilisé pour la
communication interprocessus entre des applications Java.

Java RM vs. Sockets : Les Sockets sont une technologie de communication interprocessus de
bas niveau qui permet aux processus de communiquer directement via des connexions TCP/IP.
Les Sockets sont souvent utilisés pour les communications réseau de faible niveau, tandis que
Java RM est une technologie de communication interprocessus de haut niveau qui permet de
communiquer à distance entre des processus Java.
 Java RM vs. CORBA : Common Object Request Broker Architecture (CORBA) est une
architecture de communication interprocessus multi-langage. Contrairement à Java RM, CORBA
permet aux processus de communiquer dans différents langages de programmation. CORBA est
souvent utilisé pour l'intégration de systèmes distribués hétérogènes, tandis que Java RM est
souvent utilisé pour la communication interprocessus entre des applications Java.

Java RM vs. RESTful APIs : Les APIs RESTful sont une technologie de communication
interprocessus basée sur des requêtes HTTP et JSON. Contrairement à Java RM, les APIs RESTful
sont indépendantes du langage de programmation et peuvent être utilisées avec différents
langages de programmation. Les APIs RESTful sont souvent utilisées pour les applications web,
tandis que Java RM est souvent utilisé pour la communication interprocessus entre des
applications Java.

En résumé, Java RM est une technologie de communication interprocessus haut niveau

spécifique à Java, qui se distingue des technologies telles que les Web Services, les Sockets,
CORBA et les APIs RESTful par ses fonctionnalités et sa compatibilité avec les applications Java.
Les développeurs doivent choisir la technologie la plus adaptée à leur cas d'utilisation spécifique
en tenant compte des exigences en matière de langage de programmation, de plateforme, de
sécurité, de performances et de fonctionnalités.
 CONCLUSION

Les applications réparties avec Java RMI (Remote Method Invocation) sont des applications
client-serveur qui permettent à des objets Java distribués sur un réseau de communiquer
entre eux en utilisant des méthodes distantes. RMI fournit un moyen simple et efficace pour
créer des applications distribuées en permettant aux développeurs de créer des objets Java
qui peuvent être exécutés sur différentes machines et communiquer entre eux de manière
transparente.
En utilisant Java RMI, les développeurs peuvent créer des applications réparties de manière
efficace et fiable. Les applications peuvent être développées pour fonctionner dans des
environnements distribués, tels que des réseaux d'ordinateurs, des clusters de serveurs et des
grappes de calcul haute performance.
Enfin, les applications réparties avec Java RMI sont un choix solide pour les développeurs qui
souhaitent créer des applications distribuées efficaces et fiables. Les avantages de Java RMI
incluent la facilité d'utilisation, la performance, la fiabilité et la compatibilité avec d'autres
technologies Java.
Ainsi met un terme à notre exposé.