UNIVERSIDAD COOPERATIVA DE COLOMBIA

TALLER RECUPERACION DE NOTAS – SEMINARIO REGIONAL II

Presentado por:

Omar Dario Nieto Suarez cód. 324066

UNIVERSIDAD COOPERATIVA DE COLOMBIA

FACULTAD DE INGENIERÍA
INGENIERIA DE SISTEMAS
MARZO 13 - 2018
BOGOTÁ D.C
UNIVERSIDAD COOPERATIVA DE COLOMBIA

TALLER III – SEMINARIO REGIONAL II

Presentado por:

Omar Darío Nieto Suarez

Presentado al Ingeniero:
José Vicente Palacio Hernández

UNIVERSIDAD COOPERATIVA DE COLOMBIA

FACULTAD DE INGENIERÍA
INGENIERIA DE SISTEMAS
Marzo13 - 2018
BOGOTÁ D.C
UNIVERSIDAD COOPERATIVA DE COLOMBIA

INTRODUCCION

Es en este contexto que aparece el concepto de "Sistemas Distribuidos" que se ha

popularizado tanto en la actualidad y que tiene como ámbito de estudio las redes
como, por ejemplo: Internet, redes de teléfonos móviles, redes corporativas, redes
de empresas, etc.

En consecuencia, el presente trabajo que lleva el título de "Sistemas Distribuidos",

tiene como principal objetivo: "describir panorámicamente los aspectos relevantes
que están involucrados en los Sistemas Distribuidos".
UNIVERSIDAD COOPERATIVA DE COLOMBIA

Interfaces

El uso de interfaces remotas proporciona una serie de ventajas, como son: las
implementaciones de los métodos no son visibles por los clientes y no hace falta
comunicar a los clientes cambios realizados en las implementaciones de los métodos.

Es común hablar de RMI como un middleware, en el sentido que se comporta como un

software que separa las comunicaciones entre clientes y servidores de los protocolos de
red y los mecanismos de comunicación entre procesos.

Comunicación entre objetos distribuidos

modelo de objetos

las propiedades de objetos en general, en un lenguaje de programación específico, la

tecnología, la notación y la metodología que los usa. Por ejemplo, el modelo de objetos
Java, el modelo de objetos COM, o el modelo de objetos de OMT. Tales modelos de
objetos por lo general se definen usando conceptos como clase, mensaje, herencia,
polimorfismo y encapsulación. Hay una extensa literatura sobre modelos de objetos
formalizados como un subconjunto de la semántica formal de los lenguajes de
programación.

1. objetos distribuidos
2. modelo de objetos distribuidos

Definición:
En los sistemas Cliente/Servidor, un objeto distribuido es aquel que está gestionado por
un servidor y sus clientes invocan sus métodos utilizando un "método de invocación
remota". El cliente invoca el método mediante un mensaje al servidor que gestiona el
objeto, se ejecuta el método del objeto en el servidor y el resultado se devuelve al cliente
en otro mensaje.
Tecnologías orientadas a los objetos distribuidos:
Las tres tecnologías importantes y más usadas en este ámbito son:
1. RMI.- Remoto Invocation Method.- Fue el primer fremework 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. Esta tecnología está
asociada al lenguaje de programación Java, es decir, que permite la comunicación
entre objetos creados en este lenguaje.
UNIVERSIDAD COOPERATIVA DE COLOMBIA

2. DCOM.- Distributed Component Object Model.- El Modelo de Objeto Componente

Distribuido, está incluido en los sistemas operativos de Microsoft. Es un juego de
conceptos e interfaces de programa, en el cual los objetos de programa del cliente,
pueden solicitar servicios de objetos de programa servidores en otros ordenadores
dentro de una red. Esta tecnología está asociada a la plataforma de productos
Microsoft.

CORBA.- Common Object Request Broker Architecture.- Tecnología introducida por

el Grupo de Administración de Objetos OMG, creada para establecer una plataforma
para la gestión de objetos remotos independiente del lenguaje de programación.

cuestiones de diseño para RMI

Extensión de las RPC (p.ej. Sockets) para un entorno orientado a objetos  Reto: que un objeto local sea capaz
de invocar un método de un objeto potencialmente remoto  Similitudes RPC vs. RMI: Programación con
interfaces Construidos sobre protocolos Request-Reply Nivel de transparencia equivalente: misma sintaxis
para invocación local y remota  Diferencias RPC vs. RMI Con RMI se pueden usar técnicas (patrones y
metodologías) orientadas a objetos para su programación Semántica de parámetros más “rica”  posibilidad
de usar OIDs como parámetros • Beneficio en el paso por referencia  invocación a través del OID remoto en
vez de enviar el objeto completo

3. Implementación de RMI
4. Compactación automática de memoria

Llamadas a un procedimiento remoto

La programación procedimental precede a la programación orientada a objetos. En la

programación procedimental, un procedimiento o función es una estructura de control
que proporciona la abstracción correspondiente a una acción. La acción de una función
se invoca a través de una llamada a función. Para permitir usar diferentes variables, una
llamada a función puede ir acompañada de una lista de datos, conocidos como
argumentos. El valor o la referencia de cada argumento se le pasa a la función, e incluso
podría determinar la acción que realiza dicha función. La llamada a procedimiento
convencional es una llamada a un procedimiento que reside en el mismo sistema que el
que la invoca, y, por tanto, se denomina llamada a procedimiento local.
UNIVERSIDAD COOPERATIVA DE COLOMBIA

En el modelo de llamada a procedimiento remoto, un proceso realiza una llamada a

procedimiento de otro proceso, que posiblemente resida en un sistema remoto. Los
datos se pasan a través de argumentos. Cuando un proceso recibe una llamada, se
ejecuta la acción codificada en el procedimiento. A continuación, se notifica la
finalización de la llamada al proceso que invoca la llamada y, si existe un valor de retorno
o salida, se le envía a este último proceso desde el proceso invocado. La Figura 7.3
muestra el paradigma RPC.

Basándose en el modelo RPC, han aparecido un gran número de interfaces de

programación de aplicaciones. Estas API permiten realizar llamadas a procedimientos
remotos utilizando una sintaxis y una semántica similar a las de las llamadas a
procedimientos locales. Para enmascarar los detalles de la comunicación entre procesos,
cada llamada a procedimiento remoto se transforma mediante una herramienta
denominada rpcgen en una llamada a procedimiento local dirigida a un módulo
software comúnmente denominado resguardo (stub) o, más formalmente, proxy. Los
mensajes que representan la llamada al procedimiento y sus argumentos se pasan a la
máquina remota a través del proxy.

En el otro extremo, un proxy recibe el mensaje y lo transforma en una llamada a

procedimiento local al procedimiento remoto.

Hay que destacar que hay que emplear un proxy a cada lado de la comunicación para
proporcionar el soporte en tiempo de ejecución necesario para la comunicación entre
procesos, llevándose a cabo el correspondiente empaquetado y desempaquetado de
datos, así como las llamadas a sockets necesarias.

A pesar de su importancia histórica, este libro no analiza en detalle RPC, por los
siguientes motivos:

•RPC, como su nombre indica, es orientado a procedimiento. Las API de RPC emplean
una sintaxis que permite realizar llamadas a procedimiento o función. Por tanto, son más
adecuadas para programas escritos en un lenguaje procedimental, tal como C. Sin
embargo, no son adecuadas para programas escritos en Java, el lenguaje orientado a
objetos adoptado en este libro.
UNIVERSIDAD COOPERATIVA DE COLOMBIA

En lugar de RPC, Java proporciona el API RMI, que es orientado a objetos y tiene una
sintaxis más accesible que RPC.Eventos y notificaciones

participantes en una notificación de eventos distribuida

Caso de estudio o ejemplo sobre

Construcción de programas clientes y servidores con Java RMI

Ejemplo completo de una aplicación con RMI

En este apartado se explicará, con un ejemplo concreto, los pasos seguidos para elaborar
una aplicación con objetos distribuidos RMI. Esta aplicación ejemplo proporcionará un
servicio que acepta peticiones de tareas concretas especificadas por parte de los clientes.
Es decir, cada cliente puede especificar la tarea que desea que el servidor le realice,
utilizando para ello el paso de objetos serializados.
UNIVERSIDAD COOPERATIVA DE COLOMBIA

Figura: Secuencia de pasos para programar aplicaciones RMI

En primer lugar, se escribe la interfaz remota del servidor, que en este caso se
llamará ejecutor. Toda interfaz remota debe declararse como public y debe extender la
interfaz java.rmi. Remote. Además, esta interfaz debe definir los métodos que serán
accesibles remotamente. Por último, cada uno de estos métodos debe manejar la
excepción java.rmi. RemoteException. La segunda interfaz necesitada para este ejemplo
define el tipo Tarea. Este tipo es utilizado como un argumento del método ejecutar del
interfaz ejecutor. Esta segunda interfaz permite definir desde el lado cliente la tarea
(Tarea) que debe realizar el servidor y será pasada dinámicamente como argumento del
método remoto. Observamos que la interfaz Tarea extiende el interfaz java.io.
Serializable. RMI utiliza el mecanismo de serialización de objetos para transportar
objetos entre máquinas virtuales. Tarea no es un objeto accesible remotamente, sino
que es enviada por el cliente como argumento al servidor. En definitiva, el
objeto ejecutor del lado servidor queda a disposición de ejecutar tareas Tarea que le
soliciten los clientes.

El código de la interfaz remota ejecutor es el siguiente:

package callback;
import java.rmi.*;
public interface ejecutor
extends Remote{
public String ejecutar(Tarea t) throws RemoteException;
}
UNIVERSIDAD COOPERATIVA DE COLOMBIA

El código de la interfaz Tarea es el siguiente:

package callback;
import java.io.Serializable;
public interface Tarea extends Serializable{
public String recado();
}

La interfaz ejecutor contiene un único método ejecutar, que recibe como

argumento un objeto de la clase Tarea, que es la interfaz definida por el cliente.
De esta forma el cliente implementa la tarea (de cálculo, por ejemplo) que desea
realice el servidor. Para ello define el método recado.

2. Se implementa la interfaz remota. La clase que la implementa debe heredar

de RemoteServer y lo habitual es hacerlo heredando de UnicastRemoteObject. El
código de la implementación ejecutor_Imp es el siguiente:
3. package callback;
4. import java.rmi.*;
5. import java.rmi.server.*;
6.
7. public class ejecutor_Imp extends UnicastRemoteObject
8. implements ejecutor {
9. protected ejecutor_Imp() throws RemoteException {
10. super();
11. }
12. public String ejecutar(Tarea t) throws RemoteException {
13. return t.recado();
14. }
15. }

Ésta es la implementación desde el lado servidor de la interfaz ejecutor. Utiliza el

constructor de la clase de la que hereda, UnicastRemoteObject y define el
método ejecutar(Tarea t), que devuelve la resolución del método recado() del
objeto Tarea que ha sido pasado como parámetro.

16. Se generan los archivos stub y skeleton a partir de la clase que implementa la
interfaz remota. Para ello se utiliza el compilador rmic. Para ejecutarlo
hacemos rmic nombre_claseo bien rmic -d directorio nombre_clase para
especificar una ubicación destino concreta.

Como resultado de esta operación se obtienen dos archivos:

UNIVERSIDAD COOPERATIVA DE COLOMBIA

1. ejecutor_Imp_Stub.class
2. ejecutor_Imp_Skel.class
17. Se inicia el servicio de registro RMI, rmiregistry. Un host que quiera exportar
referencias remotas a sus métodos de modo que los stubs puedan acceder a
ellos, debe estar ejecutando un servidor de registro RMI.

Este servicio se inicia en entornos Linux:

rmiregistry &

En entornos Windows:

start rmiregistry

La aplicación rmiregistry crea un objeto Registry, que escucha por un puerto, a la

espera de peticiones de procesos clientes que busquen objetos remotos en el
registro RMI. Cabe destacar que, cara al servidor de registro RMI, todos los
procesos actúan como clientes, tanto los servidores de objetos remotos como los
clientes. Un servidor que va a registrar sus objetos remotos debe estar en el
mismo host que ejecuta el servidor de registro RMI.

18. Se inicia un proceso servidor y se registra en el rmiregistry. Una vez compilada y

ejecutada, queda registrada.

El código para la implementación del servidor es el siguiente:

package callback;
import java.rmi.*;

public class servidor {

private servidor(){
try{
if (System.getSecurityManager()==null)
System.setSecurityManager(new RMISecurityManager());
ejecutor imp=new ejecutor_Imp();
Naming.rebind("rmi://192.168.2.2/Motor_Computo",imp);
}catch(Exception e){
System.out.println("Error: "+e.getMessage());
e.printStackTrace();
}
}
UNIVERSIDAD COOPERATIVA DE COLOMBIA

public static void main(String args[]){

System.out.println("Levantando el servidor...");
servidor server=new servidor();
}
}

El servidor, en primer lugar, instala un gestor de seguridad. A continuación crea

un objeto de la clase que implementa la interfaz remota y lo publica.

En el ejemplo que nos ocupa estamos suponiendo que las clases necesarias
residen en las máquinas implicadas, por lo que no sería necesario el uso de un
gestor de seguridad.

Se escribe la clase cliente. En esta parte se incluye la implementación de la

interfaz Tarea vista previamente, que utilizará el cliente para solicitar la ejecución
de una tarea determinada.

El código de la clase que implementa la interfaz Tarea es el siguiente:

package callback;
public class tarea_Imp implements Tarea{
public String recado() {
return "Hello World";
}
}

El código para la implementación del cliente es el siguiente:

package callback;
import java.rmi.*;

public class cliente {

public static void main(String args[]){
try{
if (System.getSecurityManager()==null)
System.setSecurityManager(new RMISecurityManager());
ejecutor ej=(ejecutor)
Naming.lookup("rmi://192.168.2.2/Motor_Computo");
Tarea tarea=new tarea_Imp();
String respuesta=ej.ejecutar(tarea);
UNIVERSIDAD COOPERATIVA DE COLOMBIA

System.out.println(respuesta);
}catch(Exception e){
System.out.println("Error: "+e.getMessage());
}
}
}

La clase Tarea_Imp implementa la interfaz Tarea, vista anteriormente. En este

caso, define el método recado() como un simple "Hello World". Es decir, la tarea
que el cliente quiere que realice el servidor es devolverle la frase "Hello World".

Al igual que en el lado servidor, el cliente empieza creando e instalando un gestor

de seguridad. A continuación localiza el objeto remoto y crea un objeto de la
clase Tarea_Imppara solicitar al servidor que ejecute esa tarea.

Se compila la clase cliente

Se inicia un proceso cliente.

Figura: Proceso servidor en ejecución

Figura: Proceso cliente en ejecución

UNIVERSIDAD COOPERATIVA DE COLOMBIA

WEBGRAFIA

https://es.slideshare.net/Tensor/modelos-de-sistemas-distribuidos-62743871

http://www.kybele.etsii.urjc.es/docencia/SD_GII_V/2011-2012/Material/[SSDD-2011-
12]Tema%204.Soluciones%20de%20SSDD.pdf