Cuando diferentes programas necesitan comunicarse a través de una red, existen diferentes mecanismos para intercambiar información. Uno de ellos es RPC (Remote Procedure Call), un modelo de comunicación que permite a un programa solicitar la ejecución de una función o procedimiento que se encuentra en otro ordenador o servidor.

La principal característica de RPC es que intenta hacer que una operación remota se parezca a una llamada a una función local. El programa cliente realiza una petición y recibe el resultado sin tener que gestionar directamente todos los detalles de la comunicación de red.

Este modelo se utiliza especialmente en aplicaciones distribuidas, servicios de red y arquitecturas en las que diferentes componentes necesitan trabajar conjuntamente.

¿Qué significa RPC?

RPC son las siglas de Remote Procedure Call, que en español puede traducirse como llamada a procedimiento remoto.

La idea es bastante sencilla. Imaginemos que tenemos una función llamada:

calcularPrecio()

Si la función está dentro de nuestro propio programa, podemos ejecutarla directamente:

resultado = calcularPrecio();

Con RPC, esa función puede encontrarse en otro servidor. Desde el punto de vista del programa cliente, la llamada puede seguir teniendo una apariencia similar:

resultado = calcularPrecio();

Pero internamente se produce una comunicación a través de la red.

El cliente envía los parámetros necesarios al servidor, el servidor ejecuta el procedimiento y posteriormente devuelve el resultado.

¿Cómo funciona una llamada RPC?

Aunque para el programador pueda parecer una llamada normal a una función, detrás existe un proceso de comunicación.

De forma simplificada, podemos representarlo así:

CLIENTE
   │
   │ Solicitud RPC
   ↓
RED
   │
   ↓
SERVIDOR
   │
   │ Ejecuta procedimiento
   ↓
SERVIDOR
   │
   │ Resultado
   ↓
RED
   │
   ↓
CLIENTE

Por ejemplo, una aplicación podría necesitar consultar el saldo de una cuenta.

El cliente solicita:

obtenerSaldo(12345)

La petición se envía al servidor.

El servidor recibe el identificador:

12345

Consulta la información correspondiente y devuelve, por ejemplo:

2500 €

Para el programa cliente, la operación puede parecer simplemente una llamada a una función.

Cliente y servidor en RPC

En una comunicación RPC existen normalmente dos partes principales: cliente y servidor.

El cliente es el programa que solicita que se ejecute una determinada operación.

El servidor es el sistema que recibe la petición, ejecuta el procedimiento correspondiente y devuelve el resultado.

Este modelo encaja especialmente bien con los sistemas distribuidos, donde diferentes ordenadores o servicios trabajan conjuntamente mediante una red.

Por ejemplo:

Aplicación móvil
       │
       │ RPC
       ↓
Servidor de usuarios
       │
       ↓
Base de datos

La aplicación móvil no necesita ejecutar directamente todas las operaciones. Puede pedir al servidor que las realice.

¿Qué ocurre cuando llamamos a un procedimiento remoto?

Una llamada RPC necesita convertir la información de la función en datos que puedan viajar por la red.

De forma simplificada, podemos dividir el proceso en varias etapas:

1. El cliente realiza una llamada
          ↓
2. Se preparan los parámetros
          ↓
3. Los datos se envían por la red
          ↓
4. El servidor recibe la solicitud
          ↓
5. El servidor ejecuta el procedimiento
          ↓
6. Se prepara el resultado
          ↓
7. El resultado vuelve al cliente

Una parte importante de este proceso consiste en serializar y deserializar los datos, es decir, convertir la información a un formato adecuado para transmitirla y posteriormente reconstruirla.

¿Qué es un stub en RPC?

En muchos sistemas RPC aparece el concepto de stub.

Podemos imaginarlo como un intermediario que facilita la comunicación entre el programa cliente y el servidor.

El código del cliente utiliza el stub como si estuviera llamando a una función normal. El stub se encarga de preparar los datos necesarios para realizar la comunicación.

En el lado del servidor existe un mecanismo equivalente que recibe la información y permite ejecutar el procedimiento correspondiente.

De esta manera, buena parte de los detalles relacionados con la comunicación quedan ocultos para el programador.

Un ejemplo sencillo de RPC

Supongamos que tenemos una aplicación que necesita consultar el precio de un producto.

El cliente podría realizar una llamada conceptual como:

obtenerPrecio(125)

El número 125 sería el identificador del producto.

El servidor recibiría la solicitud:

Producto: 125

Después consultaría la información correspondiente y podría devolver:

Precio: 39.99

El cliente recibiría el resultado y podría mostrarlo en pantalla.

El proceso completo sería:

Cliente
   │
   │ obtenerPrecio(125)
   ↓
Servidor
   │
   │ Consulta producto 125
   ↓
Base de datos
   │
   │ 39.99 €
   ↓
Servidor
   │
   │ 39.99 €
   ↓
Cliente

RPC frente a una función local

La principal diferencia entre una función local y una llamada RPC es dónde se ejecuta realmente el procedimiento.

Una función local:

Programa
   │
   └── función()

se ejecuta dentro del propio programa o proceso.

En cambio, una llamada RPC puede tener esta estructura:

Programa cliente
       │
       │ Red
       ↓
Servidor
       │
       └── función()

Por tanto, aunque la llamada pueda parecer similar, existen diferencias importantes.

Una función local normalmente no depende de la conexión de red. Una RPC sí depende de la comunicación entre los sistemas involucrados.

Esto significa que hay que tener en cuenta cuestiones como la latencia, los errores de conexión, los tiempos de espera y la disponibilidad del servidor.

¿Para qué se utiliza RPC?

RPC puede utilizarse en numerosos escenarios en los que diferentes aplicaciones o servicios necesitan comunicarse.

Algunos ejemplos son:

• Aplicaciones cliente-servidor.
• Servicios internos de una empresa.
• Arquitecturas de microservicios.
• Aplicaciones distribuidas.
• Servicios en la nube.
• Aplicaciones móviles conectadas a servidores.
• Comunicación entre diferentes componentes de software.

En arquitecturas de microservicios, por ejemplo, diferentes servicios pueden estar especializados en tareas concretas y comunicarse entre ellos mediante mecanismos RPC.

RPC y las API

RPC está estrechamente relacionado con las API, aunque no son exactamente lo mismo.

Una API define cómo pueden comunicarse diferentes componentes de software.

RPC es un modelo que permite realizar operaciones remotas mediante llamadas a procedimientos.

Existen diferentes formas de implementar este concepto. Entre ellas encontramos tecnologías como XML-RPC, JSON-RPC y gRPC.

Por ejemplo, JSON-RPC utiliza JSON para representar los datos intercambiados, mientras que XML-RPC utiliza XML.

Esto permite utilizar el mismo concepto de llamada remota con diferentes formatos de comunicación.

¿Qué es gRPC?

Uno de los sistemas RPC más conocidos actualmente es gRPC.

gRPC es un framework de código abierto para llamadas a procedimientos remotos desarrollado inicialmente por Google. Está diseñado para facilitar la comunicación entre servicios y puede utilizarse con diferentes lenguajes de programación.

gRPC utiliza habitualmente HTTP/2 como transporte y Protocol Buffers (Protobuf) para definir servicios y representar los mensajes.

Un servicio podría definirse conceptualmente de esta forma:

service Usuario {
    rpc ObtenerUsuario(ID) returns (Usuario);
}

Esto establece que existe un servicio llamado Usuario que proporciona un método remoto denominado ObtenerUsuario.

El cliente puede utilizar el código generado para realizar esa llamada.

RPC y microservicios

RPC tiene especial importancia en arquitecturas basadas en microservicios.

Imaginemos una tienda online dividida en varios servicios:

           Tienda online
                │
       ┌────────┼────────┐
       ↓        ↓        ↓
   Usuarios  Productos  Pedidos
       │        │        │
       └────────┼────────┘
                ↓
          Otros servicios

El servicio de pedidos podría necesitar información del servicio de usuarios.

En lugar de acceder directamente a los datos internos del otro servicio, podría realizar una llamada:

obtenerUsuario(123)

El servicio de usuarios procesa la solicitud y devuelve la información necesaria.

gRPC, por ejemplo, está orientado precisamente a conectar servicios de este tipo en arquitecturas distribuidas.

Ventajas de RPC

Una de las principales ventajas de RPC es que proporciona una forma relativamente sencilla de trabajar con operaciones que realmente se ejecutan en otro sistema.

Entre sus características podemos destacar:

Abstracción de la comunicación

El programador puede trabajar con procedimientos y métodos sin tener que gestionar manualmente todos los detalles de la transmisión.

Separación entre cliente y servidor

El cliente y el servidor pueden encargarse de funciones diferentes.

Comunicación entre servicios

RPC resulta especialmente útil cuando diferentes servicios necesitan intercambiar información y ejecutar operaciones entre ellos.

Compatibilidad con diferentes lenguajes

Algunas implementaciones modernas permiten generar código cliente y servidor para diferentes lenguajes de programación. gRPC, por ejemplo, ofrece bibliotecas para numerosos lenguajes.

Desventajas de RPC

RPC también presenta algunos inconvenientes.

El principal es que una llamada remota no es exactamente igual que una llamada local.

Cuando llamamos a una función dentro del mismo programa, normalmente no dependemos de una red.

En una llamada RPC sí.

Por eso pueden producirse problemas como:

• Pérdida de conexión.
• Latencia.
• Tiempo de espera excesivo.
• Servidor no disponible.
• Errores de comunicación.
• Problemas de autenticación.
• Fallos durante la transmisión de datos.

Por ejemplo:

Cliente
   │
   │ RPC
   ↓
Servidor
   X
Servidor no disponible

El programa cliente debe estar preparado para gestionar este tipo de situaciones.

RPC frente a REST

RPC y REST son dos enfoques diferentes para diseñar comunicaciones entre aplicaciones.

En un modelo RPC, el cliente suele pensar en términos de acciones o procedimientos:

crearUsuario()
obtenerUsuario()
eliminarUsuario()

En REST, normalmente se trabaja con recursos identificados mediante URL y operaciones HTTP.

Por ejemplo:

GET /usuarios/123

podría utilizarse para obtener un usuario.

REST representa los datos como recursos, mientras que RPC se centra en las operaciones que pueden ejecutarse de forma remota.

No significa que uno sea siempre mejor que el otro. La elección depende de las necesidades de la aplicación, los clientes, el rendimiento, la arquitectura y otros factores técnicos.

RPC síncrono y asíncrono

Las llamadas RPC pueden diseñarse con diferentes modelos de comunicación.

En una llamada síncrona, el cliente realiza una solicitud y espera el resultado:

Cliente
   │
   │ Solicitud
   ↓
Servidor
   │
   │ Procesando...
   ↓
Cliente espera
   │
   ↓
Resultado

En un modelo asíncrono, el cliente puede continuar realizando otras tareas mientras espera el resultado o utilizar mecanismos específicos para recibir posteriormente la respuesta.

Esto puede resultar especialmente útil en sistemas distribuidos en los que existen muchas operaciones simultáneas.

¿RPC es un protocolo?

Aquí existe una pequeña particularidad terminológica.

RPC suele describirse como un protocolo, pero también es habitual hablar de RPC como un modelo o paradigma de comunicación.

La idea fundamental es el mecanismo que permite realizar llamadas a procedimientos que se ejecutan de forma remota.

Para transportar los datos pueden utilizarse diferentes protocolos de red. IBM señala, por ejemplo, que RPC presupone un protocolo de transporte de bajo nivel como TCP/IP o UDP para transportar los mensajes.

Por eso conviene diferenciar el concepto general de RPC de implementaciones concretas como JSON-RPC o gRPC.

Un ejemplo de la vida cotidiana

Podemos entender RPC con una comparación sencilla.

Imagina que estás en un restaurante.

Tú eres el cliente.

El camarero sería el intermediario.

La cocina sería el servidor.

Tú solicitas:

"Quiero una hamburguesa"

El camarero lleva la petición a la cocina.

La cocina prepara el pedido y posteriormente devuelve el resultado.

Tú no necesitas entrar en la cocina ni conocer cómo se prepara la hamburguesa.

En una comunicación RPC ocurre algo parecido:

Cliente
   │
   │ Solicitud
   ↓
Intermediario
   │
   ↓
Servidor
   │
   │ Ejecuta procedimiento
   ↓
Resultado
   │
   ↓
Cliente

La diferencia es que, en informática, ese proceso se realiza mediante software y comunicación de red.

¿Dónde podemos encontrar RPC?

Aunque el concepto pueda parecer abstracto, está presente en muchas arquitecturas de software.

Puede utilizarse para comunicar:

Aplicación móvil → Servidor
Servidor → Servidor
Microservicio → Microservicio
Cliente → Servicio en la nube
Aplicación → Servicio remoto

En sistemas modernos, tecnologías como gRPC permiten conectar servicios distribuidos y dispositivos utilizando comunicaciones eficientes y mecanismos como streaming bidireccional sobre HTTP/2.

En resumen

RPC (Remote Procedure Call) es un modelo de comunicación que permite a un programa solicitar la ejecución de un procedimiento situado en otro sistema, normalmente a través de una red.

La principal idea consiste en hacer que una operación remota pueda utilizarse de una forma parecida a una llamada a una función local.

El proceso básico es:

Cliente
   ↓
Solicitud RPC
   ↓
Red
   ↓
Servidor
   ↓
Ejecuta procedimiento
   ↓
Resultado
   ↓
Cliente

RPC resulta especialmente útil para desarrollar aplicaciones distribuidas y conectar diferentes servicios.

Existen diferentes tecnologías basadas en este concepto, entre ellas XML-RPC, JSON-RPC y gRPC. Este último es una implementación moderna de RPC orientada especialmente a la comunicación eficiente entre servicios y sistemas distribuidos.

En definitiva, cuando una aplicación necesita pedirle a otro ordenador o servicio que ejecute una operación y devuelva el resultado, RPC proporciona una forma de realizar esa comunicación sin tener que gestionar manualmente todos los detalles de la red.