Parte-1

r
in
a
lim
Apuntes de Sistemas Operativos Distribuidos
Pr
e
Autor: Fabio E. Rivalta / Carlos Neetzel
Material: dictado de clases
Tema: Comunicación entre procesos (Parte 1)
Fecha: 05/2007
Ve
r
si
ón
Bibliografía utilizada:
• Apuntes de sistemas operativos distribuidos - Carlos Neetzel
• Sistemas operativos distribuidos – Andrew S. Tanenbaum
• Sistemas Distribuidos – George Coulouris y otros
• Apuntes de Internet (ver referencias para mayor detalle
Índice de contenidos
Ve
r
si
ón
in
a
Pr
e
Parte 2:
Llamada a procedimientos remotos (RPC)
Sun/RPC
CORBA
RMI
lim
Redes de comunicación de datos
El concepto de Sistema Abierto
UNIX y TCP/IP
Middleware
Tecnologías y Modelos
Comunicación en Sistemas Distribuidos
r
Parte 1:
Redes de comunicación de datos:
Objetivos:
Tipos de conexiones en red
Pr
e
lim
in
a
r
• Su objetivo principal es lograr que todos sus programas datos y equipo estén
disponible para cualquier punto de la red que lo solicite, sin importar la
localización física del recurso y del usuario.
• Otro de sus objetivos consiste en proporcionar una alta confiabilidad.
• Otro objetivo es el económico, debido a que los computadores pequeños tiene
una mejor relación costo / rendimiento, en comparación con la que ofrece las
máquinas grandes.
• También es un poderoso medio de comunicación entre personas que se
encuentran en lugares distantes entre sí.
Ve
r
si
ón
• Las instalaciones del sistema pueden conectarse físicamente de varias maneras
y cada configuración tiene sus ventajas y desventajas. Las configuraciones se
construyen según los siguientes criterios:
• Costo básico: ¿Cuánto cuesta enlazar las distintas instalaciones del sistema?
• Velocidad de comunicaciones: ¿Cuánto se tarda en enviar un mensaje de la
instalación A a la B?
• Confiabilidad: Si falla una instalación o enlace del sistema, ¿es posible que aún
sigan comunicándose las demás instalaciones?
• Las distintas conexiones se representan como grafos cuyos nodos corresponden
a las instalaciones. Una arista del nodo A al nodo B corresponde a una conexión
directa entre las dos instalaciones.
Conexiones:
Conexión total: Cada instalación esta enlazada
directamente con todas las demás instalaciones del
sistema. El costo básico de esta instalación es muy elevado.
Los mensajes entre instalaciones pueden enviarse con gran
rapidez. Además estos sistemas son muy confiables ya que
deben averiarse muchos enlaces para particionar el sistema
C
E
lim
A
in
a
r
B
D
Pr
e
Red de conexión total
B
C
si
E
D
A
C
E
F
Red jerarquica con estructura de arbol.
D
Re d d e co ne x io n p a rcia l
Conexión Jerárquica: En una red de jerarquía las
instalaciones se organizan como un árbol. Cada
instalación, excepto la raíz, tiene un solo padre y varios
hijos
Ve
r
A
ón
Conexión parcial: Hay un enlace directo entre algunos, pero no
todos, los pares de instalaciones. El costo básico de esta
configuración es menor al de una red de conexión total. Es mas
lenta la comunicación de mensajes y no es tan confiable como un
sistema de conexión total.
B
Topología de redes computacionales:
Se conoce como topología de una red a la forma de interconectar los nodos de la red.
r
Estrella
• Gran facilidad de instalación
• Posibilidad de desconectar elementos de red sin causar problemas.
• Facilidad para la detección de fallo y su reparación.
lim
Inconvenientes:
Bus
...
F
C
D
E
Red en estrella
n
ón
C
B
Ventajas:
• Es Más fácil conectar nuevos nodos a la red
• Requiere menos cable que una topología estrella.
a) Red en canal lineal
si
Desventajas:
Ve
r
A
D
Pr
e
• Requiere más cable que la topología de BUS.
• Un fallo en el concentrador provoca el aislamiento de todos los
nodos a él conectados.
• Se han de comprar hubs, switchs o concentradores.
B
A
in
a
Ventajas:
Canal multi-acceso o bus
• Toda la red se caería se hubiera una ruptura en el
cable principal.
• Se requiere terminadores.
• Es difícil detectar el origen de un problema cuando toda
la red cae.
• No se debe utilizar como única solución en un gran
edificio.
Topología de redes computacionales: (Cont)
Anillo
A
Desventajas:
in
a
• Es Más fácil conectar nuevos nodos a la red
• Requiere menos cable que una topología estrella.
r
Ventajas:
Ve
r
si
ón
Pr
e
lim
• Toda la red se caería se hubiera una ruptura en el
cable principal.
• Es difícil detectar el origen de un problema cuando toda
la red cae.
• Generalmente se hace circular un Token que al pasar
por cada nodo de la red se le incorpora o saca los
paquetes que son para dicho nodo.
E
D
B
C
Red en anillo
Tipos de redes:
in
a
r
• WAN - Waide Area Network
• Host y Routers
• MAN - Metropolitan Area Network
• LAN - Locar Area Network
lim
• Ethernet con CSMA/CD (Carrier Sense Multiple Access / Collision Detection)
• LocalTalk Apple con SCMA/CA. (Carrier Sense Multiple Access / Collision Avoidance)
• Token Ring IBM (Token Passing)
• DAN - Desk Area Network
Pr
e
Clasificación de las Redes según su uso:
ón
Redes dedicadas o exclusivas: Son las que por motivo de seguridad, velocidad o
ausencia de otro tipo de red, conectan dos o más puntos de forma exclusiva. Este tipo
de red puede estructurarse en redes punto a punto o redes multipunto.
Ve
r
si
Redes punto a punto: Permiten la conexión en línea directa entre terminales y
computadoras. La ventaja es la alta velocidad de transmisión y la seguridad que
presenta al no existir conexión con otros usuarios. Su desventaja es el precio muy
elevado de este tipo de red.
Redes multipunto: Permite la unión de varios terminales a su correspondiente
computadora compartiendo una única línea de transmisión. La ventaja es el
abaratamiento de su costo, aunque pierde velocidad y seguridad. Este tipo de redes
requiere amplificadores y difusores de señal o de multiplexores que permiten compartir
líneas dedicadas.
Clasificación de las redes según su uso:
lim
in
a
r
Redes compartidas: Son las que se une un gran número de usuarios, compartiendo
todas las necesidades de transmisión e incluso con transmisiones de otras naturalezas.
Las redes más usuales son las de conmutación de paquetes y las de conmutación de
circuitos.
Pr
e
Redes de conmutación de paquetes: Son las que existen nodos de concentración con
procesadores que regulan el tráfico de paquetes.
Paquete: es una pequeña parte de la información que cada usuario desea
transmitir. Cada paquete se compone de la información, el identificador del destino
y algunos caracteres de control.
ón
Redes de conmutación de circuitos: Son redes en las que los centros de
conmutación establecen un circuito dedicado entre dos estaciones que se comunican.
Ve
r
si
Redes digitales de servicios integrados (RDSI): Se basan en desarrollos
tecnológicos de conmutación y transmisión digital. La RDSI es una red totalmente digital
de uso general capaz de integrar una gran gama de servicios como son la voz, datos,
imagen y texto. La RDSI requiere de la instalación de centrales digitales.
Arquitectura de comunicaciones:
in
a
r
La arquitectura de comunicaciones se ocupa de las operaciones necesarias para
que la comunicación sea exitosa o informa si no se pudo lograr.
lim
Además de la vinculación para establecer una comunicación entre computadoras se
necesita dos cosas mas:
Protocolos:
Arquitectura de protocolos:
Pr
e
Es el conjunto (Set) de reglas que gobiernan el intercambio de datos entre dos
entidades.
Un protocolo implica 3 temas: la Sintaxis, la Semántica y el Timing o velocidad de las
comunicaciones.
ón
Es la estructura que conforma a un juego de protocolos que implementan las funciones
de comunicación.
Ve
r
si
Las comunicaciones implican a tres agentes:
• Procesos: son las entidades que se comunican.
• Hosts: son los sistemas computacionales donde se encuentran los Procesos:
• Redes o Networks: interconectan a los Hosts y transmiten los datos entre ellos.
Niveles de las comunicaciones:
lim
Capa especifica para manejo de Red.
Intercambio de datos entre Host y Red .
Host le provee destino (igual Host que destino).
Host (fuente) puede pedir ciertos servicios.
Protocolo de este nivel DEPENDE del tipo de Red:
Conmutación de circuito o Conmutación paquetes LAN, Etc...
Pr
e
•
•
•
•
•
•
in
a
r
La transmisión de datos se realiza de un Proceso a otro Proceso. Las comunicaciones
en los siguientes tres niveles independientes:
• Nivel de acceso a Red: Aplicación y Red tienen que ser Independientes.
• Nivel de Transporte: Se asegura del transporte de los procesos
INDEPENDIENTEMENTE de la naturaleza de los procesos.
si
ón
• Seguridad del intercambio de
datos:
• Todos los datos llegan a destino
(Proceso destino).
• Todos los datos llegan en el
mismo orden en que fueron
enviados.
Ve
r
• Nivel de Proceso: Protocolos
necesarios por la VARIEDAD de
Aplicaciones.
• Por cada tipo de Aplicación se
necesita un protocolo propio a esa
Aplicación.
Dirección del Punto de acceso de Servicio (SAP)
PROCESOS
1
2
3
PROCESOS
Dirección de la RED
Capa de Transporte
1
2
Capa de Transporte
Acceso a Red
RED DE
COMUNICACIONES
HOST A
Acceso a Red
HOST C
PROCESOS
1
2
3
4
Capa de Transporte
Acceso a Red
HOST B
Armado del paquete de transmisión de datos:
TRANSPORT
HEADER
in
a
TRANSPORT
HEADER
DATOS del PROCESO
TRANSPORT
HEADER
DATOS del PROCESO
lim
NETWORK
ACCESS
HEADER
DATOS del PROCESO
NETWORK
ACCESS
HEADER
Pr
e
TRANSPORT
HEADER
r
DATOS del PROCESO
DATOS del PROCESO
Ve
r
si
ón
Se presentan cuatro aspectos importantes de la comunicación en cuanto al trabajo
interno:
Nombre: ¿Cómo hacen los procesos PARA UBICARSE.?
Estrategia de Ruteo: ¿Cómo hacen los mensajes PARA PASAR POR LA RED?
Estrategia de Comunicación: ¿Cómo hacen dos Procesos PARA MANDARSE
UNA SECUENCIA DE MENSAJES? .
Contención: La Red es un recurso compartido, ¿CÓMO RESOLVER EL
CONFLICTO DE SU DEMANDA?.
Estas cuatro preguntas, en la arquitectura de comunicaciones, llevan a plantearse un
nuevo conjunto de interrogantes en los aspectos del diseño que deben ser resuelto
mediante diferentes estrategias.
Estrategias:
r
Al diseñar un red de comunicaciones es necesario tener en cuenta cuatro aspectos:
•
lim
Pr
e
•
Ruteo fijo: Se especifica por adelantado una ruta de A a B y no cambia a menos que
una falla en el hardware invalide esta ruta. Se mantiene hasta el final de la
comunicación. Su aspecto negativo es que no puede adaptarse a los cambios de la
carga, del trafico de la ruta pero los mensajes se entregaran en el orden en que
fueron enviados.
Circuito virtual: Se determina un camino entre dos nodos (de A a B) que va a durar
una sesión puede cambiar entre sesión y sesión.
Ruteo Dinámico: Se elige el camino solo cuando un mensaje es enviado. Cada
nodo intermedio decide donde mandarlo. La ruta para enviar un mensaje de la
instalación A a la Instalación B se elige en el momento de enviar el mensaje.
Generalmente se elige la ruta menos congestionada en ese momento.
ón
•
in
a
• Estrategias de ruteo: ¿Como se enviarán los mensajes por la red?
Ve
r
si
• Estrategias de conexión: ¿Como envían dos procesos una serie de mensajes?
• Conflictos: Dado que la red es un recurso compartido, ¿Como solucionamos las
demandas de uso conflictivas?
• Estrategias de diseño: ¿Cual es el diseño global para la comunicación entre
aplicaciones?
Estrategias: (Cont)
• Estrategias de conexión: ¿Como envían dos procesos una serie de mensajes?
•
Se establece un enlace físico permanente.
Este enlace se asigna para todo el tiempo que dura la comunicación
Ningún otro proceso puede utilizarlo durante ese periodo.
Las desventajas es que requiere tiempo de preparación,
Pero provoca menos tiempo de procesamiento adicional para enviar cada mensaje.
in
a
•
•
•
•
•
r
Conmutación de circuitos:
Conmutación de mensajes:
lim
•
Pr
e
• Se establece un enlace temporal durante el tiempo que dura la transferencia de un mensaje.
• Los enlaces físicos se asignan dinámicamente según se requiera y durante un periodo breve.
• Cada mensaje es un bloque de datos, junto con cierta información (fuente, destino, y códigos
de corrección de errores) que permite a la red de comunicaciones entregar correctamente el
mensaje a su destino.
• Tiene como aspecto negativo que requiere menos tiempo para la preparación del mensaje
pero necesita mas tiempo de procesamiento adicional por cada mensaje.
Los mensajes generalmente tienen longitud variable.
Generalmente Comunicación con mensajes de longitud fija llamados paquetes.
Es posible que un mensaje lógico tenga que dividirse en varios paquetes,
Cada uno de los cuales se envía por separado a su destino y puede seguir rutas diferentes
por la red.
• Para formar el mensaje hay que reensamblar los paquetes conforme llegan.
• Los mensajes entran en memoria no necesitan bajar a disco.
• Al igual que la conmutación de mensajes requiere menos tiempo de preparación y pierde
mas tiempo de procesamiento adicional con el agregado de que debe dividir los mensajes en
paquetes y luego reagruparlos.
si
•
•
•
•
ón
Conmutación de paquetes:
Ve
r
•
Estrategias: (Cont)
r
• Conflictos: Dado que la red es un recurso compartido, ¿Como solucionamos las
demandas de uso conflictivas?
Un enlace puede conectar varios nodos.
Es posible que estos quieran transmitir simultáneamente información por un enlace.
En este caso se mezcla la información transmitida y hay que descartar la que no
corresponde a ese nodo.
• Es necesario notificar el problema a los nodos para que estos puedan retransmitir la
información.
Se han desarrollado técnicas para evitar las colisiones repetidas en un enlace:
• CSMA/CD (Carrier Sence Multipple Access/ Collision Detection)
Pr
e
lim
in
a
•
•
•
Ve
r
si
ón
• Escuchar antes de transmitir un mensaje por un enlace, para determinar si en ese
momento se esta transmitiendo otro mensaje en ese mismo instante por el enlace.
• Esta técnica se denomina detección de portadora con acceso múltiple.
• Si el enlace esta libre, la instalación puede comenzar a transmitir de lo contrario debe
esperar y seguir escuchando hasta que el enlace quede libre.
• Si dos o mas nodos comienzan a transmitir en el mismo instante entonces ambos
registraran una detección de colisión y dejaran de transmitir.
• Cada nodo intentará hacerlo de nuevo, después de un cierto periodo aleatorio de
tiempo.
• El problema principal con esta estrategia es que cuando el sistema esta muy ocupado
pueden ocurrir muchas colisiones y degradarse el rendimiento.
Estrategias: (Cont)
•
Paso de testigo (Token Passing)
•
lim
in
a
r
• Un tipo de mensaje único, conocido como testigo, circula continuamente por el sistema.
• Un nodo que desea transmitir información espera a que llegue el testigo; lo saca de la
red y comienza a transmitir sus mensajes.
• Cuando termina vuelve a transmitir el testigo lo que permite que otro nodo reciba y
quite el testigo para comenzar la transmisión de sus mensajes.
• El sistema debe detectar si se ha perdido el testigo y en tal caso generar uno nuevo.
Ranura de mensaje (Message slots)
Ve
r
si
ón
Pr
e
• Por el sistema circulan constantemente varias ranuras de mensaje de longitud fija.
• Cada ranura puede contener un mensaje de longitud fija e información de control
(origen, destino y si la ranura esta vacía o llena).
• Un nodo que esta listo para transmitir debe esperar que llegue una ranura vacía, en la
cual insertará su mensaje ajustando la información de control adecuada.
• La ranura con su mensaje prosigue entonces por la red y al llegar a un nodo, este
examina la información de control para ver si le corresponde o no el mensaje en la
ranura.
• Si no es para ese nodo, la ranura con el mensaje vuelve a circular; de lo contrario, el
nodo toma el mensaje, restablece la información de control indicando que la ranura
esta vacía, y luego puede enviar un mensaje propio o liberar la ranura.
• Como una ranura solo puede contener mensajes de longitud fija, en ocasiones hay que
dividir el mensaje lógico en paquetes mas chicos, cada uno de los cuales se envía en
una ranura diferente.
• Estrategias de diseño: ¿Cual es el diseño global para la comunicación entre
aplicaciones?
Estrategias: (Cont)
Ve
r
si
ón
Pr
e
lim
in
a
r
• Estrategias de diseño: ¿Cual es el diseño global para la comunicación entre
aplicaciones?
• Al diseñar una red de comunicaciones debemos tratar con la complejidad
inherente de la coordinación de operaciones sincrónicas que se comunican
en un entorno potencialmente lento y propenso a errores.
• La tarea del diseño es definir una serie de niveles y servicios
desempeñados por cada uno.
• La división debe agrupar lógicamente a las funciones y debe disponer
suficientes niveles para hacer que el manejo de cada uno no sea muy
complicado.
• Básicamente hay dos modelos:
• Modelo OSI
• Modelo TCP/IP
El concepto de Sistema Abierto
in
a
r
La interconexión de sistemas abiertos se basa en el concepto de aplicaciones
distribuidas cooperativas.
Una aplicación distribuida es cualquier actividad en la que interviene el intercambio de
información entre dos sistemas abiertos.
Pr
e
lim
El objetivo del esfuerzo de OSI es definir un conjunto de estándares que habilitará a los
sistemas abiertos ubicados en cualquier lugar del mundo para cooperar,
interconectándolos mediante servicios de comunicaciones estándares y ejecutando
protocolos OSI estándares.
Ve
r
si
ón
Un sistema abierto puede implementarse de cualquier forma que esté de acuerdo con
un conjunto mínimo de estándares que permitan conseguir la comunicación con otros
sistemas abiertos
El modelo OSI (Open System Interconnection)
Computadora 1
Computadora 2
Proce
so
B
Aplicación
6
Presentación
Protocolo de
Presentación
Presentación
5
Sesión
Protocolo de
Sesión
Sesión
4
Transporte
3
Red
in
a
Pr
e
lim
Protocolo de
Aplicación
Protocolo de
Transporte
Transporte
Protocolo de
Red
Red
Enlace
Protocolo de Enlace de
Datos
Enlace
Física
Protocolo
Físico
Física
Ve
r
si
ón
2
1
r
7
Proce
so
A
Aplicación
Ambiente de RED
Ambiente OSI
Sistema Ambiente Real
Red física de
DATOS
El Modelo TCP/IP(Transmission Control Protocol / Internet Protocol)
lim
in
a
Capa de proceso o de aplicación (FTP, SMTP, TELNET, etc...).
Capa Host to host o capa de transporte (TCP).
Capa Internet (IP).
Capa de Acceso a Red y
Capa física
Pr
e
•
•
•
•
•
r
Modelo construido en base a tres conceptos mas el Acceso a Red:
si
ón
El TCP secuencia numeralmente los segmentos que
serán mandados a un puerto de destino particular de tal
manera que si los segmentos llegan desordenados,
entonces la entidad TCP del destinatario los reordena.
Ve
r
Un datagrama es el conjunto de las
cabeceras de control de la información de
cada segmento.
EF
IP
FTP
SMTP
TELNET
TCP
IP
NET
ACCESS
Datos del Usuario
TCP
Segmento
Datagramas
Paquetes
El Modelo TCP/IP (Transmission Control Protocol / Internet Protocol): (Cont)
Ve
r
si
ón
Pr
e
lim
in
a
r
El protocolo de datagrama del usuario (UDP- User Datagram Protocol) provee el
servicio de conexión para los procedimientos a nivel de las aplicaciones:
• No existe ninguna garantía de mensajería ni una preservación de la secuencia ni
ninguna protección contra la duplicación.
• El UDP permite a un procedimiento mandar mensajes a otro procedimiento con
un mínimo de mecanismos de protocolos.
• Esencialmente adhiere una capacidad de dirección de un puerto al IP.
• El campo de protocolo indica cuándo el TCP, UDP u otro tipo de protocolo de
capa “alta” es usado por el IP.
Características y problemas del IPv4:
IHL
Identificación
Protocol
Ve
r
si
Tiempo de Vida
Tipo de
Servicio
ón
Versión
Pr
e
lim
in
a
r
• Ofrece soportes para aplicaciones simples. Por ejemplo:
• Correo electrónico,
• File Transfer
• Acceso remoto (mediante Telnet o SSH).
• Provee servicios pobres para una gran cantidad de aplicaciones multimediales.
• Las redes empresariales crecen en complejidad (Client-Server).
• Las Aplicaciones hoy día requieren soporte de:
• Tráfico en Tiempo Real
• Mecanismos de Control de Gestión flexibles.
• Funciones de seguridad mejoradas.
Flags
Longitud Total
Desplazamiento de Fragmento
Checksum del Encabezado
Dirección de Origen
Dirección de Destino
Opciones + Padding
Características y problemas del IPv6:
4
Versión
8
Prioridad
16
lim
0
in
a
r
• El encabezado contiene 40 By. El encabezado de TCP 20 By. El de
fragmentación 8 bytes. El resto de los encabezados son de longitud Variable.
• El IPv6 resuelve los problemas del IPv4 e incorpora las siguientes mejoras:
• Espacio de direcciones expandido de 128 bits.
Etiqueta de Flujo
encabezado
siguiente
Pr
e
Longitud de Carga
Dirección
de
Origen
Dirección
de
Destino
ón
si
Ve
r
24
límite de salto
31
UNIX y TCP/IP:
in
a
r
• El Kernel de UNIX tiene incorporado:
• TCP/IP
• Variedad de Interfases para Acceso a Red llamados puertos.
• Mecanismos de programación estándar (Sockets)
ón
Pr
e
lim
Al hacer un pedido (request) con FTP:
1. Se crea un Proceso.
2. Este Proceso abre una Conexión TCP con el
Destino.
3. Se crea un segundo proceso que asiste con el
manejo de la Transferencia. El primer Proceso trata
con la transferencia de datos.
4. Mientras que el Segundo Proceso trata con las
respuestas para el Control de la Conexión. Al
Terminar, el server cierra la conexión y avisa al
usuario
6.
7.
Se crea un Proceso que toma el control de la conexión.
Proceso que se va a dedicar al último request llegado.
(aplicación se desvincula de la situación y sigue esperando
nuevos request).
Proceso crea segundo Proceso para establecer y manejar la
conexión de datos.
Este proceso se ocupa de la conexión de datos y su
transferencia.
Ve
r
5.
si
Transmisión por medio de FTP en UNIX
RecepciónmedianteFTPenUNIX
MIDDLEWARE (en Client-Server Computing):
Pr
e
Del ruteo apropiado de datos.
De la incompatibilidad de las plataformas integrándolas.
De ejecuta en cada ambiente.
De garantizar la transparencia de accesos a los recursos
De utilizar técnicas de Message passing o Remote Procedure Call (RPC) para sus
comunicaciones.
APLICACIONES
SIST. OPERAT.1
HARDWARE 1
INTERFASE
MIDDLEWARE
SOPORTE DE
APLICACIONES
si
HERRAMIENTAS
APLICACIONES
Ve
r
SOPORTE DE
APLICACIONES
ón
•
•
•
•
•
lim
in
a
r
Es una Categoría de software que reside entre una aplicación y la Red cuya principal
función es el envío de mensajes, o la organización de sesiones, entre los Nodos de la
red para luego ejecutar (entre bastidores) con el fin de proveer datos y conectar las
partes.
Surge como solución a aspectos no cubiertos por los estándares Físico-Lógicos en
cuanto al procesamiento distribuido.
Se ocupa:
Servicios de la
Presentación
Lógica de la
APLICACIÓN
HERRAMIENTAS
MIDDLEWARE
SIST. OPERAT.2
SW de Comunic.
Interacción del M iddleware
Interacción de Protocolos
MIDDLEWARE
SW de
Comunic.
Servicios de
Aplicaciones
SIST . OPERAT . (Servidor)
HARDWARE 2
INTERFASE
SIST. OPERAT. (Cliente)
HARDWARE 2
HARDWARE 1
Server
Controlador de RED
RED de COMUNICACIONES (Homogenea o Heterogenea)
Workstation Client
Aspectos lógicos del Middleware:
Pr
e
• Ethernet.
• Token Ring.
• Fiber Distribuited Data Interface (FDDI).
lim
in
a
r
• Se deben definir los protocolos que el middleware debe soportar para lograr
conectividad que permita a programas o procesos comunicarse en forma
transparente.
• Los protocolos se dividen en tres grupos: de medios, de transporte y protocolos
cliente/servidor.
• Los protocolos de medios determinan el tipo de conexión física usada en la red ej:
• IPX/SPX de Novell.
• AppleTalk de Apple.
• TCP/IP.
ón
• Los protocolo de transporte proveen los mecanismos para mover paquetes de datos
desde el cliente al servidor o viceversa ej:
NetBIOS,
RPC,
Advanced Program-to-Program Communication (APPC),
Named Pipes,
Transport Level Interface (TLI)
Sequenced Packet Exchange (SPX).
Ve
r
•
•
•
•
•
•
si
• Un protocolo cliente/servidor define la manera en que los clientes requieren la
información al servidor y como el servidor le responde a esos requerimientos. Ej:
Servicios de Middleware
in
a
r
Se define tres niveles de funciones para el middleware, básicas, intermedias,
avanzadas.
• Servicios Básicos
lim
• Son un mínimo nivel de funciones que se deben esperar de una arquitectura
middleware.
• Deben proveer transparencia, en otras palabras que se invisible al usuario.
Pr
e
• Diferentes protocolos: A bajo nivel esto incluye tecnologías como IPX/SPX y
TCP/IP. El Middleware debe proveer soporte para una cantidad importante de
protocolos para cubrir los actuales y futuros estándares.
ón
• Diferencias en TCP/IP’s: (hay por lo menos 15 variantes de este “estándar”) El
middleware necesita ser capaz de operar sobre todas o la mayoría de estas
implementaciones.
Ve
r
si
• Traslación de Protocolos: Cuando parte de la red de una empresa opera con
un protocolo y otra parte lo hace con otros, los mensajes tendrán que pasar por
múltiples protocolos sin problema.
Servicios de Middleware: (Cont)
r
• Conectividad: Este es generalmente el punto clave del middleware en una
arquitectura cliente/servidor.
Pr
e
lim
in
a
• Hay un numero de propiedades estándar de APIs que pueden ser usadas para
establecer conectividad.
• Estas APIs pueden ser de propósito general o orientadas a SQL y de hecho,
estándares basado en objetos como OLE o DSOM y sus procesos de mensajes
también pueden ser usados para establecer conectividad.
• Un producto middleware debe soportar estándares comunes en este área como
ODBC, DBLib, OLI, DRDA, SQL/API y X/Open.
• Optimización de Consultas (Query): Para acceso a DBMS distribuido.
Ve
r
si
ón
• Cuando un JOIN requiere de datos que están ubicados en lugares distintos, el
middleware debe proveer inteligencia para navegación para completar el Query.
• En referencia a la navegación distribuida, la existencia de diferentes estructuras de
archivos y esquemas de índices en varios sitios se requiere un enfoque inteligente
para evitar costos en la ejecución del Query.
• La lógica del middleware debe trabajar en forma relacional, no relacional, estructura
de archivos plano u orientado a objeto.
• Llamadas Procedimiento Remoto (RPC):
• Diferentes motores de DBMS soportan diferentes formas de procedimientos remotos.
• Hay otras formas de procedimientos remotos tales como OSF, DCE que el
middleware debe soportar sin problemas.
Servicios de Middleware: (Cont)
Manejo de Hilos:
Proveer una capacidad de explotar comunicaciones cruce de proceso (crossprocess) y sistemas basados en transacciones seguras, tales como CICS o IMS/DS.
Estos permiten el manejo de múltiples procesos simultáneamente. Ya que en
diferentes entornos el manejo de estas funciones difiere, el middleware debe
enmascarar estas diferencias, haciendo mas fácil el diseño de aplicaciones que
puedan correr bien en los entornos cliente/servidor.
EL Balance de Carga:
Seteo de Prioridad:
•
El middleware debe brindar facilidades para permitir que algunas tares se ejecuten
como “privadas” o como compartidas.
ón
•
Servicios Intermedios:
•
Posiblemente algunos de los servicios que se presentan como de categoría
intermedia podrían pertenecer a servicios avanzados dado que no hay una línea
definida para ello.
si
•
Puede o no ser soportada por entornos operativos (como el caso de sistemas
paralelos), el middleware debe proveer habilidad para cumplir esta función.
Pr
e
•
Ve
r
•
lim
in
a
•
r
•
Servicios de Middleware: (Cont)
Servicios de Seguridad:
•
r
in
a
Comunicación entre procesos de un Job
•
Cuando un Job se divide en varios coprocesos paralelos y se ejecutan en distintos
sitios.
Para reducir los costos de comunicación es necesario que esos coprocesos se
comuniquen directamente unos con otros independiente de su locación.
ón
•
si
•
lim
•
El middleware debe manejar múltiples entornos de seguridad ofreciendo una
interfase heterogénea para los usuarios.
Cada entorno operativo puede tener distintos mecanismo de seguridad que difieren
entre si como controles de login o productos de seguridad separados como RACF o
Top Secret, también administradores de Base de Datos pueden tener restricciones
de seguridad.
El uso de “recursos confiables” permite el mapeo de IDs auténticos dentro del
sistema. Por ejemplo un ID valido puede mapear a alguien en un Sistema Digital,
eliminando que el usuario necesite distintas passwords para cada subsistema.
Pr
e
•
Ve
r
•
Tecnologías y Modelos:
in
a
r
Modelos
Cómo se diseña el servicio
lim
Modelo cliente/servidor
Modelos con intermediario:
Modelo proxy/caché
Modelo multinivel
Peer-to-peer
Ve
r
si
ón
Pr
e
Tecnologías
Cómo se realiza la programación.
• Paso de mensajes:
• Berkeley Sockets
• Java Sockets
• Llamadas a procedimientos remotos
• Sun RPC
• Objetos distribuidos:
• Java RMI
• CORBA
• Servicios web:
• SOAP (Simple Object Access
Protocol )
Otras tecnologías o variantes de ellas
Código Móvil
Comunicación en Sistemas Distribuidos:
lim
in
a
r
Permite la interacción entre aplicaciones y servicios del sistema.
Existen varios modelos de comunicación entre procesos:
• Memoria compartida (Sólo multiprocesador no distribuido).
• Paso de mensajes.
Pr
e
El nivel de abstracción en la comunicación:
• Paso de mensajes puro (Cliente-Servidor).
• Llamadas a procedimientos remotos.
• Modelos de objetos distribuidos.
Ve
r
si
ón
Los diferentes mecanismos de comunicación se caracterizan por los siguientes factores:
• Rendimiento: Latencia, ratio de transferencia, ancho de banda, ...
• Escalabilidad: Número de elementos activos.
• Fiabilidad: Pérdida de mensajes.
• Seguridad:Cifrado, certificación, ...
• Movilidad: Equipos móviles.
• Calidad de Servicio (QoS): Reserva y garantía de anchos de banda.
• Comunicación en grupo: Multicast.
Comunicación en Sistemas Distribuidos: (Cont)
Ve
r
si
ón
Pr
e
lim
in
a
r
Niveles de Comunicación:
Primitivas de Comunicación:
Pr
e
lim
in
a
r
Cada una de las funciones de comunicación de una tecnología determinada. Las
primitivas básicas son:
• Envío: send(destino,mensaje).
• Recepción: receive(fuente,mensaje).
Otras primitivas:
• Conexión: connect(destino).
• Desconexión: close().
Cada una de las primitivas tiene las siguientes características:
• Boqueantes vs No-bloqueantes.
• No bloqueantes:
• Bloqueantes:
Lo más natural, fácil de usar.
Necesitamos threads o múltiples procesos.
Send se bloquea hasta que se envía el mensaje.
Recv se bloquea hasta que se recibe el
mensaje.
Ve
r
si
ón
•
•
•
•
•
•
•
•
Más difíciles de usar, en ocasiones más
eficientes.
Send retorna inmediatamente copia el mensaje
para enviarlo, o guarda un puntero.
Recv retorna si no hay mensaje que recibir.
Interrupciones para notificar envío/recepción.
Primitivas de Comunicación: (Cont)
• Sincronización: Síncronas vs. Asíncronas.
in
a
r
Esta característica afecta no tanto a la primitiva como a la transmisión en sí.
Comunicación síncrona: Envío y recepción se realizan de forma simultanea.
Comunicación asíncrona: El envío no requiere que el receptor este esperando.
La comunicación asíncrona usa un buffer de almacenamiento.
Implica ciertas condiciones de bloque en envío y recepción.
• Fiabilidad: Fiables vs. No-fiables
lim
•
•
•
•
•
Ve
r
si
ón
Pr
e
• El envío fiable de datos garantiza que un mensaje enviado ha sido recibido por el
receptor.
• Implica la retransmisión de mensajes de validación (ACKs).
• La fiabilidad la puede garantizar:
• El protocolo de comunicación (TCP si y UDP no).
• Los elementos emisor y receptor.
Direccionamiento:
Ve
r
si
ón
Pr
e
lim
in
a
r
Información válida para la identificación de elementos del sistema. Posibles receptores
de un mensaje.
Mecanismos:
• Dirección dependiente de la localización:
• Por ejemplo: dirección máquina + dirección puerto local.
• No proporciona transparencia.
• Dirección independiente de la localización (dir. lógica):
• Facilita transparencia.
• Necesidad de proceso de localización:
• Mediante broadcast.
• Uso de un servidor de localización que mantiene relaciones entre
direcciones lógicas y físicas.
• Uso de caché en clientes para evitar localización.
Comunicación en Grupo:
Variantes de protocolos de red: IP-multicast.
Emulandola por medio de protocolos de alto nivel o por las aplicaciones.
in
a
•
•
r
Se habilita por medio de:
•
•
•
Grupo abierto.
Grupo abierto controlado.
Grupo cerrado.
Problemática:
Comunicación fiable es difícil.
Escalabilidad de las tecnologías (Internet con MBone).
Gestión de grupos.
Encaminamiento (Flooding, Spanning Tree, RPB, TRPB, RPM).
si
•
•
•
•
ón
Ofrecer tolerancia a fallos basado en servicios replicados.
Localizar objetos en sistemas distribuidos.
Mejor rendimiento mediante datos replicados.
Actualizaciones múltiples.
Operaciones colectivas en cálculo paralelo.
Ve
r
•
•
•
•
•
Pr
e
Utilidad para los sistemas distribuidos:
lim
El direccionamiento se realiza por medio de una dirección de grupo (grupo al que
pertenecen todos los receptores).
Modelos de grupos:
Orden en la Comunicación en Grupo:
•
•
•
FIFO: Los mensajes de una fuente llegan a cada receptor en el orden que son enviados.
Causal: Los mensajes enviados por dos emisores distintos son recibidos en el orden relativo en el que
se han enviado.
Total: Todos los mensajes (de varias fuentes) enviados a un grupo son recibidos en el mismo orden por
todos los elementos.
Modelos con / sin estado:
Ve
r
si
ón
Pr
e
lim
in
a
r
Servicio Con estado vs. Sin estado:
Determina si el servidor mantiene información de los clientes o no.
• Ventajas de servicio con estado:
• Mensajes de petición más cortos.
• Mejor rendimiento (se mantiene información en memoria).
• Favorece estrategias de optimización:
• Estrategias predictivas: análisis del patrón de operaciones del cliente.
• Ventajas de servicio sin estado:
• Más tolerantes a fallos (rearranque del servidor).
• Peticiones autocontenidas.
• Reduce el número de mensajes: no hay comienzos/finales de sesión.
• Más económicos para el servidor (no consume recursos de memoria)
• Servicios inherentes con estado (cerrojos distribuidos).
• Estado sobre servicios sin estado (HTTP+cookies).
Cliente –Servidor: Paso de mensajes:
Pr
e
lim
in
a
r
Los modelos de comunicación
basados en cliente-servidor con
paso de mensajes responden al
esqueleto:
Los mensajes intercambiados pueden ser:
si
Tamaño de los datos numéricos.
Ordenación de bytes.
Formatos de texto: (ASCII vs EBCDIC)
Ve
r
•
•
•
ón
• Mensajes de texto (por ejemplo: HTTP).
• Mensajes con formato (binarios). Una característica de éste método es que tanto emisor y
receptor deben coincidir en la interpretación de los bytes transmitidos. Se presentan
problemas con:
Network Byte Order vs. Host Byte Order:
Ve
r
si
ón
Pr
e
lim
in
a
r
Existen dos formas para ordenar los bytes:
• El más significativo primero: Network Byte Order o "Big-Endian Byte Order“
• El menos significativo primero: Host Byte Order o “Little -Endian Byte Order"
Siempre debe convertirse los datos a Network Byte Order antes de
enviarlos por la red
Mecanismos para envío de mensajes:
in
a
r
Cuando se mueven los procesos debe asegurarse que lleguen a su nueva locación:
• Mensajes en ruta (emitidos por terceros y no recibidos el nodo origen del
proceso migrado)
• Mensajes pendientes. Pueden ser de 3 tipos
Pr
e
lim
• Tipo 1: recibidos en el nodo origen luego que se ha congelado el proceso y no se ha
reiniciado en el sitio destino
• Tipo 2: recibidos en el nodo origen cuando el proceso se inició en el sitio destino
• Tipo 3: enviados al proceso desde otros nodos luego que éste reinició en el sitio
destino
• Mensajes futuros
Los mecanismos más usados son:
• Reenvío de mensajes (V-System, Amoeba)
•
Tipos 1 y 2 son retornados o dejados caer para que retransmitan.
•
•
ón
• Sitio origen (AIX TCF, Sprite )
Cada sitio tiene información sobre el traslado del proceso.
Es inseguro por caídas de los sitios intermedios, los sitios origen siguen cargados.
Los tipo 1 son encolados en el sitio fuente, luego de notificada la ubicación del proceso le
son enviados como parte del proceso de migración.
Para los tipo 2 y 3 es dejada una dirección adelantada en el sitio fuente apuntado al sitio
destino llamada link.
Ve
r
•
si
• Enlace transversal : (DEMOS/MP)
•
• Actualización del link (Charlotte)
•
Desde el sitio origen se manda a todos los demás kernels un mensaje de actualización de la
nueva ubicación.
Migrando procesos, como afecta las comunicaciones:
in
a
r
Cuando un proceso es migrado es necesario no solo pasar parte o toda la información
que el proceso tiene en el sistema origen al sistema destino, sino que también se deben
realizar las siguientes tareas que afectan la forma en que se comunica:
•
si
•
Cualquier conexión (link) entre este proceso y otros procesos, como por ejemplo el paso de
mensajes y señales, debe ser actualizado o redireccionado al nuevo sitio.
Una estrategia es transmitir todo el archivo al nuevo nodo, y a partir de ese momento todo
acceso al archivo es local. Cuando el usuario ya no requiere acceso al archivo, se envía de
regreso una copia al nodo origen.
El otro enfoque consiste en transferir al nodo destino solo las porciones del archivo que en
ese momento realmente son necesarias para la tarea actual. Si se requiere otra porción, se
efectúa otra transferencia y, cuando el usuario ya no quiera acceder al archivo, todas las
porciones modificadas se mandan de regreso origen.
ón
•
Pr
e
lim
• Destruir el proceso en la fuente del sistema y crearlo en el otro sistema. Esto es un
movimiento de parámetros del proceso, no una replicación.
• La imagen del proceso, o sea, una parte del bloque de control del proceso (PCB), debe ser
movido. Es importante destacar que no se puede copiar el PCB en forma directa sino que
se deberá generar uno nuevo en el sistema destino y copiarle los datos del PCB en el
equipo origen.
• Transferencia de los datos:
•
•
•
Ve
r
• Migración de cálculos:
El proceso p invoca un procedimiento predefinido del nodo destino, el cuál se ejecuta y devuelve
a p los resultados.
Como alternativa, el proceso p puede enviar un mensaje al nodo destino. El sistema operativo del
nodo destino crea un nuevo proceso q cuya función es realizar la tarea solicitada y cuando q
termina su ejecución, envía a p el resultado por medio del sistema de mensajes.
Obsérvese que en este esquema los procesos p y q pueden ejecutarse concurrentemente y, de
hecho, puede haber varios procesos concurrentes en distintas instalaciones.
Migrando procesos, como afecta las comunicaciones: (Cont)
Estrategias para mover el contenido parcial del PCB:
Pr
e
lim
in
a
r
• Intenso (todos): Transfiere el espacio de dirección entero en el momento de la migración.
• Intenso (sucio): Transfiere sólo aquellas páginas del espacio de dirección que están en
memoria central y fueron modificados. Requiere soporte de paginación remota.
• Precopia: El proceso continúa ejecutando en el nodo fuente mientras el espacio de
dirección es copiado a otro nodo.
• Copia por referencia: Esta es una variación de la anterior en la cual las páginas son
traídas sólo cuando son referenciadas.
• Mover (flushing): Las páginas de los procesos son limpiadas desde la memoria central de
la fuente moviendo las páginas viejas al disco. Después se realiza una copia por
referencia.
Problemas que se encuentran al mover el PCB:
Ve
r
si
ón
• Espacio de Direccionamiento: Suponiendo memoria virtual (paginación o segmentación):
dos estrategias.
• Transferir todo el espacio de direccionamiento en el momento de la migración. Si el
espacio de direccionamiento es grande y sólo se necesita una parte esto es CARO.
• Transferir solo lo que está en Memoria Central. El resto se transfiere por demanda.
La máquina de origen siga pendiente del proceso (mientras viva) para la paginación
o la segmentación.
• Archivos asignados al Proceso Migrado:
• Si va a seguir accediendo al Archivo y es el único, conviene migrar el Archivo
también.
• Si el proceso va y vuelve en seguida, conviene dejar el Archivo o solo moverlo ante
una solicitud de I/O.
Migrando procesos, como afecta las comunicaciones: (Cont)
Pr
e
lim
in
a
r
Qué pasa con los Mensajes y las Señales:
• El destino de los mensajes y las señales pendientes, se puede tratar mediante
un mecanismo de almacenamiento temporal, durante la migración, para dirigirlos
posteriormente a su nuevo destino.
• Puede hacer falta mantener una información de desvío en el emplazamiento
inicial durante algún tiempo, para asegurar que llegan todos los mensajes y las
señales pendientes.
• Los Mensajes que lleguen para el proceso durante la migración son guardados,
por el sistema temporalmente y después reenviados.
Ve
r
si
ón
Ejemplo de Self Migration: AIX (IBM).
• El proceso P decide que debe migrarse, por lo que solicita al SO que seleccione
una máquina de destino. Y le mande un mensaje con la IMAGE (imagen del
proceso) y un archivo con la información necesaria para que el SO receptor
pueda trabajar.
• En la máquina destino, el Kernel crea un hijo y le asigna como información del
proceso los datos recibidos del SO origen.
• El Hijo toma los datos de la imagen transferida como ser: contexto, argumentos,
stack, etc. que necesita para completar la operación.
• El Proceso Original P es suspendido durante la migración tanto en el equipo
origen como en el destino. Cuando el proceso de migración termina se destruye
a ese proceso del sistema origen, quedando una sola copia en el equipo destino.
Llamadas a procedimientos remotos: Generalidades
lim
in
a
r
Se denomina genéricamente “Llamada a procedimientos remotos (Remote Procedure
Call)” al proceso por el cual un proceso le pide la ejecución parcial o total de una
determinada problemática a otro proceso que se encuentra ejecutándose en forma
concurrente ya sea dentro o fuera del equipo computacional donde se encuentra el
proceso que necesita los servicios.
De esta manera la primer forma de comunicación de este tipo son las llamadas entre
procesos catalogados cliente-servidor, que es la primera de las formas de hacer RPC.
Algunos métodos para hacer RPC:
Ve
r
si
ón
Pr
e
• Independientes al paradigma de programación:
• Cliente – Servidor: Es muy de bajo nivel, ya que en cada tipo de aplicación hay que
realizar todo el proceso de comunicación, manejo de errores, etc.
• Para programación procedural:
• Sun RPC: Propuesto por Birrel y Nelson en 1985. Es un protocolo que desarrollo la
empresa SUN donde toda la parte del manejo de la comunicación está implementado
a nivel de bibliotecas comunes, por lo que los programadores solo deben ocuparse
de realizar las funciones servidor y los clientes que las consumen, pero no de toda la
problemática de la comunicación propiamente dicha. Como ejemplos de éste tipo de
servicios podemos tomar al NFS o NIS.
• Para programación orientada a objetos: Llegaron a su culminación en 1990 con
DCE (Distributed Computing Environment), se basan en consumir métodos en
forma remota, los más importantes son:
•
•
•
CORBA / ICE ZeroC
RMI
DCOM
Llamadas a procedimientos remotos: Método RPC o Sun RPC
•
Es 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 (a través de otro mensaje).
Pr
e
•
•
lim
in
a
r
Se usa para encapsular la comunicación entre dos procesos actuando uno como cliente
y el otro como servidor. Lo fundamental de la técnica es permitir que programas que se
están ejecutando en la misma máquina o en máquinas diferentes interactúen mediante
una simple semántica de mensajes y consuman los procedimientos publicados, como si
los dos programas estuvieran en la misma máquina, y sin que esto sea una
problemática para el programador.
Funcionamiento General de RPC:
Cliente:
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 envía al cliente.
si
•
•
•
ón
Servidor:
Ve
r
Código cliente.
Código del servidor.
Formato de representación.
Definición de la interfase.
Localización del servidor.
Semánticas de fallo.
...
...
x=buscar(1556)
...
int buscar(int cod)
{
...
...
return val;
}
Servidor
•
•
•
•
•
•
Cliente
Elementos Necesarios:
Llamadas a procedimientos remotos: Método RPC o Sun RPC (Cont)
Ventajas del método:
•
•
•
r
in
a
lim
•
La llamada a procedimientos es una abstracción muy usada, aceptada y bien
comprendida.
Permite que las interfases remotas se especifiquen como un conjunto de operaciones con
nombre y tipo determinado. De este modo, la interfase puede documentarse de forma
clara y los programas distribuidos pueden chequearse para detectar errores de tipo.
Como la interfase es estándar y está definida de forma precisa, el código de
comunicaciones de una aplicación puede generarse automáticamente.
Los productores de software pueden escribir módulos clientes y servidores que pueden
trasladarse entre computadores y SO con pocas modificaciones.
Puede considerarse como un refinamiento de mensajes confiable y bloqueantes.
Pr
e
•
Ve
r
si
ón
Desventajas del método:
• Sólo funciona en lenguajes procedurales (C, Pascal, etc.)
Llamadas a procedimientos remotos: Método RPC o Sun RPC (Cont)
in
a
r
Código Cliente/Código Servidor:
Las funciones de abstracción de una llamada RPC para el intercambio de mensajes se
denominan resguardos (stubs).
SISTEMA CLIENTE
lim
SISTEMA SERVIDOR
PROCEDIMIENTOS
INICIO
LLAMADA
PREPARA
1 ENTRADA
ón
RESGUARDO
CLIENTE
FIN
LLAMADA
CONVIERTE 9
SALIDA
Ve
r
si
BIBLIOT.
ENVÍA
EJECUCIÓN 2 ENTRADA
RPC
RECIBE 8
SALIDA
5
EJECUTA
PROCEDIMIENTO
REMOTO
Pr
e
CÓDIGO DE LA APLICACIÓN
CONVIERTE 4
ENTRADA
RESGUARDO
SERVIDOR
6 PREPARA
SALIDA
BIBLIOT.
EJECUCIÓN
RPC
RECIBE 3
Y PASA
7 TRANSMITE
SALIDA
Llamadas a procedimientos remotos: Método RPC o Sun RPC (Cont)
Ve
r
si
ón
Pr
e
lim
in
a
r
Sobre los resguardos (stubs):
• Se generan automáticamente por el software de RPC en base a la interfase del
servicio.
• Son independientes de la implementación que se haga tanto del lado del cliente
como del servidor. Sólo dependen de la interfase definida para la comunicación.
• 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.
Llamadas a procedimientos remotos: Método RPC o Sun RPC (Cont)
El pasaje de parámetros y su problemática
Ve
r
1
si
ón
Pr
e
lim
in
a
r
• El paso de parámetros por valor es sencillo para las llamadas a procedimientos remotos,
ya los parámetros se copian simplemente en el mensaje y se envían al sistema remoto.
• Las llamadas por referencia son más complicadas de implementar, porque es necesario
que exista un único puntero para cada objeto, válido en todo el sistema.
• Otro problema es cómo representar los parámetros y los resultados en los mensajes. Si el
programa cliente y el servidor están construido en los mismos lenguajes de programación,
sobre el mismo tipo de máquinas y con el mismo SO, los requisitos de representación no
son un problema, pero si esto no ocurre se pueden presentar problemas de
representación. Para solucionar esto el mejor enfoque para este problema es ofrecer un
formato estándar para los objetos comunes, como los enteros, números en coma flotante,
caracteres y cadenas de caracteres. De esta forma, los parámetros propios de cualquier
máquina pueden convertirse a la representación estándar y viceversa. Para solucionar esto
se utiliza XDR (external data representation) que es un estándar que define la
representación de tipos de datos.
2
3
Llamadas a procedimientos remotos: Método CORBA
CORBA (Common Object Request Broker Architecture):
r
in
a
lim
•
Pr
e
•
IDL: Un lenguaje de descripción de interfases, llamado Lenguaje de Definición de
Interfases IDL (Interface Definition Language), existen muchas traducciones de este
lenguaje de especificación IDL a lenguajes de implementación (como pueden ser
C++, Java, ADA, etc.) y una infraestructura de distribución de objetos llamada Object
Request Broker (ORB) que ha dado su nombre a la propia norma: Common Object
Request Broker Architecture (CORBA).
ón
•
si
•
Es un estándar definido en 1991 por la OMG (Object Management Group) para tratar la problemática de
realizar aplicaciones distribuidas en el paradigma de orientación a objetos.
CORBA es una especificación para la tecnología de la gestión de objetos distribuidos (DOM). La
tecnología DOM proporciona una interfase de alto nivel OO situada en la cima de los servicios básicos
de la programación distribuida. El nivel más alto de la especificación es denominado arquitectura de
gestión de objetos (OMA)
Una aplicación definida sobre OMA esta compuesta por una serie de objetos distribuidos que cooperan
entre sí.
Esta norma cubre cinco grandes ámbitos que constituyen los sistemas de objetos distribuidos:
Ve
r
•
Llamadas a procedimientos remotos: Método CORBA (Cont)
Servicios: Una descripción de servicios, conocidos con el nombre de Servicios
CORBA: (CorbaServices), Proporcionan funciones elementales necesarias para
cualquier tipo de entorno distribuido, independientemente del entorno de aplicación.
Estas especificaciones cubren los servicios de nombrado, de persistencia, de
eventos, de transacciones, la notificación asíncrona de eventos o la creación y
migración de objetos etc. El número de servicios se amplía continuamente para
añadir nuevas capacidades a los sistemas desarrollados con CORBA. Están
pensados para grandes sistemas.
si
ón
Facilidades Comunes: Una descripción de servicios orientados al desarrollo de
aplicaciones finales, estructurados sobre los objetos y servicios CORBA. Con el
nombre de Facilidades CORBA (CorbaFacilities), estas especificaciones cubren
servicios de alto nivel, como las interfases de usuario, los documentos compuestos,
la administración de sistemas y redes, etc. La ambición es aquí bastante amplia ya
que CorbaFacilities pretende definir colecciones de objetos prefabricados para
aplicaciones habituales en la empresa: creación de documentos, administración de
sistemas informáticos, etc. (También denominadas Facilidades Horizontales)
Ve
r
•
Naming Service : Permite a un cliente encontrar un objeto, a través de su nombre.
Event Service: Permite a los clientes y servidores enviar mensajes o eventos.
Security Service: Permite dar permisos a objetos o grupos de objetos.
Trading Service: Permite a los clientes encontrar objetos dada una restricción.
Transaction Service: Permite tener transacciones distribuidas bajo two phase commit
Persistent State Service: Servicio de persistencia de objetos.
Pr
e
•
•
•
•
•
•
lim
in
a
r
•
Llamadas a procedimientos remotos: Método CORBA (Cont)
Interfases de Dominio: Una descripción de servicios verticales denominados
Dominios CORBA (CorbaDomains), que proveen funcionalidad de interés para
usuarios finales en campos de aplicación particulares. Proporcionan funciones
complejas, al igual que las Facilidades, pero restringidas a campos de aplicación muy
concretos Por ejemplo, existen proyectos en curso en sectores como:
telecomunicaciones, finanzas, medicina, etc. (También denominadas Facilidades
Verticales)
GIOP (General Inter-ORB Protocol): Un protocolo genérico de intercomunicación,
el Protocolo General Inter-ORB GIOP, que define los mensajes y el empaquetado de
los datos que se transmiten entre los objetos. Además define implementaciones, de
ese protocolo genérico, sobre diferentes protocolos de transporte, lo que permite la
comunicación entre los diferentes ORBs consiguiendo la interoperabilidad de
elementos de diferentes vendedores. Por ejemplo el IIOP para redes con la capa de
transporte TCP.
Pr
e
ón
si
Ve
r
•
lim
in
a
r
•
Llamadas a procedimientos remotos: Método CORBA (Cont)
Interfases de Dominio: Una descripción de servicios verticales denominados
Dominios CORBA (CorbaDomains), que proveen funcionalidad de interés para
usuarios finales en campos de aplicación particulares. Proporcionan funciones
complejas, al igual que las Facilidades, pero restringidas a campos de aplicación muy
concretos Por ejemplo, existen proyectos en curso en sectores como:
telecomunicaciones, finanzas, medicina, etc. (También denominadas Facilidades
Verticales)
GIOP (General Inter-ORB Protocol): Un protocolo genérico de intercomunicación,
el Protocolo General Inter-ORB GIOP, que define los mensajes y el empaquetado de
los datos que se transmiten entre los objetos. Además define implementaciones, de
ese protocolo genérico, sobre diferentes protocolos de transporte, lo que permite la
comunicación entre los diferentes ORBs consiguiendo la interoperabilidad de
elementos de diferentes vendedores. Por ejemplo el IIOP para redes con la capa de
transporte TCP.
Pr
e
ón
si
Ve
r
•
lim
in
a
r
•
Llamadas a procedimientos remotos: Método RMI
in
a
r
La idea básica de RMI (Remote Method Invocation) es que, objetos ejecutándose en
una Virtual Machine (VM) sean capaces invocar métodos de objetos ejecutándose en
otra VM. Las VM's pueden estar en la misma máquina o en máquinas distintas
conectadas por una red ya que esto no es una limitación del método.
Pr
e
lim
Como principales características podemos encontrar las siguientes:
• Sencillez en su implementación
• Transparencia, el programador puede trabajar con los objetos igual que si
estuviese en su máquina local
• Implementación 100% Java (es también su principal desventaja)
• Independencia del protocolo de comunicación
Ve
r
si
ón
La arquitectura de RMI consta de 3 capas:
• La capa de stub/skeleton
• La capa de referencia remota
• Y la capa de transporte