SESIÓN 04 - APLICACIONES CON OBJETOS DISTRIBUIDOS.pptx

APLICACACIONES CON OBJETOS DISTRIBUIDOS EN JAVA

1. PROGRAMACIÓN DE COMPUTADORAS II DR. NIXON OMAR FERNANDEZ CARRIÓN

2. 1 2 SISTEMAS DISTRIBUIDOS, OBJETOS DISTRIBUIDOS, ORGANIZACIÓN, TIPOS, PROCESOS, COMUNICACIÓN: MODELO, RMI, EJEMPLO: JAVA RMI 3 SINCRONIZACIÓN, CONSISTENCIA Y REPLICACIÓN EJEMPLO MIDDLEWARE: CORBA LABORATORIO 4: USO DE OBJETOS DISTRIBUIDOS

3. Al finalizar la sesión, el estudiante comprende y desarrolla programas empleando objetos distribuidos. LOGRO DE LA SESIÓN

4. RMI

5. Definición. Remote Method Invocation . Exclusivo de Java *. Mecanismo/sistema que permite que un objeto ejecutándose en un JVM llame a métodos de otro objeto que esta en una JVM diferente. Para plataformas diferentes se necesitaría SOAP o CORBA. RMI proporciona el mecanismo para transferir información entre procesos de diferentes máquinas.

6. Estructura. Formado básicamente por 2 programas remotos: Servidor. Crea objetos remotos. Referencia a ellos. Espera por la solicitud de los clientes. Cliente. Obtiene referencia a los objetos remotos. Ejecuta sus métodos. Mecanismo general de comunicación: Localización de objetos. 2 maneras: rmiregitry o paso de objetos en parámetros o valores de retorno de funciones. Comunicación con objetos remotos. Control por parte de RMI. Transparencia para el programador del cliente. Carga de bytecodes (código intermedio). Descarga del código del objeto y transferencia de sus datos.

7. Una aplicación... Pasos en los que se observa el desarrollo de una aplicación distribuida RMI: Se inicia el servidor y registra sus objetos y métodos a invocarse en un servicio de nombramiento. Asocia un nombre con el objeto remoto. Se inicia el cliente y localiza los objetos y/o métodos a invocar de manera remota en el directorio de nombres del servidor obteniendo la referencia al objeto. El cliente invoca a los métodos remotos mediante la referencia al objeto obtenida. Espera por respuesta. Marshalling (reconocimiento) de los parámetros – Serialización. Invocación del método en el servidor. Termina la ejecución del método en el servidor y se regresa el valor de retorno serializado al cliente.

8. Esquema de funcionamiento.

9. Funcionamiento a nivel de Sockets. El servidor escucha un puerto. El servidor conoce la máquina y puerto de eschucha del servidor mediante el “ stub ”. El cliente invoca la función del stub . El stub se conecta al puerto del servidor y envía los parámetros de la siguiente manera: El cliente se conecta al puerto de escucha del servidor. El servidor acepta conexión entrante y crea un nuevo socket para gestionar esta única solicitud (… en caso de bootstraping …). El antiguo puerto de escucha permanece así en espera de más clientes. Comunicación cliente-servidor mediante el nuevo socket. Intercambio de parámetros del método mediante un protocolo. Puede ser JRMP, CORBA, SOAP. El método es ejecutado en el servidor y devuelto el valor de retorno vía stub . El stub devuelve el resultado al cliente como una llamada a método local.

10. Especificación de RMI (en Java). Interfaces, objetos y métodos remotos. Interfaces remotas: Heredan de java.rmi.Remote Lanzan excepción java.rmi.RemoteException . Objetos y métodos remotos. Heredan de java.rmi.server.UnicastRemoteObject ó Heredan de java.rmi.server.Activatable . Paso de parámetros en RMI. Paso de objetos remotos. Paso de objetos locales. Transmisión de datos.

11. Diagrama de interfaces y clases de objetos .

12. RMI Stub y Skeleton . STUB : Es una representación local EN EL CLIENTE del objeto remoto. El objeto que realiza una llamada remota invoca el método en el stub “local”. Implementa exactamente el mismo conjunto de interfaces remotas que el objeto remoto. Pasos que realiza son: Inicia una conexión con la JVM remota que contiene el objeto remoto. Escribe (serializa) y transmite los parámetros a la JVM remota. Espera los resultados de la invocación remota. Lee ( deserializa ) los valores de retorno o excepciones devueltas. Devuelve el valor al objeto que inicio la llamada. Hace uso del rmic .

13. RMI Stub y Skeleton . Skeleton : Es una representación local EN EL SERVIDOR del objeto remoto. Es responsable de enviar la llamada a la implementación del objeto remoto. Pasos que realiza son: Lee ( deserializa ) los parámetros del método remoto. Invoca al método en la implementación del objeto remoto. Escribe (serializa) y transmite el resultado. A partir del JDK 1.2 (versión de Java 2) se ha introducido un protocolo stub adicional que elimina la necesidad del uso de los “esqueletos”.

14. Registro de objetos remotos. RMIRegistry : Se ejecuta en el servidor y es un objeto remoto con un puerto conocido. Relaciona el objeto remoto con un nombre. El contacto directo se tiene con el stub proporcionado por el objeto remoto. Almacena internamente la etiqueta y el objeto stub en un hashmap . Devuelve el stub al cliente que solicito el objeto remoto. En caso de no hacer uso de este ejecutable de Java se encuentran la interfaz Registry y la clase LocateRegistry (con sus métodos createRegustry y getRegistry ).

15. Localización de objetos remotos. Se realiza utilizando la clase java.rmi.Naming . Esta clase “construye” un objeto stub y lo asocia al objeto remoto del registro. Maneja principalmente dos parámetros para la mayoria de sus métodos primordiales: cadena que nombra al objeto (URL): // host:puerto /nombre. Stub del objeto remoto. Hace uso de los siguientes métodos: bind y rebind . lookup . unbind . list .

16. Creación de una aplicación distribuida. Diseño e implementación de las componentes (interfaz, servidor, cliente). Compilar las fuentes y generar los stubs . Hacer accesibles las clases a la red. Iniciar la aplicación (registro y cliente - servidor).

17. Metas del sistema RMI en Java Proporcionar invocación remota de objetos que se encuentran en JVM’s diferentes. Integrar el modelo de objetos distribuidos en Java de forma natural. Intentar simplificar al máximo la escritura de aplicaciones distribuidas. Preservar la seguridad proporcionada por Java. Proporcionar varias semánticas para las referencias de los objetos remotos (persistentes, no persistentes y de "activación retardada" ).

18. Ejemplo programado package serverrmi ; import java . rmi .Remote ; import java . rmi . RemoteException ; public interface Persona extends Remote { public abstract String BuscarPersona ( int id ) throws RemoteException ; } Proyecto ServerRMI Interfaz: Persona.java Se crea un .JAR de solo la interfaz ( Click derecho en proyecto ServerRMI y click en Clean and Build )

19. package serverrmi ; import java . rmi . RemoteException ; import java . rmi .server. UnicastRemoteObject ; public class ImplementacionPersona extends UnicastRemoteObject implements Persona { private int id_persona ; private String nombre ; private String profesion ; public ImplementacionPersona ( int id_persona , String nombre , String profesion ) throws RemoteException { this . id_persona = id_persona ; this . nombre = nombre ; this . profesion = profesion ; } @ Override public String BuscarPersona ( int id ) throws RemoteException { String cadena = null ; if ( id == this . id_persona ) { cadena = "ID: " + this . id_persona + "\ nNombres : " + nombre + "\ nProfesion : " + profesion ; } else { cadena = "Registro no se encuentra" ; } return cadena ; } } Clase: ImplementacionPersona.java

20. Clase Principal: Server.java package serverrmi ; import java . net . MalformedURLException ; import java . rmi . registry . LocateRegistry ; import java . rmi . Naming ; import java . rmi . RemoteException ; public class Server { public static void main ( String [] args ) { try { String ip = "127.0.0.1" ; / / Cambia a la IP de tu servidor int puerto = 1099 ; / / Puerto personalizado String nombreObjeto = "Datos" ; LocateRegistry . createRegistry ( puerto ); String url = " rmi ://" + ip + ":" + puerto + "/" + nombreObjeto ; Persona p1 = new ImplementacionPersona ( 1 , "Juan Miguel" , "Ingeniero de Sistemas" ); Naming . rebind ( url , p1 ); System.out. println ( "Servidor RMI activo en " + url ); } catch ( MalformedURLException | RemoteException e ) { System.out. println ( "Error: " + e ); } } }

21. private void btn_iniciarActionPerformed ( java . awt .event. ActionEvent evt ) { try { String ip = "127.0.0.1" ; / / Cambia a la IP de tu servidor int puerto = 1099 ; / / Puerto personalizado String nombreObjeto = "Datos" ; LocateRegistry . createRegistry ( puerto ); String url = " rmi ://" + ip + ":" + puerto + "/" + nombreObjeto ; Persona p1 = new ImplementacionPersona ( 1 , "Juan Miguel" , "Ingeniero de Sistemas" ); Naming . rebind ( url , p1 ); System.out. println ( "Servidor RMI activo en " + url ); } catch ( MalformedURLException | RemoteException e ) { System.out. println ( "Error: " + e ); } } private void btn_detenerActionPerformed ( java . awt .event. ActionEvent evt ) { String ip = "127.0.0.1" ; / / Cambia a la IP de tu servidor int puerto = 1099 ; / / Puerto personalizado String nombreObjeto = "Datos" ; / / LocateRegistry . createRegistry ( puerto ); String url = " rmi ://" + ip + ":" + puerto + "/" + nombreObjeto ; try { Naming . unbind ( url ); System.out. println ( "El servidor se ha desconectado..." ); } catch ( MalformedURLException | NotBoundException | RemoteException e ) { System.out. println ( "No se ha podido cerrar la conexion " ); } } Formulario: ControlServidor.java

22. Proyecto ClienteRMI El .JAR creado se importa en el proyecto ClienteRMI , en la sección de Classpath Click derecho en el proyecto/propiedades -> Libraries

23. Clase principal: ClienteRMI.java package clientermi ; import java . net . MalformedURLException ; import java . rmi . Naming ; import java . rmi . NotBoundException ; import serverrmi . Persona ; import java . rmi . RemoteException ; public class ClienteRMI { public static void main ( String [] args ) throws NotBoundException , MalformedURLException { try { String ip = "127.0.0.1" ; / / Cambia a la IP de tu servidor int puerto = 1099 ; / / Puerto personalizado String nombreObjeto = "Datos" ; String url = " rmi ://" + ip + ":" + puerto + "/" + nombreObjeto ; Object obj = Naming . lookup ( url ); / / 1. Obtenemos el objeto remoto como Object Persona ps = ( Persona ) obj ; / / 2. Lo convertimos ( cast ) a tipo Persona System.out. println ( ps . BuscarPersona ( 1 )); } catch ( RemoteException e ) { System.out. println ( "Error: " + e ); } } }

24. Ejecución Ejecutar el archivo del servidor para que pueda escuchar las peticiones Presionar en iniciar

25. Ejecución Ejecutar el archivo el archivo Cliente Resultado:

26. Middleware CORBA CORBA ( Common Object Request Broker Architecture ) es un middleware de propósito general desarrollado por la OMG ( Object Management Group ) que permite que aplicaciones escritas en diferentes lenguajes de programación y ejecutadas en distintas plataformas puedan comunicarse e interoperar de manera transparente . Su núcleo es el ORB ( Object Request Broker ) , un intermediario que gestiona las solicitudes entre objetos distribuidos, haciendo que un programa cliente pueda invocar métodos de un objeto remoto como si fuera local.

27. Características principales Independencia de lenguaje y plataforma : CORBA define interfaces en IDL (Interface Definition Language ) , que luego se pueden mapear a lenguajes como C++, Java, Python, entre otros. Transparencia de distribución : el cliente no necesita saber dónde está el objeto ni cómo se implementa; el ORB se encarga de localizarlo, transmitir la solicitud y devolver la respuesta. Interoperabilidad : usa el protocolo estándar IIOP (Internet Inter-ORB Protocol ) para permitir que ORBs de distintos proveedores se comuniquen. Servicios CORBA (CORBA Services ) : un conjunto de componentes estándar que amplían sus capacidades, como: Naming Service (localización de objetos). Event / Notification Service (comunicación asíncrona). Transaction Service (transacciones distribuidas). Security Service (autenticación, autorización, cifrado). Fault-Tolerant CORBA (FT-CORBA) (replicación, alta disponibilidad)

28. Ejemplo sencillo Un cliente en Java necesita acceder a un servicio de gestión académica implementado en C++ que corre en otro servidor. Ambos definen la interfaz en IDL . El ORB genera los “ stubs ” (para el cliente) y los “ skeletons ” (para el servidor). El cliente invoca matricula.inscribirEstudiante (...) como si fuera local. El ORB traduce la llamada y la envía al servidor, donde se ejecuta la lógica y se devuelve la respuesta. El cliente no percibe que el servicio está en otro lenguaje ni en otra máquina . En conclusión: CORBA es un middleware que actúa como puente universal en sistemas distribuidos heterogéneos, garantizando interoperabilidad, transparencia y escalabilidad.