PDF version - DIUF

Implementing a simple RMI
Application over the Internet
(using and comparing HTTP tunneling, RMI Proxy)
Abstract
Un problème se pose lorsque l’on veut effectuer des appels RMI à travers un
firewall, car souvent il empêche l’accès à certains ports pour cause de sécurité. Une
technique peut être le HTTP tunneling où les appels se font sous forme de requête
HTTP à l’aide d’une servlet. Une deuxième technique expliquée dans ce document
est le RMIProxy, dans laquel on place un proxy RMI pour chaque firewall, celui-ci
effectue un contrôle pour ne laisser passer que les requête RMI, il permet aussi
d’ajouter d’autres contraintes. Ce document permettra de se faire une idée sur ces
deux concepts permettant aux requêtes RMI de traverser des firewall.
Master Seminar
Advanced Software Engineering Topics
Prof. Jacques Pasquier-Rocha
University of Fribourg, Switzerland
Departement of Informatics
Software Engineering Group
Author : Fabien Pochon
[email protected]
Supervisor : Patrik Fuhrer
[email protected]
Jun 12, 2003

Master Seminar RMI Application over the Internet
Table des matières
1. Introduction....................................................................................... 3
2. Problématique ................................................................................... 3
3. HTTP Tunneling ............................................................................... 4
3.1 Comment RMI « tunnelle » des messages.................................. 5
3.2 Naming services and « the server machine ».............................. 6
3.3 L’implémentation d’un servlet pour le HTTP tunneling ............ 7
3.3.1 Le code du servlet ................................................................ 7
3.4 Modifications à apporter afin d’utiliser le Tunneling ............... 12
3.5 Désavantages du HTTP tunneling ............................................ 12
3.6 Configuration du fichier policy................................................. 12
3.7 Exemple d’appel RMI utilisant HTTP tunneling...................... 13
4. RMIProxy ....................................................................................... 15
4.1 Où trouve-t-on RMIProxy ........................................................ 15
4.2 Les objectifs.............................................................................. 15
4.3 Les caractéristiques................................................................... 15
4.4 Le contrôle d’accès ................................................................... 16
4.5 L’architecture............................................................................ 17
4.6 Comment RMIProxy fonctionne............................................... 17
4.7 L’API coté client....................................................................... 18
4.8 L’API côté serveur.................................................................... 19
4.9 Proxies multiple ........................................................................ 20
4.10 Limitations du RMI Proxy...................................................... 21
4.10.1 Activation......................................................................... 21
4.10.2 Stubs cachés..................................................................... 21
4.10.3 Socket Factories............................................................... 21
4.10.4 GetClientHost .................................................................. 21
4.10.5 RMI / IIOP ....................................................................... 21
4.10.6 Stubs distants indirectes................................................... 21
4.11 Les modifications à apporter au client et au serveur............... 22
5. Les différences entre RMI Proxy et HTTP tunneling..................... 23
6. Conclusion ...................................................................................... 23
Le RMI Proxy est certainement une méthode bien meilleur que le
HTTP tunneling, car elle ne comporte que des avantages sur cette
dernière. Malheureusement je n’ai pas testée. .................................... 23
7. Annexes : Configurations ............................................................... 24
7.1 Installation du seveur Apache................................................... 24
7.2 Installation de Tomcat............................................................... 24
7.3 Configuration du serveur Apache ............................................. 24
7.4 Redirection du script CGI ......................................................... 26
8. Bibliographie............................................................................... 27
2

Master Seminar RMI Application over the Internet
1. Introduction
RMI (Remote Method Invocation) est un système distribué, ce qui signifie que
une ou plusieurs applications peuvent s’exécuter sur une ou plusieurs machines. Une
caractéristique d’un système distribué est le besoin de collaboration entre les
différents processus qui composent le système. Ce qui donne l’illusion à l’utilisateur
qu’il utilise une application locale, alors que des invocations de méthodes se font
dans un autre processus qui peut être sur une machine différente. Il y a donc un
échange d’informations qui s’effectue entre plusieurs machines à l’aide du protocole
RMI. Ceci peut s’effectuer sans aucun problème lorsque il n’y a aucun firewall entre
les deux parties communiquant via RMI. Lorsque un firewall sépare le client d’un
serveur il y aura certainement un problème. C’est ce problème et la solution pour le
contourner qui va donc être traité plus en détail dans ce document.
2. Problématique
Le problème principal qui intervient lorsqu’un client veut effectuer un appel
RMI sur une machine distante est effectivement le firewall qui peut y avoir entre les
deux. En effet les firewalls interdisent souvent l’accès à certains ports spécialisés
comme ceux qu’on désire utiliser lors d’un appel RMI.
Les firewalls sont capables de filtrer des paquets selon :
• Leur adresse source
• Leur adresse de destination
• Le port de destination
• Le protocole de niveau supérieur (exemple : TCP, UDP) utilisé
Cependant les firewalls sont généralement incapables de prendre des décisions
en fonction des données contenues dans ces paquets. C’est pourquoi les techniques
de tunneling, RMI Proxy ou encore d’autres peuvent être utilisées.
3

Master Seminar RMI Application over the Internet
3. HTTP Tunneling
Le principe de base du http tunneling est d’utiliser comme protocole de
communication des appelles http à travers le Web pour des application qui ne se font
pas par le Web. Le requête originale émise n’est pas envoyé par un Web browser
mais par une instance d’une URLClassLoader, et la réponse n’est pas une page html
mais le code binaire d’une classe.
HTTP tunneling est utilisé pour deux raisons essentielles, qui sont les deux très
pragmatiques. Premièrement il permet au développeur d’applications d’utiliser les
composants et l’infrastructure qui existe déjà pour les applications web, il est alors
facile de définir un protocole utilisant ces composants.
De plus il rend aussi facilement possible aux développeurs d’applications
d’incorporer de multiples langages. Depuis que presque chaque langage moderne a
sa librairie permettant de traiter et de générer du XML, utiliser HTTP et XML pour
définir un protocole permet au client d’être écrit dans un langage et le serveur dans
un autre.
La seconde raison d’utiliser HTTP tunneling est qu’il est possible pour des
applications distribuées d’éviter les firewalls. Pour comprendre pourquoi il suffit de
regarger la figure 1.
Figure 1 : HTTP tunneling en action (tirée de O’Reilly, Java RMI)
Le point clé dans cette architecture est que le client utilise une couche
supplémentaire (marshalling layer) qui encode la requête du client en une requête
HTTP valide. Le serveur de l’autre coté possède aussi une couche supplémentaire
(layer of demarshalling code), laquelle transforme une requête HTTP en une requête
correspondant à celle attendue par le serveur.
Le HTTP tunneling est divisé en trois parties :
4

Master Seminar RMI Application over the Internet
• Le client :
Envoie une requête au serveur web
• Le servlet :
Transmet la requête à la socket du serveur RMI en préservant la
structure HTTP qui a été envoyée par le client
• Le serveur :
Transforme automatiquement l’envoi HTTP en une commande JRMP
(Java Remote Method Invocation)
3.1 Comment RMI « tunnelle » des messages
Maintenant le but du mécanisme de RMI HTTP tunneling devrait être clair : il
encode un appel de méthode à distance à la façon d’une requête HTTP POST, et
ensuite décode la « page web » retournée en une réponse du type approprié. RMI
accomplit ceci de la même manière en utilisant un type élaboré de socket, dans
laquelle une sérialisation est faite pour générer aussi bien les requêtes que les
réponses HTTP.
Bien qu’un différent mode de socket est utilisé, RMI va utiliser par défaut son
propre mode de socket quand des connections seront créées. Les sockets par défauts
retournées par RMI tentent d’utiliser HTTP tunneling si auparavant elles ont reçu
une erreur du serveur. Les sockets par défaut emploient la stratégie suivante quand
elles tentent une invocation de méthode sur un serveur :
1. Tentent d’établir une connexion JRMP directe vers le serveur.
2. Si la connexion échoue, elles tentent d’établir une connexion HTTP directe
avec le serveur. Ainsi elles créent une connexion par socket vers le port sur
lequel le serveur est en train d’écouter et ensuite communique en
encapsulant les méthodes demandées dans des requêtes HTTP. La première
chose que le « RMI demarshalling » effectue est de déterminer si la requête
a été encodée en utilisant JRMP ou HTTP.
3. Si la requête échoue encore, elles tentent d’utiliser le firewall comme un
serveur proxy (demandant au firewall de transmettre la requête au port
approprié du serveur). Le firewall transmettra la requête comme une
requête HTTP (le firewall ne va pas traduire la requête en appel RMI).
4. Si il y a encore un échec, elles tentent de se connecter sur le port 80 de la
machine serveur et lui envoie la requête selon un URL commençant avec
/cgi-bin/java-rmi.cgi. Cet URL signifie que la requête doit être transmise
vers un programme qui interprète les requêtes HTTP et qui la transmet,
comme une requête HTTP, vers le port approprié du serveur.
Cette façon de communiquer peut paraître plutôt complexe. Ces points sont
classés dans l’ordre décroissant de leur privilège. De plus ces points sont
indépendants les uns des autres, il est possible d’imaginer un scénario pour lequel le
quatrième point soit l’unique possibilité d’établir une communication.
Par exemple supposons qu’un firewall ait été installé pour ne permettre
qu’uniquement les connexions HTTP vers un serveur et qu’un serveur RMI soit
derrière le firewall. Un client qui essaye de communiquer avec le serveur aura besoin
5