SISTEMAS DISTRIBUIDOS

INTEGRANTES:

JOHNNY CANABAL RIVERA

JORGE JULIO EMILIANI

PRESENTADO A:

ING. RONALD CUELLO

FUNDACION UNIVERSITARIA TECNOLOGICO COMFENALCO

FACULTAD DE INGENIERIAS
PROGRAMA DE INGENIERIA DE SISTEMAS
SEMESTRE 9
2019
 PREGUNTAS

1. ¿SERVICIOS DE NOMBRES?

2. ¿COMUNICACIÓN DE MENSAJES?

 ¿RPC (REMOTE PROCEDURE CALL)?

 ¿JAVA RMI (Remote Method Invocation)?

 ¿CORBA (Common Object Request Broker Architecture)?

 ¿WEB SERVICES SOAP (Simple Object Access Protocol)?

 1. Servicios de nombre

R/ Un servicio de nombres realiza consultas de información almacenada, por ejemplo:

 Nombres de host y direcciones

 Nombres de usuario
 Contraseñas
 Permisos de acceso
 Pertenencia a grupos, mapas de montaje automático, etc.

Esta información está disponible para que los usuarios puedan iniciar una sesión en su host,
tener acceso a los recursos y se les concedan los permisos. La información del servicio de
nombres se puede almacenar en archivos, mapas o diferentes formatos de archivos de base de
datos. Estos repositorios de información pueden ser locales en el sistema o estar alojados en
una base de datos o un repositorio basado en red de manera central.

Sin un servicio de nombres central, cada host tendría que conservar su propia copia de esta
información. Si centraliza todos los datos, la administración resulta más fácil.

Los servicios de nombres son fundamentales para cualquier red informática. Entre otras
funciones, los servicios de nombres proporcionan una funcionalidad que realiza lo siguiente.

 Asocia (vincula) nombres con objetos

 Resuelve nombres para objetos
 Elimina enlaces
 Enumera los nombres
 Cambia el nombre de la información

2. Comunicación de mensajes
 Comunicación de mensajes RPC

R/ En computación distribuida, la llamada a procedimiento remoto (en inglés, Remote

Procedure Call, RPC) es un programa que utiliza una computadora para ejecutar código en otra
máquina remota sin tener que preocuparse por las comunicaciones entre ambas. El protocolo
que se utiliza para esta llamada es un gran avance sobre los sockets de Internet usados hasta el
momento. De esta manera el programador no tenía que estar pendiente de las
comunicaciones, estando estas encapsuladas dentro de las RPC.

Las RPC son muy utilizadas dentro de la comunicación cliente-servidor. Siendo el cliente el que
inicia el proceso solicitando al servidor que ejecute cierto procedimiento o función y enviando
este de vuelta el resultado de dicha operación al cliente.
El modelo RCP implica un nivel de transparencia de ubicación, a saber, que la llamada a
procedimiento es en gran parte la misma tanto si es local como remota, pero usualmente estas
no son idénticas, entonces las llamadas locales pueden ser distinguidas de las llamadas
remotas. Las llamadas remotas son usualmente más lentas y menos confiables que las llamadas
locales, por lo tanto, distinguirlas es útil.

Existen diversas tecnologías para implementar RPC que no son compatibles entre sí, como ser
el RFC 1057 (RPC de Sun), DCOM (de Microsoft), etc.

 Comunicación de mensajes java RMI

R/ RMI (Java Remote Method Invocation) es un mecanismo ofrecido por Java para invocar un
método de manera remota. Forma parte del entorno estándar de ejecución de Java y
proporciona un mecanismo simple para la comunicación de servidores en aplicaciones
distribuidas basadas exclusivamente en Java. Si se requiere comunicación entre otras
tecnologías debe utilizarse CORBA o SOAP en lugar de RMI.

RMI se caracteriza por la facilidad de su uso en la programación por estar específicamente

diseñado para Java; proporciona paso de objetos por referencia (no permitido por SOAP),
recolección de basura distribuida (Garbage Collector distribuido) y paso de tipos arbitrarios
(funcionalidad no provista por CORBA).

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

La invocación se compone de los siguientes pasos:

  Encapsulado (marshalling) de los parámetros (utilizando la funcionalidad de serialización
de Java).
 Invocación del método (del cliente sobre el servidor). El invocador se queda esperando
una respuesta.
 Al terminar la ejecución, el servidor serializa el valor de retorno (si lo hay) y lo envía al
cliente.
 El código cliente recibe la respuesta y continúa como si la invocación hubiera sido local.

Arquitectura

La arquitectura RMI puede verse como un modelo de cuatro capas.

Primera capa: La primera capa es la de aplicación y se corresponde con la implementación real

de las aplicaciones cliente y servidor. Aquí tienen lugar las llamadas a alto nivel para acceder y
exportar objetos remotos. Cualquier aplicación que quiera que sus métodos estén disponibles
para su acceso por clientes remotos debe declarar dichos métodos en una interfaz que extienda
java.rmi.Remote.
Segunda capa: La capa 2 es la capa proxy, o capa stub-skeleton. Esta capa es la que interactúa
directamente con la capa de aplicación. Todas las llamadas a objetos remotos y acciones junto
con sus parámetros y retorno de objetos tienen lugar en esta capa.
Tercera capa: La capa 3 es la de referencia remota, y es responsable del manejo de la parte
semántica de las invocaciones remotas. También es responsable de la gestión de la replicación
de objetos y realización de tareas específicas de la implementación con los objetos remotos,
como el establecimiento de las persistencias semánticas y estrategias adecuadas para la
recuperación de conexiones perdidas. En esta capa se espera una conexión de tipo stream
(stream-oriented connection) desde la capa de transporte.
Cuarta Capa: La capa 4 es la de transporte. Es la responsable de realizar las conexiones necesarias y
manejo del transporte de los datos de una máquina a otra. El protocolo de transporte subyacente para
RMI es JRMP (Java Remote Method Protocol), que solamente es "comprendido" por programas Java.

Elementos

Toda aplicación RMI normalmente se descompone en 2 partes:

 Un servidor, que crea algunos objetos remotos, crea referencias para hacerlos
accesibles, y espera a que el cliente los invoque.
 Un cliente, que obtiene una referencia a objetos remotos en el servidor, y los invoca.
  Comunicación de mensajes Corba
R/ Common Object Request Broker Architecture (CORBA) es un estándar definido por Object
Management Group (OMG) que permite que diversos componentes de software escritos en
múltiples lenguajes de programación y que corren en diferentes computadoras, puedan
trabajar juntos; es decir, facilita el desarrollo de aplicaciones distribuidas en entornos
heterogéneos.
Su objetivo es ayudar a reducir la complejidad, disminuir los costes y acelerar la introducción de
nuevas aplicaciones informáticas, promoviendo la teoría y la práctica de la tecnología de
objetos en los sistemas distribuidos.
Es una tecnología que oculta la programación a bajo nivel de aplicaciones distribuidas. No
obstante, también brinda al programador una tecnología orientada a objetos; las funciones
objetos y estos objetos pueden estar en diferentes máquinas, pero el programador accederá a
ellos a través de funciones normales dentro de su programa.
CORBA es más que una especificación multiplataforma, también define servicios habitualmente
necesarios como seguridad y transacciones. Y así este no es un sistema operativo en sí, en
realidad es un middleware.
Características

Entre las principales características de CORBA nos encontramos con:

 Independencia en el lenguaje de programación y sistema operativo: CORBA fue

diseñado para liberar a los ingenieros de las limitaciones en cuanto al diseño del
software. Actualmente soporta Ada, C, C++, C++11, Lisp, Ruby, Smalltalk, Java, COBOL,
PL/I y Python.
 Posibilidad de interacción entre diferentes tecnologías: uno de los principales beneficios
de la utilización de CORBA es la posibilidad de normalizar las interfaces entre las
diversas tecnologías y poder así combinarlas.
 Transparencia de distribución: ni cliente ni servidor necesitan saber si la aplicación está
distribuida o centralizada, pues el sistema se ocupa de todo eso.
 Transparencia de localización: el cliente no necesita saber dónde ejecuta el servicio y el
servicio no necesita saber dónde ejecuta el cliente.
 Integración de software existente: se amortiza la inversión previa reutilizando el
software con el que se trabaja, incluso con sistemas heredados.
 Activación de objetos: los objetos remotos no tienen por qué estar en memoria
permanentemente, y se hace de manera invisible para el cliente.
 Otras como: el tapado fuerte de datos, la alta capacidad de configuración, libertad de
elección de los detalles de transferencia de datos, o la compresión de los datos.

Interface Definition Language (IDL)

El lenguaje de definición de interfaz o IDL (Interface Definition Language), es un lenguaje que se

utiliza para definir las interfaces entre los componentes de una aplicación y es el elemento que
soporta la interoperabilidad de la tecnología. El IDL sólo puede definir interfaces, no
implementaciones. Al especificar las interfaces entre objetos en CORBA, IDL es el encargado de
asegurar la independencia del lenguaje de programación utilizado.

Para que esto sea posible, es necesario asegurar que los datos son correctamente
intercambiados entre dos lenguajes distintos, para lo cual IDL define los tipos de datos de una
forma independiente del lenguaje con las correspondencias necesarias. Por ejemplo, un tipo
long en C++ de 32 bits puede corresponderse con un int de Java. OMG ha definido bastantes
correspondencias con lenguajes de programación populares, como: C, C++, COBOL, Java,
Smalltalk o Ada.
Tendremos principalmente dos tipos diferentes de IDL en CORBA:

 Stub IDL: es la interfaz estática a los servicios declarados en las interfaces IDL, para el
cliente todas las llamadas parecen locales. Actuará como proxy del objeto remoto,
realizando la invocación de métodos remotos, incluyendo la serialización, la recepción
de respuestas y la deserialización. El cliente puede tener tantos stubs como interfaces
IDL existan. Es generado a partir del IDL en el lenguaje de programación del cliente (C,
C++ Java, Smalltalk, Ada,… ) por un compilador IDL.
 Skeleton IDL: es el representante estático del cliente en el servidor. Para el servidor
todas las llamadas parecen locales. Es generado a partir del IDL por un compilador IDL y
realiza la deserialización de las invocaciones del cliente.

Comparativa RMI vs CORBACORBA

 permite una mayor heterogeneidad en el desarrollo de aplicaciones (RMI sólo se puede
desarrollar con Java).
 CORBA además de las funcionalidades de comunicación, proporciona servicios.
 RMI funciona sobre CORBA (IIOP).
 RMI es mucho más sencillo y cómodo de usar.
 RMI permite un desarrollo rápido de prototipos.

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)
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- 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.
  Comunicación de mensajes web services (SOAP)
R/ SOAP es un protocolo escrito en XML para el intercambio de información entre aplicaciones.
Es un formato para enviar mensajes, diseñado especialmente para servir de comunicación en
Internet, pudiendo extender los HTTP headers. Es una forma de definir qué información se
envía y cómo mediante XML. Básicamente es un protocolo para acceder a un Web Service.
Especificaciones básicas
SOAP: El fundamento de todos los servicios web basados en SOAP, la especificación SOAP
detalla el formato de los mensajes. También detalla la forma en que las aplicaciones deben
tratar determinados aspectos del mensaje, tales como los elementos del “encabezado”, lo que
le permitirá crear aplicaciones en las que un mensaje pasa entre múltiples intermediarios antes
de llegar a su destino final. Este tutorial abarcará la especificación SOAP.

Características

El protocolo SOAP tiene tres características principales:

 Extensibilidad (seguridad y WS-routing son extensiones aplicadas en el desarrollo).

 Neutralidad (bajo protocolo de transporte TCP puede ser utilizado sobre cualquier
protocolo de aplicación como HTTP, SMTP o JMS).
 Independencia (permite cualquier modelo de programación).
Estructura del mensaje

Un mensaje SOAP es un documento XML ordinario con una estructura definida en la

especificación del protocolo. Dicha estructura la conforman las siguientes partes:

 Envelope (obligatoria): raíz que de la estructura, es la parte que identifica al mensaje

SOAP como tal.
 Header: esta parte es un mecanismo de extensión ya que permite enviar información
relativa a cómo debe ser procesado el mensaje. Es una herramienta para que los
mensajes puedan ser enviados de la forma más conveniente para las aplicaciones. El
elemento "Header" se compone a su vez de "Header Blocks" que delimitan las unidades
de información necesarias para el header.
 Body (obligatoria): contiene la información relativa a la llamada y la respuesta.
 Fault: bloque que contiene información relativa a errores que se hayan producido
durante el procesado del mensaje y el envío desde el "SOAP Sender" hasta el "Ultimate
SOAP Receiver".

Modelo de procesado
El modelo de procesado de SOAP está definido como un sistema distribuido, en el que
intervienen diferentes nodos. En un escenario básico, los nodos SOAP se comunican uno
asumiendo el rol de SOAP Sender y SOAP Receiver. Aun así, la especificación define diferentes
tipos de nodos en función del rol que asumen en el envío del mensaje:

 SOAP Sender: nodo que transmite un mensaje SOAP.

 SOAP Receiver: nodo que acepta un mensaje.
 SOAP message path: conjunto de nodos por los cuales debe pasar un mensaje SOAP,
incluyendo el nodo inicial, cero o más nodos intermediarios y el SOAP Receiver
definitivo.
 Initial SOAP sender: el "sender" que origina el mensaje y que es el punto de inicio del
camino que seguirá el mensaje.
 SOAP intermediary: el intermediario actúa como SOAP receiver y como SOAP sender, ya
que primero recibe el mensaje para después reenviarlo al siguiente nodo en el camino.
 Ultimate SOAP receiver: destino final del mensaje SOAP, es el responsable de
procesarlo. Cabe destacar que el mensaje podría no llegar al receptor definitivo debido
a que problemas en los intermediarios hagan que se pierda.
Casos de uso
La forma más habitual de utilizar el protocolo SOAP es mediante el patrón petición-respuesta
con remitente SOAP y destinatario final SOAP, el cual es utilizado cuando los mensajes SOAP
están predefinidos y únicamente se desea enviar una petición y consultar su valor de retorno.
No obstante, muchas veces este patrón no es suficiente, y es necesario establecer un
intercambio múltiple de mensajes entre los nodos. La W3C define dos tipos de intercambios de
mensajes SOAP para formar una conversación:

 Intercambio de mensajes Conversacionales: permite redefinir la información de la

petición. Estos intercambios pueden acabar comportándose como un patrón de
mensajes de ida y vuelta.
 Llamadas a Procedimientos Remotos: permite encapsular la funcionalidad de
procedimientos remotos utilizando las ventajas de XML de extensibilidad y
funcionalidad, por este motivo se ha definido en la especificación una
representación uniforme para realizar invocaciones y respuestas RPC mediante
mensajes SOAP.

En ocasiones, es necesario el uso de intermediarios en las comunicaciones SOAP, la

especificación SOAP 1.2 define dos tipos:

 Intermediario redirector: se trata de un nodo SOAP, el cual redirige el mensaje

SOAP a otro nodo SOAP según lo establecido en un bloque de encabezado que ha
recibido el nodo destino o según el patrón de mensajes en uso.
 Intermediario activo: realiza un procesamiento adicional del mensaje SOAP antes de
redirigirlo, sin utilizar criterios descritos en el encabezado del mensaje o del patrón
de mensajes en uso.

Ventajas y desventajas de utilizar SOAP

Ventajas

 Debido al uso de XML permite invocar procedimientos remotos de muchos lenguajes,

por lo tanto, presenta una gran interoperabilidad.
 Al utilizar una comunicación vía HTTP es fácilmente escalable, además de ser casi
siempre permitido por los cortafuegos.
 Puede ser implementado utilizando cualquier lenguaje y ejecutado en cualquier
plataforma.
 Es posible utilizarlo mediante usuario anónimo y mediante autentificación.
 Es posible transmitirlo mediante cualquier protocolo de transporte capaz de transmitir
texto, típicamente HTTP o SMTP.
Desventajas

 Debido al uso de XML para el paso de mensajes, SOAP es considerablemente más lento
que otros middleware como CORBA ya que los datos binarios se codifican como texto.
Para contrarrestar este punto débil en el caso de XML con código binario incrustado se
desarrolló un método optimizado de transmisión de mensajes.
 Depende del WSDL (Web Services Description Language).
 Al contrario que Java, PHP o Python ciertos lenguajes no ofrecen un apoyo adecuado
para su uso ya sea a nivel de integración o de soporte IDE.