Rapport de projet SOI- = Juillet 1997 -Demar Claudine.

JAVA RMI (REMOTE METHOD = INVOCATION).

Les systèmes distribués mettent en jeu des applications qui s'exécutent dans des espaces d'adressages différents et potentiellement sur des sites différents : Ces applications doivent être capables de communiquer. Les sockets constituent un outil assez flexible mais ne fournissent pas de protocoles de haut niveau entre les clients et les serveurs. RPC (Remote Procedure Call) permet des communications de plus haut niveau: Le client fait appel à des procédures comme si celles ci étaient locales, les requêtes sont en fait encapsulées et passées à l'application serveur. De plus, le mécanisme de RPC peut fonctionner dans un milieu hétérogène puisque la compatibilité des formats entre les différents systèmes est assurée par un mécanisme de filtres XDR, fixant une représentation uniforme des données.

Par rapport aux RPC, java RMI permet l'invocation à distance de méthodes sur un objet java dans un environnement homogène java. La compatibilité est garantie puisque les objets serveur et client sont exécutés par des machines virtuelles java.

Le système RMI est constitué de trois couches :

Lorsqu'un client invoque une méthode sur l'objet serveur, il utilise en fait un stub pour l'objet distant. La référence qu'a un client d'un serveur distant est en fait la référence locale sur le stub. Le stub implémente les interfaces du serveur distant de façon à faire passer la requête du client à l'objet serveur adéquat, via la couche de référence. Mais attention, un stub peut être chargé dynamiquement du site du serveur, s'il n'est pas présent localement sur le site du client.

Cette couche de référence s'occupe du routage correct des requêtes des clients ou des réponses des serveurs. La couche de référence détermine la sémantique de l'invocation, ie si le serveur est un objet simple ou un objet répliqué. Dans le second cas, le routage devra être multiple. La couche de référence détermine aussi la sémantique du serveur, ie si le serveur est permanent ou si le serveur doit être activé à chaque invocation d'une de ses méthodes.

La couche transport s'occupe de l'établissement et de la gestion des connections, ainsi que du répertoriage des objets distribués susceptibles d'être invoqués.

Pour faire parvenir une requête à un serveur, la couche de référence, après avoir activé si nécessaire le serveur, va passer la requête au skeleton associé au serveur ; le skeleton va alors invoquer la requête sur le serveur. La réponse à la requête va être successivement passée au skeleton, puis à la couche de référence, puis à la couche transport, du côté serveur puis, du côté client, à la couche transport, à la couche de référence , au stub et enfin au client.

LES STUBS ET LES SKELETONS

Cette couche constitue l'interface entre la couche applicative et le reste du système RMI. Elle doit transmettre ou récupérer les données des flux clients et serveurs à la couche de référence. Pour cela, les données sont encapsulées selon le mécanisme de sérialisation java (façon de sauvegarder une classe et son contexte d'exécution). Les objets distants sont alors passés par référence.

Les stubs et les skeletons sont déterminés et chargés dynamiquement à l'exécution. Leur bytecode est généré par le compilateur rmic fournis avec le jdk1.1.2. .

LA COUCHE DE REFERENCE

Cette couche doit déterminer et appliquer le protocole d'invocation d'une communication:

• Invocation unicast point à point,
• Invocation multicast (à plusieurs objets répliqués),
• Stratégies de reconnection( si l'objet distribué devient inaccessible).

Cette couche est scindée en fait en deux : Le composant côté client et le composant côté serveur. Le composant côté client communique avec le composant côté serveur via la couche transport.

LA COUCHE TRANSPORT

Les tâches que doit réaliser cette couche sont les suivantes :

• Etablir les connections vers des espaces d'adressage distants ;
• Gérer et contrôler les connections établies;
• Maintenir une table des objets distants qui sont susceptibles d'être invoqués ;
• Ecouter les appels entrants ;
• Localiser la cible d'une invocation et router correctement la requête.

La couche transport peut supporter divers protocoles de transport : UDP, TCP peuvent être supportés au sein de la même machine virtuelle. Cette couche n'est accessible que par la machine virtuelle.

Normallement, la couche transport va essayer d'ouvrir directement des sockets pour se connecter à des machines sur réseau Internet, ce que beaucoup de réseaux intranet n'autorisent pas. Pour contourner cette interdiction et ainsi permettre à un client se trouvant derrière un firewall d'invoquer un serveur qui se trouve en dehors du réseau interne, le système RMI propose un mécanisme basé sur le protocole HTTP : la couche transport va encapsuler la requête du client dans une requête HTTP que le fireWall laissera passer. La requête d'invocation est envoyée dans le corps d'une requête HTTP POST et la réponse est encapsulée dans la réponse HTTP. Il est clair que le système fonctionnant ainsi est plus lent qu'une implémentation directement avec des sockets. La possibilité de désactiver ce mécanisme est alors donnée au client. Un autre inconvénient important de ce mécanisme basé sur HTTP est que les requêtes HTTP ne peuvent être initiées qu'unilatéralement à travers le fireWall. Une application ne pourra donc pas être client et en même temps serveur par rapport à une autre application sur un site qui se trouverait en dehors du fireWall.

Le système RMI supporte de nombreux scénarios de configuration :

• Les serveurs peuvent être ouverts ou fermés : Dans le premier cas, le serveur peut charger des classes pour un client distant. Il fournit alors un codebase pour permettre qu'un client ayant fait une requête au serveur puisse trouver les stubs associés au serveur, si ces stubs ne sont pas locaux au site client. Dans le second cas, il ne chargera aucune classe si le client est distant : Il ne fournit pas de codebase.
• Les applets peuvent invoquer des méthodes sur des objets distants supportés par un serveur. Vu la sécurité renforçée dont les applets font l'objet, ce serveur doit se trouver sur le serveur de l'applet.
• Les applications java contrairement aux applets peuvent se connecter à n'importe quel serveur. Les options de configuration sont alors plus variées que pour les applets. Si une application est chargée localement alors les classes de l'application doivent être accessibles localement. Il est aussi possible de charger une application à distance en utilisant le mécanisme de bootstrapping.

Le package SOI comporte 4 fichiers :

• L'application cliente : Client.java;
• L'interface exposées les fonctionnalités proposées par le serveur : Iserver.java ;
• L'implémentation du serveur : ServerImpl.java qui fait appel à l'interface graphique Drawtest.java ;

On fournit aussi des fichiers pour l'installation :

• Compilation : permet de compiler tout le package et de générer les stubs et les skeletons.
• DrawServer : permet de lancer le serveur ;
• Client : permet de lancer le client .

Les codes source de tout le package sont joints.

Le système RMI permet assez simplement de mettre en oeuvre des applications orientées objets distribués: En effet, le modèle d'objets distribués a été intégré de façon très = naturelle au langage java, en harmonie avec la sémantique du langage et permet de construire des applications distribuées qui préservent la sécurité de l'exécution. On peut aussi souligner que le système RMI fournit un certain nombre de mécanismes intéressants : la réplication de serveurs, l'activation d'objets pour un service, = le ramasse-miette des objets distribués, l'extensibilité à d'autres protocoles de communication. L'avantage le plus remarquable de ce système est son intéropérabilité, interopérabilité qu'il doit en fait au langage java, sachant que tout le système doit fonctionner en milieu homogène.