Comment comparer Java RPC vs Services Web Java. J'ai une petite expérience pratique avec les Services Web. Maintenant, je dois savoir comment RPC se compare aux Services Web. Comment fonctionne RPC?
Ajout : Quand choisissons-nous l'une ou l'autre des options?
Comme le dit Daff, Java RMI lui-même est vraiment seulement pertinent pour les communications de Java à Java. En termes de facilité de développement de nos jours, le degré de codage du point de vue du fournisseur de services est assez similaire.
Cependant, en plus des problèmes de performance, où l'écart entre les services web et RMI est assez variable (pour certaines tailles de messages, il peut y avoir une différence négligeable), il y a un autre aspect à considérer : la résilience.
Typiquement, RMI est facile à mettre en place lorsque qu'un client communique avec un seul serveur et que vous ne vous souciez pas de la disponibilité du client étant liée à celle du serveur unique. Serveur en panne, client en panne, ainsi va la vie.
Dans le cas des services web, vous pouvez déployer assez facilement votre service sur un cluster de serveurs et, étant donné que vous invoquez le service web via HTTP, vous pouvez facilement exploiter toutes les techniques normales de routage réseau et de répartition utilisées dans les sites web à plus grande échelle. Aucun codage spécial nécessaire dans le serveur ou dans le client.
Maintenant, vous pouvez obtenir le même niveau de résilience avec RMI, mais cela nécessite une infrastructure de provision de services légèrement meilleure et c'est là que le modèle de programmation Java EE EJB (ou des cadres tels que Spring) entre en jeu. EJB utilise RMI sur IIOP, un protocole qui permet des appels résilients aux instances de serveur, gérant de manière transparente les pannes de serveur. [Il en fait beaucoup plus aussi, comme la sécurité et les transactions, mais les services web le peuvent aussi. Intéressant mais pas partie de cette discussion.]
En résumé : Pour fournir un service de qualité en production, je commence normalement par créer un objet service. J'utilise Java EE EJB 3, d'autres personnes utilisent Spring. Vous pouvez exposer cet objet service en tant que service web ou en tant que RMI/IIOP avec une configuration/annotation très simple. Il est très peu d'effort de choisir l'un ou l'autre, voire les deux. Mon monde se concentre principalement sur l'interopérabilité, donc j'ai tendance à exposer des services web. Si vous avez seulement Java à prendre en compte, cela peut donner une amélioration des performances en utilisant RMI/IIOP, mais ce n'est pas garanti, vous devriez mesurer les performances pour être sûr.
Je pense que tu veux dire RMI avec Java RPC. L'invocation de méthode à distance est très spécifique à Java et donc assez facile à gérer dans les programmes Java natifs (Java des deux côtés). Elle utilise un format binaire pour transférer les données et ne fonctionne pas via HTTP, donc elle est probablement plus rapide que la solution webservice.
Les webservices, en revanche, utilisent (en général) un format générique comme XML ou JSON qui peut être demandé et lu par n'importe quelle autre application à distance. Les frais généraux sont plus importants (faire une requête http et sérialiser/désérialiser les données), mais le client utilisant un webservice se moque de la manière dont le webservice a généré ces données et ne dépend pas d'un langage de programmation spécifique tant qu'il respecte un format spécifié.
Donc, le choix de la technologie à utiliser dépend de savoir s'il pourrait y avoir d'autres clients que des clients Java qui veulent utiliser votre service.
Si vous regardez les services Web RPC vs Document, cette question et les réponses pourraient être ce que vous recherchez.
Je pourrais l'expliquer, mais quand quelqu'un a une discussion, avec des exemples de code, à regarder, ma réponse ne suffirait pas.
De plus, je ne suis pas certain de ce que vous demandez, je pense que la terminologie peut être un problème ici.
RPC est utilisé uniquement lorsque la même plateforme est utilisée aux deux extrémités EJB est utilisé uniquement pour Java.
Q : Que se passe-t-il si une application non Java souhaite accéder à mon service ?
R : C'est là que les Services Web sont introduits Les Services Web peuvent être non Java aussi Et sont également utilisés pour une communication synchrone et asynchrone
Prograide est une communauté de développeurs qui cherche à élargir la connaissance de la programmation au-delà de l'anglais.
Pour cela nous avons les plus grands doutes résolus en français et vous pouvez aussi poser vos propres questions ou résoudre celles des autres.
