RMI/RPC pourquoi ?

Notre chère plateforme JavaEE tend à la simplification des développements  pour que le développeur n’ait à se concentrer que sur la logique métier qu’il doit implémenter et ne s’attarde pas sur les problématiques techniques que sont la concurrence des accès, la sécurité ou la scalabilité. C’est fort louable, mais mon ressenti c’est que nous « jeunes » développeurs, n’ayant pas forcément l’historique des erreurs du passé, ne comprenons pas vraiment ce que nous faisons aujourd’hui. En effet, nous sommes incapables de faire une analyse technique poussée lors de problèmes critiques.

C’est pour cela  qu’il m’arrive de temps en temps de chercher à savoir qui ou quoi était au commencement, puis de tirer la corde des simplifications pour en arriver à ce que nous avons aujourd’hui.

Je n’ai pas toujours le temps de le faire par ce qu’en entreprise il faut travailler quand même -:) mais dès que je peux je le fais.

Et pour fêter mon premier post je propose de répondre à une petite question :

RMI/RPC pourquoi ?
RMI: Remote Method Ivocation (EJB)
PS : Si vous pensiez au Revenu Minimum d’Insertion en venant sur cette page passez votre chemin J


RPC : Remote Procedure Call (JAX-RPC, JAX-WS)


RMI et RPC sont des modèles de programmation qui s’appliquent aux architectures distribuées. On parle d’architecture distribuée dès lors que l’un des composants de votre application n’est pas hébergé au même endroit que les autres (Autre JVM, autre machine etc.). Comme leurs noms l’indiquent, ces styles architecturaux permettent d’invoquer des services distants.
Ces services sont alors modélisés, « exposés », matérialisés dans des méthodes d’objets distants, localisés sur un serveur d’application par exemple. Ces objets peuvent être enregistrés dans un annuaire (JNDI dans un cas UDDI dans l’autre) puis retrouvés par « lookup ».
Cette modélisation a pour but de masquer le caractère distribué de ces services (on masque le réseau) et d’offrir un modèle de programmation unifié pour le développeur. Ainsi, on sait à peine si on manipule un objet distant ou un objet local. On fera toujours

MonObjet.monService()

pour obtenir un service

A savoir :
RMI est :
- utilisable entre composants Java ou composants java et CORBA grâce au protocole IIOP.
- Peu performant car nécessite sérialisation/désérialisation des objets
En outre, les composants communiquant via RMI/RPC sont fortement couplés de par les messages qu’ils échangent :


Autre alternative : REST
Il existe d’autres façons de modéliser des services distants, notamment REST (Representational State Transfert) ou le modèle du web.
REST est un modèle où tout service est considéré comme une ressource web c'est-à-dire accessible depuis une URL.
Par exemple, le cours de l’action BNP Paribas peut être obtenu à l’adresse suivante :
http://www.bourseenligne.com/bourse/cours/action/bnpparibas
Ce modèle utilise les standards du web en terme de transport c'est-à-dire HTTP, XML sur HTTP ou JSON.
Le réseau n’est pas masqué au développeur :


REST a pour avantage d’utiliser une pile de protocoles plus légère ce qui le rend plus performant. Comme l’exemple le montre, le couplage est lâche entre l’application appelante et le service sollicité.