Pour une application type de client Web vers Servlet/WS-to-Business (Spring ou EJB), quels sont les compromis des approches telles que le RPC ou la messagerie distante pour le niveau Web (Servlet) vers le niveau Business distant, à partir des aspects de base de synchronisation/async?Quels sont les avantages et les inconvénients de l'utilisation de RMI ou JMS entre les niveaux Web et métier?
Par client Web, voulez-vous dire navigateur Web? Si je regarde des choses comme DWR ou JAX-RS sont mes recommandations. RMI ou JMS ne fonctionnent vraiment que lorsque les deux côtés sont du code Java. Avec toute technologie de communication à distance, le plus gros problème est de savoir à quel point la technologie devient intrusive sur vos objets de gestion. par exemple. en utilisant l'interface/les exceptions RMI partout ou en utilisant les API JMS dans votre code d'entreprise. Ma recommandation est d'utiliser des POJOs partout en Java, puis d'utiliser une technologie comme Spring Remoting pour superposer sur votre middleware, que ce soit RMI ou JMS ou autre - mais découpler totalement le code middleware de votre logique métier pour pouvoir passer d'une technologie à l'autre à tout moment (et gardez votre code de logique métier plus simple et concentré sur votre problème métier). Par exemple, voir le Camel implementation of Spring Remoting qui vous permet ensuite d'utiliser any of these transports and protocols tel que RMI, JMS ou même HTTP simple, email, fichiers ou XMPP - puis basculez entre eux trivialement en utilisant un simple changement de chaîne d'URI.
Nous utilisons RMI via Spring et le trouvons très facile à utiliser, assez robuste et rapide. Bien que nos exigences étaient pour un lien assez réactif et il n'y avait pas vraiment besoin d'ajouter un composant de messagerie.
SUN RMI cassé pour nous.
Les paramètres et la récupération de place pour une application très longue durée avec mesure continue. Nous corrigeons pour le faire fonctionner en continu. Les applications JMS que nous exécutons n'obtiennent pas les erreurs de mémoire ou les problèmes de gc que RMI fait. Tout ce qui doit appeler System.gc() périodiquement et ne fonctionne pas avec la collecte incrémentielle pour récupérer des ressources est incorrect.
La fiabilité RMI s'améliore avec le JDK 6 et les paramètres de propriété corrects, mais JHC, c'est un cadre de bodgey. RMI serait grandement améliorée en utilisant des canaux dans nio et en fixant les utilisations de sun nio de system.gc().
La réponse correcte - communication séparée (mécanisme) à partir du code de domaine. RPC est étroitement couplé, et le protocole et l'application peuvent interférer les uns avec les autres. JMS sépare le protocole de l'application, un bien meilleur paradigme.