Quels sont les avantages et les inconvénients de l'utilisation de RMI ou de JMS entre les niveaux Web et métier?

Question

Pour une application client Web type Servlet / WS-to- Business Tier (Spring ou EJB), quels sont les inconvénients d'approches telles que le RPC distant ou la messagerie pour la couche Web (Servlet) vers la couche Business distante, en dehors des aspects de base sync / async?

Answer 1

Par client Web, voulez-vous dire navigateur Web? Si tel est le cas, j’aimerais vous recommander des solutions telles que DWR ou JAX-RS. RMI ou JMS ne fonctionnent réellement que lorsque les deux côtés sont du code Java.

Quelle que soit la technologie de communication à distance, le principal problème de leur utilisation réside dans le degré d'intrusion de la technologie dans vos objets métier. par exemple. utiliser l'interface / les exceptions RMI partout ou à l'aide des API JMS dans le code de votre entreprise.

Je vous recommande d'utiliser des POJO partout en Java, puis une technologie telle que Spring Remoting pour superposer sur votre middleware, que ce soit son RMI, son JMS ou autre - mais découplez totalement le code du middleware de votre logique métier afin que vous puissiez basculer entre les technologies à tout moment (et conserver votre code de logique plus simple et concentré sur votre problème d’affaires).

Voir, par exemple, la implémentation de Spring Remoting par Camel . d'utiliser n'importe lequel de ces transports et protocoles tels que RMI, JMS ou même le protocole HTTP en clair, courrier électronique, fichiers ou XMPP - puis basculez entre eux de manière triviale en utilisant un simple changement de chaîne d'URI.

Answer 2

Nous utilisons RMI via Spring et le trouvons très facile à utiliser, assez robuste et rapide. Même si nos exigences visaient un lien assez réactif et qu’il n’y avait aucun besoin réel d’ajouter un composant de messagerie.

Answer 3

SUN RMI s'est cassé pour nous.

Les paramètres et la récupération de place pour une application très longue avec une surveillance continue. Nous corrigeons pour que cela fonctionne continuellement. Les applications JMS que nous exécutons ne rencontrent pas d'erreurs de mémoire insuffisante ni de problèmes de gc comme le fait RMI. Tout ce qui doit appeler System.gc () périodiquement et qui ne fonctionne pas avec la collecte incrémentielle pour récupérer des ressources est codé incorrectement.

La fiabilité de RMI s’améliore avec le JDK 6 et les paramètres de propriétés corrects, mais JHC est un framework hétéroclite. RMI serait grandement amélioré en utilisant des canaux in nio et en corrigeant les nombreuses utilisations de system.gc ().

La réponse correcte - communication séparée (mécanisme) du code de domaine. Le protocole RPC est étroitement lié et le protocole et l'application peuvent interférer les uns avec les autres. JMS sépare le protocole de l'application, un paradigme bien meilleur.