Mécanismes d’Appel de

procédure à distance: RPC,

gRPC, RMI
Sofiane ouni

1
 • Client/Serveur « traditionnel » : RPC, gRPC
Le modèle Client-Serveur • Client/Serveur « à objets » : RMI, CORBA, DCOM
pour les applications • Client/Serveur « de données » : Requêtes SQL
• Client/Serveur « WEB » : WebSocket, CGI, Servlet, asp, jsp, php,...
distribués • Client/Serveur web service : SOAP, REST, GraphQL,…

• RPC (remote procedure call) est un protocole réseau permettant de

faire des appels de procédures sur un ordinateur distant à l'aide d'un
serveur d'applications.
• RMI (Remote Method Invocation) est une technologie fournie à partir
du JDK pour permettre de mettre en œuvre facilement des objets
distribués.
• DCOM : Distributed Component Object Model est une technique
propriétaire de Microsoft qui permet la communication entre des
composants logiciels distribués
• CORBA :Common Object Request Broker Architecture, est une
architecture logicielle pour le développement de composants et
d’object request broker (ORB).
2
RPC : Remote Procedure Call

3
RPC: Remote Procedure Call
• L'appel de procédure à distance (RPC) est
• une technologie de communication utilisée par un programme pour demander à
un autre programme d'utiliser son service sur un réseau sans même connaître
les détails du réseau.
• Un appel de fonction ou un appel de sous-programme sont d'autres termes
désignant un appel de procédure.
• Il est basé sur le concept client-serveur. Le client est le programme qui fait la
demande et le serveur est le programme qui fournit le service.
• Un RPC, comme un appel de procédure locale, est basé sur l'opération
synchrone qui nécessite l'arrêt de l'application requérante jusqu'à ce que le
processus distant renvoie ses résultats.
• Plusieurs RPC peuvent être exécutés simultanément en utilisant des processus
ou des threads légers partageant le même espace d'adressage.
• Le programme d'appel de procédure à distance utilise aussi souvent le langage de
définition d'interface (IDL), un langage de détermination permettant de décrire
l'interface de programmation d'application (API) d'un composant de programme
informatique. Dans ce cas, IDL agit comme une interface entre les machines
situées aux deux extrémités de la connexion, qui peuvent exécuter des systèmes
d'exploitation et des langages de programmation différents.
4
Fonctionnement de RPC

5
• Threads d'appel simultanés
s'exécutant dans un contexte
d'exécution partagé montre un
serveur exécutant des procédures
distantes dans ses deux threads
d'appel, pendant que le thread
d'application du serveur écoute.

6
• Les processus appelant et appelé dans le RPC communiquent pour
échanger des informations via le schéma de transmission de
messages.
• La première tâche côté serveur consiste à extraire les paramètres
de la procédure lorsqu'un message de requête arrive, puis le
résultat, à envoyer un message de réponse et enfin à attendre le
prochain message d'appel.
• Un seul processus est activé à un moment donné.
• Il n’est pas toujours nécessaire que l’appelant soit bloqué.
• Le mécanisme asynchrone pourrait être utilisé dans le RPC pour
permettre au client de fonctionner même si le serveur n'a pas
encore répondu.
• Afin de gérer les demandes entrantes, le serveur peut créer un
thread qui libère le serveur pour gérer les demandes ultérieures.

7
Types RPC: Callback RPC, Broadcast RPC, Batch-mode RPC
• RPC synchrone : dans le RPC synchrone, le programme client envoie une
requête au serveur et attend une réponse avant de continuer. Cela signifie que le
programme client est bloqué jusqu'à ce qu'il reçoive une réponse du serveur.
• RPC asynchrone ou Callback RPC : dans le RPC asynchrone, le programme
client envoie une requête au serveur et continue de s'exécuter sans attendre
de réponse. Une fois que le serveur a reçu la demande d'appel de procédure à
distance du client, il exécute la procédure demandée et renvoie la réponse au
client via le réseau lorsqu'il est prêt. Le RPC asynchrone est souvent utilisé
lorsque le serveur peut mettre beaucoup de temps à accuser réception ou
lorsque le client doit continuer à s'exécuter sans blocage. un paradigme P2P
(Peer-to-Peer) choisit entre les processus participants.
• Broadcast RPC (RPC pour diffusion) : la demande d'un client qui est diffusée sur
tout le réseau et gérée par tous les serveurs possédant la méthode de traitement
de cette demande est connue sous le nom de RPC de diffusion.
• RPC en mode batch : le RPC en mode batch permet au client d'aligner et de
séparer les requêtes RPC dans un tampon de transmission avant de les
envoyer au serveur en un seul lot sur le réseau.

8
9
 Architecture de RPC

• Le client invoque un « stub client » qui réside dans

son propre espace d'adressage.
• Ce stub convertit le message au format standard
en fonction des services réseau du client.
• Ensuite, il transfère le message au service réseau
distant.
• De l'autre côté, le serveur invoque le "server stub"
qui décode le message transféré selon son format
standard et reprend l'appel de procédure habituel.
• Une fois l'appel exécuté selon sa procédure, l'appel
est renvoyé au stub du serveur et il transfère le
message à la couche transport.
• Ensuite, la couche de transport renvoie le Un stub est un morceau de code qui traduit
message au stub client-serveur.
les paramètres envoyés entre le client et le
serveur lors d'un appel de procédure à
distance en informatique distribuée.
10
Dérivées de RPC
• Common Object Request Broker Architecture (CORBA)
• Java Remote Method Invocation (RMI)
• DCOM stands for Distributed Component Object Model.

11
Couche RPC d'un système
distribué utilisant Netty

12
framework Netty
• Netty est un framework open source
• permettant de créer un composant réseau haute performance
(messagerie ou RPC ou transport) d'un système distribué.
• Il repose sur les principes de conception de la programmation
asynchrone et aide les développeurs en évitant les efforts
importants de conception, de mise en œuvre et de maintenance
requis pour disposer d'une couche réseau hautes performances
dans un système.
• Les E/S non bloquantes, asynchrones et pilotées par
événements sont les éléments de base de Netty.

13
 Exemple de code : NettyRpc

14
https://github.com/luxiaoxun/NettyRpc
gRPC

15
gRPC

• gRPC est un framework RPC (Remote procedure call) open source initialement développé par
Google.
• Il utilise le protocole HTTP/2 pour le transport, Protocol Buffers comme langage de description
d'interface (IDL : interface description language),
• offre des fonctionnalités telles que l'authentification, la transmission bidirectionnelle et le
contrôle de flux, par le blocage ou non des communications par annulation ou délais d'attente.
• Il permet la construction de liaisons client/serveur multiplateforme pour de nombreux langages.
16
 gRPC

• Appels de Procédure à Distance Haute Performance

• gRPC fournit un mécanisme d'appel de procédure à distance (RPC) efficace et
performant en exploitant Protobuf.
• Il offre un streaming bidirectionnel, permettant aux clients et aux serveurs
d'envoyer et de recevoir plusieurs messages de manière asynchrone.
• Un message représente une unité de données qui doit être sérialisée (convertie en
format binaire) lorsqu'elle est envoyée sur le « fil » et désérialisée (convertie en sa forme
d'origine) lors de sa réception.
• gRPC plusque 5 X plus rapide que RPC

17
Fonctionnement

• gRPC est basé sur l'idée de définir un service, spécifiant les méthodes pouvant être
appelées à distance avec leurs paramètres et types de retour.
• Côté serveur, le serveur implémente cette interface et exécute un serveur gRPC
pour gérer les appels clients.
• Côté client, le client dispose d'un stub (appelé simplement client dans certaines
langues) qui fournit les mêmes méthodes que le serveur.
• Les données échangées se font avec Protobuf (Protocol Buffers). il est un format de
sérialisation de données agnostique au langage développé par Google.
18
 Exemple de gRPC : fichier proto
• On Commence par définir un fichier proto.
L'extension .proto est utilisée pour définir le
langage Protobuf. Dans le fichier proto, vous
définissez la structure des messages qui
seront échangés entre le client et le serveur.
• On a créé 3 messages. Le premier message
sert à créer la tâche Todo, le suivant est
l'objet complet de la tâche Todo et le dernier
est le message pour récupérer une tâche en
fonction d'un ID.
• Sans un service, nous ne pouvons pas utiliser
ces messages. Créons donc quelques
services gRPC dans le même fichier proto.

19
Exemple: en python
helloworld.proto

$ python -m grpc_tools.protoc -I../../protos --python_out=. --

pyi_out=. --grpc_python_out=. ../../protos/helloworld.proto

https://github.com/grpc/grpc/blob/master/examples/python/helloworld/greeter_client.py
https://github.com/grpc/grpc/blob/master/examples/python/helloworld/greeter_server.py

https://github.com/grpc/grpc/tree/master/src/python/grpcio 20
https://grpc.io/docs/languages/python/quickstart/
 Installation de gRPC pour python

https://grpc.io/docs/languages/python/quickstart/#generate-grpc-code

21
https://github.com/grpc/grpc/tree/master/src/python/grpcio
gRPC platforms https://grpc.io/docs/platforms/

Development or target platform to get started:

• Mobile : Android, iOS

• Web

Backend
22
Example : gRPC server and client in Node.js

callback function that sends a message

field back to the client 23
Intégration avec le Web browser

le serveur API REST fait office de point de contact entre

l'application Web et le backend. Dans de nombreux
scénarios, le serveur REST (comme un proxy) ne fait guère
plus que traduire les appels HTTP du client en appels
gRPC vers les services backend.

• gRPC est principalement destiné aux applications backend

• Il est actuellement impossible d'implémenter la spécification HTTP/2 gRPC3 dans le navigateur.
• Un proxy obligatoire pour la traduction entre les requêtes gRPC-Web et les réponses gRPC HTTP/2
• L'idée de base est que le navigateur envoie des requêtes HTTP normales (et dispose d'un petit proxy
devant le serveur gRPC pour traduire les requêtes et les réponses en quelque chose que le
navigateur peut utiliser.

24
gRPC-web & ASP.NET Core 3.1

• En janvier 2020, Microsoft a annoncé un support expérimental de gRPC-web

avec ASP.NET Core. Compatible avec les navigateurs (comme Angular, les
applications React et plus de SPA), Blazor WebAssembly et même Xamarin,
cette implémentation apporte une fonctionnalité importante : l'inutilité
d'utiliser un proxy tel qu'Envoy.

https://devblogs.microsoft.com/dotnet/grpc-web-experiment/
25
 gRPC comme API pour la communication entre
microservices distribués
Ces derniers temps, l’architecture des microservices est
devenue un choix populaire pour le développement
d’applications logicielles en particulier dans un
environnement distribué.
Dans une architecture de microservices, les microservices
doivent souvent communiquer entre eux. Par rapport à l'API
Web RESTful traditionnelle, un framework RPC basé sur
gRPC peut constituer une meilleure alternative (plus rapide
5X ou plus) pour la communication des microservices.

• La norme de facto pour l'utilisation de l'API

publique est REST sur HTTP.
• Pour les API privées, vous pouvez penser à
utiliser gRPC ; pour les avantages de gRPC.

• API publique : ces API sont consommées par les applications

clientes, généralement des navigateurs, des applications
mobiles ou d'autres applications,
• API privée : ces API ne sont pas exposées au monde extérieur et
sont principalement utilisées pour la communication
26
interservices au sein de votre application.
 gRPC vs RabbitMQ
• RabbitMQ donne une véritable communication asynchrone et fournira un
véritable découplage entre les services, le système fonctionnera
fonctionnera même si l'un des services est en panne. (Mieux structuré)
• Le cluster/broker RabbitMQ représente une surcharge supplémentaire que
vous devez payer et entretenir
• De plus, la surcharge du réseau est beaucoup plus importante pour l'envoi et
la réception de messages depuis un broker de messages que pour gRPC.
gRPC a été conçu pour utiliser un format de données très compact et pour
être un moyen de communication efficace en ressources entre les
microservices. (Plus rapide)
• Un broker de messages stocke généralement ses données sur un disque
tandis que gRPC fonctionne sur la RAM. Un broker de messages est installé
en tant qu'exécutable sur un serveur tandis que gRPC dépend de HTTP 2.0.
• Avec RabbitMQ, l’utilisation de files/messages persistants permet la
tolérance aux fautes ou pannes dans les systèmes répartis,
27
Request-Driven Architecture

Event-Driven Architecture

28
 Performances sur les temps de latences

https://medium.com/l3montree-techblog/performance-comparison-rest-vs-grpc-vs-asynchronous-communication-3ad27d144a13

• L'architecture API gRPC est la méthode de communication la plus performante

étudiée dans le cadre de l'expérience. Sous faible charge, il peut accepter 3,41 fois
plus de commandes que le système utilisant les interfaces REST.
• En outre, le temps de réponse moyen est inférieur de 9,71 millisecondes à celui
des API REST et de 9,37 millisecondes inférieur à celui des API AMQP.
29
 30
https://itnext.io/rpc-benchmark-and-inverted-json-b5ce0bf587be
Complexité des liens entre entités
(microservices)

31