Question

Je connais les services Web et RMI pour la première fois et je me demande quel est le meilleur moyen d'effectuer la communication à distance entre différentes applications Web, lorsque ces applications sont toutes écrites en Java, c'est-à-dire lorsque différents langages de programmation ne comptent pas serait l’avantage de WS).

Alors que, d’une part, j’imaginais que l’utilisation de services Web supposait un surcoût (tout le monde a-t-il des chiffres pour le prouver?), il me semble par ailleurs que les services Web sont beaucoup plus faiblement couplés et peuvent être utilisé pour mettre en œuvre une architecture plus orientée services (ce qui n’est pas possible avec RMI, non?).

Bien que ce soit une question assez générale, quelle est votre opinion?

Merci

Était-ce utile?

La solution

Les services Web permettent une architecture à couplage lâche. 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 cela est nécessaire). nécessaire assez souvent à cause des UUID série et autres)

En outre, il n’est pas très évolutif, ce qui peut poser problème si vous souhaitez disposer d’équilibreurs de charge.

Dans mon esprit, RMI fonctionne mieux pour les applications locales plus petites, qui ne sont pas liées à Internet mais doivent encore être découplées. Je l'ai utilisé pour créer une application Java qui gère les communications électroniques et j'étais assez satisfait des résultats. Pour les autres applications nécessitant un déploiement plus complexe et fonctionnant sur Internet, je préfère les services Web.

Autres conseils

Si vous utilisez des services Web ou un service plus "natif" L’approche 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 vous oblige à ouvrir un autre port pour votre application, ce qui peut s'avérer difficile (mais techniquement pas) dans certains environnements ...

Si vous savez que ce problème n’est pas un problème, envisagez d’utiliser RMI. La SOA ne dépend pas tant de la technologie que d’une bonne conception des services. Si vous avez un conteneur EJB, vous pouvez appeler des 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 souhaitez envoyer des réseaux d'objets complexes d'une application à une autre, le protocole RMI est probablement plus rapide, car il est transféré au format binaire (généralement). Si vous avez quand même un contenu textuel / XML, les services Web peuvent être équivalents, voire plus rapides, car vous n’auriez alors plus besoin de rien convertir (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é par les pare-feu, peut fonctionner derrière NAT, etc. RMI a un protocole réseau sous-jacent très complexe qui vous oblige à ouvrir des ports RMI et peut également ne pas fonctionner si le client est NATTED. Deuxièmement, avec RMI, vous limitez votre travail à la communication JAVA-JAVA, tandis qu’avec Webservies, aucune limitation de ce type n’existe. Il est beaucoup plus facile de déboguer des services Web sur le réseau, car les données sont au format SOAP / HTTP, qui peuvent être facilement capturées à l’aide d’outils de détection pour le débogage. Je ne connais pas de moyen facile de faire cela avec RMI. De plus, RMI est vraiment très vieux et n'a pas beaucoup retenu l'attention ces dernières années. À l'époque où CORBA était déjà très important, c'était énorme, et les deux RMI CORBA sont des technologies vraiment dépassées. 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 de l’interface est explicitement définie pour les services Web.

Notez qu'aucun de ces protocoles n’exige que les applications des deux côtés soient en Java. J'avais 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 devez conserver un état complexe.

@Martin Klinke

"Les performances dépendent des données que vous souhaitez échanger. Si vous souhaitez envoyer des réseaux d'objets complexes d'une application à une autre, le protocole RMI est probablement plus rapide, car il est transféré au format binaire (généralement). De toute façon, si vous avez un contenu textuel / XML, les services Web peuvent être équivalents, voire plus rapides, car vous n’auriez alors plus besoin de rien convertir (pour la communication). "

Autant que je sache, le problème de performances fait toute la différence lors de la sérialisation-désérialisation, autrement dit, le processus de marshalling-demarshalling.Je ne suis pas sûr que ces deux termes soient identiques En programmation distribuée, je ne parle pas du processus qui se déroule dans la même machine virtuelle, mais de la façon dont vous copiez les données. Il s'agit de passer par valeur ou de passer par référence.Le format binaire correspond à passer par valeur, ce qui signifie copier un objet vers distant. serveur en 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-démarshalling 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 sera envoyé à la fin dans des fichiers binaires, non?

acclamations Hakki

Qu'en est-il de Spring Remoting. Il combine un protocole HTTP de type REST avec le format binaire de RMI. Fonctionne parfaitement pour moi.

En tant que fan de Spring et exposant de la SOA depuis de nombreuses années, je conseillerais Spring à distance. Ce type d’exportateur de services fera l’affaire pour RMI.

org.springframework.remoting.rmi.RmiServiceExporter

D'autres transports sont bien sûr disponibles. La sérialisation est tout à fait gérable si vous modifiez vos interfaces (points de terminaison) et vos DTO de manière sensée & amp; gérer correctement les UUID de sérialisation. Nous postfixons 'Alpha', 'Bravo' à nos interfaces et objets et incrémentons, décrémentons & amp; réinventer où et quand cela est nécessaire. Nous corrigeons également nos UUID de sérialisation sur 1 et nous nous assurons que les modifications ne sont qu'additives. Sinon, nous passons de «Bravo» à «Charlie». Tout est gérable dans une configuration d'entreprise.

Pour Spring Remoting (je suppose que vous voulez dire HTTP Invoker), les deux parties doivent utiliser Spring, si c'est le cas, on peut en discuter.

Pour une application Java à Java, le RMI est une bonne solution. Il convient d'éviter les communications JAX-RPC ou JAX-WS pour Java à Java si les clients ne sont pas sous votre contrôle ou risquent de passer à une autre plate-forme.

Licencié sous: CC-BY-SA avec attribution
Non affilié à StackOverflow
scroll top