RMI vs Web Services. Quel est le meilleur pour le remoting Java2Java?

Les services Web permettent une architecture faiblement couplée. Avec RMI, vous devez vous assurer que les définitions de classe restnt synchronisées dans toutes les instances d’applications, ce qui signifie que vous devez toujours les déployer toutes en même temps, même si l’une d’elles est modifiée (pas nécessairement, mais requirejs assez souvent à cause des UUID en série et autres joyeusetés)

En outre, ce n’est pas très évolutif, ce qui pourrait poser problème si vous souhaitez avoir des équilibreurs de charge.

Dans mon esprit, RMI fonctionne mieux pour les applications locales plus petites, qui ne sont pas liées à Internet mais doivent toujours être découplées. Je l’ai utilisé pour avoir une application Java qui gère les communications électroniques et j’ai été très satisfait des résultats. Pour les autres applications nécessitant un déploiement et un travail plus complexes sur Internet, j’utilise plutôt des services Web.

Que vous utilisiez des services Web ou une approche plus “native” dépend également de l’environnement. Si vous devez passer par un proxy ou un ou plusieurs pare-feu d’entreprise, les services Web sont plus susceptibles de fonctionner car ils reposent uniquement sur HTTP. RMI exige que vous ouvriez un autre port pour votre application, ce qui peut être difficile (pas techniquement, cependant) dans certains environnements …

Si vous savez que ce problème ne pose pas de problème, vous devriez envisager d’utiliser RMI. La SOA ne dépend pas autant de la technologie que de la bonne conception du service. Si vous avez un conteneur EJB, vous pouvez appeler les beans de session via RMI et les exposer en tant que services Web, si vous en avez vraiment besoin.

Les performances dépendent des données que vous envisagez d’échanger. Si vous voulez envoyer des réseaux d’objects complexes d’une application à une autre, il est probablement plus rapide avec RMI, car il est transféré dans un format binary (généralement). Si vous avez tout de même un contenu textuel / XML, les services Web peuvent être équivalents ou même plus rapides, car vous n’auriez pas besoin de convertir quoi que ce soit (pour la communication).

HTH,
Martin

Une chose qui favorise WS sur RMI est que WS fonctionne sur le port HTTP 80/443 qui n’est normalement pas bloqué sur les pare-feu, peut fonctionner derrière NAT, etc. RMI a un protocole de réseau sous-jacent très complexe qui vous oblige à ouvrir les ports RMI. peut ne pas fonctionner si le client est NATTED. Deuxièmement, avec RMI, vous limitez vos communications avec les communications JAVA-JAVA, tandis qu’avec Webservies, il n’ya aucune limitation de ce type. Il est beaucoup plus facile de déboguer les Webservices sur le réseau, car les données sont SOAP / HTTP, qui peuvent être facilement capturées via des outils de reniflage pour le débogage. Je ne connais pas un moyen facile de faire cela sur RMI. De plus, le RMI est vraiment très ancien et n’a pas reçu beaucoup d’attention depuis quelques années. C’était un grand retour à l’époque où CORBA était grand, et les deux RMI CORBA sont des technologies vraiment désuètes. La meilleure option est les Webservices de style REST.

Mon expérience avec RMI et Web Services reflète vos suppositions ci-dessus. En général, les performances de RMI dépassent de loin les services Web, mais la spécification de l’interface est explicitement indiquée pour les services Web.

Notez qu’aucun de ces protocoles ne nécessite que les applications des deux côtés soient Java. J’aurais tendance à utiliser les services Web lorsque j’avais un ou plusieurs partenaires externes qui implémentaient l’interface, mais RMI si je contrôlais les deux extrémités de la connexion.

RMI peut être la meilleure direction si vous avez besoin de maintenir un état complexe.

@Martin Klinke

«Les performances dépendent des données que vous envisagez d’échanger. Si vous souhaitez envoyer des réseaux d’objects complexes d’une application à une autre, il est probablement plus rapide avec RMI, car il est transféré sous un format binary (généralement). De toute façon, du contenu textuel / XML, les services Web peuvent être équivalents ou même plus rapides, car vous n’auriez plus besoin de convertir quoi que ce soit (pour la communication). ”

Autant que je sache, le problème de performance fait la différence lors de la sérialisation-désérialisation en d’autres termes, le processus de regroupement-démasquage. Je ne suis pas sûr que ces deux termes soient identiques. En programmation dissortingbuée, je ne parle pas du processus Il s’agit soit de passer par valeur soit de passer par référence. Le format binary correspond à passer par valeur, ce qui signifie copier un object sur le serveur distant dans des binarys. Si vous avez le moindre doute jusqu’à présent, je voudrais entendre

Quelle est la différence entre l’envoi au format binary et le contenu textuel / xml en termes de marshalling-demarshalling ou de sérialisation-deserialization?

Je ne fais que deviner.Il ne dépend pas du type de données que vous envoyez. Quel que soit le type de données que vous envoyez, cela fera partie du processus de regroupement et de démasquage et sera envoyé à la fin dans des binarys, n’est-ce pas?

acclamations Hakki

Qu’en est-il de Spring Remoting? Il combine le protocole HTTP de type REST avec le format binary de RMI. Fonctionne parfaitement pour moi.

En tant que bigot de spring et exposant de SOA pendant de nombreuses années, je conseille le remoting printanier. Cette saveur d’exportateur de services fera l’affaire pour RMI.

org.springframework.remoting.rmi.RmiServiceExporter 

D’autres transports sont bien sûr disponibles. La chose de sérialisation est tout à fait gérable si vous mettez à jour vos interfaces (points d’extrémité) et vos DTO de manière judicieuse et gérez correctement les UUID de sérialisation. Nous postfixons ‘Alpha’, ‘Bravo’ à nos interfaces et objects et incrémentons, décrémentons et réinventons où et quand nécessaire. Nous corrigeons également nos UUID de sérialisation sur 1 et nous nous assurons que les modifications ne sont que des ajouts, sinon nous passons de dire “Bravo” à “Charlie”. Tous gérables dans une configuration d’entreprise.

Pour Spring Remoting (je suppose que vous entendez HTTP Invoker), les deux parties doivent utiliser Spring, si c’est le cas, cela peut être discuté.

Pour une application Java to Java, RMI est une bonne solution. JAX-RPC ou JAX-WS pour la communication Java-Java doit être évité si les clients ne sont pas sous votre contrôle ou peuvent passer à une autre plate-forme.