RMI vs services Web. Quel est le meilleur pour la communication à distance Java2Java?
Je suis nouveau dans les services Web et RMI et je me demande quelle est la meilleure façon de procéder à distance entre différentes applications Web, lorsque ces applications sont toutes écrites en Java, c'est-à-dire lorsque différents langages de programmation n'ont pas d'importance (ce qui serait le avantage de WS).
Alors que d'une part, je suppose qu'il y a un surcoût de performance lors de l'utilisation des services Web (quelqu'un a-t-il des chiffres pour le prouver?), D'autre part, il me semble que les services Web sont beaucoup plus lâchement couplés et peuvent être utilisés pour implémenter une architecture plus orientée services (SOA) (ce qui n'est pas possible avec RMI, non?).
Bien que ce soit une question assez générale, quelle est votre opinion?
Merci
Les services Web permettent une architecture faiblement couplée. Avec RMI, vous devez vous assurer que les définitions de classe restent synchronisées dans toutes les instances d'application, ce qui signifie que vous devez toujours les déployer toutes en même temps même si une seule d'entre elles est modifiée (pas nécessairement, mais c'est requis assez souvent à cause des UUID série et ainsi de suite)
De plus, il n'est pas très évolutif, ce qui pourrait être un problème si vous souhaitez avoir des équilibreurs de charge.
Dans mon esprit, RMI fonctionne mieux pour les petites applications locales, qui ne sont pas liées à Internet mais doivent encore être découplées. Je l'ai utilisé pour avoir une application Java qui gère les communications électroniques et j'étais assez satisfait des résultats. Pour d'autres applications qui nécessitent un déploiement plus complexe et fonctionnent sur Internet, j'utilise plutôt le Web prestations de service.
Que vous utilisiez les services Web ou une approche plus "native" dépend également de l'environnement. Si vous devez passer par un proxy ou certains pare-feu d'entreprise, les services Web sont plus susceptibles de fonctionner car ils s'appuient uniquement sur HTTP. RMI vous oblige à ouvrir un autre port pour votre application qui peut être difficile (mais pas techniquement, cependant) dans certains environnements ...
Si vous savez que ce problème n'est pas un problème, vous devriez envisager d'utiliser RMI. SOA ne dépend pas autant de la technologie que d'une bonne conception de service. Si vous avez un conteneur EJB, vous pouvez appeler des beans session via RMI et les exposer en tant que services Web, si vous en avez vraiment besoin , au fait.
Les performances dépendent des données que vous prévoyez d'échanger. Si vous voulez envoyer des réseaux d'objets complexes d'une application à une autre, c'est probablement plus rapide avec RMI, car il est transféré dans un format binaire (généralement). Si vous avez quand même une sorte de contenu textuel/XML, les services Web peuvent être équivalents ou même plus rapides, car vous n'auriez alors 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 réseau sous-jacent très complexe qui nécessite vous devez ouvrir les ports RMI, et cela peut également ne pas fonctionner si le client est NATTED. Deuxièmement, avec RMI, vous limitez votre Slef à la communication Java-JAVA, tandis qu'avec les Webservies il n'y a pas de limitation. Il est beaucoup plus facile de déboguer des Webservices sur le fil car les données sont SOAP/HTTP, qui peuvent être facilement capturées via des outils de reniflement pour le débogage. Je ne connais pas de moyen facile de le faire sur RMI. En outre, RMI est vraiment très ancien et n'a pas reçu beaucoup d'attention pour la dernière Il y a quelques années, c'était très important à l'époque où CORBA était grand, et les deux RMI CORBA sont vraiment des technologies désuètes. La meilleure option est les services Web de style REST.
Mon expérience avec RMI et les services Web 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 d'interface est explicitement indiquée pour les services Web.
Notez qu'aucun de ces protocoles 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.
@Martin Klinke
"Les performances dépendent des données que vous prévoyez d'échanger. Si vous souhaitez envoyer des réseaux d'objets complexes d'une application à une autre, c'est probablement plus rapide avec RMI, car il est transféré au format binaire (généralement). Si vous en avez de contenu textuel/XML de toute façon, les services Web peuvent être équivalents ou même plus rapides, car alors vous n'auriez pas besoin de convertir quoi que ce soit (pour la communication).
Autant que je sache, le problème de performances fait la différence lors de la sérialisation-désérialisation en d'autres termes, le processus de marshalling-demarshalling.Je ne suis pas sûr que ces deux termes sont les mêmes btw Dans la programmation distribuée, je ne parle pas du processus qui se produit dans la même JVM, il s'agit de la façon dont vous copiez les données.C'est soit passer par valeur ou passer par référence.Le format binaire correspond à passer par valeur ce qui signifie copier un objet sur un serveur distant dans des binaires.Si vous avez un doute jusqu'à présent, j'aimerais entendre
quelle est la différence entre l'envoi au format binaire et le contenu textuel/xml en termes de marshalling-demarshalling ou de sérialisation-désérialisation?
Je ne fais que deviner.Cela ne dépend pas du type de données que vous envoyez.Quel que soit le type de données que vous envoyez, il fera partie du processus de marshalling-demarshalling et, à la fin, sera envoyé en binaires, n'est-ce pas?
cheers Hakki
RMI peut être la meilleure direction si vous devez maintenir un état complexe.
Qu'en est-il de l'accès à distance au printemps. Il combine un protocole HTTP de type REST avec un format binaire RMI. Fonctionne parfaitement pour moi.
En tant que fanatique de Spring et exposant de SOA pendant de nombreuses années, je conseillerais la communication à distance de Spring. Cet exportateur de saveur de service fera l'affaire pour RMI.
org.springframework.remoting.rmi.RmiServiceExporter
D'autres transports sont bien sûr disponibles. La question de la sérialisation est assez gérable si vous versionnez vos interfaces (points d'extrémité) et DTO de manière raisonnable et gérez correctement les UUID de sérialisation. Nous postfixons 'Alpha', 'Bravo' à nos interfaces et objets et incrémentons, décrémentons et réinventons où et quand cela est nécessaire. Nous fixons également nos UUID de sérialisation à 1 et nous assurons que les modifications ne sont qu'additives, sinon nous passons de "Bravo" à "Charlie". Tous gérables dans une configuration d'entreprise.