AD Unidad3: Tecnologías de aplicaciones distribuidas

Aplicaciones Distribuidas Carrera de Software
Ph.D. Franklin Parrales 1
30/01/2023
Tecnologías de aplicaciones
distribuidas
Unidad 3
Material docente compilado por el profesor Ph.D. Franklin Parrales Bravo
para uso de los cursos de Aplciaciones Distribuidas

30/01/2023
Objetivo general de la Unidad 3
Aplicar tecnologías y mecanismos para el
desarrollo de aplicaciones distribuidas básicas, a
través de la utilización de técnicas y librerías para
sistemas distribuidos.

30/01/2023
Unidad 3: Tecnologías de aplicaciones
distribuidas
• Conceptos de tecnología y
Servicios
– Paso de mensajes
– Llamadas a servicio
– RPC
– RMI
– Sockets
– Middleware (P2P-Pub/Sub)
– Componente Distribuidos
(CORBA-DCOM-EJB)
– Webservices SOAP y REST
– GraphQL
– gRPC
– Transmisión de código
(Código móvil-Agentes
móviles)
• Modelo de Representación
de Datos y Formatos de
Fichero para serialización
– Modelo Raster
– Modelo Vectorial
– Formatos de Fichero para
Serialización de Datos.
• Apache Avro-Parquet-
Sequence File -Optimized
Row Columnar (ORC),
Feather, HDFS, raw
• Sincronización de tareas
• Mecanismos de tolerancia a
fallas en computación
distribuida.

30/01/2023
Introducción
• Esta sección estudia algunos modelos de
programación para aplicaciones distribuidas
• Modelos tradicionales han sido adaptados:
– Llamadas a procedimientos → RPC
– Programación Orientada a Objetos → RMI
– Programación basada en eventos → Eventos
distribuidos

30/01/2023
Introducción
• Comunicación Directa: mensajes, sockets
• Comunicación Remota: request-reply, RPC,
RMI.
• Comunicación Indirecta: Grupo, MOM,
Publica-Suscribe

30/01/2023
distribuidas
Servicios
– RPC
– RMI
– Sockets
(CORBA-DCOM-EJB)
– GraphQL
– gRPC
móviles)
– Modelo Raster
Row Columnar (ORC),
Feather, HDFS, raw
distribuida.

30/01/2023
Procesador
caché
nodo
mem e/s
Procesador
caché
nodo
mem e/s
Procesador
caché
nodo
mem e/s
Procesador
caché
nodo
mem e/s
red de interconexión
Arquitectura de memoria distribuida

30/01/2023
Sistemas de paso de mensajes
• Como alternativa al modelo de memoria
compartida, se define el modelo de paso de
mensajes:
– los procesos no comparten memoria (variables,
objetos, etc.)
– la comunicación se hace mediante operaciones
explícitas de envío y recepción
Emisor Receptor
CANAL
mensaje
enviar recibir

30/01/2023
Paso de Mensajes
Los modelos de comunicación basados en cliente-
servidor con paso de mensajes responden al esqueleto:
CLIENTE
msg
Send(msg)
Send(msg)
msg
SERVIDOR msg
Receive(msg)
Mensaje msg,reply;
msg=<dato a trasmitir>
send(msg);
receive(reply);
if(isOK(reply))
<operación correcto>
else
<error en operación>
...
Mensaje op,ack;
receive(op);
if(validOp(op))
ack=<operación OK>
else
ack=<operación ERROR>
send(ack);
...

30/01/2023
Paso de Mensajes
Cada pareja send-receive transmite un mensaje entre
cliente y servidor. Por lo general de forma asíncrona.
Habitualmente:
– Send no bloqueante.
– Receive bloqueante (pude hacerse no bloqueante).
Los mensajes intercambiados pueden ser:
– Mensajes de texto (por ejemplo: HTTP).
– Mensajes con formato (binarios).
Las aplicaciones definen el protocolo de comunicación:
Petición-respuesta, recepción explícita, sin/con
confirmación, ...

30/01/2023
Modelos de paso de mensajes
• Unicast: uno a uno
• Multicast: uno a varios (grupo)

30/01/2023
Serialización (marshalling)
• Proceso de codificación de un objeto en un medio de
almacenamiento (como puede ser un archivo, o un
buffer de memoria) con el fin de transmitirlo a través de
una conexión en red como una serie de bytes o en un
formato humanamente más legible como XML o JSON,
entre otros.

30/01/2023
Datos y marshalling
• Representación de datos varía en
diferentes plataformas. ¿Cómo enviarlos?
– Usando un estándar
– Usar formato original + descripción del
formato(xdr)
• Marshalling: juntar ítems (datos) a transmitir
y re-organizarlos para su transmisión
– Usar estándares. Ej.:
• CORBA: Common data representation
• Java: Serialización de objetos

30/01/2023
Marshalling – Unmarshalling
(Marshalling = Aplanamiento + XDR)
• Es el aplanamiento de estructuras de datos para
transmitirlas por la red
• Normalmente implica la conversión de datos a
un formato ‘exterior’ estándar
Proceso 2
Proceso 1
XDR
(External Data
Representation)

30/01/2023
¿Quién se encarga del marshalling?
• ¡Middleware!
– Evitar re-inventar la rueda
– Evitar introducir errores
– Mayor eficiencia
• Ejemplos:
– CORBA y JAVA → formato binario
– HTTP → ASCII (texto); ocupa más espacio
• ¿Por que HTTP usa ASCII?
– Para que pueda ser leido por humanos
• Otros usos (a más de RMI y RPC):
– transmisión de mensajes y almacenamiento en
archivos

30/01/2023
Unicast
• Es el modelo básico aplicado en las
arquitecturas Cliente-Servidor
• Está basado en protocolos de pedido-
respuesta (Request-Reply)
• Utiliza tres operaciones primitivas
– DoOperation( Port serverPort, Message req,
Message rsp )
– GetRequest( Port portID, Message req )
– SendReply( Port clientPort, Message reply )

30/01/2023
Unicast
Cliente-Servidor: interacción
DoOperation()
GetRequest()
SendReply()
Bloqueo
Bloqueo
Cliente Servidor

30/01/2023
Argumentos
Unicast
Formato de mensajes
ID Requerimiento
ID de proceso
ID de tipo Request, Reply

30/01/2023
Multicast
Un emisor, un mensaje, varios receptores

30/01/2023
Multicast
Tipificación
• Atómico: un mensaje transmitido a un
grupo de receptores es recibido por todos
o ninguno. Se utiliza con servidores
replicados que deben mantener el mismo
estado.
• Reliable: semántica de ‘mejor esfuerzo’:
no garantiza que todos los receptores
reciban el mensaje

30/01/2023
Multicast
Ordenamiento temporal
• Ciertas aplicaciones requieren que los mensajes
se reciban en el ordenamiento temporal en que
fueron emitidos 
– Multicast totalmente ordenado
– Multicast causal
E1 R1 R2 R3 E2
t1
Mensaje A
Mensaje B
Para R3 ‘A’ sucede antes que ‘B’

30/01/2023
Ventajas del paso de mensajes
• Válido para cualquier arquitectura de
computadores
– sistemas distribuidos
– arquitecturas paralelas sin memoria
compartida
– también en sistemas de memoria compartida
• No existe el problema universal del
acceso en exclusión mutua a datos
compartidos.

30/01/2023
Memoria Compartida OR/XOR Paso de
Mensajes
• Ambos esquemas de comunicación NO
son mutuamente exclusivos
• Podrían utilizarse simultáneamente dentro
de un mismo SO, o incluso dentro de un
mismo proceso

30/01/2023
Cuestiones básicas de la comunicación
• Sincronización entre emisor y receptor
– Comunicación síncrona/asíncrona
• Identificación en el proceso de
comunicación
– Comunicación directa/indirecta
– Comunicación simétrica/asimétrica
• Características del canal
– Capacidad, uni/bidireccional, etc...

30/01/2023
Comunicación síncrona o asíncrona
• Com. síncrona. El intercambio de un
mensaje es una operación atómica que
exige la participación simultánea del
emisor y el receptor (rendezvous).
• Com. asíncrona. El emisor puede enviar
un mensaje sin bloquearse; el receptor lo
puede recoger más tarde.

30/01/2023
Comunicación síncrona o asíncrona
• Símil:
Comunicación síncrona  llamada telefónica
Comunicación asíncrona  correo postal
• La comunicación síncrona es en principio más sencilla
de implementar
• Podemos emular comunicación síncrona usando
primitivas de comunicación asíncrona. P.ej. usando
SEND y REPLY.
• Podemos emular comunicación asíncrona usando
primitivas de comunicación síncrona. Símil: contestador
automático

30/01/2023
Repercusiones de la comunicación
asíncrona
• El emisor puede enviar varios mensajes:
– NECESIDAD de disponer de búferes
• ¿Cuándo sabe el emisor que su mensaje
ha llegado/se ha atendido?
– conveniencia de operaciones de “acuse de
recibo” o de respuesta
(send → receive → send_reply →
receive_reply)

30/01/2023
Llamadas bloqueantes / no
bloqueantes
• Las operaciones de envío y recepción
pueden estar definidas como bloqueantes
o no bloqueantes
• Un envío/recepción con bloqueo es un
ejemplo de comunicación síncrona
• Un envío/recepción sin bloqueo es un
ejemplo de comunicación asíncrona

30/01/2023
Identificación
• Comunicación directa
– Cada proceso que desea comunicarse debe
nombrar explícitamente el destinatario o el
remitente de la comunicación
• enviar(P, mensaje)
– Enviar un mensaje al proceso P
• recibir(Q, mensaje)
– Recibir un mensaje del proceso Q

30/01/2023
Identificación
• Comunicación indirecta
– Con la comunicación indirecta, los mensajes
se envían a, y se reciben de, buzones
(también llamados puertos)
• enviar(A, mensaje)
– Enviar un mensaje al buzón A
• recibir(A, mensaje)
– Recibir un mensaje del buzón A

30/01/2023
Comunicación indirecta
• P1, P2, P3 comparten un buzón A. P1 envía
un mensaje a A, y P2 y P3 ejecutan cada
uno un recibir de A. ¿Qué proceso recibirá
el mensaje que envió P1?
• Un buzón puede ser propiedad de un
proceso o del sistema

30/01/2023
Identificación
• Comunicación simétrica
– Los procesos tanto receptor como emisor
necesitan nombrar al otro para comunicarse
• Comunicación asimétrica
– Sólo el emisor nombra al destinatario.
Particularmente útil para cliente/servidor
• Otra forma más flexible: bulletin boards
(tablones) => nadie nombra a nadie

30/01/2023
Ejemplos
• Comunicación directa simétrica
– Enviar(P,mensaje)/Recibir(Q,mensaje)
• Comunicación directa asimétrica
– Enviar(P,mensaje)/Recibir(mensaje)
– Enviar(P,mensaje)/Recibir(id,mensaje)

30/01/2023
Características del canal
• Punto a punto, multipunto
• Unidireccional, bidireccional
• Capacidad del canal
– cero
– limitada
– infinita (teórico)
• Mensajes:
– Tamaño fijo o variable
– Canales con tipo o sin tipo
– Paso por copia o por referencia (¡cuidado!)

30/01/2023
Características del canal de
comunicación: ejemplos
• Comunicación directa
– Se establece automáticamente
– Un canal se asocia a exactamente dos
procesos
– Entre cada par de procesos sólo existe un
canal
– El enlace puede ser unidireccional, pero suele
ser bidireccional

30/01/2023
Características del canal de
comunicación: ejemplos
• Comunicación indirecta
– Se establece un canal entre un par de
procesos sólo si tienen un buzón compartido
– Un canal puede estar asociado a más de dos
procesos
– Entre cada par de procesos en comunicación
puede haber varios enlaces distintos, cada
uno de los cuales corresponderá a un buzón
– Los enlaces pueden ser unidireccionales o
bidireccionales

30/01/2023
Direccionamiento de los procesos

30/01/2023
Elección de mensajes
• Supongamos un proceso servidor que es
capaz de recibir peticiones de varios canales.
• Queremos que el proceso quede bloqueado
hasta que alguna petición llegue.
– ¿cómo lo resolvemos?
– solución: espera selectiva (select), espera no
determinista (ALT de occam), “select” de UNIX,
etc.

30/01/2023
Fallas en la transmisión
• Los mensajes pueden perderse por un
conjunto de causas:
– Descartados por emisores, receptores o
nodos intermedios de la red
– Red particionada
– Procesos que fallan

30/01/2023
Condiciones de error
• 1 máquina => los mensajes se implementan
(generalmente) en memoria compartida
– Fallo => falla todo el sistema
• Entornos distribuidos => procesos residen en diferentes
máquinas
– Los mensajes se transfieren por líneas de comunicación
– La probabilidad de que ocurra un error durante la comunicación
y el procesamiento es mucho mayor que en un entorno de una
sola máquina
– El fallo de un enlace no causa necesariamente el fallo de todo el
sistema

30/01/2023
• Cuando ocurre un fallo en un sistema, sea
centralizado o distribuido, el sistema debe
intentar recuperarse del error
• Algunas situaciones de error:
– El emisor o el receptor podría terminar antes
de que se procese un mensaje
• P espera un mensaje de Q (proceso terminado)
• P envía un mensaje a Q (proceso terminado)

30/01/2023
• Mensajes perdidos
– Fallo hardware o de la línea de comunicación
• Tres métodos para enfrentar este suceso
en función de quien asume la
responsabilidad de detectar el fallo:
– SO
– Emisor
– SO/Emisor

30/01/2023
• No siempre es necesario detectar los
mensajes perdidos => protocolos de red
que garantizan la confiabilidad
• ¿Cómo detectar la pérdida de mensajes?
– El método de detección más común consiste
en emplear tiempos límite o plazos

30/01/2023
• Mensajes alterados
– es común el uso de códigos de verificación de
errores (paridad, etc...)

30/01/2023
distribuidas
Servicios
– RPC
– RMI
– Sockets
(CORBA-DCOM-EJB)
– GraphQL
– gRPC
móviles)
– Modelo Raster
Row Columnar (ORC),
Feather, HDFS, raw
distribuida.

30/01/2023
Llamadas a servicio
• Método o función que puede invocar un proceso
para solicitar un cierto servicio al SO.
• Dado que el acceso a ciertos recursos del sistema
requiere la ejecución de código en modo
privilegiado, el SO ofrece un conjunto de métodos
o funciones que el programa puede emplear para
acceder a dichos recursos.
• En otras palabras, el SO actúa como
intermediario, ofreciendo una interfaz de
programación (API) que el programa puede usar
en cualquier momento para solicitar recursos
gestionados por el SO.

30/01/2023
Llamadas a servicio
Algunos ejemplos de llamadas al sistema son las
siguientes:
• write, que se emplea para escribir un dato en un
cierto dispositivo de salida, tales como una pantalla o
un disco magnético.
• read, que es usada para leer de un dispositivo de
entrada, tales como un teclado o un disco magnético.
• open, que es usada para obtener un descriptor de un
fichero del sistema, ese fichero suele pasarse a write.
• close, que se emplea para cerrar un descriptor de
fichero.

30/01/2023
Llamadas a servicio
El siguiente ejemplo
muestra en C la
invocación de las
llamadas al
sistema write, read, o
pen y close.
#include <stdio.h>
#include <stdlib.h>
int main(void) {
char buf[1024];
int fd, ret;
fd = open("f123", O_RDONLY);
if (fd < 0) {
perror("open");
exit(EXIT_FAILURE);
}
ret = read(fd, buf, sizeof(buf));
if (ret < 0) {
perror("read");
exit(EXIT_FAILURE);
}
close(fd);
write(1, buf, ret);
}

30/01/2023
distribuidas
Servicios
– RPC
– RMI
– Sockets
(CORBA-DCOM-EJB)
– GraphQL
– gRPC
móviles)
– Modelo Raster
Row Columnar (ORC),
Feather, HDFS, raw
distribuida.

30/01/2023
Llamada a Procedimiento Remoto
(RPC)
• Motivación:
– Aprovechar el paralelismo potencial existente
en un sistema distribuido
• ¿ Cómo ?
– Posibilitando que un proceso llame a un
procedimiento que se ejecutará en otro
procesador

30/01/2023
Remote Procedure Call
• Técnica que permite invocar un
procedimiento en un computador remoto
• Implica conocer la localización del
procedimiento e intercambiar mensajes de
pedido y respuesta
• Utiliza un protocolo de interacción
específico

30/01/2023
Llamadas a Procedimientos Remotos
...
send(msg)
...
receive(rpy)
...
receive(msg)
...
send(rpy)
Paso de mensajes (visión de bajo nivel)
...
...
x=buscar(1556)
...
int buscar(int cod)
{
...
...
return val;
}
Llamadas a procedimientos remotos (más alto nivel) Comodidad
Cliente
Cliente
Servidor
Servidor
msg
rpy

30/01/2023
RPC
• Similar a RMI (Java)
• Ejemplo: Sun RPC
programa
Request
Reply
Módulo de
Módulo de
comunicaciones
comunicaciones
despachador
procedimiento
procedimiento procedimiento
stub cliente stub servidor
proceso cliente proceso servidor
de servicio
cliente

30/01/2023
Funcionamiento General de RPC
Cliente:
– El proceso que realiza una la llamada a una función.
– Dicha llamada empaqueta los argumentos en un mensaje y se
los envía a otro proceso.
– Queda la espera del resultado.
Servidor:
– Se recibe un mensaje consistente en varios argumentos.
– Los argumentos son usados para llamar una función en el
servidor.
– El resultado de la función se empaqueta en un mensaje que se
retransmite al cliente.
Objetivo: acercar la semántica de las llamadas a procedimiento
convencional a un entorno distribuido (transparencia).

30/01/2023
Elementos Necesarios
• Código cliente.
• Código del servidor.
• Formato de representación.
• Definición del interfaz.
• Localización del servidor.
• Semánticas de fallo.
...
...
x=buscar(1556)
...
int buscar(int cod)
{
...
...
return val;
}
Cliente
Servidor

30/01/2023
Código Cliente/Código Servidor
Las funciones de abstracción de una llamada RPC a
intercambio de mensajes se denominan resguardos (stubs).
SISTEMA CLIENTE
CÓDIGO DE LA APLICACIÓN
PREPARA
ENTRADA
CONVIERTE
SALIDA
INICIO
LLAMADA
FIN
LLAMADA
BIBLIOT.
EJECUCIÓN
RPC
ENVÍA
ENTRADA
RECIBE
SALIDA
RESGUARDO
CLIENTE 1
2
8
9
5
3
PROCEDIMIENTOS
EJECUTA
PROCEDIMIENTO
REMOTO
SISTEMA SERVIDOR
RECIBE
Y PASA
RESGUARDO
SERVIDOR
PREPARA
SALIDA
TRANSMITE
SALIDA
CONVIERTE
ENTRADA
BIBLIOT.
EJECUCIÓN
RPC
4
6
7

30/01/2023
Mensajes de RPC
Mensaje de llamada
Mensaje de respuesta
Mensaje
ID
Mensaje
tipo
Cliente
Id Procedimiento Remoto Id
Prog. Nro. Ver. Nro. Proc.Nro.
Argumentos
Mensaje Id Mensaje tipo Respuesta Estado
(éxito)
Resultado
Mensaje Id Mensaje tipo Respuesta Estado
(no exitoso)
Razón de la falla

30/01/2023
Alternativas para protocolos RPC
• Request (R)
• Request-reply (RR)
• Request-reply-acknowledge reply (RRA)
Name Messages sent by
Client Server Client
R Request
RR Request Reply
RRA Request Reply Acknowledge reply

30/01/2023
Protocolos de RPC: R
• Request
– El cliente solicita la ejecución del
procedimiento remoto sin esperar respuesta
– Ejemplo: envío de alarmas o mediciones

30/01/2023
Protocolos de RPC: RR
• Request-Reply
– El cliente requiere la ejecución de un
procedimiento remoto
– El servidor recibe el pedido (mensaje R) y
ejecuta el procedimiento
– Una vez finalizada la ejecución, el servidor
empaqueta los resultados en un mensaje de
respuesta (Reply) y lo envía al cliente

30/01/2023
Protocolos de RPC: RRA
• Request-Reply-Acknowlege
– El cliente requiere la ejecución de un
procedimiento remoto
– El servidor recibe el pedido (mensaje R) y
ejecuta el procedimiento
– Una vez finalizada la ejecución, el servidor
empaqueta los resultados en un mensaje de
respuesta (Reply) y lo envía al cliente
– Cuando el cliente recibe la respuesta, envía
una confirmación (ACK)

30/01/2023
Resguardos (stubs)
Se generan automáticamente por el software de RPC en
base a la interfaz del servicio.
– Son independientes de la implementación que se haga del
cliente y del servidor. Sólo dependen de la interfaz.
Tareas que realizan:
– Localizan al servidor.
– Empaquetan los parámetros y construyen los mensajes.
– Envían el mensaje al servidor.
– Espera la recepción del mensaje y devuelven los
resultados.
Se basan en una librería de funciones RPC para las
tareas más habituales.

30/01/2023
Formato de Representación
Una de las funciones de los resguardos es
empaquetar los parámetros en un mensaje:
aplanamiento (marshalling).
Problemas en la representación de los datos
– Servidor y cliente pueden ejecutar en máquinas con
arquitecturas distintas.
– XDR (external data representation) es un estándar
que define la representación de tipos de datos.
– Pasos de parámetros (entrada/salida):
• Problemas con los punteros: Una dirección sólo tiene
sentido en un espacio de direcciones.

30/01/2023
Definición de Interfaces: IDL
IDL (Interface Definition Language) es un lenguaje de
representación de interfaces:
– Hay muchas variantes de IDL:
• Integrado con un lenguaje de programación (Cedar, Argus).
• Específico para describir las interfaces (RPC de Sun y RPC de DCE).
– Define procedimientos y argumentos (No la
implementación).
– Se usa habitualmente para generar de forma automática
los resguardos (stubs).
Server ServidorTickets
{
procedure void reset();
procedure int getTicket(in string ident);
procedure bool isValid(in int ticket);
}

30/01/2023
Localización del Servidor
La comunicación de bajo nivel entre cliente y
servidor por medio de paso de mensajes (por
ejemplo sockets). Esto requiere:
– Localizar la dirección del servidor: tanto dirección IP
como número de puerto en el caso de sockets.
– Enlazar con dicho servidor (verificar si esta
sirviendo).
Estas tareas las realiza el resguardo cliente.
En el caso de servicios cuya localización no es
estándar se recurre al enlace dinámico (dynamic
binding).

30/01/2023
Enlace Dinámico
Enlace dinámico: permite localizar objetos con
nombre en un sistema distribuido, en concreto,
servidores que ejecutan las RPC.
Tipos de enlace:
– Enlace no persistente: la conexión entre el cliente
y el servidor se establece en cada llamada RPC.
– Enlace persistente: la conexión se mantiene
después de la primera RPC:
• Útil en aplicaciones con muchas RPC repetidas.
• Problemas si lo servidores cambian de lugar o fallan.

30/01/2023
Enlazador Dinámico
Enlazador dinámico (binder): Es el servicio que
mantiene una tabla de traducciones entre nombres de
servicio y direcciones. Incluye funciones para:
– Registrar un nombre de servicio (versión).
– Eliminar un nombre de servicio.
– Buscar la dirección correspondiente a un nombre de
servicio.
Como localizar al enlazador dinámico:
– Ejecuta en una dirección fija de un computador fijo.
– El sistema operativo se encarga de indicar su dirección.
– Difundiendo un mensaje (broadcast) cuando los procesos
comienzan su ejecución.

30/01/2023
RPC: Protocolo Básico
cliente servidor
Desempaqueta
la respuesta
Se registra con un
servicio de nombres
recibe petición
Ejecuta el
procedimiento
envía petición
“enlaza con
el servidor”
prepara
parámetros,
envía petición

30/01/2023
Semántica Fallos
Problemas que pueden plantear las RPC:
– El cliente no es capaz de localizar al servidor. [1]
– Se pierde el mensaje de petición del cliente al servidor. [2]
– Se pierde el mensaje de respuesta del servidor al cliente. [3]
– El servidor falla después de recibir una petición. [4]
– El cliente falla después de enviar una petición. [5]
?
[1]
[2]
[4]
[5]

30/01/2023
Cliente no Puede Localizar al Servidor
• El servidor puede estar caído
• El cliente puede estar usando una versión
antigua del servidor
• La versión ayuda a detectar accesos a
copias obsoletas
• Cómo indicar el error al cliente
– Devolviendo un código de error (-1)
• No es transparente
– Ejemplo: sumar(a,b)
– Elevando una excepción
• Necesita un lenguaje que tenga excepciones

30/01/2023
Pérdida de Mensajes del Cliente
• Es la más fácil de tratar.
• Se activa una alarma (timeout) después
de enviar el mensaje.
• Si no se recibe una respuesta se
retransmite.
• Depende del protocolo de comunicación
subyacente.

30/01/2023
Pérdidas de Mensajes de Respuesta
• Más difícil de tratar
• Se pueden emplear alarmas y retransmisiones, pero:
– ¿Se perdió la petición?
– ¿Se perdió la respuesta?
– ¿El servidor va lento?
• Algunas operaciones pueden repetirse sin problemas
(operaciones idempotentes)
– Una transferencia bancaria no es idempotente
• Solución con operaciones no idempotentes es
descartar peticiones ya ejecutadas
– Un nº de secuencia en el cliente
– Un campo en el mensaje que indique si es una petición
original o una retransmisión

30/01/2023
Fallos en los Servidores
• El servidor no ha llegado a ejecutar la operación
– Se podría retransmitir
• El servidor ha llegado a ejecutar la operación
• El cliente no puede distinguir los dos
• ¿Qué hacer?
– No garantizar nada
– Semántica al menos una vez
• Reintentar y garantizar que la RPC se realiza al menos una vez
• No vale para operaciones no idempotentes
– Semántica a lo más una vez
• No reintentar, puede que no se realice ni una sola vez
– Semántica de exactamente una
• Sería lo deseable

30/01/2023
Fallos en los Clientes
• La computación está activa pero ningún
cliente espera los resultados (computación
huérfana)
– Gasto de ciclos de CPU
– Si cliente rearranca y ejecuta de nuevo la
RPC se pueden crear confusiones

30/01/2023
Aspectos de Implementación
• Protocolos RPC
– Orientados a conexión
• Fiabilidad se resuelve a bajo nivel, peor rendimiento
– No orientados a conexión
– Uso de un protocolo estándar o un específico
• Algunos utilizan TCP o UDP como protocolos básicos
• Coste de copiar información aspecto dominante en
rendimiento:
– buffer del cliente → buffer del SO local → red → buffer del
SO remoto + buffer del servidor
– Puede haber más copias en cliente para añadir cabeceras
– scatter-gather: puede mejorar rendimiento

30/01/2023
RPC de Sun
Utiliza como lenguaje de definición de interfaz IDL:
– Una interfaz contiene un nº de programa y un nº de
versión.
– Cada procedimiento específica un nombre y un nº de
procedimiento
– Los procedimientos sólo aceptan un parámetro.
– Los parámetros de salida se devuelven mediante un
único resultado
– El lenguaje ofrece una notación para definir:
• constantes
• definición de tipos
• estructuras, uniones
• programas

30/01/2023
RPC de Sun
• rpcgen es el compilador de interfaces que genera:
– Resguardo del cliente
– Resguardo del servidor y procedimiento principal del
servidor.
– Procedimientos para el aplanamiento (marshalling)
– Fichero de cabecera (.h) con los tipos y declaración de
prototipos.
• Enlace dinámico
– El cliente debe especificar el host donde ejecuta el servidor
– El servidor se registra (nº de programa, nº de versión y nº de
puerto) en el port mapper local
– El cliente envía una petición al port mapper del host donde
ejecuta el servidor

30/01/2023
Ejemplo de Fichero IDL (Sun RPC)
struct peticion {
int a;
int b;
};
program SUMAR {
version SUMAVER {
int SUMA(peticion) = 1;
} = 1;
} = 99;

30/01/2023
Programación con un Paquete de RPC
• El programador debe proporcionar:
– La definición de la interfaz (fichero idl)
• Nombres de las funciones
• Parámetros que el cliente pasa al servidor
• Resultados que devuelve el servidor al cliente
– El código del cliente
– El código del servidor
• El compilador de idl proporciona:
– El resguardo del cliente
– El resguardo del servidor

30/01/2023
Programación con RPC
COMPILADOR C COMPILADOR C
COMPILADOR C
COMPILADOR C
CABECERA CABECERA
FICHEROS
FUENTE DEL
CLIENTE
FICHEROS
OBJETO DEL
CLIENTE
FICHEROS
OBJETO DEL
SERVIDOR
EJECUTABLE
DEL
CLIENTE
EJECUTABLE
DEL
SERVIDOR
FICHEROS
FUENTE DEL
SERVIDOR
OBJETO
RESGUARDO
EN CLIENTE
OBJETO
RESGUARDO
EN SERVIDOR
MONTADOR MONTADOR
BIBLIOT.
RPC
BIBLIOT.
RPC
DESARROLLO
DE LA
INTERFAZ
DESARROLLO
DEL
CLIENTE
DESARROLLO
DEL
SERVIDOR
COMPILADOR IDL
RESGUARDO
EN SERVIDOR
RESGUARDO
EN CLIENTE
CABECERA
FICHERO
DE DEFINICIÓN
DE INTERFAZ

30/01/2023
idl.x
repcgen
idl_svc.c
servidor.c
idl.h
idl_xdr.c
idl_clnt.c
cliente.c
Archivos para
el cliente
Archivos
comunes
Archivos para
el servidor
Esquema de una Aplicación

30/01/2023
Invocación de objetos remotos
• Se necesita una referencia al objeto
– Debe ser única, aún con el paso del tiempo
– No deben ser re-utilizadas
– Ejemplo:
Internet address port number time object number
interface of
remote object
32 bits 32 bits 32 bits 32 bits

30/01/2023
Invocación remota vs RPC’s
• La invocación remota es una construcción
de los lenguajes concurrentes
• La RPC es una técnica para permitir
llamadas a procedimientos en entornos
distribuidos
• La palabra “remoto” tiene significados
diferentes en ambos casos:
– Invocación remota: “otro proceso”
– RPC: “otro procesador”

30/01/2023
• El punto de entrada llamado durante una invocación
remota sólo se ejecutará cuando su propietario lo
permita
• El procedimiento llamado durante una RPC se
puede ejecutar de inmediato
• El punto de entrada llamado durante una invocación
remota es ejecutado por el proceso propietario de
dicho punto de entrada
• El procedimiento llamado durante una RPC se
ejecuta en nombre del proceso llamador por un
proceso subordinado creado por el entorno de
ejecución

30/01/2023
• El proceso llamador y el punto de entrada
llamado durante una invocación remota se
pueden ejecutar en el mismo procesador.
Esto no tiene sentido en el caso de una
RPC

30/01/2023
Dificultades implementación RPC’s
• Paso de parámetros
– Valor
– Referencia: ¡más complejo!
• Los formatos internos de los datos pueden ser
muy diferentes en redes de máquinas
heterogéneas
• Requerirían conversaciones complejas y un
considerable trabajo adicional
• Fallos en la transmisión

30/01/2023
distribuidas
Servicios
– RPC
– RMI
– Sockets
(CORBA-DCOM-EJB)
– GraphQL
– gRPC
móviles)
– Modelo Raster
Row Columnar (ORC),
Feather, HDFS, raw
distribuida.

30/01/2023
Entornos orientados a objetos
• Tendencia actual hacia
sistemas compuestos
por un conjunto de
objetos que interactúan
entre sí.
– Un programa solicita
servicios invocando los
métodos que ofrece un
objeto.
– La invocación de
métodos se ve como
un paso de mensajes.
DATOS
Implementación de
métodos
(op1, op2, ..., opN)
op1
op2
opN

30/01/2023
Entornos orientados a objetos
• Comunicación entre objetos: Mensajes.
• Encapsulación.
• Identidad del objeto (Identificación).
• Herencia.
• Acciones.
• Clases.
• Instancias.
• Interfaces vs implementaciones.
• Herencia múltiple.
• Enlace dinámico.
• Recolección de basura.

30/01/2023
Motivación
La extensión de los mecanismos de RPC a una
programación orientada a objetos dio lugar a los
modelos de objetos distribuidos.
Ventajas:
– Los métodos remotos están asociados a objetos remotos.
– Más natural para desarrollo orientado a objetos.
– Admite modelos de programación orientada a eventos.
Problemas:
– El concepto de referencia a objeto es fundamental.
– Objetos volátiles y objetos persistentes.

30/01/2023
Modelo de objetos en sistemas
distribuidos
• ANSA (1989-1991) fue el primer proyecto
que intentó desarrollar una tecnología para
modelizar sistemas distribuidos complejos
– Utilizaba un diseño orientado a objetos
• Estándares:
– RMI: invocación de métodos remotos de Java
– CORBA: expande DCE con servicios orientados
a objetos
– DCOM: versión CORBA de Microsoft

30/01/2023
Invocación de métodos remotos (RMI)
• Comunicación cliente/servidor => RPC.
• Sistemas distribuidos basados en objetos =>
RMI (Remote method invocation).
• RMI: Acción de invocar un método de un
interfaz remoto en un objeto remoto.
• RMI ofrece:
– Mecanismos para crear servidores y objetos
cuyos métodos se puedan invocar remotamente.
– Mecanismos que permiten a los clientes localizar
los objetos remotos.

30/01/2023
Invocación de métodos remotos en
Java
• Java RMI
• El soporte para RMI en Java está basado en las
interfaces y clases definidas en los paquetes java.rmi
y java.rmi.server
• Características de Java RMI:
– No requiere un IDL (Interface Definition Language).
– Los argumentos y resultados se pasan mediante RMI por
valor (nunca por referencia).
– Un objeto remoto se pasa por referencia.
– La transferencia de objetos de tipos de datos complejos se
lleva a cabo mediante mecanismos de serialización.
– Es necesario tratar mayor número de excepciones que en
el caso de invocación de métodos locales.

30/01/2023
Invocación de métodos remotos en
Java
• Localización de objetos remotos:
– Servidor de nombres: java.rmi.Naming
• Ejemplo:
BankAccount acct = new BankAccountImpl();
String url = “rmi://java.Sun.COM/account”;
// enlazamos una url a un objeto remoto
java.rmi.Naming.bind(url, acct);
....
// búsqueda de la cuenta
acct = (BankAccount) java.rmi.Naming.lookup(url);

30/01/2023
Arquitectura de Java RMI

30/01/2023
Arquitectura de Java RMI
• Nivel de transporte: se encarga de las comunicaciones y de
establecer las conexiones necesarias
• Nivel de gestión de referencias remotas: trata los aspectos
relacionados con el comportamiento esperado de las
referencias remotas (mecanismos de recuperación, etc.)
• Nivel de resguardo/esqueleto (proxy/skeleton) que se
encarga del aplanamiento (serialización) de los parámetros
– proxy: resguardo local. Cuando un cliente realiza una invocación
remota, en realidad hace una invocación de un método del
resguardo local.
– Esqueleto (skeleton): recibe las peticiones de los clientes,
realiza la invocación del método y devuelve los resultados.

30/01/2023
Transparencia
• Sintaxis igual a invocación local
– referenciaRemota.metodo()
• Chequeo de formato de datos (igual a
invocaciones locales)
– refRem.procesaString(variableEntera) // error!

30/01/2023
No Todo es Transparente
• Objetos son consientes de que ciertas
invocaciones son remotas
– Asegurado por el uso de excepciones remotas
• Objeto local sabe que un objeto es remoto y
debe manejar RemoteException
• Quien implementa un objeto que va a ser
usado remotamente debe extender la
interfaz Remote

30/01/2023
Desarrollo de Aplicaciones RMI
Definición de la
interfaz remota
javac
(.java)
1
2
3
4
10
9
5
6
7
8
(.java)
usa
Cliente
Ejectuar
Cliente
(.class)
CLIENTE SERVIDOR
(.class)
Esqueleto
(.class)
Implementación de la
interfaz remota
Esqueleto
(.class)
Servidor
(.class)
Arrancar RMIRegistry
Crear los objetos
Registrar los objetos
javac
rmic

30/01/2023
Ejemplo 1: Sumador distribuido

30/01/2023
Interfaces Remotas en Java RMI
• Interfaces remotas
– se definen al extender interfaz Remote, del
paquete java.rmi
– Métodos deben arrojar RemoteException
– Otras excepciones particulares de la
aplicación también pueden utilizarse

30/01/2023
Modelización de la interfaz remota
(Sumador)
public interface Sumador extends java.rmi.Remote
{
public int sumar(int a, int b)
throws java.rmi.RemoteException;
}
1

30/01/2023
void rebind (String name, Remote obj)
Usado por un servidor para registrar el identificador a un objeto
remoto en base a su nombre.
void bind (String name, Remote obj)
Alternativamente, utilizado por servidor para registrar un objeto
remoto, pero si su nombre ya se encuentra asociado a una
referencia remota, arroja una excepción.
void unbind (String name, Remote obj)
Elimina un enlace nombre-referencia.
Remote lookup(String name)
Usado por clientes para buscar un objeto remoto basado en su
nombre. Retorna una referencia a un objeto remoto.
String [] list()
Retorna un arreglo de Strings con todos los nombres de objetos
enlazados en el registro..
RMIregistry

30/01/2023
Clase que implementa la interfaz (SumadorImpl)
import java.rmi.*;
import java.rmi.server.UnicastRemoteObject;
public class SumadorImpl extends UnicastRemoteObject implements Sumador{
public SumadorImpl(String name) throws RemoteException {
super();
try {
System.out.println("Rebind Object " + name);
Naming.rebind(name, this);
} catch (Exception e){
System.out.println("Exception: " + e.getMessage());
e.printStackTrace();
}
}
public int sumar (int a, int b) throws RemoteException {
return a + b;
}
}
2

30/01/2023
Código del servidor (SumadorServer)
import java.rmi.*;
import java.rmi.server.*;
public class SumadorServer {
public static void main (String args[]) {
try {
SumadorImpl misuma = new SumadorImpl("MiSumador");
}catch(Exception e) {
System.err.println("System exception" + e);
}
}
}

30/01/2023
Código en el cliente (SumadorClient)
import java.rmi.registry.*;
public class SumadorClient {
public static void main(String args[]){
int res = 0;
try {
System.out.println("Buscando Objeto ");
Sumador misuma =
(Sumador)Naming.lookup("rmi://"+args[0]+"/"+"MiSumador");
res = misuma.sumar(5, 2);
System.out.println("5 + 2 = " + res);
}
catch(Exception e){
System.err.println(" System exception"); }
System.exit(0);
}
}

30/01/2023
Registro del servicio
(Arrancar RMIRegistry)
• Antes de arrancar el cliente y el servidor, se
debe arrancar el programa rmiregistry en el
servidor para el servicio de nombres.
– El puerto que utiliza el rmiregistry por defecto es
el 1099.
– rmiregistry [port_number]
• El método rebind es utilizado normalmente
en lugar del método bind, porque garantiza
que si un objeto rémoto se registró
previamente con dicho nombre, el nuevo
objeto reemplazará al antiguo.
5

30/01/2023
Búsqueda
• Cualquier programa que quiera instanciar un
objeto remoto debe realizar una búsqueda de
la siguiente forma:
Sumador misuma = (Sumador)Naming.lookup("rmi://" + args[0]
+ "/" +"MiSumador");
• El método lookup devuelve una referencia
remota a un objeto que implementa la interfaz
remota.
• El método lookup interactúa con rmiregistry.

30/01/2023
Pasos
• Java RMI:
– Enlace a un nombre: bind(), rebind()
– Encontrar un objeto y obtener su referencia:
lookup()
– refObj.nombre_met()

30/01/2023
Cuadro general
Cliente Servidor
Stub Skeleton
Red
op1
op2
opN

30/01/2023
¿Cómo se ejecuta?
• Compilación
javac Sumador.java
javac SumadorImpl.java
javac SumadorClient.java
javac SumadorServer.java
• Generación de los esqueletos
rmic SumadorImpl
• Ejecución del programa de registro de RMI
rmiregistry
• Ejecución del servidor
java SumadorServer
• Ejecución del cliente
java SumadorCliente <host-del-servidor>
4
3
5
6 7
8 9 10

30/01/2023
Ejemplo 2: Pizarrón distribuido
• Usuarios pueden compartir una vista común
de un área de dibujo donde pueden añadir
objetos gráficos
• Servidor
– mantiene el estado actual del dibujo
• Clientes
– informan a servidor sobre cada figura añadida al
dibujo
– puede preguntar a servidor qué otras figuras han
sido añadidas
• Cada figura tiene un número de versión

30/01/2023
Interfaces Remotas en Java RMI
• Interfaces remotas
– se definen al extender interfaz Remote, del
paquete java.rmi
– Métodos deben arrojar RemoteException
– Otras excepciones particulares de la
aplicación también pueden utilizarse
• GraphicalObject: clase que almacena el
estado de un objeto gráfico
– Debe implementar Serializable

30/01/2023
Interfaces Remotas
public interface Shape extends Remote {
int getVersion() throws RemoteException;
GraphicalObject getAllState()
throws RemoteException;
}
public interface ShapeList extends Remote {
Shape newShape(GraphicalObject g)
throws RemoteException;
Vector allShapes() throws RemoteException;
int getVersion() throws RemoteException;
}

30/01/2023
Paso de Parámetros y Resultados
• Argumentos de métodos son parámetros
de entrada
• Retorno de método: parámetro de salida
• Cualquier objeto Serializable puede ser
mandado como parámetro o retornado
remotamente
– Todos los tipos primitivos de datos y objetos
remotos son Serializable

30/01/2023
• Clases de argumentos y valores de retorno
son bajadas (download) al destino por el
sistema RMI, si es necesario
• Pasando objetos remotos:
– Si tipo de un parámetro o retorno es interfaz
remota, entonces se pasa la referencia remota
• Pasando objetos no remotos:
– Todo objeto Serializable no remoto es copiado
y pasado por valor

30/01/2023
• Serializando objetos:
1. Objetos Remote: se reemplaza por su
referencia remota, la cual contiene el
nombre de su clase
2. Otros objetos: Java los serializa e incluye
una dirección para ubicar su clase (un URL),
para que pueda ser bajada por el receptor
de ser necesario

30/01/2023
Bajando Clases
• Si el destino no contiene la clase del
objeto que recibe, se baja el código de la
clase automáticamente
• De igual manera, si quien recibe una
referencia remota no tiene la clase proxy,
se baja el código automáticamente

30/01/2023
Ejemplo
• Supongamos que GraphicalObject no
soporta texto
• Cliente puede crear una subclase que
soporte texto y mandarla como parámetro
de newShape
• Cuando otros clientes se enteren de la
existencia de esa nueva figura, se bajarán
el código de la clase automáticamente

30/01/2023
RMIregistry
• Enlazador de Java RMI
• Una instancia de RMIRegistry debe correr
en cada servidor que tenga objetos remotos
• Mantiene tabla de mapeo entre nombres
(con formato parecido a un URL) a
referencias a objetos remotos presentes en
el servidor
– //nombreComputadora:puerto/nombreObjeto

30/01/2023
RMIregistry
• Contactado por métodos de clase Naming
• Servicio proporcionado por RMIregistry y
Naming no es un enlazador para todo un
sistema
– Consultas de clientes deben ser dirigidas al
host particular que contiene el objeto remoto
• Default: puerto 1099
• Cliente, servidor y registry pueden estar
en el mismo host (localhost)

30/01/2023
void rebind (String name, Remote obj)
Usado por un servidor para registrar el identificador a un objeto
remoto en base a su nombre.
void bind (String name, Remote obj)
Alternativamente, utilizado por servidor para registrar un objeto
remoto, pero si su nombre ya se encuentra asociado a una
referencia remota, arroja una excepción.
void unbind (String name, Remote obj)
Elimina un enlace nombre-referencia.
Remote lookup(String name)
Usado por clientes para buscar un objeto remoto basado en su
nombre. Retorna una referencia a un objeto remoto.
String [] list()
Retorna un arreglo de Strings con todos los nombres de objetos
enlazados en el registro..
RMIregistry

30/01/2023
Localización de objetos remotos
Localización de objetos remotos:
– Servidor de nombres: java.rmi.Naming
Ejemplo:
Cuenta cnt = new CuentaImpl();
String url = “rmi://java.Sun.COM/cuenta”;
// enlazamos una url a un objeto remoto
java.rmi.Naming.bind(url, cnt);
....
// búsqueda de la cuenta
cnt=(Cuenta)java.rmi.Naming.lookup(url);

30/01/2023
Registro de Objetos
Cualquier programa que quiera instanciar un
objeto de esta clase debe realizar el registro
con el servicio de nombrado de la siguiente
forma:
Cuenta mi_cuenta=
(Cuenta)Naming.lookup("rmi://"+host+"/"+”MiCuenta");
Antes de arrancar el cliente y el servidor, se
debe arrancar el programa rmiregistry en el
servidor para el servicio de nombres

30/01/2023
Programa Servidor
import java.rmi.*;
public class ShapeListServer
{
public static void main(String args[])
{
System.setSecurityManager(new RMISecurityManager());
try{
ShapeList aShapeList = new ShapeListServant();
Naming.rebind("Shape List", aShapeList );
System.out.println("ShapeList server ready");
System.out.println("ShapeList server main “
+ e.getMessage());
}
}
}

30/01/2023
import java.rmi.*;
import java.rmi.server.UnicastRemoteObject;
import java.util.Vector;
public class ShapeListServant
extends UnicastRemoteObject
implements ShapeList
{
private Vector theList;
private int version;
public ShapeListServant()throws RemoteException{...}
public Shape newShape(GraphicalObject g)
throws RemoteException
{
version++;
Shape s = new ShapeServant(g, version);
theList.addElement(s);
return s;
}
public Vector allShapes() throws RemoteException{...}
public int getVersion() throws RemoteException { ... }
}

30/01/2023
• UnicastRemoteObject: para objetos remotos
que viven mientras vive su proceso padre
• newShape: método fábrica, crea objetos
remotos
• RMISecurityManager: manejador de
serguridades por defecto
• Si no se proporciona un manejador de
seguridades, proxies y otras clases solo
pueden ser cargados del CLASSPATH local (no
bajadas de otros procesos)

30/01/2023
Programa Cliente
import java.rmi.*;
import java.util.Vector;
public class ShapeListClient{
public static void main(String args[])
{
System.setSecurityManager(new RMISecurityManager());
ShapeList aShapeList = null;
try{
aShapeList =
(ShapeList) Naming.lookup("//bruno/ShapeList");
Vector sList = aShapeList.allShapes();
} catch(RemoteException e) {
System.out.println(e.getMessage());
System.out.println("Client: " + e.getMessage());}
}
}

30/01/2023
Flujo de una Llamada Remota
Stub Skeleton
Objeto
cliente
Objeto
servidor
Sistema local Sistema remoto
Camino aparente
Camino real

30/01/2023
Más Sobre Java RMI
• Métodos estáticos (static) no pueden ser
parte de la interfaz remota
• Campos no pueden ser miembros de
interfaz remota
• Compilador de interfaces:
– rmic
– NombreClase_Stub.class
– NombreClase_Skel.class

30/01/2023
Seguridades
• RMISecurity.policy
grant{
permission java.net.SocketPermission “*:1024-65535”, “connect,accept”;
}
• Cargador de clases usado por RMI no se baja
ninguna clase de localidades remotas a menos que
haya un SecurityManager instalado
System.setProperty(“java.security.policy”, “RMISecurity.policy”);

30/01/2023
JNDI
• RMIRegistry no es escalable
– Debe haber uno por host con objetos remotos
• JNDI: Java Naming and Directory
Interface
• Es una interfaz unificada a múltiples
servicios de naming y directorios
• javax.naming

30/01/2023
Clases que dan Soporte a RMI
RemoteServer
UnicastRemoteObject
<servant class>
Activatable
RemoteObject

30/01/2023
Java RMI vs CORBA
• Java RMI es más sencillo:
– Trata sólo con objetos Java.
• Java RMI permite pasar por valor cualquier
objeto que se pueda “serializar”.
• CORBA es más flexible:
– Proporciona soporte RMI de objetos
implementados en diversos lenguajes y clientes
escritos también en distintos lenguajes.
• CORBA añade bastante complejidad.

30/01/2023
distribuidas
Servicios
– RPC
– RMI
– Sockets
(CORBA-DCOM-EJB)
– GraphQL
– gRPC
móviles)
– Modelo Raster
Row Columnar (ORC),
Feather, HDFS, raw
distribuida.

30/01/2023
¿Qué es un Socket?
• Un socket (enchufe), es un método para la
comunicación entre un programa del cliente y
un programa del servidor en una red.
• Se define como el punto final en una
conexión.
• Los sockets se crean y se utilizan con un
sistema de peticiones o de llamadas de
función a veces llamados interfaz de
programación de aplicación de sockets (API,
application programming interface).

30/01/2023
Sockets
• Es una interfaz de entrada-salida de
datos que permite la intercomunicación
entre procesos.
• Es un punto final (endpoint) en la
comunicación, el cual una aplicación
puede escribir datos que serán enviados
por la red y desde el cual ingresará los
datos que puede leer.

30/01/2023
Tipos de socket (1/2)
• Hay dos tipos de socket:
– Orientado a conexión (TCP):
• Establece un camino virtual entre servidor y
cliente, fiable, sin pérdidas de información ni
duplicados, la información llega en el mismo orden
que se envía.
• El cliente abre una sesión en el servidor y este
guarda un estado del cliente.
– El cliente utiliza la clase Socket
– El servidor utiliza la clase ServerSocket

30/01/2023
Tipos de socket (2/2)
– No orientado a conexión (UDP):
• Envío de datagramas de tamaño fijo. No es fiable,
puede haber pérdidas de información y
duplicados, y la información puede llegar en
distinto orden del que se envía.
• No se guarda ningún estado del cliente en el
servidor, por ello, es más tolerante a fallos del
sistema.
– Tanto el cliente como el servidor utilizan la clase
DatagramSocket.
• Todas estas clases (Socket, ServerSocket y
DatagramSocket) se encuentran en el paquete
java.net

30/01/2023
Operaciones a implementar en el cliente
• Para el cliente tenemos la clase Socket.
Basta instanciarla indicandole contra que
máquina conectarse y el puerto con el que
debe conectarse.
– Debe ser el mismo que el puerto que está
atendiendo el servidor.
• El resto es igual que en el servidor.
Socket socket = new Socket ("localhost", 35557);

30/01/2023
Operaciones a implementar en el servidor
• Los pasos que debemos dar en el servidor
son los siguientes:
1. Crear el socket servidor
2. Aceptar un cliente
3. Obtener los InputStream y/o OutputStream del
cliente.
4. Crear unos InputStream y/o OutputStream más
adecuados a nuestras necesidades.
5. Leer y escribir datos del y al cliente.
6. Cerrar el socket.

30/01/2023
1. Crear el socket servidor
• Para hacer el servidor en java tenemos la
clase ServerSocket.
• Al instanciarla usaremos el constructor al que
se le pasa un número de servicio (de puerto).
– Como se vio en C, este número de puerto puede
ser cualquier entero entre 1 y 65535.
• Los números de 1 a 1023 están reservados para
servicios del sistema (como ftp, mail, www, telnet, etc,
etc).
• Del 1024 en adelante podemos usarlos a nuestro
gusto. Lo único es que no puede haber dos servidores
atendiendo al mismo puerto/servicio.
ServerSocket socket = new ServerSocket (35557);

30/01/2023
2. Aceptar un cliente
• Una vez creado el servidor, le decimos que
empiece a atender conexiones de clientes.
Para ello llamamos al método accept().
– Este método se queda bloqueado hasta que
algún cliente se conecta.
– Nos devuelve un Socket, que es la conexión con
dicho cliente.
• Podemos aceptar simultáneamente varios
clientes, pero para atenderlos necesitaremos
programación multitarea o algo similar.
Socket cliente = socket.accept();

30/01/2023
3. Obtener el InputStream y/o OutputStream
• Ahora en cliente tenemos la conexión con el
cliente (valga la redundancia).
• Lo único que tenemos que hacer es obtener de él
el OuputStream o InputStream con los métodos:
getOutputStream() o getInputStream().
– La clase OutpuStream nos sirve para enviarle datos
al cliente.
– La clase InputStream nos sirve para leer datos del
cliente.
InputStream entrada = cliente.getIntputStream();
OutputStream salida = cliente.getOutputStream();

30/01/2023
4. Construirnos un InputStream y/o un
OutputStream más adecuados a nuestras
necesidades (1/2)
• Los métodos de estas dos clases para leer o escribr
datos son un poco feos, ya que únicamente envían
bytes.
– Suele ser habitual construir alguna otra clase de
entrada/salida de datos que tenga métodos más
adecuados:
• Si queremos enviar o recibir tipos normales (enteros,
flotantes, strings) tenemos las
clases DataInputStream y DataOutputStream.
– Estas clases tienen un constructor que admite
un InputStream y un OutputStream respectivamente.
DataInputStream entradaDatos = new DataInputStream (entrada);
DataOuputStream salidaDatos = new DataOutputStream (salida);

30/01/2023
4. Construirnos un InputStream y/o un
OutputStream más adecuados a nuestras
necesidades (2/2)
• Si queremos enviar o recibir clases enteras propias
nuestras, tenemos las
clases ObjectInputStream y ObjectDataStream.
– Al igual que las anteriores, usaremos el constructor que admite
un InputStream y un OutputStream
• Estas nuevas clases tienen métodos más bonitos de
usar (writeInt(), writeChar(), etc)
ObjectInputStream entradaObjetos = new ObjectInputStream (entrada);
ObjectOutputStream salidaObjetos = new ObjectOutputStream (salida);

30/01/2023
5. Envio/Lectura de datos normales
(enteros, flotantes, strings)
• El envío/lectura de datos normales se hace con las
clases
DataInputStream y DataOutputStream
– No tienen ningún truco especial,
– basta usar el metodo adecuado (writeInt(),
writeFloat(), readInt(), etc).
– Para strings usaremos los métodos writeUTF() y readUTF(),
que envían/leen las cadenas en formato UTF.

30/01/2023
5. Envio/Lectura de clases enteras
(1/6)
• Para el envio/lectura de clases normales usaremos los
métodos readObject() y writeObject() de ObjectInputS
tream y ObjectOutputStream.
• Para poder usar estos métodos las clases que enviemos
deben implementar la interface Serializable.
– Las clases de tipos de java (Integer, Float, String, etc)
implementan esa interface, así que se pueden enviar/leer a
través de estos métodos.

30/01/2023
(2/6)
• Si una clase nuestra contiene atributos que sean
primitivos de java (int, float, etc) o clases primitivas
(Float, Integer, String, etc), basta con hacer que
implemente la interface Serializable para poder
enviarlas.
– No hace falta que escribamos ningún método, simplemente
poner que se implementa.
// Esta clase se puede enviar/leer por un socket.
class Atributo implements Serializable
{
int a;
String b;
}

30/01/2023
(3/6)
• Si alguno de los atributos no es primitivo de java, basta
con que implemente la misma interface Serializable. Si
es así, no tendremos ningún problema.
• Si alguna de las clases no es Serializable, tendremos
que implementar los métodos privados
// Esta clase se puede enviar/leer por un socket
class DatoSocket implements Serializable
{
int c;
String d;
Atributo e; // Esta clase es serializable.
}

30/01/2023
(4/6)
private void writeObject(java.io.ObjectOutputStream out) throws
IOException {
// Enviamos los atributos a y b en un orden cualquiera.
out.writeInt (a);
out.writeUtf (b);
}
private void readObject(java.io.ObjectInputStream in) throws
IOException, ClassNotFoundException {
// Leemos los atributos a y b en el mismo orden que los
enviamos en writeObject()
a = in.readInt();
b = in.readUtf();
}

30/01/2023
(5/6)
• En el método writeObject() deberemos enviar por
el ObjectOutputStream todos los atributos de nuestra
clase, en el orden que consideremos adecuado.
– En el método readObject() deberemos ir leyendo
del ObjectInputStream todos los atributos de nuestra
clase e ir rellenando nuestros atributos.
– El orden en que leemos debe ser el mismo que en el que
escribimos y el formato leido el mismo que el escrito.
• En la diapositiva anterior existe el código de ambos
métodos para la clase Atributo, pero realmente no
hace falta escribir este código. ¿Por qué?
• Métodos son innecesarios salvo que queramos que se
envíen y reciban los datos de forma no standard.

30/01/2023

30/01/2023
(6/6)
• Para enviar una de estas clases el código es sencillo
• Para leerlo es igual de simple, sólo que tenemos que
saber qué tipo de clase estamos recibiendo para hacer
el "cast" adecuado.
DatoSocket dato = new DatoSocket();
cliente.writeObject(dato);
DatoSocket dato;
Object aux;
aux = socket.readObject();// Se lee el objeto
if (aux instanceof DatoSocket) // Se comprueba si es de tipo DatoSocket
dato = (DatoSocket)aux; // Se hace el cast.
• Debemos ir haciendo varios if con las posibles clases que
nos envíen desde el otro lado.

30/01/2023
6. Cierre del socket
• Para cerrar un socket hay que llamar a la
función close().
cliente.close(); // Con esto se cierra la conexión con el cliente.
socket.close(); // Con esto se cierra el socket servidor, ya no
atendemos más conexiones.

30/01/2023
◼ Invocación de objetos remotos
◼ Sencillo
◼ No hay un protocolo
◼ Genera mucho tráfico
◼ Stub+registro+objetos
◼ Invocación de métodos remotos
◼ Complicado
◼ Necesidad de un protocolo
◼ Genera poco tráfico
RMI Sockets
En el fondo, RMI = Sockets + Serialización + Algunas utilidades
Diferencias entre RMI y Sockets

30/01/2023
RMI
• Invocación remota de
métodos.
• Se traduce llamadas de
método y valores de
retorno y envía aquellos a
través de sockets.
• La llamada queda
bloqueada hasta recibir la
respuesta.
Sockets
• Sockets envía datos y
NO métodos.
• Toca definir el protocolo
propio.
• Se envía un mensaje y se
debe esperar por la
respuesta, que puede
llegar o no.
– Las lecturas de mensajes
dejan bloqueado el hilo
hasta que llegan

30/01/2023
Ancho de banda
RMI
• se envía además todo el
protocolo interno de rmi,
que suele ser de un
tamaño considerable. En
general, rmi consume
más ancho de banda de
nuestro enlace físico que
los sockets.
Sockets
• por la red sólo se envían
los mensajes que
nosotros enviamos

30/01/2023
Mensajes en broadcast
RMI
• la comunicación siempre
es punto a punto.
Sockets
• permiten enviar mensajes
sin destinatario, de forma
que cualquiera puede
recogerlo

30/01/2023
Carga dinámica de clases
RMI
• permite la carga dinámica
de clases, es decir, el
servidor puede pasar al
cliente clases que este no
tenga en su CLASSPATH
en tiempo de ejecución y
viceversa.
– Esto hace que ampliar
dinámicamente el
comportamiento de una
aplicación rmi sea más
sencillo.
Sockets

30/01/2023
Cuándo usar sockets y cuándo usar
rmi
• Si nuestro enlace físico es lento (puerto RS232,
modem, etc) es mejor usar sockets.
• Si tenemos pocos tipos de mensajes y se usan
para transmitir muchos datos (por ejemplo,
transferencia de ficheros), es mejor sockets.
• Si el servidor ofrece muchas funcionalidades, es
mejor rmi.
• Si la aplicación servidor va a modificarse con
cierta frecuencia y no queremos tener que
actualizar todos los clientes uno a uno, la carga
dinámica de clases de rmi puede ser una solución.

30/01/2023
Recapitulando…
• ¿Qué es un Socket?
• ¿Qué operaciones hay que definir en el servidor
y en el cliente?
En el Servidor
– Crear el socket servidor
– Aceptar un cliente
– Obtener los InputStream y/o OutputStream del cliente.
– Crear unos InputStream y/o OutputStream más
– Leer y escribir datos del y al cliente.
– Cerrar el socket.

30/01/2023
Recapitulando…
• ¿Qué es un Socket?
• ¿Qué operaciones hay que definir en el servidor
y en el cliente?
En el Servidor
– Crear el socket servidor
– Aceptar un cliente
– Obtener los InputStream y/o OutputStream del cliente.
– Leer y escribir datos del y al cliente.
En el Cliente
– Instanciar el socket cliente conectándolo al servidor
– Obtener los InputStream y/o OutputStream del Servidor.
– Leer y escribir datos del y al servidor.

30/01/2023
distribuidas
Servicios
– RPC
– RMI
– Sockets
(CORBA-DCOM-EJB)
– GraphQL
– gRPC
móviles)
– Modelo Raster
Row Columnar (ORC),
Feather, HDFS, raw
distribuida.

30/01/2023
Componentes Básicos
Diferentes Tecnologías a nivel de cada componente
Tecnologías
a nivel de
Red
CLIENTE SERVIDOR
Tecnologías
a nivel de
Cliente
Tecnologías
a nivel de
Server
NETWORK

30/01/2023
¿Qué es Middleware?
• Todo el software que está entre clientes y
servidores, y que soporta la interacción
entre ellos
• Conjunto de procesos intermedios entre
clientes y servidores
• ¿Dónde comienza?
• ¿Dónde termina?

30/01/2023
Elemento Clave: Middleware
• Transparencia de
– Ubicación: Local o remoto
– Protocolos de comunicación: TCP o UDP
– Hardware (Representación de datos)
– Sistema operativo
– Lenguaje de programación: Ej. CORBA
• IDL: Lenguaje de Definición de Interfaces

30/01/2023
Middleware
Middleware:
– Capa de software que ejecuta sobre el sistema operativo local
ofreciendo unos servicios distribuidos estandarizados.
– Sistema abierto independiente del fabricante.
– No depende del hardware y sistema operativo subyacente.
Ejemplos:
– DCE (Open Group).
– CORBA (OMG).
– ...
Hardware
SO
Hardware
SO
Hardware
SO
Middleware

30/01/2023
Middleware
• Se divide en dos categorías:
– Middleware genérico
• Procesos de apoyo que extienden el alcance y la
capacidad de los sistemas operativos de los
computadores empleados en clientes y servidores
+ protocolos de comunicación de capas 3, 4 y 5
– Middleware específico
• Procesos muy ligados y dependientes del tipo de
servidor con el que se está operando

30/01/2023
MiddleWare Genérico
• Incluye a protocolos de comunicación a nivel
de sesión, transporte y red
– Ejs: NetBIOS/NetBEUI, Named Pipes, Sockets
(TCP/IP), Sockets (IPX/SPX)
• Complementos a los NOS
– Servicios de archivos, servicios para la
invocación de procedimientos remotos, servicios
de encolamiento, servicios de seguridad,
servicios de directorios distribuidos, servicios
para manejo del tiempo en forma distribuida,
entre otros

30/01/2023
Middleware Específico
• Necesario para cumplir con una particular
interacción cliente/servidor
• 5 categorías básicas:
– DataBase-specific middleware
– Transactional-specific middleware
– Groupware-specific middleware
– Object-specific middleware
– Web-specific middleware

30/01/2023
distribuidas
Servicios
– RPC
– RMI
– Sockets
(CORBA-DCOM-EJB)
– GraphQL
– gRPC
móviles)
– Modelo Raster
Row Columnar (ORC),
Feather, HDFS, raw
distribuida.

30/01/2023
Motivación
La extensión de los mecanismos de RPC a una
programación orientada a objetos dio lugar a los
modelos de objetos distribuidos.
Ventajas:
– Los métodos remotos están asociados a objetos remotos.
– Más natural para desarrollo orientado a objetos.
– Admite modelos de programación orientada a eventos.
Problemas:
– El concepto de referencia a objeto es fundamental.
– Objetos volátiles y objetos persistentes.

30/01/2023
¿Qué son objetos (distribuidos)?
• Colección bien definida de variables (datos) y la
colección de funciones que trabajan sobre ellos
• Objetos distribuidos “parecen” objetos regulares,
pero pueden encontrarse en otras
computadoras

30/01/2023
Tecnología de Componentes
y Objetos Distribuidos
Client
Object
Server
Objects
ORB
ORB
NetWork

30/01/2023
Objetos-Distribuidos
Características:
– Uso de un Middleware: Nivel de abstracción para la
comunicación de los objetos distribuidos. Oculta:
• Localización de objetos.
• Protocolos de comunicación.
• Hardware de computadora.
• Sistemas Operativos.
– Modelo de objetos distribuidos: Describe los aspectos
del paradigma de objetos que es aceptado por la
tecnología: Herencia, Interfaces, Excepciones,
Polimorfismo, ...
– Recogida de basura (Garbage Collection): Determina
los objetos que no están siendo usados para a liberar
recursos.

30/01/2023
Tecnologías de Objetos Distribuidos
Actualmente existen tres tecnologías de desarrollo
de sistemas distribuidos basados en objetos:
– ANSA (1989-1991) fue el primer proyecto que intentó
desarrollar una tecnología para modelizar sistemas
distribuidos complejos con objetos.
– DCOM de Microsoft.
– CORBA de OMG.
– Tecnologías Java de Sun Microsytems:
• Remote Method Invocation (RMI).
• Enterprise Java Beans (EJB).
• Jini.
– Diferentes entornos de trabajo propietarios.

30/01/2023
OMG
(Object Management Group)
Conjunto de organizaciones que cooperan
en la definición de estándares para la
interoperabilidad en entornos heteregéneos.
Fundado en 1989, en la actualidad lo
componen más de 700 empresas y otros
organismos.

30/01/2023
OMA
(Object Management Architecture)
Arquitectura de referencia sobre cual se pueden
definir aplicaciones distribuidas sobre un entorno
heteregéneo. CORBA es la tecnología asociada a
esta arquitectura genérica.
Formalmente esta dividida en una serie de modelos:
– Modelo de Objetos
– Modelo de Interacción
– ...

30/01/2023
ORB
Servicios Facilidades
Comúnes
Interfaces
de Dominio
Aplicaciones
OMA
Una aplicación definida sobre OMA esta compuesta por
una serie de objetos distribuidos que cooperan entre si.
Estos objetos se clasifican en los siguientes grupos:

30/01/2023
OMA
Servicios:
– Proporcionan funciones elementales necesarias para
cualquier tipo de entorno distribuido, independientemente
del entorno de aplicación.
– Los tipos de funciones proporcionados son cuestiones
tales como la resolución de nombres, la notificación
asíncrona de eventos o la creación y migración de objetos.
– Concede un valor añadido sobre otras tecnologías (por
ejemplo RMI).
– Están pensados para grandes sistemas.

30/01/2023
OMA
Facilidades Comunes:
– Proporcionan funciones, al igual que los servicios
válidas para varios dominios pero más
complejas. Están orientadas a usuarios finales
(no al desarrollo de aplicaciones).
– Un ejemplo de este tipo de funciones es el DDCF
(Distributed Document Component Facility)
formato de documentación basado en OpenDoc.
– (También denominadas Facilidades
Horizontales)

30/01/2023
OMA
Interfaces de Dominio:
– Proporcionan funciones complejas, al igual que
las Facilidades, pero restringidas a campos de
aplicación muy concretos. Por ejemplo,
telecomunicaciones, aplicaciones médicas o
financieras, etc.
– Muchos grupos de interés (SIGs) trabajan sobre
estas especificaciones.
– (También denominadas Facilidades Verticales)

30/01/2023
OMA
Aplicaciones:
– El resto de funciones requeridas por una
aplicación en concreto. Es el único grupo de
objetos que OMG no define, pues esta
compuesto por los objetos propios de cada caso
concreto.
– Estos son los objetos que un sistema concreto
tiene que desarrollar. El resto (servicios,
facilidades) pueden venir dentro del entorno de
desarrollo.

30/01/2023
OMA
ORB:
– (Object Request Broker)
– Es el elemento central de la arquitectura.
Proporciona las funcionalidades de interconexión
entre los objetos distribuidos (servicios,
facilidades y objetos de aplicación) que forman
una aplicación.
– Representa un bus de comunicación entre
objetos.

30/01/2023
Servidor
void ingresar(long){
....
.... }
Cliente
x->ingresar(30)
ORB
ORB
Para posibilitar la comunicación entre dos objetos
cualesquiera de una aplicación se realiza por
medio del ORB. El escenario de aplicación
elemental es:

30/01/2023
IDL de CORBA
(Interface Definition Language)
Es el lenguaje mediante el cual se describen
los métodos que un determinado objeto del
entorno proporciona al resto de elementos del
mismo.
interface Cuenta
{
void ingresar(in long cantidad);
void retirar(in long cantidad);
long balance();
};

30/01/2023
IDL de CORBA
Language Mappings:
– Traducen la definición IDL a un lenguaje de
programación como:
• C++,
• Ada,
• COBOL,
• SmallTalk,
• Java,
• ...
– Este proceso genera dos fragmentos de código
denominados Stub y Skeleton que representan el
código de cliente y servidor respectivamente.

30/01/2023
IDL de CORBA
El código cliente
generado en base a la
definición IDL (stub)
contiene las llamadas
para realizar el proceso
de marshalling.
Marshalling: Traducción
de los argumentos a un
formato intermedio y pedir
al ORB su ejecución.
Interface Cuenta
{
void ingresar(in long cantidad);
}
Cuenta.idl
Compilador IDL
Cuenta_Skel.c++
class Cuenta_Stub : ...
{
void ingresar(CORBA::Long &cantidad)
{ <MARSHALLING> }
}
Cuenta_Stub.c++

30/01/2023
IDL de CORBA
El código servidor
generado en base a la
definición IDL (skeleton)
contiene las llamadas
para realizar el proceso
inverso (de-marshalling).
De-marshalling:
Recuperar del ORB los
parametros con los que
se invocó el método,
construir la llamada y
realizar la petición.
Compilador IDL
Cuenta_Stub.c++
class Cuenta_Skel : ...
{
virtual
void ingresar(CORBA::Long &cantidad)=0;
void __ingresar()
{
<DE-MARSHALLING>
ingresar(c);
}
}
Cuenta_Skel.c++

30/01/2023
IDL de CORBA
Implementación del Objeto:
– La implementación del objeto es invocada por los
métodos definidos en el Skeleton. Por lo general
se trata de una clase derivada del mismo.
class Cuenta_Impl: public Cuenta_Skel
{
void ingresar(CORBA::Long &cantidad)
{
dinero += cantidad;
}
};

30/01/2023
ORB ORB
DII Stub ORB
Interface
ORB
Interface
Skel. DSI
Object Adapter (OA)
Cliente Objeto Servidor
Componentes de un ORB
La arquitectura completa de comunicaciones
de CORBA es la siguiente:

30/01/2023
Stub:
– Código cliente asociado al objeto remoto con el que
se desea interactuar. Simula para el cliente los
métodos del objeto remoto, asociando a cada uno de
los métodos una serie de funciones que realizan la
comunicación con el objeto servidor.
Skeleton:
– Código servidor asociado al objeto. Representa el
elemento análogo al stub del cliente. Se encarga de
simular la petición remota del cliente como una
petición local a la implementación real del objeto.

30/01/2023
DII:
– (Dynamic Invocation Interface)
– Alternativa al uso de stubs estáticos que permite que
un cliente solicite peticiones a servidores cuyos
interfaces se desconocían en fase de compilación.
DSI:
– (Dynamic Skeleton Interface)
– Alternativa dinámica al uso de skeletons estáticos
definidos en tiempo de compilación del objeto. Es
usado por servidores que durante su ejecución
pueden arrancar diferentes objetos que pueden ser
desconocidos cuando se compiló el servidor.

30/01/2023
ORB/Interface ORB:
– Elemento encargado de (entre otras) las tareas asociadas a la
interconexión entre la computadora cliente y servidor, de forma
independiente de las arquitecturas hardware y SSOO.
– Debido a que tanto clientes como servidores pueden requerir de
ciertas funcionalidades del ORB, ambos son capaces de
acceder a las mismas por medio de un interfaz.
Las dos principales responsabilidades del ORB son:
– Localización de objetos: El cliente desconoce la computadora
donde se encuentra el objeto remoto.
– Comunicación entre cliente y servidor: De forma independiente
de protocolos de comunicación o características de
implementación (lenguaje, sistema operativo, ...)

30/01/2023
Adaptado de Objetos:
– En este elemento se registran todos los objetos que
sirven en un determinado nodo. Es el encargado de
mantener todas las referencias de los objetos que
sirven en una determinada computadora de forma
que cuando llega una petición a un método es capaz
de redirigírla al código del skeleton adecuado.
Existen dos tipos de Adaptadores de Objetos
especificados por OMG:
– BOA: (Basic Object Adapter).
– POA: (Portable Object Adapter).

30/01/2023
Las principales tareas del Adaptador de Objetos son:
– Multiplexar a dos niveles (obnjeto y método) las llamadas.
– Mantiene información (almacenada en el Repositorio de
Implementaciones) sobre los objetos servidos, siendo el
encargado de activarlos si al llegar una petición no se
encontraban en ejecución.
– Permite diferente modos de activación de los objetos:
• Persistente: El estado del objeto se almacena entre varias
ejecuciones.
• Compartido: Todos los clientes comparten la instancia de objeto.
• No-compartido: Cada cliente accede a una instancia diferente del
objeto.
• Por-método: Cada método solicitado es servido por una instancia de
objeto diferente.
– Genera las referencias de los objetos dentro del entorno. Esta
referencia es única para todos los objetos.

30/01/2023
ORB ORB
DII Stub ORB
Interface
ORB
Interface
Skel. DSI
Object Adapter (OA)
Comunicación vía CORBA
Pasos de una comunicación:
1- El cliente invoca el método asociado en el stub que realiza el
proceso de marshalling. (Stub cliente)
2- El stub solicita del ORB la transmisión de la petición hacia el objeto
servidor. (ORB cliente)
3- El ORB del servidor toma la petición y la transmite el Adaptador de
Objetos asociado, por lo general sólo hay uno. (ORB servidor)
1
2 3
4
5
6
7

30/01/2023
Comunicación vía CORBA
4- El Adaptador de Objetos resuelve cuál es el objeto invocado, y dentro
de dicho objeto cuál es el método solicitado (Adaptador de Objetos)
5- El skeleton del servidor realiza el proceso de de-marshalling de los
argumentos e invoca a la implementación del objeto. (Skeleton
servidor)
6- La implementación del objeto se ejecuta y los resultados y/o
parámetros de salida se retornan al skeleton. (Implementación del
objeto)
7- El proceso de retorno de los resultados es análogo.
ORB ORB
DII Stub ORB
Interface
ORB
Interface
Skel. DSI
Object Adapter (OA)
1
2 3
4
5
6
7

30/01/2023
Implementación de un ORB
El ORB representa a nivel lógico el bus de
objetos que comparten tanto clientes como
servidores. A nivel de práctico puede estar
implementado como:
– Residente cliente/servidor: Código que tanto
clientes como objetos tiene que enlazar.
– Demonio del sistema: Un servicio del sistema
encargado de centralizar las peticiones.
– Interno al sistema: Integrado dentro del SO.
– Librería: Usado cuando tanto clientes como
servidores residen dentro del mismo espacio de
memoria.

30/01/2023
Localización de Objetos
• Los objetos de servicio de una aplicación
CORBA se encuentran identificados por
medio de una referencia única (Identificador
de Objeto).
• Esta referencia es generada al activar un
objeto en el Adaptador de Objetos.
• Por medio de esta referencia el ORB es
capaz de localizar la computadora y el
Adaptador de Objetos donde se encuentra, y
éste último es capaz de identificar el objeto
concreto dentro del Adaptador.

30/01/2023
Localización de Objetos
El ORB proporciona mecanismos para
transformar a cadena de caracteres y de
cadena de caracteres a dicha referencia :
object_to_string,
string_to_object
Ejemplo:
IOR:010000000f00000049444c3a4375656e74613a312e300000020
00000000000003000000001010000160000007175696e6f2e646174
73692e66692e75706d2e65730041040c000000424f418a640965000
009f403010000002400000001000000010000000100000014000000
0100000001000100000000000901010000000000

30/01/2023
Implementación del Servidor
La implementación del objeto
se diseña como una subclase
de la clase generada por el
compilador (el skeleton) de
IDL en base a la definición.
Si el lenguaje usado para la
implementación no soporta
objetos el mecanismo es
diferente.
Cuenta.idl
idl
Cuenta_skel
<DEMARSHALLING>
Cuenta_impl
<implementación>
Clase generada
automáticamente
Implementación
del objeto

30/01/2023
Tareas Típicas de un Servidor
El servidor debe realizar las siguientes tareas:
– Inicializar el ORB (obtiene el interfaz con el
ORB).
CORBA::ORB_init
– Obtener la referencia del Adaptador de objetos.
orb->BOA_init
– Crear un un objeto (de la clase Cuenta_impl).
new Cuenta_impl()
– Activar el objeto.
boa->impl_is_ready(...)
– Iniciar el bucle de servicio.
orb->run()

30/01/2023
Tareas Típicas de un Cliente
El cliente debe realizar las siguientes tareas:
– Inicializar el ORB (obtiene el interfaz con el ORB).
CORBA::ORB_init
– Obtener la referencia del Adaptador de objetos.
orb->BOA_init
– Obtener la referencia al objeto (desde un string).
orb->string_to_object(...)
– Cambiar la clase del objeto obtenido (down-casting).
Cuenta::_narrow(obj)
– Realizar las llamadas al objeto.
cc->...

30/01/2023
Otros Modos de Activación
Como alternativa al proceso de arrancar
cada uno de los objetos de servicio, existe
la posibilidad de indicar al Adaptador de
Objetos otros modos de activación:
– Esto permite no arrancar la instancia hasta
que un cliente la solicite o sea activada
explícitamente.
– Esta alternativa requiere un ORB del tipo
demonio o interno al sistema.

30/01/2023
Otros Modos de Activación
1- En primer lugar es necesario
arrancar el demonio.
Para la implementación MICO es:
micod -ORBIIOPAddr <direc.>
2- Se registra en el repositorio de
implementaciones un nuevo
objeto, indicando el mandato
para ejecutarlo.
imr create <nombre> <modo>
<programa>
-ORBImplRepoAddr <direc.>
3- En cualquier otro momento se
activa el objeto
imr activate <nombre>
-ORBImplRepoAddr <direc.>
ORB
Adaptador de Objetos
Repositorio de
Implementaciones
Nombre Estado Referencia
CuentaCorriente active IOR:0f.....
Cuenta

AD Unidad3: Tecnologías de aplicaciones distribuidas

AD Unidad3: Tecnologías de aplicaciones distribuidas

Empfohlen

Empfohlen

Weitere ähnliche Inhalte

Was ist angesagt?

Was ist angesagt? (20)

Ähnlich wie AD Unidad3: Tecnologías de aplicaciones distribuidas

Ähnlich wie AD Unidad3: Tecnologías de aplicaciones distribuidas (20)

Mehr von Franklin Parrales Bravo

Mehr von Franklin Parrales Bravo (20)

AD Unidad3: Tecnologías de aplicaciones distribuidas