SISTEMAS DISTRIBUIDOS

Identifica los
modelos de
La sintaxis y los formatos de comunicación que
dependen de los productos y el transporte en si, que

comunicación a proporciona el transportista, elemento tan

estandarizado e integrado en el Middleware que hoy
partir de los cuales día es, creo que afortunadamente, desconocido por la
mayoría de desarrolladores.
se puede diseñar y Podemos encontrar los siguientes modelos de
Comunicación: sincrónica, asincrónica y desacoplada
construir un
sistema distribuido
 El cliente lanza la petición y se para a esperar la
respuesta. Es el modelo convencional de
comunicación entre un programa y una rutina. Por
eso los modelos de comunicación síncronos son los
mas utilizados. En un programa clásico, cuando se
llama a una rutina, si no llega respuesta con el
programa en explotación, el problema que tendremos
será mucho más grave que no el hecho en si;
SINCRÓNICA probablemente la máquina esté “colgada” o tenga
graves problemas. En un modelo de comunicación
síncrono C/S la respuesta puede no llegar por
problemas de acceso o de máquina en la localización
del servicio, pero el programa cliente continua
perfectamente activo esperando la respuesta. No hay
que decir que un modelo de síncrono necesita un
mecanismo de multicliente para que varios de ellos
puedan realizar llamadas al mismo tiempo, aunque se
atiendan una detrás de otra.
 Hay dos submodelos de comunicación síncrona:
Síncrono no controlado: La caída del servicio provoca
el “cuelgue” del cliente. Afortunadamente no queda
prácticamente ningún modelo síncrono de este grupo.
Síncrono controlado. El Middleware realiza dos
controles de existencia del servicio:
• Control de conexión. Cuando el cliente pide el
servicio se comprueba que este disponible y en
SINCRÓNICA caso contrario se devuelve error inmediatamente al
cliente.
• Control de respuesta. Normalmente por time-out,
se controla que, si pasado un tiempo no hay
respuesta, se devuelva control y aviso de error al
cliente. Hay dos modalidades:
• Esperando: Si el servidor no esta disponible, es
decir “esperando”, se devuelve el mensaje.
Equivale a time_out=0.
• Cronometrado: es el caso de time_out>0.
 En comunicación asíncrona, el cliente lanza la
respuesta, continua trabajando y cuando le conviene
recoge la respuesta.
Inmediatamente se observa que este modelo de
comunicación es más potente que el síncrono, pero
que también es más complejo de gestionar. Cada
mecanismo que proporcione un modelo de
comunicación asíncrono ha de proporcionar como
mínimo tres mecanismos adicionales:

ASINCRÓNICA • Multipetición: Los clientes deben poder dejar

peticiones para los servidores aunque estos estén
ocupados. Este mecanismo, aunque escondido,
también existe en la comunicación síncrona.
• Interrogación. Preguntar desde el cliente si la
respuesta está disponible.
• Almacén de respuestas. El servidor ha de ser capaz
de poder almacenar respuestas hasta que el cliente
este disponible para recogerlas. De otra forma, el
servidor daría la sensación de “cuelgue”.
 En comunicación desacoplada, el cliente lanza la
petición y no recoge nunca la respuesta ya que
supone que el servicio se ejecutará siempre y acabará
sin problemas.
Un ejemplo clásico es el uso de un servidor de
impresión. El programa imprime por una impresora
lógica y se despreocupa de si el spool está activado o
no. La filosofía de traspaso de datos entre
aplicaciones (interfase) es también un modelo de
DESACOPLADA comunicación desacoplado.
Es considerado por muchos autores como un modelo
asíncrono límite. Yo particularmente pienso que no es
C/S sino una comunicación por interfase ya que
necesita un almacén intermedio de comunicación. Y
el hecho de que eso se consiga en muchos casos con
una cola, la aparición de un fichero en un directorio o
de un registro en una entidad de la base de datos no
cabía nada. En otras palabras, obtiene un servicio sin
utilizar comunicación cliente/servidor.
 Reconoce el modelo distribuido basado en la obtención
de servicios en arquitectura cliente/servidor. 
El modelo cliente-servidor está diseñado para proporcionar
servicios de red, los cuales fueron, y todavía son, la aplicación
más popular de la computación distribuida. Permite a los usuarios
de la red compartir recursos. En el esquema más simple, la
localización de un servicio es estática y se puede identificar
utilizando la dirección del proceso servidor, en términos del
nombre de la máquina y el número de puerto de protocolo
asignado al proceso servidor. Este es el esquema usado para los
servicios de Internet, donde a cada servicio de Internet se le
asigna un número de puerto específico. En particular, a un
servicio bien conocido, como FTP, HTTP, o telnet, se le asigna un
número de puerto por defecto que se reserva en cada máquina
de Internet para ese servicio. Por ejemplo, al servicio FTP se le
asignan dos números de puerto de TCP: 20 y 21, y al HTTP el
puerto de TCP 80.
 Presentar la arquitectura de la Internet y los detalles de
los protocolos del nivel de aplicación utilizados en la Web. 
La capa de aplicación permite que los mensajes se puedan intercambiar entre los programas, a
fin de posibilitar el funcionamiento de una aplicación, tal como la Web. Los protocolos de nivel
de aplicaciones oficiales de Internet incluyen:
• Domain Name Protocol (Protocolo de nombres de dominio)
• Exterior Gateway Protocol (Protocolo de pasarela exterior)
• File Transfer Protocol (Protocolo de transferencia de archivos)
• Name/Finger Protocol (Protocolo de nombres/finger)
• Telnet Protocol (Protocolo Telnet)
• Trivial File Transfer Protocol (Protocolo de transferencia de archivos trivial)
TCP/IP implementa otros protocolos de nivel superior que no son protocolos oficiales de
Internet pero que se utilizan comúnmente en la comunidad de Internet a nivel de programa de
aplicación. Estos protocolos incluyen:
• Protocolo de red local de DCN (Distributed Computer Network - Red de sistemas
distribuidos)
• Protocolo de ejecución remota de mandatos
• Protocolo de inicio de sesión remoto
• Protocolo de shell remoto
• Protocolo Wake On LAN
• Protocolo de información de direccionamiento
• Protocolo de servidor horario
 Los middlewares de computación distribuida más
Presentar los conocidos son CORBA (Common Object Request
estándares, Broker Agent, definido por el OMG) y RMI (Remote
Method Invocation, de Sun Microsystems). RMI es
protocolos, entornos más simple pero está limitado al mundo Java, lo que
hace que sea una solución más limitada. Ambos
y middlewares disponen de normas de funcionamiento
y de protocolos propios que pueden resultar
herramientas actuale complejos de comprender y “pesados” desde el punto
s para desarrollo de de vista de la transmisión de información. En la
actualidad ha surgido otra tecnología de computación
aplicaciones distribuida, la arquitectura SOA (Service Oriented
Architecture) que pretende estandarizar las normas
distribuidas de funcionamiento para que la transparencia de
ubicación sea completa (independiente de lenguaje
(CORBA, SOAP, de programación y/o sistema operativo) y la
RMI). comunicación se realice mediante el estándar XML
bajo distintas normas (SOAP, WSDL, UDDI).
 RMI
RMI- Remote Invocation Method. Fue el primer framework
para crear sistemas distribuidos de Java. El sistema de
Invocación Remota de Métodos (RMI) de Java permite, a un
objeto que se está ejecutando en una Máquina Virtual Java
(VM), llamar a métodos de otro objeto que está en otra VM
diferente. En RMI, un servidor de objeto exporta un objeto
remoto y lo registra en un servicio de directorios. El objeto
proporciona métodos remotos, que pueden invocar los
programas clientes. Sintácticamente, un objeto remoto se
declara como una interfaz remota, una extensión de la
interfaz Java. El servidor de objeto implementa la interfaz
remota. Un cliente de objeto accede al objeto mediante la
invocación de sus métodos, utilizando una sintaxis similar a
las invocaciones de los métodos locales.
 CORBA
CORBA.- Common Object Request Broker Architecture. Tecnología
introducida por el Grupo de Administración de Objetos OMG. Es una
arquitectura diseñada para dar soporte multi-plataforma; de forma
que las herramientas basadas en esta tecnología pueden soportar
programas escritos en diversos lenguajes y también procesos
ejecutando sobre distintas plataformas. Un cliente de objeto realiza
una llamada a un método de un objeto distribuido. El cliente
interactúa con un proxy, un stub mientras que la implementación del
objeto interactúa con un proxy de servidor, un skeleton. A diferencia
del caso de Java RMI, una capa adicional de software, conocida como
ORB (Object Request Broker) es necesaria. En el lado del cliente, la
capa del ORB actúa con intermediaria entre el stub y la red y sistema
operativo local del cliente. En el lado del servidor, la capa del ORB
sirve de intermediaria entre el skeleton y la red y sistema operativo
del servidor. Utilizando un protocolo común, las capas ORB de ambos
extremos son capaces de resolver las diferencias existentes en lo
referente a lenguajes de programación, así como las relativas a las
plataformas (red y sistema operativo), para de esta forma ayudar a la
comunicación entre los dos extremos.
 SOAP
SOAP – Simple Object Access Protocol. Es un protocolo de
comunicación bajo HTTP mediante XML. Usando este protocolo
se podía ya desde el cliente o desde el servidor realizar
peticiones mediante HTTP a un servidor web. Los mensajes
deben tener un formato determinado empleando XML para
encapsular los parámetros de la petición. Facilita una
comunicación entre un cliente y un servidor remoto pero
existen multitud de protocolos creados para facilitar la
comunicación entre aplicaciones. No esta asociado con ningún
lenguaje. Los mensajes de SOAP se pueden asociar a los
protocolos de transporte existentes como HTTP y SMTP. Un
cliente web manda una petición HTTP, cuyo cuerpo contiene un
mensaje con formato SOAP que representa la llamada a un
método de un objeto de servicio. La petición se transmite a un
servidor web, que la reenvía, junto con los parámetros de la
llamada al método. A continuación se invoca el método. Una
vez completado, el valor devuelto por el método se envía al
servidor web y a continuación se transmite al cliente web en el
cuerpo de la respuesta HTTP,
 Presentar los protocolos de comunicaciones
basados en paso de mensajes (Sockets).
Es la aproximación más básica a la comunicación entre procesos.
Los datos que representan mensajes se intercambian entre dos
procesos, un emisor y un receptor. Es el paradigma fundamental
para aplicaciones distribuidas. Un proceso envía un mensaje que
representa una petición. El mensaje se entrega a un receptor, que
procesa la petición y envía un mensaje como respuesta. En
secuencia, la réplica puede disparar posteriores peticiones, que
lleven a sucesivas respuestas, y así en adelante. Por medio del
grado de abstracción proporcionado por este modelo, los
procesos interconectados realizan la entrada y la salida hacia el
otro proceso, de una forma similar a la utilizada en la
entrada/salida (E/S) de ficheros. Como en el caso de la E/S de
ficheros, las operaciones sirven para encapsular el detalle de la
comunicación a nivel del sistema operativo, de forma que el
programador puede hacer uso de operaciones para enviar y
recibir mensajes sin preocuparse por el detalle subyacente.
Usando un socket, una construcción lógica, dos procesos pueden
intercambiarse datos de la siguiente forma: un emisor escribe o
inserta un mensaje en el socket', en el otro extremo, un receptor
lee o extrae un mensaje del socket.
 Dentro de los protocolos más utilizados en los sistemas
distribuidos se encuentran:
IP: Protocolo de Internet.- Protocolo de la capa de Red, que
Exponer las define la unidad básica de transferencia de datos y se encarga
del direccionamiento de la información, para que llegue a su

unidades de datos destino en la red.

TCP: Protocolo de Control de Transmisión.- Protocolo de la capa
de los protocolos de Transporte, que divide y ordena la información a transportar
en paquetes de menor tamaño para su envío y recepción.
de comunicaciones HTTP: Protocolo de Transferencia de Hipertexto.- Protocolo de
la capa de aplicación, que permite el servicio de transferencia de
en red empleados páginas de hipertexto entre el cliente Web y los servidores.

en los sistemas SMTP: Protocolo de Transferencia de Correo Simple.- Protocolo

de la capa de aplicación, que procesa el envío de correo

distribuidos. electrónico por la red.

POP3: Protocolo de Oficina de Correo.- Protocolo de la capa de
aplicación, que gestiona los correos en Internet, es decir,
permite a una estación de trabajo recuperar los correos que
están almacenados en el servidor.
 Sistemas Distribuidos (español –versión anterior -) George
Coulouris; Jean Dollimore; Sebastián Dormido; Tim Kindberg
Editorial: Addison Wesley | 3era Edición Idioma: Español
ISBN: 8478290494.
Artículos: Andrew S. Tanenbaum and Robbert Van Renesse,
Distributed Operating Systems. ACM Computing Surveys
(CSUR), Volume 17, Issue 4. Pags. 419-470. ISSN:0360-0300.
The MIT Press scientific computation series. 1985. Eliezer

BIBLIOGRAFÍA Levy and Abraham Silberschatz, Distributed file systems:

concepts and examples. ACM Computing Surveys (CSUR),
Volume 22, Issue 4. Pags. 321-374. ISSN:0360-0300. 1990.
George Coulouris. Sistemas Distribuidos. Tercera Edición.
Addison Wesley. Madrid. 2001.
COMPUTACIÓN DISTRIBUIDA: FUNDAMENTOS Y
APLICACIONES Autor/es: Liu, Mei-Ling ; Editorial: PEARSON
ADDISON-WESLEY