Introduction graphique à la technologie de communication à distance Java et analyse des principes

Dans le cadre de services distribués, l'un des problèmes les plus fondamentaux est la façon dont les services distants communiquent. Il existe de nombreuses technologies qui peuvent réaliser une communication à distance dans le domaine Java, telles que : RMI, MINA, ESB, Burlap, Hessian, SOAP, EJB, JMS, etc., quelle est la relation entre ces termes et sur quels principes sont-ils basés ? Comprendre ceux-ci est la connaissance de base pour implémenter un cadre de services distribués, et s'il existe des exigences de performances élevées, il est nécessaire compréhension approfondie des mécanismes derrière ces technologies.

1 principe de base

Pour parvenir à la communication entre les machines réseau, nous devons d'abord examiner les principes de base de la communication réseau dans les systèmes informatiques. Au niveau sous-jacent, ce que la communication réseau doit faire est de. convertir les flux La transmission d'un ordinateur à un autre est mise en œuvre sur la base de protocoles de transmission et d'E/S réseau. Parmi les protocoles de transmission les plus connus figurent TCP, UDP, etc., TCP et UDP sont tous basés sur le concept Socket et sont étendus pour certains scénarios d'application. Le protocole de transmission et les E/S réseau incluent principalement bio, nio et aio. Toutes les communications d'applications distribuées sont mises en œuvre sur la base de ce principe. Juste pour faciliter l'utilisation de l'application, diverses langues en proposent généralement qui sont plus proches de l'application. . Protocole de couche application facile à utiliser.

2 Mode Message

En dernière analyse, un système d'application d'entreprise est le traitement des données, et pour un système d'application d'entreprise avec plusieurs sous-systèmes, son support de base est sans aucun doute le traitement des messages. Différent des objets, un message est essentiellement une structure de données (bien entendu, un objet peut également être considéré comme un message spécial). Il contient des données qui peuvent être identifiées à la fois par le consommateur et par le service. stocké dans différents processus transmis entre les processus (machines) et peut être consommé par plusieurs clients complètement différents. La messagerie semble être meilleure que le transfert de fichiers et l'appel de procédure à distance (RPC), car elle a une meilleure indépendance de la plate-forme et peut bien prendre en charge les appels simultanés et asynchrones.

Pour Web Service et RESTful, il peut être considéré comme un dérivé ou une encapsulation de la technologie de messagerie.

2.1 Mode Message Channel

Le mode message que nous utilisons souvent est le mode Message Channel, comme le montre la figure.

Le canal de message est une couche indirecte introduite entre le client (Consommateur) et le service (Producteur), qui peut effectivement dissoudre la relation entre les deux de couplage. Tant que le format du message que les deux parties doivent communiquer ainsi que le mécanisme et le calendrier de traitement du message sont mis en œuvre, le consommateur peut être « ignorant » du producteur. En fait, ce modèle peut soutenir plusieurs producteurs et consommateurs. Par exemple, nous pouvons laisser plusieurs producteurs envoyer des messages au canal de messages. Étant donné que le consommateur ignore le producteur, il n'a pas besoin de déterminer quel producteur a envoyé le message.

Bien que le canal de message dissocie le producteur et le consommateur, nous permettant d'élargir arbitrairement le producteur et le consommateur, il introduit également leurs dépendances respectives sur le canal de message, car ils L'emplacement de la ressource du canal doit être connu. Pour soulager cette dépendance à l'égard de la chaîne, vous pouvez envisager d'introduire le service Lookup pour trouver la ressource de la chaîne. Par exemple, dans JMS, vous pouvez obtenir le canal de message Queue via JNDI. Pour obtenir une flexibilité totale, les informations relatives au canal peuvent être stockées dans le fichier de configuration. Le service Lookup obtient d'abord le canal en lisant le fichier de configuration.

Les canaux de messages existent généralement sous forme de files d'attente. Cette structure de données premier entré, premier sorti est sans aucun doute la plus adaptée à ce scénario de traitement de messages. MSMQ, IBM MQ, JBoss MQ, RabbitMQ open source et Apache ActiveMQ de Microsoft implémentent tous le mode Message Channel via des files d'attente. Par conséquent, lors du choix d'utiliser le modèle Message Channel, il est plus nécessaire de procéder à une analyse complète et à un compromis des différents produits qui mettent en œuvre ce modèle du point de vue des attributs de qualité. Par exemple, la prise en charge par le canal de messages de la simultanéité et des performances ; la prise en compte complète de la gestion des erreurs par le canal de messages ; et la prise en charge de la persistance des messages, de la reprise après sinistre (basculement) et du clustering.

Étant donné que les messages transmis par le canal sont souvent des données commerciales importantes, une fois que le canal devient un point de défaillance ou une faille de sécurité, cela aura un impact catastrophique sur le système.

Le mécanisme de jndi est également mentionné ici. Puisque JNDI dépend de l'implémentation spécifique, nous ne pouvons expliquer ici que l'implémentation de jndi de jboss :

Dans le futur Après l'objet. L'instance est liée au serveur jboss jnp, lorsque l'extrémité distante utilise la méthode context.lookup() pour obtenir l'instance d'objet distant et commence à appeler, la méthode d'implémentation de jboss jndi consiste à obtenir l'instance d'objet à partir du serveur jnp et à la sérialiser. revenez au local. Ensuite, désérialisez localement, puis effectuez des appels de classe localement.

Grâce à ce mécanisme, vous pouvez savoir que le local doit en fait avoir une classe liée à l'instance d'objet sur jboss, sinon il échouera définitivement lors de la désérialisation et une communication à distance doit être effectuée. Il s'agit d'effectuer une action à distance et obtenir les résultats correspondants. On peut voir que la communication à distance ne peut pas être réalisée uniquement sur la base de JNDI.

Mais JNDI est également un point technique clé dans la mise en œuvre d'un cadre de services distribués, car il peut être utilisé pour réaliser des appels distants et locaux transparents, tout comme ejb. De plus, c'est également un bon mécanisme de déploiement réel pour cacher (juste des solutions telles que). comme source de données).

2.2 Modèle éditeur-abonné

Une fois qu'un canal de messagerie doit prendre en charge plusieurs consommateurs, vous pouvez avoir le choix entre deux modèles : le modèle pull et le modèle Push. Le modèle pull est initié par le consommateur du message, et l'initiative est entre les mains du consommateur, qui lancera un appel au producteur en fonction de sa propre situation. Comme le montre la figure :

Un autre mode de réalisation du modèle pull consiste pour le producteur à informer le consommateur que son statut a changé lorsque le statut change. Cependant, le consommateur notifié utilisera un rappel pour obtenir des informations plus détaillées en appelant l'objet consommateur transmis.

Dans un système distribué basé sur des messages, le consommateur du modèle pull écoute généralement régulièrement l'état du canal sous la forme d'un travail par lots selon un intervalle de temps prédéfini. Une fois qu'un message est livré, le message sera transmis au processeur réel (qui peut également être considéré comme un consommateur) pour traiter le message et exécuter les services associés.

L'initiative de promouvoir le modèle est souvent entre les mains du producteur, et le consommateur attend passivement les notifications du producteur, ce qui oblige le producteur à connaître les informations pertinentes du consommateur. Comme le montre la figure :

Pour le modèle push, le consommateur n'a pas besoin de connaître le producteur. Lorsqu'un producteur avertit un consommateur, c'est souvent le message (ou l'événement) qui est délivré, et non le producteur lui-même. Dans le même temps, les producteurs peuvent également enregistrer différents consommateurs en fonction de différentes situations, ou notifier différents consommateurs en fonction de différents changements de statut dans la logique de notification encapsulée.

Les deux modèles ont leurs propres avantages. L'avantage du modèle pull est qu'il peut soulager davantage les consommateurs de leur dépendance à l'égard du canal et accéder régulièrement au canal de messages via des tâches en arrière-plan. L'inconvénient est qu'un processus de service distinct doit être introduit et exécuté sous la forme d'un calendrier. Pour le modèle push, le canal de message servira en fait de sujet d'observation par le consommateur. Une fois qu'un message est découvert, le consommateur sera informé de le traiter. Indépendamment du modèle push ou du modèle pull, pour les objets de message, un mécanisme similaire au modèle Observer peut être utilisé pour mettre en œuvre les abonnements des consommateurs aux producteurs, ce mécanisme est donc souvent appelé modèle Éditeur-Abonné , comme indiqué dans le chiffre :

Normalement, les éditeurs et les abonnés seront enregistrés sur l'infrastructure utilisée pour propager les modifications (c'est-à-dire les canaux de messages). L'éditeur comprendra activement le canal de message afin de pouvoir envoyer des messages au canal ; une fois que le canal de message recevra le message, il appellera activement les abonnés enregistrés dans le canal pour terminer la consommation du contenu du message.

Pour les abonnés, il existe deux manières de traiter les messages. Une solution est le mécanisme de diffusion. À ce moment-là, lorsque le message dans le canal de message est retiré de la file d'attente, l'objet du message doit également être copié pour transmettre le message à plusieurs abonnés . Par exemple, plusieurs sous-systèmes doivent obtenir des informations client à partir du système CRM et effectuer le traitement correspondant en fonction des informations client transmises. À l’heure actuelle, le canal de message est également appelé canal de propagation. L'autre méthode est un mécanisme de préemption, qui suit une méthode synchrone, et un seul abonné peut traiter le message en même temps . Un canal de message qui implémente le modèle Éditeur-Abonné sélectionnera le seul abonné actuellement inactif, retirera le message de la file d'attente et le transmettra à la méthode de traitement des messages de l'abonné.

Actuellement, il existe de nombreux middlewares de messages qui peuvent bien prendre en charge le modèle Publisher-Subscriber, tels que les interfaces MessagePublisher et MessageSubscriber fournies pour les objets Topic dans la spécification de l'interface JMS. RabbitMQ fournit également sa propre implémentation de ce modèle. Bien que MSMQ de Microsoft ait introduit un mécanisme d'événement, il peut déclencher des événements pour avertir les abonnés lorsque la file d'attente reçoit un message. Mais il ne s’agit pas strictement d’une implémentation du modèle Éditeur-Abonné. NServiceBus, avec Microsoft MVP Udi Dahan comme principal contributeur, regroupe en outre MSMQ et WCF et peut bien implémenter ce modèle.

2.3 Mode Message Router

Qu'il s'agisse du mode Message Channel ou du mode Editeur-Abonné, la file d'attente y joue un rôle central. Cependant, dans les systèmes d'applications d'entreprise, lorsque le système devient de plus en plus complexe, les exigences de performances deviendront également de plus en plus élevées. À ce stade, le système devra peut-être prendre en charge le déploiement simultané de plusieurs files d'attente et nécessiter le déploiement de différentes files d'attente. . Ces files d'attente peuvent recevoir différents messages selon la définition, tels que des messages de traitement de commande, des informations de journal, des messages de tâche de requête, etc. À l’heure actuelle, il n’est pas approprié que les producteurs et les consommateurs de messages assument la responsabilité de déterminer le chemin de transmission du message. En fait, selon le principe de responsabilité unique S, ce type d'attribution de responsabilités est également déraisonnable. Il n'est pas propice à la réutilisation de la logique métier et provoquera également un couplage entre les producteurs, les consommateurs et les files d'attente de messages, affectant ainsi l'expansion de la logique métier. système.

Étant donné que ces trois objets (composants) ne sont pas adaptés pour assumer de telles responsabilités, il est nécessaire d'introduire un nouvel objet spécifiquement responsable de la fonction de sélection du chemin. C'est ce qu'on appelle le Message. Modèle de routeur , comme le montre la figure :

Grâce au routage des messages, nous pouvons configurer des règles de routage pour spécifier le chemin de livraison des messages et spécifier le producteur correspondant à la consommation spécifique du consommateur. Par exemple, spécifiez le mot-clé de routage et utilisez-le pour lier une file d'attente spécifique au producteur (ou consommateur) spécifié. La prise en charge du routage offre une flexibilité dans la livraison et le traitement des messages, et contribue également à améliorer les capacités de traitement des messages de l'ensemble du système. Dans le même temps, l'objet de routage encapsule efficacement la logique de recherche et de mise en correspondance des chemins de messages, tout comme un médiateur (Meditator), chargé de coordonner la relation entre les messages, les files d'attente et l'adressage des chemins.

3 Protocole au niveau de l'application

Communication de service à distance, l'objectif à atteindre est de lancer une demande sur un ordinateur, et l'autre machine traitera la demande en conséquence après l'avoir reçue et renverra le résultat du côté requête, il existe des méthodes de requête telles que la requête unidirectionnelle, la requête synchrone, la requête asynchrone, etc. Selon le principe de la communication réseau, ce qu'il faut faire pour y parvenir est de convertir la requête en flux et Transmettez-le à l'extrémité distante via le protocole de transmission. L'ordinateur final traite le flux demandé après l'avoir reçu, une fois le traitement terminé, le résultat est converti en flux et renvoyé à l'extrémité appelante via le protocole de transmission.

Le principe est le suivant, mais pour la commodité de l'application, l'industrie a lancé de nombreux protocoles au niveau des applications basés sur ce principe, afin que tout le monde n'ait pas besoin d'exploiter directement des choses de si bas niveau, généralement des applications. -communication à distance au niveau Le protocole fournira :

1. Afin d'éviter les problèmes liés aux opérations de flux directement, il fournira un format de transmission standard plus facile à utiliser ou plus adapté au langue ;

2. La mise en œuvre du mécanisme de communication réseau consiste à terminer la conversion du format de transmission en flux pour vous, et à le transmettre à l'ordinateur distant via un certain protocole de transmission. En recevant le flux, l'ordinateur distant le convertit dans un format de transmission et le stocke ou l'utilise d'une certaine manière pour notifier l'ordinateur distant.

Ainsi, lors de l'apprentissage des protocoles de communication à distance au niveau des applications, nous pouvons étudier avec ces questions :

1. Format standard de transmission Qu'est-ce que c'est ?

2. Comment convertir la requête en flux transmis ?

3. Comment recevoir et traiter les flux ?

4. Quel est le protocole de transmission ?

Cependant, le protocole de communication à distance au niveau de l'application n'apportera pas beaucoup d'amélioration au protocole de transmission. Il s'agit principalement du fonctionnement du flux, permettant à la couche application de générer des flux et de traiter des flux. Il est plus conforme au langage ou au standard utilisé. Quant au protocole de transmission, il est généralement facultatif. Les plus connus dans le domaine Java sont : RMI, XML-RPC, Binary-RPC, SOAP, CORBA, JMS. HTTP, pour être précis. Jetez un œil à ces protocoles au niveau des applications pour la communication à distance.

3.1 RMI (Remote Method Invocation)

RMI est un protocole de communication à distance typique personnalisé pour Java Nous savons tous que dans une seule machine virtuelle, nous pouvons y parvenir en appelant directement l'instance d'objet Java Communication, alors bien sûr, il serait préférable que cette méthode puisse être utilisée pour la communication à distance. Ce mécanisme de communication à distance est appelé RPC (Remote Procedure Call), et RMI est né dans ce but.

RMI utilise des stubs et des squelettes pour communiquer avec des objets distants. Le stub agit comme le proxy client de l'objet distant et a la même interface distante que l'objet distant. L'appel à l'objet distant est en fait effectué en appelant le stub de l'objet proxy client de l'objet. Grâce à ce mécanisme, RMI fonctionne comme si. c'est un travail local, le client appelle directement certaines méthodes sur le serveur. L'avantage est qu'il est fortement typé et les erreurs peuvent être vérifiées lors de la compilation. L'inconvénient est qu'il ne peut être basé que sur le langage JAVA et que le client et le serveur sont étroitement couplés.

Regardons le principe d'un processus complet de communication à distance basé sur RMI :

1. Le client initie une requête et la requête est transmis au client RMI ;

2. La classe stub sérialise l'interface, la méthode, le paramètre et d'autres informations demandés

3. ; socket le Stream sérialisé sur le serveur

4. Le serveur reçoit le flux et le transmet à la classe squelette correspondante

5. La classe squelette désérialise les informations demandées et appelle la classe de traitement réelle

6. Une fois le traitement terminé par la classe de traitement, le résultat sera renvoyé à la classe skelton

7. La classe Skelton sérialisera le résultat et enverra le flux vers le client via le socket. Le stub à la fin

8. stub est désérialisé après réception du flux et renvoie l'objet Java désérialisé à l'appelant.

Sur la base des principes, répondons à quelques questions qui accompagnaient auparavant l'apprentissage des protocoles au niveau des applications :

1. Normes de transmission Quel est le format ? est un ObjectStream Java.

2. Comment convertir la requête en flux transmis ? Convertissez les informations sur l'objet Java demandées en un flux basé sur le mécanisme de sérialisation Java.

3. Comment recevoir et traiter les flux ? Démarrez le port d'écoute correspondant selon le protocole adopté. Lorsqu'un flux arrive, le flux est désérialisé sur la base du mécanisme de sérialisation Java et les informations sur l'objet de traitement correspondant sont obtenues selon le protocole RMI, appelées et traitées, et le traitement est terminé. Le résultat final est également renvoyé sur la base du mécanisme de sérialisation Java.

4. Quel est le protocole de transmission ? Prise.

3.2 XML-RPC

RPC utilise le mode C/S, adopte le protocole http, envoie une requête au serveur et attend que le serveur renvoie le résultat. La requête comprend un ensemble de paramètres et un ensemble de textes, généralement sous la forme « classname.methodname ». L'avantage est qu'il est multilingue et multiplateforme, et que les côtés C et S ont une plus grande indépendance. L'inconvénient est qu'il ne prend pas en charge les objets et ne peut pas vérifier les erreurs dans le compilateur, mais ne peut les vérifier qu'au moment de l'exécution. .

XML-RPC est également un protocole d'appel à distance similaire à RMI. La différence entre celui-ci et RMI est qu'il utilise le format XML standard pour définir les informations demandées (objets demandés, méthodes, paramètres, etc.). Quel est l'avantage de cela ? Il peut également être utilisé dans la communication multilingue.

Jetons un coup d'œil à un processus de communication à distance du protocole XML-RPC :

1. Le client initie une requête et remplit les informations de la requête en fonction du Protocole XML-RPC ;

2. Une fois le remplissage terminé, le XML est converti en flux et transmis via le protocole de transmission

3. ; reçu et converti en XML après réception du flux. Obtenez les informations demandées et traitez-les selon le protocole XML-RPC

4. Après le traitement, écrivez le résultat en XML selon le XML-; Protocole RPC et renvoyez-le.

Répondez de la même façon à la question :

1. Quel est le format standard de transmission ? Format standard XML.

2. Comment convertir la requête en flux transmis ? Convertir XML en flux.

3. Comment recevoir et traiter les flux ? Obtenez le flux demandé via le port d'écoute, convertissez-le en XML, obtenez les informations demandées selon le protocole, traitez-le et écrivez le résultat en XML et renvoyez-le.

4. Quel est le protocole de transmission ? Http.

3.3 Binary-RPC

Comme vous pouvez le voir d'après le nom, Binary-RPC est similaire à XML-RPC. La seule différence est le format standard de transmission. est converti à partir de XML pour le format binaire.

Répondez de la même façon à la question :

1. Quel est le format standard de transmission ? Fichiers binaires au format standard.

2. Comment convertir la requête en flux transmis ? Convertissez les fichiers au format binaire en flux.

3. Comment recevoir et traiter les flux ? Récupérez le flux demandé via le port d'écoute, convertissez-le en fichier binaire, obtenez les informations demandées selon le protocole, traitez-le et écrivez le résultat en XML et renvoyez-le.

4. Quel est le protocole de transmission ? Http.

3.4 SOAP

SOAP signifie à l'origine Simple Object Access Protocol, qui est un protocole de communication léger pour l'échange d'informations basé sur XML pour les environnements distribués, on peut considérer que. SOAP est une version avancée de XML RPC. Les principes des deux sont exactement les mêmes, les deux sont http+XML. La seule différence est que les spécifications XML définies par SOAP sont également la norme de protocole d'invocation de service adoptée par. Webservice, donc le voici Plus d'élaboration.

Les services fournis par Web Service sont basés sur des conteneurs Web. La couche inférieure utilise le protocole http. Elle est similaire à un fournisseur de services distant, tel qu'un service de prévisions météorologiques. lieux et est un mécanisme de réponse aux demandes, est multi-système et multi-plateforme. C'est via une servlet que l'on fournit des services.

Tout d'abord, le client obtient le WSDL du WebService du serveur, et génère en même temps une classe proxy (Proxy Class) sur le client. Cette classe proxy est responsable des requêtes et des réponses avec le. Serveur WebService. Lorsqu'une donnée (au format XML) est encapsulée dans un flux de données au format SOAP et envoyée au serveur, un objet de processus sera généré et le paquet SOAP reçu par la requête sera analysé, puis l'objet sera traité. Une fois le traitement terminé, le résultat du calcul est encapsulé dans SOAP, puis le package est envoyé à la classe proxy du client (Proxy Class) en tant que réponse. De même, la classe proxy analyse également le package SOAP et effectue les opérations suivantes. Il s'agit d'un processus en cours d'exécution de WebService.

Le Web Service est généralement divisé en 5 niveaux :

1. Canal de transport HTTP

2. Format de données XML ;

3. Format d'encapsulation SOAP ;

4. Comment WSDL est décrit ;

5. UDDI UDDI est un service d'annuaire que les entreprises peuvent utiliser pour enregistrer et rechercher des services Web ;

3.5 JMS

JMS est un moyen et une méthode pour réaliser une communication à distance dans le domaine Java. La communication à distance basée sur JMS est différente de RPC, bien qu'elle puisse être réalisée. L'effet de RPC. , mais comme il n'est pas défini au niveau du protocole, nous ne pensons pas que JMS soit un protocole RPC, mais c'est bien un protocole de communication à distance. Il existe également des choses similaires à JMS dans d'autres systèmes linguistiques, qui peuvent être unifiées. est appelé mécanisme de message, et le mécanisme de message est généralement un mécanisme de communication recommandé dans les domaines à haute concurrence et distribués. Le principal problème ici est la tolérance aux pannes.

JMS est un service de messagerie Java. Les clients JMS peuvent transmettre des messages asynchrones via le service JMS. JMS prend en charge deux modèles de messages : point à point (P2P) et publication/abonnement (Pub/Sub), à savoir le modèle point à point et publication-abonnement .

Regardons le processus d'une communication à distance dans JMS :

1. Le client convertit la requête en un Message conforme à la réglementation JMS

2. Mettez le message dans la file d'attente ou le sujet JMS via l'API JMS

3. S'il s'agit d'une file d'attente JMS, il sera envoyé à la cible correspondante ; File d'attente. S'il s'agit d'un sujet, alors envoyé à la file d'attente JMS abonnée à ce sujet.

4. La fin du traitement obtient le message en faisant tourner la file d'attente JMS. Après avoir reçu le message, elle analyse le message et le traite selon le protocole JMS.

Répondez de la même façon à la question :

1. Quel est le format standard de transmission ? Message spécifié par JMS.

2. Comment convertir la requête en flux transmis ? Mettez les informations sur les paramètres dans Message.

3. Comment recevoir et traiter les flux ? La file d'attente JMS est entraînée en rotation pour recevoir le message. Après sa réception, il est traité. Après traitement, il est toujours mis dans la file d'attente sous forme de message pour envoi ou multidiffusion.

4. Quel est le protocole de transmission ? Aucune limite.

Basé sur JMS, c'est également l'une des méthodes couramment utilisées pour implémenter des appels asynchrones à distance.

4 Différences entre

4.1 RPC et RMI

1. RPC est multilingue, tandis que RMI ne prend en charge que Java.

2. RMI appelle des méthodes d'objet distant, permettant aux méthodes de renvoyer des objets Java et des types de données de base, tandis que RPC ne prend pas en charge le concept d'objet et que les messages transmis aux services RPC sont représentés par des données externes. Representation , XDR) représentation du langage qui résume les différences entre les classes endian et les structures de types de données. Seuls les types de données définis par XDR peuvent être transmis. On peut dire que RMI est un RPC Java orienté objet.

3. Sur les appels de méthode, dans RMI, l'interface distante permet à chaque méthode distante d'avoir une signature de méthode. Si une méthode est exécutée sur le serveur, mais qu'aucune signature correspondante n'est ajoutée à l'interface distante, la nouvelle méthode ne peut pas être appelée par le client RMI. Dans RPC, lorsqu'une requête arrive sur le serveur RPC, la requête contient un ensemble de paramètres et une valeur textuelle, généralement sous la forme de « classname.methodname ». Cela indique au serveur RPC que la méthode demandée se trouve dans la classe nommée "methodname". Le serveur RPC recherche ensuite une classe et une méthode correspondantes et les utilise comme entrée pour ce type de paramètre de méthode. Le type de paramètre ici correspond au type de la requête RPC. Une fois la correspondance réussie, cette méthode est appelée et le résultat est codé et renvoyé au client.

4. RPC lui-même n'a pas de spécifications, mais le mécanisme de fonctionnement de base est le même, à savoir : sérialisation/désérialisation+stub+squelette. D'une manière générale, tant que les appels à distance peuvent être effectués, il. est RPC Tel que : rmi .net-remoting ws/soap/rest hessian xmlrpc thrift potocolbuffer.

5. Une interface de communication de sockets complète est fournie en Java, mais les sockets nécessitent que le client et le serveur encodent et échangent des données à l'aide de protocoles au niveau de l'application. L'utilisation de sockets est très gênante. Un protocole qui remplace Sockets est RPC (Remote Procedure Call), qui résume l'interface de communication pour les appels de procédure, ce qui permet aux programmeurs d'appeler aussi facilement une procédure distante que d'appeler une procédure locale. Le système RPC utilise XDR pour coder les paramètres et renvoyer les valeurs des appels à distance. Cependant, RPC ne prend pas en charge les objets, donc l'invocation à distance orientée objet RMI (Remote Method Invocation) est devenue un choix inévitable. Avec RMI, appeler des objets distants est aussi pratique que d'appeler des objets locaux. RMI utilise le protocole de communication JRMP (Java Remote Method Protocol), qui est une méthode d'appel à distance basée sur le protocole TCP/IP.

4.2 JMS et RMI

1. À l'aide du service JMS, les objets sont physiquement déplacés de manière asynchrone directement d'une JVM sur le réseau à une autre Sur une JVM ( c'est un mécanisme de notification de message), tandis que l'objet RMI est lié à la JVM locale, et seuls les paramètres de fonction et les valeurs de retour sont transmis via le réseau (c'est un mécanisme de réponse aux requêtes).

2. RMI est généralement synchrone, c'est-à-dire que lorsque le client appelle une méthode du Serveur, il doit attendre le retour de l'autre partie avant de pouvoir continuer à exécuter ce processus de client. appeler une méthode locale donne l'impression que c'est également une fonctionnalité de RMI. JMS envoie généralement simplement un message au serveur de messages à partir d'un point précis. Après l'avoir envoyé, il ne se soucie généralement pas de savoir qui utilise le message. Par conséquent, les applications RMI sont généralement étroitement couplées, tandis que les applications JMS sont relativement faiblement couplées.

4.3 Webservice et RMI

RMI transfère des objets Java sérialisables via le protocole TCP et ne peut être utilisé que sur des machines virtuelles Java, des langages de liaison et des clients. Le client et le serveur doit être Java. Webservice n'a pas cette limitation. Webservice transmet des fichiers texte XML via le protocole http, quelles que soient la langue et la plate-forme.

4.4 Webservice et JMS

Webservice se concentre sur l'invocation de services à distance, et jms se concentre sur l'échange d'informations.

Dans la plupart des cas, Webservice est une interaction directe entre deux systèmes (Consumer Producer), tandis que dans la plupart des cas, jms est une interaction système à trois (Consumer Producer). Bien entendu, JMS peut également mettre en œuvre une communication en mode demande-réponse, à condition que l'un des consommateurs ou producteurs fasse également office de courtier.

JMS peut réaliser des appels asynchrones qui isolent complètement le client et le fournisseur de services, et peut résister aux pics de trafic ; les services WebService sont généralement appelés de manière synchrone et nécessitent une conversion d'objet complexe. Par rapport à SOAP, JSON et le reste sont désormais tous les deux. une bonne solution d'architecture http ;

JMS est une spécification de message sur la plateforme Java. Généralement, un message JMS n'est pas un XML, mais un objet Java. Évidemment, JMS ne prend pas en compte les systèmes hétérogènes. Pour parler franchement, JMS ne prend pas en compte les éléments non Java. Mais heureusement, la plupart des fournisseurs JMS (c'est-à-dire divers produits d'implémentation de JMS) ont résolu ce problème hétérogène. Par rapport au multiplateforme de WebService, chacun a ses propres avantages.

5 Technologies d'implémentation facultatives

Actuellement, le champ Java peut être utilisé pour implémenter des frameworks ou des bibliothèques pour la communication à distance. Les plus connus incluent : JBoss-Remoting, Spring-Remoting, Hessian, Burlap. , XFire (Axis) , ActiveMQ, Mina, Mule, EJB3, etc., donnons une brève introduction et évaluation de chacun. En fait, pour construire un cadre de services distribués, vous devez avoir une compréhension très approfondie de ces choses, car. le cadre de services distribués En fait, cela inclut la résolution de problèmes dans le domaine distribué et dans le domaine du niveau application.

Bien sûr, vous pouvez également implémenter votre propre framework ou bibliothèque de communication basé sur le principe de communication réseau distant (protocole de transport + Net IO).

Alors, lorsque vous comprendrez ces cadres ou bibliothèques de communication à distance, quelles questions apporterez-vous à l'étude ? Sur quel protocole

1. est basé ?

2. Comment initier une demande ?

3. Comment convertir la requête dans un format conforme au protocole ?

4. Quel protocole de transmission est utilisé pour la transmission ?

5. Quel mécanisme le répondeur utilise-t-il pour recevoir les demandes ?

6. Comment restaurer le flux au format transport ?

7. Comment répondre après traitement ?

5.1 Spring-Remoting

Spring-remoting est un cadre de communication à distance fourni par Spring dans le domaine Java. Sur la base de ce cadre, les beans Spring ordinaires peuvent également être facilement. Publié dans un certain protocole distant, vous pouvez également configurer le spring bean comme bean d'appel distant. Sur quel protocole est basé

1. ? En tant que framework de communication à distance, Spring intègre plusieurs bibliothèques de communication à distance pour prendre en charge plusieurs protocoles, tels que rmi, http+io, xml-rpc, binaire-rpc, etc.

2. Comment initier une demande ? Au Spring, puisqu'il utilise l'implémentation d'un proxy pour les beans d'appel à distance, la requête est entièrement initiée via l'appel de l'interface de service.

3. Comment convertir la requête dans un format conforme au protocole ? Spring convertit les informations d'objet demandées en flux selon le protocole. Par exemple, Spring Http Invoker est implémenté sur la base d'un protocole défini par Spring lui-même. Le protocole de transmission est http et les informations de demande sont converties en fonction de Java. mécanisme de sérialisation. Transport pour les flux.

4. Quel protocole de transport est utilisé pour la transmission ? Prend en charge plusieurs protocoles de transmission, tels que rmi, http, etc.

5. Quel mécanisme le répondeur utilise-t-il pour recevoir les requêtes ? Le répondeur suit la méthode du protocole pour recevoir les requêtes. Pour les utilisateurs, il leur suffit de configurer les beans Spring ordinaires en tant que répondeur ou serveur via la méthode de configuration Spring.

6. Comment restaurer le flux au format transport ? Restaurer selon le protocole.

7. Comment répondre après traitement ? Revenez simplement directement après le traitement, et spring-remoting effectuera la sérialisation correspondante selon la méthode du protocole.

5.2 Hessian

Hessian est une bibliothèque de communication à distance basée sur le RPC binaire fourni par caucho. Sur quel protocole est basé

1. ? Implémenté sur la base du protocole Binary-RPC.

2. Comment initier une demande ? Les requêtes doivent être initiées via l'API fournie par Hessian lui-même.

3. Comment convertir la requête dans un format conforme au protocole ? Hessian sérialise les informations de la demande via son mécanisme de sérialisation personnalisé pour générer un flux binaire.

4. Quel protocole de transport est utilisé pour la transmission ? Hessian transmet sur la base du protocole HTTP.

5. Quel mécanisme le répondeur utilise-t-il pour recevoir les requêtes ? Le répondeur reçoit des requêtes basées sur l'API fournie par Hessian.

6. Comment restaurer le flux au format transport ? Hessian désérialise les informations de requête selon son mécanisme de sérialisation privé, et lorsqu'elles sont transmises à l'utilisateur, il s'agit déjà de l'objet d'informations de requête correspondant.

7. Comment répondre après traitement ? Revenez directement après le traitement, et Hessian sérialise l'objet résultat et le transmet à l'extrémité appelante.

5.3 Toile de jute

La toile de jute est également fournie par caucho. La différence entre celle-ci et la toile de jute est qu'elle est basée sur le protocole XML-RPC. Sur quel protocole est basé

1. ? Implémenté sur la base du protocole XML-RPC.

2. Comment initier une demande ? Basé sur l'API fournie par Burlap.

3. Comment convertir la requête dans un format conforme au protocole ? Convertissez les informations de la demande dans un format XML conforme au protocole et convertissez-les en flux pour la transmission.

4. Quel protocole de transport est utilisé pour la transmission ? Protocole HTTP.

5. Quel mécanisme le répondeur utilise-t-il pour recevoir les requêtes ? Écoutez les requêtes HTTP.

6. Comment restaurer le flux au format transport ? Restaurer selon le protocole XML-RPC.

7. Comment répondre après traitement ? Le résultat du retour est écrit en XML et renvoyé à l'extrémité appelante par Burlap.

5.4 XFire, Axis

XFire et Axis sont les cadres d'implémentation de WebService qui peuvent être considérés comme un standard complet d'implémentation d'architecture SOA, donc l'utilisation de XFire et Axis est. Cela signifie également utiliser la méthode du service Web. Sur quel protocole est basé

1. ? Basé sur le protocole SOAP.

2. Comment initier une demande ? Appelez directement après avoir obtenu le proxy du service à distance.

3. Comment convertir la requête dans un format conforme au protocole ? Convertissez les informations de la demande au format XML qui suit le protocole SOAP, puis convertissez-les en flux pour transmission par le framework.

4. Quel protocole de transport est utilisé pour la transmission ? Protocole HTTP.

5. Quel mécanisme le répondeur utilise-t-il pour recevoir les requêtes ? Écoutez les requêtes HTTP.

6. Comment restaurer le flux au format transport ? Restaurer selon le protocole SOAP.

7. Comment répondre après traitement ? Le résultat du retour est écrit en XML et renvoyé à l'appelant par le framework.

5.5 ActiveMQ

ActiveMQ est une implémentation de JMS C'est un bon choix pour implémenter une communication à distance basée sur des mécanismes de message tels que JMS. le mécanisme de message lui-même permet d'implémenter une communication à distance basée sur JMS. Il peut facilement implémenter des appels synchrones/asynchrones/unidirectionnels, etc., et le mécanisme de message est également un bon choix du point de vue de la tolérance aux pannes. base importante pour qu'Erlang puisse atteindre la tolérance aux pannes. Sur quel protocole est basé

1. ? Basé sur le protocole JMS.

2. Comment initier une demande ? Suivez l'API JMS pour faire des requêtes.

3. Comment convertir la requête dans un format conforme au protocole ? Je ne suis pas sûr, je suppose que c'est un flux binaire.

4. Quel protocole de transport est utilisé pour la transmission ? Prend en charge plusieurs protocoles de transmission, tels que socket, http, etc.

5. Quel mécanisme le répondeur utilise-t-il pour recevoir les requêtes ? Écoutez le port conforme au protocole.

6. Comment restaurer le flux au format transport ? Identique à la question 3.

7. Comment répondre après traitement ? Suivez l'API JMS pour générer des messages et les écrire dans la file d'attente JMS.

5.6 Mina

Mina est un framework de communication fourni par Apache Network IO n'a pas été mentionné auparavant. Les frameworks ou bibliothèques mentionnés précédemment sont essentiellement basés sur BIO, tandis que. Mina utilise NIO. Lorsque la concurrence augmente, NIO aura une amélioration significative des performances par rapport à BIO, et l'amélioration des performances Java est étroitement liée à l'intégration étroite de NIO et du système d'exploitation. Sur quel protocole est basé

1. ? Basé sur Socket+NIO pur.

2. Comment initier une demande ? Grâce à l'API client fournie par Mina.

3. Comment convertir la requête dans un format conforme au protocole ? Mina suit le mécanisme de sérialisation Java pour sérialiser l'objet de requête.

4. Quel protocole de transport est utilisé pour la transmission ? Prend en charge plusieurs protocoles de transmission, tels que socket, http, etc.

5. Quel mécanisme le répondeur utilise-t-il pour recevoir les requêtes ? Écoutez le port de protocole en mode NIO.

6. Comment restaurer le flux au format transport ? Désérialisez l'objet de requête en suivant le mécanisme de sérialisation Java.

7. Comment répondre après traitement ? Suivez l'API Mina pour les retours.

MINA est NIO, il n'est donc pas surprenant qu'il prenne en charge les appels asynchrones.

6 Développement et situation actuelle du framework RPC

RPC (Remote Procedure Call) est un protocole d'appel à distance En termes simples, il permet aux applications d'appeler des méthodes distantes tout comme l'appel de méthodes locales. Le processus ou le service peut être appliqué dans de nombreux scénarios tels que les services distribués, l'informatique distribuée, l'appel de service à distance, etc. En parlant de RPC, tout le monde le connaît. Il existe de nombreux excellents frameworks RPC open source dans l'industrie, tels que Dubbo, Thrift, gRPC, Hprose, etc. Présentons brièvement les caractéristiques du RPC et les méthodes courantes d'appel à distance, ainsi que quelques excellents frameworks RPC open source.

Par rapport à d'autres méthodes d'appel à distance, RPC, HTTP, RMI et Web Service peuvent tous effectuer des appels à distance, mais les méthodes et objectifs de mise en œuvre sont différents.

6.1 RPC et HTTP

HTTP (HyperText Transfer Protocol) est un protocole de communication de couche application qui utilise une sémantique standard pour accéder aux ressources spécifiées (images, interfaces, etc.). Le serveur du réseau peut identifier le contenu de l'accord. Le protocole HTTP est un protocole d'accès aux ressources grâce auquel les requêtes à distance peuvent être complétées et les résultats des requêtes renvoyés.

Les avantages du HTTP sont la simplicité, la facilité d'utilisation, une forte compréhensibilité et l'indépendance linguistique. Il est largement utilisé dans les appels de service à distance, y compris sur Weibo. L'inconvénient de HTTP est que l'en-tête du protocole est plus lourd et que le lien entre la requête générale et le serveur spécifique est long, ce qui peut inclure la résolution DNS, le proxy Nginx, etc.

RPC est une spécification de protocole. HTTP peut être considéré comme une implémentation de RPC, ou HTTP peut être appliqué comme protocole de transmission de RPC. Le service RPC a un degré d'automatisation relativement élevé, peut réaliser de puissantes fonctions de gestion de services, est plus convivial lorsqu'il est combiné avec le langage et offre d'excellentes performances. Par rapport à HTTP, l’inconvénient du RPC est qu’il est relativement complexe et que le coût d’apprentissage est légèrement plus élevé.

6.2 RPC et RMI

RMI (Remote Method Invocation) fait référence à l'invocation de méthode à distance dans le langage Java. Chaque méthode dans RMI a une signature de méthode pour le client et le serveur RMI. appel de méthode à distance. RMI ne peut être utilisé que dans le langage Java. Vous pouvez considérer RMI comme un RPC Java orienté objet.

6.3 RPC et service Web

Le service Web est une méthode architecturale permettant de publier, d'interroger et d'appeler des services basés sur le Web, en se concentrant sur la gestion et l'utilisation des services. Les services Web décrivent généralement les services via WSDL et utilisent SOAP pour appeler les services via HTTP.

RPC est un protocole d'accès à distance, tandis que Web Service est une architecture qui peut également effectuer des appels de service via RPC, le service Web est donc plus adapté à la comparaison avec le même framework RPC. Lorsque le framework RPC assure la découverte et la gestion des services et utilise HTTP comme protocole de transmission, il s'agit en réalité d'un service Web.

Par rapport au service Web, le framework RPC peut mener une gouvernance plus fine des services, y compris le contrôle de flux, la gestion des SLA, etc., et présente de plus grands avantages dans les microservices et l'informatique distribuée.

RPC peut être basé sur le protocole HTTP ou TCP. Le service Web est RPC basé sur le protocole HTTP. Il a de bonnes performances multiplateformes, mais ses performances ne sont pas aussi bonnes que celles du RPC basé sur le protocole TCP. Deux aspects affecteront directement les performances de RPC : l'un est la méthode de transmission et l'autre est la sérialisation.

Comme nous le savons tous, TCP est un protocole de couche de transport, HTTP est un protocole de couche d'application et la couche de transport est inférieure à la couche d'application. En termes de transmission de données, plus la couche est basse, plus elle est rapide. Par conséquent, en général, TCP doit être plus rapide que HTTP.

7 Résumé

Dans le domaine de la communication à distance, il y a encore pas mal de points de connaissances impliqués, par exemple : Protocole de communication (Socket/tcp/http/udp/rmi /xml -rpc etc.), mécanisme de message, IO réseau (BIO/NIO/AIO), MultiThread, solution transparente d'appel local et d'appel distant (impliquant un Java Classchargeur, Dynamic Proxy, Unit Test etc.) , appels asynchrones et synchrones, mécanismes de traitement des communications réseau (reconnexion automatique, diffusion, exceptions, traitement de pool, etc.), sérialisation Java (mécanismes de sérialisation privés de divers protocoles, etc.), principes de mise en œuvre de divers frameworks (formats de transmission, comment Convertir le format de transport en flux, comment convertir les informations de la demande en format de transport, comment recevoir le flux, comment restaurer le flux au format de transport, etc.) , lesquels d'entre eux devez-vous maîtriser Cela dépend des besoins réels. C'est seulement lorsque vous comprenez les principes que vous pouvez faire un choix facile. Vous pouvez même créer un protocole de communication à distance privé en fonction de vos besoins. Pour ceux qui sont engagés dans des plates-formes de services distribués ou qui développent des applications distribuées plus importantes. , je pense qu'au moins les points de connaissances mentionnés ci-dessus doivent être compris.

Articles connexes :

Implémentation Java des requêtes get, PUT, POST et delete

Introduction détaillée aux problèmes courants de programmation Java

🎜 >

Explication détaillée des bases du multi-threading Java

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!