1.

LLAMADA A PROCEDIMIENTOS REMOTOS (RPC) COMO

MIDDLEWARE

El RPC (del inglés Remote Procedure Call, Llamada a Procedimiento

Remoto) es un protocolo que permite a un programa de ordenador ejecutar
código en otra máquina remota sin tener que preocuparse por las
comunicaciones entre ambos. El protocolo es un gran avance sobre los
sockets usados hasta el momento.1

RPC fue desarrollado por Sun Microsystems, y es una colección de

herramientas y funciones de librería. Ejemplos de aplicaciones construidas
sobre RPC son NFS (sistema de ficheros en red), y NIS (sistema de
información de red)2

Las RPC son muy utilizadas dentro del paradigma cliente-servidor. Siendo
el cliente el que inicia el proceso solicitando al servidor que ejecute cierto
procedimiento o función y enviando a este de vuelta el resultado de dicha
operación al cliente.3

1 Disponible en : http://es.wikipedia.org/wiki/Middleware
2 Disponible en : http://es.tldp.org/Manuales-LuCAS/GARL2/garl2/x-087-2-appl.rpc.html
3 Disponible en : http://es.scribd.com/doc/52219317/El-RPC-Trabajo-de-investigacion
 ENLACE CLIENTE/SERVIDOR
El enlace especifica la relación entre un procedimiento remoto y el
programa llamador.

Enlaces no persistentes:
La conexión lógica se establece entre dos procesos en el momento de la
llamada remota. 4

Enlaces persistentes:
Una conexión se mantiene después de que el procedimiento termina. Las
conexiones persistentes son enlaces que no se cierran cuando termina la
ejecución del archivo de comandos. Cuando se pide una conexión
persistente, PHP comprueba si hay ya una conexión persistente idéntica
(que permanecía abierta desde antes) - y si existe, la usa. Si no existe, crea
un enlace.5

4 Disponible en http://www.slidefinder.net/s/ssoocap13/ssoocap13/1005992/p2 página 39

5 Disponible en http://www.slidefinder.net/s/ssoocap13/ssoocap13/1005992/p2 página 39
 SINCRONISMO FRENTE A ASINCRONISMO

RPC síncrona:
Las llamadas tradicionales a procedimiento remoto son síncronas, lo que
requiere que el proceso llamador espere hasta que el proceso llamado
devuelva un valor.
Se comporta de manera muy parecida a una llamada a subrutina. 6

RPC asíncrona:
No bloquea al llamador.
Permite que un cliente invoque repetidamente a un servidor, generando una
serie de peticiones de una vez.7

DESCRIPCIÓN DE RPC:

 RPC usa el mecanismo de solicitud respuesta presentado previamente.

 Oculta los detalles relacionados con la creación envío y recepción de los
mensajes.
 El cliente y el servidor se comunican mediante dos stub.
 Un stub es una interfaz de comunicación que implementa el protocolo RPC
y especifica cómo se construyen y como se intercambian los mensajes.
 Los stub son generados por un compilador de protocolo y se enlazan con
los clientes y los servidores.8

6 Disponible en http://www.slidefinder.net/s/ssoocap13/ssoocap13/1005992/p2 página 40

7 Disponible en http://www.slidefinder.net/s/ssoocap13/ssoocap13/1005992/p2 página 40
8 Disponible en http://www.ica.luz.ve/carevalo/procesamiento-distribuido-1/c29.html
 IMPLEMENTACIÓN DE LLAMADA REMOTA:

Primer Paso: El programa cliente (o procedimiento) llama al procedimiento

stub enlazado en su propio espacio de direcciones. Los parámetros pueden
pasarse de la manera usual y hasta aquí el cliente no nota nada inusual en
esta llamada ya que es una llamada local normal. El stub cliente reúne los
parámetros y los empaqueta en un mensaje. Esta operación se conoce
como reunión de argumentos (parameter marshalling).9

Segundo Paso: Después que se ha construido el mensaje, se lo pasa a la

capa de transporte para su transmisión.10

Tercer Paso: En un sistema LAN con un servicio sin conexiones, la entidad

de transporte probablemente sólo le agrega al mensaje un encabezamiento
y lo coloca en la subred sin mayor trabajo. En una WAN, la transmisión real
puede ser más complicada. 11

Cuarto Paso: Cuando el mensaje llega al servidor, la entidad de transporte

lo pasa al stub del servidor que desempaqueta los parámetros.12

Quinto Paso: El stub servidor llama luego al procedimiento servidor,

pasándole los parámetros de manera estándar. El procedimiento servidor
no tiene forma de saber que está siendo activado remotamente, debido a
que se lo llama desde un procedimiento local que cumple con todas las
reglas estándares. Únicamente el stub sabe que está ocurriendo algo
particular.13

9Disponible en http://www.wiziq.com/tutorial/97871-Llamadas-a-Procedimientos-Remotos-RPC-
DCE-XML-RPC
10
11
12
13
 Sexto Paso: Después que ha completado su trabajo, el procedimiento
servidor retorna de la misma forma en que retornan otros procedimientos
cuando terminan y, desde luego, puede retornar un resultado a un llamador.
14

Séptimo Paso: El stub servidor empaqueta luego el resultado en un

mensaje y lo entrega a la interfaz con transporte, posiblemente mediante
una llamada al sistema, al igual que en el Segundo Paso. 15

Octavo Paso: La respuesta retorna a la máquina cliente.16

Noveno Paso: La misma se entrega al stub cliente que desempaqueta las

respuestas. 17

Décimo Paso: Finalmente, el stub cliente retorna a su llamador, el

procedimiento cliente y cualquier valor devuelto por el servidor en el paso 6,
se entrega al cliente en el paso 10.18

14
Disponible en http://www.wiziq.com/tutorial/97871-Llamadas-a-Procedimientos-Remotos-RPC-
DCE-XML-RPC
15
16
17
18
 Figura

VENTAJA

 La ventaja está en que el desarrollador se preocupa de las interfaces que

soporta el servidor. Para especificar dichos interfaces se dispones de un IDL
(lenguaje de definición de interfaces). Los sistemas RPC disponen de
mecanismos de RPC integrados en un lenguaje de programación particular que
incluye además una notación para definir interfaces entre clientes y servidores
(IDL específico). Un IDL permite definir el nombre de las operaciones
soportadas por el servidor y sus parámetros (tipo y dirección). También se
deben proveer mecanismos para manejo de excepciones, garantizar la
ejecución de las operaciones, así como la detección de fallos. Todo ello de la
forma más transparente posible.
 La llamada a procedimiento es una abstracción muy usada, aceptada y bien
comprendida.
 Como la interfaz es estándar y está definida de forma precisa, el código de
comunicaciones de una aplicación puede generarse automáticamente.
 Como la interfaz es estándar y está definida de forma precisa, los
desarrolladores de software pueden escribir módulos clientes y servidores que
 pueden trasladarse ente computadores y sistemas operativos con pocas
modificaciones.
 En RPC las llamadas a los procedimientos son sincrónicas. Esto quiere decir
que cuando una aplicación hace una llamada a un procedimiento RPC debe
esperar que el servidor le responda para poder continuar con el procesamiento.
Tiene dos ventajas:
 Uso de múltiples componentes: Si su aplicación distribuida depende de
muchos componentes que se llaman entre sí, esto hace que la aplicación sea
más susceptible a fallas.
 Balanceo de Carga y Tolerancia a fallos: Es el problema de como las
aplicaciones descubren la información necesaria para poder conectarse otros
servidores en el caso de que el que está utilizando falle.

DESVENTAJA

 Exige alto nivel de procesamiento.

 Tiene bajo rendimiento.
 Priorización: Con RPC es muy difícil detectar que servidores están con mucha
carga de trabajo y derivar la llamada RPC a otro servidor menos ocupado.
 Picos de carga de Trabajo: RPC no puede manejar los picos de carga de
trabajo que puede tener un servidor si tiene llamadas RPC de muchos clientes.

Hay distintos tipos de RPC, muchos de ellos estandarizados como pueden ser:

 El RPC de Sun denominado ONC RPC (RFC 1057),

 El RPC de OSF denominado DCE/RPC y

 El Modelo de Objetos de Componentes Distribuidos de Microsoft DCOM.

Ninguno de estos es compatible entre sí. La mayoría de ellos utilizan un lenguaje

de descripción de interfaz (IDL) que define los métodos exportados por el
servidor.
 Hoy en día se está utilizando el XML como lenguaje para definir el IDL y el HTTP
como protocolo de red, dando lugar a lo que se conoce como servicios web.
Ejemplos de éstos pueden ser SOAP o XML-RPC.

ONC/ RPC

 ONC: Open Network Computing

 Ambiente para computación distribuida de Sun
 Muy utilizado en ambientes Unix
 Define mecanismos para llamadas de procedimientos remotos RPC y para
representación de datos independientes de la máquina (XDR)
 Adicionalmente ofrece los siguientes servicios:
 NIS: Network Information Service (antes Yellow Pages)
 REX: Remote Execution Service
 NFS: Network File System: Permite acceder a ficheros en anfitriones
remotos.
 NLM: Network Lock Manager 19

DCE/ RPC

 DCE: Distributed Computing Environment.

 Tecnología originalmente desarrollada por HP, llamada NCS (Network
Computing System).
 Posteriormente una versión ampliada fue seleccionada por la OSF (Open
Software Foundation) como su plataforma de computación distribuida, bajo el
nombre de DCE.
 Es el fundamento de DCOM (Distributed common object model), una
tecnología de objetos distribuidos de Microsoft.
 Define:
 Mecanismos de representación de datos independientes de la máquina
 Un protocolo de bajo nivel para realizar llamadas de procedimiento remoto

19 Disponible en http://www.ica.luz.ve/carevalo/procesamiento-distribuido-1/c31.html
  Un compilador de protocolos que lee la definición de un procedimiento
remoto y genera los stubs para que las aplicaciones puedan realizar las
llamadas
 Adicionalmente define:
 Servicios de autenticación
 Servicio de nombres
 Servicio de hora
 Sistema de archivos distribuidos 20

La característica más sugerente de la RPC de DCE es que puede integrarse a

los servicios de seguridad y nombramiento de DCE. Esta integración hace
posible autenticar cada llamada a procedimiento y localizar dinámicamente
servidores en tiempo de ejecución. Los servidores pueden atender
concurrentemente RPC mediante el empleo de hilos. El mecanismo de RPC
ofrece independencia de protocolos y redes.

20 Disponible en http://www.ica.luz.ve/carevalo/procesamiento-distribuido-1/c31.html
Cuadro comparativo:

- ONC DCE

 El servidor envía los datos

 Define un único formato de
sin conversión, junto con el
datos (XDR)
tipo de datos.
 El servidor convierte los
Representación  El cliente convierte los
de datos datos a XDR y los transmite
datos, en caso necesario, al
 el cliente convierte los datos
formato de la máquina local.
de XDR al formato de la
 Existen 16 formatos
máquina local
definidos.

UDP y Apollo domain

Mecanismo TIRPC (Transport Independent
datagrams (protocolo
RPC RPC)
propietario)

Compilador de Lenguaje incompatible con DCE Lenguaje incompatible con

protocolos RPC ONC RPC
2. MANEJO DE MENSAJES Y COLAS (MOM)

MOM es el Middleware orientado a mensajes (message-orien/ed

middleware). MOM es una pieza clave de middleware, absolutamente
esencial para una clase de productos de cliente/servidor. Si su aplicación
puede tolerar cierto nivel de respuestas independientes del tiempo, MOM
representa la vía más fácil para la creación de sistemas de cliente/servidor
empresariales e interempresariales. Contribuye también a la creación de
sistemas de cliente/servidor nómadas capaces de acumular en colas de
espera de transacciones en curso y ejecutar una carga en masa cuando es
posible establecer una conexión con un servidor de oficina.

MOM permite que mensajes de propósito general sean intercambiados en

un sistema de cliente/ servidor mediante colas de mensajes. Las
aplicaciones se comunican a través de redes insertando simplemente
mensajes en colas y obteniendo mensajes de colas. MOM oculta todas las
molestas comunicaciones de las aplicaciones y ofrece por lo general una
muy simple API de alto nivel con sus servicios. El MOM Consortium se
formó a mediados de 1993 con el propósito de crear estándares para el
middleware de manejo de mensajes. Sus miembros son proveedores de
productos como IBM (MQSeries), Cgovia (Comllll/TIicaliollsImegralor),
Peerlogic (PIPES),

Horizon Strategies (Message Express) y System Strategies (ezBridge).

Pero, ¿qué puede hacer usted con MOM? El manejo de mensajes y la
formación de colas de MOM permiten la comunicación en red entre clientes
y servidores sin que estén vinculados por una conexión lógica privada
especial. Clientes y servidores pueden operar a diferentes tiempos. Todos
se comunican insertando mensajes en colas y retirando mensajes de colas
Obsérvese que el servidor envía la respuesta a través de una cola de
mensajes. El manejo de mensajes no impone ninguna restricción a la
estructura de una aplicación: si no se requiere de respuesta, sencillamente
no se le envía.

Los productos de MOM ofrecen sus propios servicios de NOS, como

nombramiento jerárquico, seguridad y una capa que aísla aplicaciones de la
red. Usan memoria virtual del OS local para crear sus colas. La mayoría de
los productos de manejo de mensajes permiten que el emisor especifique el
nombre de la cola de respuesta. Incluyen también algún tipo de campo de
formatos que le indica al receptor cómo interpretar los datos del mensaje.

Los programas con integración de MOM no se comunican directamente

entre sí, de manera que un programa puede estar ya sea ocupado o no
disponible, o simplemente no correr al mismo tiempo. Un programa puede
decidir el momento en que desea recuperar un mensaje de su cola; no
existen restricciones de tiempo. El programa de destino puede incluso ser
puesto en marcha varias horas después. Si usted emplea una laptop, puede
reunir en una cola solicitudes en curso y someterlas al servidor al momento
de obtener acceso a un teléfono o a una LAN de oficina. El manejo de
mensajes permite que el cliente o el, servidor no estén disponibles.
Las colas de mensajes son muy versátiles. Pueden usarse para crear
relaciones uno a muchos o muchos a uno. En la figura, muchos clientes
envían solicitudes a la cola de un servidor. Los mensajes son extraídos de
la cola por múltiples instancias del programa del servidor, las cuales
atienden concurrentemente a los clientes. Las instancias del servidor
pueden extraer mensajes de la cola de acuerdo con su orden de recepción
o con algún esquema de prioridad o equilibrio de cargas. En todos los
casos es posible acceder concurrentemente a una cola de mensajes. Los
servidores también pueden hacer uso de filtros de mensajes para eliminar
aquellos que no desean procesar o transmitírselos a otros servidores.
La mayoría de los productos de manejo de mensajes de MOM ofrecen un
conjunto de API simple que corre en múltiples plataformas de sistemas
operativos. Casi todos ellos brindan también colas de mensajes
persistentes (registrados en el disco) y no persistentes (en memoria).

Los mensajes persistentes son más lentos, pero pueden recuperarse en

caso de fallas de energía eléctrica tras la reiniciación de un sistema. En
ambos casos, los mensajes pueden ser ya sea copiados o eliminados de
una cola. Una cola de mensajes puede ser local para la máquina o remota.
Los administradores de sistemas pueden especificar por lo general "el
número de mensajes que una cola está en condiciones de alojar y el
tamaño máximo de los mensajes. Los productos de manejo de mensajes
proporcionan en su mayoría un nivel mínimo de tolerancia de fallas bajo la
forma de colas persistentes. Algunos de ellos cuentan con alguna
modalidad de protección para transacciones, lo que hace posible que la
cola participe en un protocolo de sincronización de grabación en dos fases.
Asimismo, algunos pueden incluso redireccionar mensajes a colas alternas
en caso de una falla en la red.

Middleware orientado a mensajes; está diseñado para el servicio de

mensajes con tecnología asíncrona. Permite el envío de mensajes entre
aplicaciones, las aplicaciones sólo ponen y sacan mensajes de las colas, no
se conectan. El cliente y el servidor pueden ejecutarse en diferentes
tiempos (mensajes asíncronos), por lo que no necesariamente se requiere
respuesta.