201

RESÚMEN
Universidad 2 UNIDAD
Nacional de Briceño Montaño Javier Rodolfo

1
Trujillo
Contenido

I. LLAMADAS A PROCEDIMIENTOS REMOTOS .......................................................... 3

Entonces, ¿Qué sé propuso para resolver dicho problema? ........................................ 3
 Llamadas a Procedimientos Remotos (RPC) .............................................................. 3
a. ¿Qué es lo que hace un RPC? .................................................................................... 3
b. ¿Qué es un Procedimiento Convencional?............................................................. 3
c. ¿Y cómo logra un RPC dicha simulación?.............................................................. 3
d. ¿Cómo se gestionan los pases de parámetros en una RPC? ............................ 4
e. ¿Qué suceden con los tiempos de espera en un RPC? ...................................... 4
f. ¿Y cuál es la solución propuesta a este problema? ............................................. 4
g. ¿Cuáles son las posibles fallas en un sistema RPC? .......................................... 4
h. ¿Cómo lograr que un RPC sea confiable con estás posibles fallas? .............. 5
*Comentario Personal: .......................................................................................................... 5
II. INVOCACIÓN REMOTA DE MÉTODOS – RMI ........................................................... 5
Comentario Personal: ............................................................................................................... 6
III. COMUNICACIÓN ORIENTADA A MENSAJES ........................................................... 6
Entonces, ¿Cómo le damos solución? ................................................................................ 6
a. Sockets ................................................................................................................................. 6
b. Message-passing interface(MPI) .................................................................................... 6
IV. CORBA ................................................................................................................................ 7
¿Qué se necesita para implementar CORBA? ................................................................... 7
¿La Arquitectura CORBA es orientada a objetos? ........................................................... 7
¿Cómo se la da la comunicación entre objetos? .............................................................. 7
¿Cuáles son los componentes de CORBA en el lado del cliente? ............................... 8
a. Stub IDL ............................................................................................................................ 8
b. Interfaz del ORB .............................................................................................................. 8
c. Repositorio de interfaces ............................................................................................. 8
d. Interfaz de invocación dinámica................................................................................. 8
*Comentario Personal: .............................................................................................................. 8

2
 I. LLAMADAS A PROCEDIMIENTOS REMOTOS

Los computadores en la actualidad están en su mayoría conectadas a una red, y

soportan comunicación de datos entre ellas. Es así que se han desarrollado muchas
técnicas para soportar dicha comunicación entre diferentes sistemas.
Ahora bien, con la aparición de los sistemas distribuidos, las comunicaciones de
datos se realizaban con el traspaso explícito de mensajes. Entonces, recordando la
definición de Sistemas distribuidos, se denota que la comunicación debe ser
transparente para el usuario y este tipo traspaso explícito de mensajes no cumple
con tal regla.

Entonces, ¿Qué sé propuso para resolver dicho problema?

En 1984, Birrell y Nelson publican un artículo donde se mostró una forma
completamente diferente de manejar la comunicación. En pocas palabras, lo que
sugirieron fue permitir que los programas llamaran a procedimientos ubicados en
otras máquinas y que dicha comunicación sea totalmente transparente. A dicha
comunicación se le conoce como “Llamada a procedimiento remoto”.

 Llamadas a Procedimientos Remotos (RPC)

RPC es una tecnología empleada para desarrollar aplicaciones que requieren
comunicación entre procesadores en un sistema distribuido.
a. ¿Qué es lo que hace un RPC?
Un RPC trata de simular la llamada a un procedimiento convencional, pero
entre diferentes ordenadores.
b. ¿Qué es un Procedimiento Convencional?
Es decir, invocar a un procedimiento que se encuentra en el mismo proceso de
un computador en particular.
c. ¿Y cómo logra un RPC dicha simulación?
El sistema local invoca, a través de la red, a una función alojada en otro sistema.
Lo que se pretende es hacerle parecer al programador que está ocurriendo una
simple llamada local. Esto se logra gracias a que el RPC asigna la tarea de
comunicación a un proceso (resguardo del cliente) que se encarga de establecer
la comunicación con el sistema operativo para enviar un mensaje remoto al
resguardo del servidor quien devuelve el mensaje al sistema operativo quien se
comunica con dicho resguardo para hacer la comunicación efectiva.

3
d. ¿Cómo se gestionan los pases de parámetros en una RPC?
En esta situación se deben examinar dos tipos de pases de parámetros, por
referencia y por valor.
Cuando se realiza un pase de parámetros por valor entonces el resguardo del
cliente toma sus parámetros y los coloca en un mensaje. También coloca el nombre o
el número del procedimiento por llamar en el mensaje porque el servidor puede soportar
muchas llamadas diferentes, y se le debe informar cuál llamada es requerida. Cuando
el mensaje llega al servidor, el resguardo lo examina para ver qué procedimiento se
necesita y realiza entonces la llamada adecuada. La llamada real del resguardo al
servidor parece la llamada cliente original, excepto por que los parámetros son variables
inicializadas desde el mensaje entrante.

Cuando se realiza un pase de parámetro por referencia, se realiza una copia del
arreglo a procesar, esta copia del arreglo se pasa como un mensaje, y es gestionado
por el servidor quien realiza sus operaciones sobre el mismo, el mensaje devuelto es el
mismo arreglo, con probables modificaciones que serán copiados o restaurados en su
posición de memoria inicial de la máquina cliente.

e. ¿Qué suceden con los tiempos de espera en un RPC?

Igual que en las llamadas a procedimientos convencionales, cuando un cliente llama a
un procedimiento remoto, el cliente se bloqueará hasta que se devuelva una respuesta.
Comentario: Claramente esto sugiere un problema, ya que en el tiempo de espera la
maquina cliente pudo haber realizado muchos otros procesos.

f. ¿Y cuál es la solución propuesta a este problema?

Para soportar tales situaciones, los sistemas RPC pueden proporcionar facilidades para
lo que conocemos como RPC asíncronas, mediante las cuales, un cliente continúa
trabajando de inmediato después de emitir la petición RPC.

g. ¿Cuáles son las posibles fallas en un sistema RPC?

 Pérdida del mensaje de petición (1): si un mensaje fue perdido, el cliente debe
retransmitir el mensaje despues de un tiempo de espera.
 Pérdida del mensaje de respuesta (2): el proceso fue ejecutado en el servidor,
pero se perdió el mensaje con la respuesta al cliente.
 Servidor caído (3): si el servidor falla mientras estaba completando la ejecución de
una llamada, debe ser capaz de quitar cualquier efecto colateral que se haya
producido por la ejecución parcial no finalizada.
 Cliente caído (4): cuando un proceso cliente cae mientras espera la respuesta de
una RPC, se la denomina invocación huérfana. En este caso debe definirse si el
servidor debe enviar o no la respuesta.

4
 h. ¿Cómo lograr que un RPC sea confiable con estás posibles fallas?
Para lograr confiabilidad en la comunicación, el uso de tiempo de espera exige que se
retransmitan los mensajes si no se reciben los mensajes de confirmado. Las diferentes
semánticas de RPCs puede ser:
“por-lo-menos-una-vez” (At-least-once): en este tipo de RPCs el servidor repite el
procesamiento del mensaje, aún si sólo se requiere una sola ejecución.
“exactamente-una-vez” (Exactly-once): en muchos casos, la repetición de la
ejecución de una petición puede destruir la consistencia de la información. De aquí la
necesidad de una primitiva que asegura que la petición fuese procesada una y sólo una
vez. Esta es la primitiva más deseada, pero la más difícil de implementar.

*Comentario Personal:
Las llamadas a procedimientos remotos son muy útiles en cuanto a
programación de aplicaciones que tengan la necesidad de intercambiar
información remotamente con otras máquinas, ya que disminuye complejidad y
robustez al código, así mismo da la impresión de estar tratando con
procedimientos locales.

II. INVOCACIÓN REMOTA DE MÉTODOS – RMI

Es una expansión de RPC cuyo objetivo es dar soporte en la comunicación de sistemas
orientado a objetos.

El objetivo de este es ser aplicado a sistemas distribuidos. En donde la condición inicial es

que exista un objeto mediante el cual se realizan los llamados a los métodos que
correspondan al mismo tipo de objeto. Un objeto ofrece múltiples interfaces. Una interface
puede ser implementada por múltiples objetos.

A través de RMI, un programa Java puede exportar un objeto, con lo que dicho objeto estará
accesible a través de la red y el programa permanece a la espera de peticiones en un puerto
TCP. A partir de ese momento, un cliente puede conectarse e invocar los métodos
proporcionados por el objeto.
La invocación se compone de los siguientes pasos:

 Encapsulado (marshalling) de los parámetros (utilizando la funcionalidad

de serialización de Java).
 Invocación del método (del cliente sobre el servidor). El invocador se queda
esperando una respuesta.

5
Al terminar la ejecución, el servidor serializa el valor de retorno (si lo hay) y lo envía al
cliente.
El código cliente recibe la respuesta y continúa como si la invocación hubiera sido local.

Comentario Personal:
La invocación de métodos remotos se hace muy interesante debido a que el paradigma
orientado a objetos es muy utilizado en el desarrollo de aplicaciones, y utilizar sus
propiedades para la comunicación remota hace una gran diferencia a la hora de
implementar estos tipos de comunicaciones.

III. COMUNICACIÓN ORIENTADA A MENSAJES

Las comunicaciones remotas mencionadas anteriormente se basan en la idea
de que el servidor está siempre operativo para poder procesar información, pero
esto no siempre sucede, muchas veces el servidor o el receptor está inactivo
entonces urge manejar este tipo de excepciones.
Entonces, ¿Cómo le damos solución?
La solución es definir la comunicación en término de paso de mensajes. Estos mensajes
pueden ser momentáneos o persistentes. Los momentáneos funcionan por intermedio
de Sockets y Message-passing interface.

a. Sockets

Para que dos programas puedan comunicarse entre sí es necesario que se cumplan
ciertos requisitos:

 Que un programa sea capaz de localizar al otro y así le sea más fácil.
 Que ambos programas sean capaces de intercambiarse cualquier
secuencia de octetos, es decir, datos relevantes a su finalidad.
Para ello son necesarios los dos recursos que originan el concepto de socket:

 Un par de direcciones del protocolo de red (dirección IP, si se utiliza el

protocolo TCP/IP), que identifican la computadora de origen y la remota.
 Un par de números de puerto, que identifican a un programa dentro de
cada computadora.
Los sockets permiten implementar una arquitectura cliente-servidor. La
comunicación debe ser iniciada por uno de los programas que se denomina
programa "cliente". El segundo programa espera a que otro inicie la comunicación,
por este motivo se denomina programa "servidor".
Un socket es un proceso o hilo existente en la máquina cliente y en la máquina servidora,
que sirve en última instancia para que el programa servidor y el cliente lean y escriban la
información. Esta información será la transmitida por las diferentes capas de red.
b. Message-passing interface(MPI)

6
Este está diseñado para aplicaciones paralelas, el cual su nivel de abstracción es mucho
más alto que el que se evidencia en sockets. Provee una interface con primitivas más
avanzadas. Por el contrario, cuenta con una gran cantidad de implementaciones
(librería y protocolos) propietarias lo que genera la necesidad de una interface standard.

IV. CORBA
Muchas de los métodos de comunicaciones entre aplicaciones vienen limitados
por el hecho de que estos necesitan estar desarrollados en el mismo lenguaje
de programación para poder establecer un intercambio óptimo de datos.
Es por ello la necesidad de contar con una arquitectura que permita la
integración de tecnologías de diferente fabricante.
De esta manera nace CORBA que es una arquitectura de comunicaciones que
soporta la construcción e integración de tecnologías de diferente fabricante
independientemente del tiempo de creación, así como pueden intercambiar
información personas que dominan diferente idioma, sin importar que no sea
usado actualmente.
¿Qué se necesita para implementar CORBA?
 Toda aplicación CORBA empieza con la definición de las interfaces de los
objetos que pueden distribuirse. Para ello se utiliza el lenguaje IDL. Esta
especificación establece un contrato entre cliente y servidor: qué servicios
(operaciones) ofrece el servidor al cliente.
 Compilar la interfaz remota. El compilador genera todo el código fuente
mencionado en el paso anterior.
 Implementar el servidor. A partir de los esqueletos que genera el compilador
idl es sencillo implementar el servidor.
 Implementar el cliente. De una manera similar al servidor, el cliente hace uso
de los stubs generados en el paso 2.
 Arrancar los programas. Una vez está todo implementado, se arranca el
servicio de nombrado, el servidor y finalmente, el cliente.
¿La Arquitectura CORBA es orientada a objetos?
Si está orientada a objetos, por lo que los objetos CORBA presentan muchas
características de otros sistemas orientados a objetos, incluyendo la herencia de
interfaces y el polimorfismo.
¿Cómo se la da la comunicación entre objetos?
Gracias a su ORB es que se permite la comunicación de objetos entre Cliente y
Servidor a través del "El bus de objetos", el cual es el intermediario entre clientes
y servidores que transmite las peticiones cliente-servidor y las respuestas
servidor-cliente. Se necesita un ORB en cada máquina.

7
 ¿Cuáles son los componentes de CORBA en el lado del cliente?

a. Stub IDL
Es el intermediario entre el cliente y el ORB, recoge del cliente llamadas
a métodos y las transmite al ORB. Por cada clase remota se requiere una
clase de STUB, además, es un componente que actúa como servidor,
puede estar ejecutándose en cualquier máquina conectada a la red que
recibe peticiones por parte de clientes que pueden ser locales o remotos.
b. Interfaz del ORB
Es un conjunto de librerías o APIs que definen funciones del ORB y que
el cliente puede acceder a él.

c. Repositorio de interfaces
Es una base de datos en tiempo de ejecución con versiones máquina de
las interfaces IDL.
d. Interfaz de invocación dinámica
Una interfaz de invocación dinámica permite la construcción dinámica de
invocaciones para un determinado objeto, ello garantiza que el cliente
pueda especificar el objeto, la invocación y los parámetros que se pasan
al servidor.

*Comentario Personal:
CORBA surge como una opción muy interesante para la comunicación de datos
entre aplicaciones desarrolladas en diferente lenguaje de programación, además
está comunicación es totalmente heterogénea, y de fácil migración. Si bien CORBA
aún no es aún un estándar para el desarrollo de aplicaciones, debido a que aún
tiene ciertas limitaciones, sus múltiples ventajas seguramente serán eje para su
utilización en el desarrollo de sistemas distribuidos.