PRESENTACIÓN DE JDEVELOPER

SOLUCIÓN: LABORATORIO ARQUITECTURAS SOFTWARE DE

VARIOS NIVELES EN JAVA

Arquitectura física en 3 niveles usando java rmi

Tareas a realizar

1) Descomprimir en C:\ el fichero LabRMI.zip, el cual contiene las clases anteriores, la BD de passwords, un fichero con la política de seguridad y un fichero .bat que permite generar los STUBS y los SKELETON, de tal manera que el contenido del directorio C:\LabRMI\ sea:

 

 2)      Crear un workspace nuevo (LabRMI.jws), un proyecto nuevo (LabRMI.jpr) y poner las propiedades del proyecto que se muestran a continuación. Se pone como “Java Source Path” el C:\ y como “Default Package” el LabRMI debido a que los tres ficheros Java están definidos en el paquete LabRMI y se encuentran físicamente en el directorio C:\LabRMI\. Así se es coherente con el comportamiento de JDeveloper, que siempre que crea una nueva clase la deja en el directorio definido en “Java Source Path”, subdirectorio/s con nombre igual/es al paquete por defecto. Añadir las clases EntradaSistemaBDRemoto.java, PresentacionRemoto.java e InterfaceRemotoLogicaNegocio.java al proyecto.  

Página 1

PRESENTACIÓN DE JDEVELOPER

3) Añadir un método main al cliente RMI (PresentacionRemoto.java) para que cree la presentación, esto es, la interfaz gráfica de usuario, obtenga la lógica del negocio y se la asigne al objeto de presentación. 

public static void main(String[] args){ // En PresentacionRemoto.java    PresentacionRemoto p = new PresentacionRemoto();    try{      p.setLogicaNegocio((InterfaceRemotoLogicaNegocio)                       Naming.lookup("rmi://localhost:1099/entradaSistema"));    } catch(Exception e)         {System.out.println("Error al conseguir la lógica del negocio: "            

                      +e.toString());}    p.setVisible(true); }

4) Compilar el proyecto para obtener el servidor RMI en

   C:\LabRMI\classes\LabRMI\EntradaSistemaBDRemoto.class

5) Modificar y ejecutar el fichero de comandos crearStubs.bat para que cree el STUB y el SKELETON correspondiente al servidor RMI y los deje en

   C:\LabRMI\classes\LabRMI\EntradaSistemaBDRemoto_Stub.class y    C:\LabRMI\classes\LabRMI\EntradaSistemaBDRemoto_Skel.class

Página 2

PRESENTACIÓN DE JDEVELOPER

   C:\LabRMI\classes\LabRMI\EntradaSistemaBDRemoto_Skel.class

Se supone que el JDeveloper 9i está instalado en C:\Archivos de programa\Oracle\JDev9i 

NOTA: ES IMPORTANTE PONER LOS NOMBRES DE FICHERO ENTRE COMILLAS SI CONTIENEN ESPACIOS EN BLANCO.

Ejemplo: “C:\Archivos de programa\Oracle\JDev9i\jdk1.3\bin\rmic”

COMPROBAR, QUE EFECTIVAMENTE SE HAN CREADO LAS CLASES STUB Y SKELETON EN C:\LabRMI\classes\LabRMI, esto es, que existen las clases

C:\LabRMI\classes\LabRMI\EntradaSistemaBDRemoto_Stub.class y C:\LabRMI\classes\LabRMI\EntradaSistemaBDRemoto_Skel.class y

6) Configurar la opción de seguridad a pasar a la máquina virtual java cuando se ejecuten tanto el cliente como el servidor RMI.

NOTA: Si en el nombre completo del fichero hubiera espacios en blanco, habría que ponerlo entre comillas. Tampoco hay que dejar espacios en blanco ni entre la opción D y

Página 3

PRESENTACIÓN DE JDEVELOPER

ponerlo entre comillas. Tampoco hay que dejar espacios en blanco ni entre la opción D y java.security.policy, ni entre el = y el nombre del fichero. Ejemplo:

   -Djava.security.policy=“C\Archivos de programa\LabRMI\java.policy”

8) Configurar la fuente de datos ODBC dándole el nombre BDPasswLab3N y asociándola a la base de datos C:\LabRMI\passwords.mdb

9) Ejecutar el servidor RMI (que a su vez ejecuta el RMIREGISTRY), esto es, ejecutar la clase EntradaSistemaBDRemoto

10) Ejecutar el cliente RMI, esto es, ejecutar la clase PresentacionRemoto

Página 4

PRESENTACIÓN DE JDEVELOPER

11) Ejecutar la aplicación desplegada en 3 niveles físicos:

Modificar la fuente de datos ODBC con nombre “BDPasswLab3N” para que esté conectada con la base de datos “passwords.mdb” que se encuentra en el servidor docente JIPL00, recurso llamado DOCENCIA y directorio ISO Lanzar la lógica del negocio en vuestro ordenador (Run EntradaSistemaBDRemoto) Encontrar el nombre o número IP de dicho ordenador (Menú Inicio => Ejecutar=> cmd => ipconfig /all). Supongamos que es el ordenador con IP IP_Servidor En otro ordenador del laboratorio, modificar la presentación para que trabaje con la lógica del negocio que se está ejecutando en el ordenador IP_Servidor. Para ello modificar la instrucción Naming.lookup("rmi://localhost:1099/entradaSistema") y sustituir localhost por IP_Servidor. Compilar y ejecutar la presentación (la clase PresentacionRemoto).

2) Ejecutar la aplicación desplegada en 3 niveles físicos, pero donde el cliente NO tenga la clase STUB (EntradaSistemaBDRemoto_Stub) en su CLASSPATH, esto es, que la cargue de manera dinámica desde una URL.

Para ello, eliminar la clase del CLASSPATH del ordenador cliente, o bien crear un subdirectorio “esconderStub” y moverla ahí, esto es: mover la clase C:\LabRMI\classes\LabRMI\EntradaSistemaBDRemoto_Stub.classa C:\LabRMI\classes\LabRMI\esconderStub\EntradaSistemaBDRemoto_Stub.classpara que el stub no esté accesible al cliente mediante su CLASSPATH. Añadir la opción –Djava.rmi.server.codebase=http://siul02.si.ehu.es/~alfredoque es la URL donde se han dejado disponibles tanto la clase stub como la interfaz

Página 5

PRESENTACIÓN DE JDEVELOPERque es la URL donde se han dejado disponibles tanto la clase stub como la interfaz remota. Esto se hace en Project => Project Setting => Runner => Java Options

NOTA IMPORTANTE: NO OLVIDÉIS TERMINAR LA URL CON EL CARÁCTER /

Lanzar la presentación remota en el cliente y comprobar que funciona.

 NOTAS:

1.- Se puede lanzar el RMIREGISTRY desde el servidor RMI (EntradaSistemaBDRemoto) con LocateRegistry. Si se hiciera desde un intérprete de comandos, entonces habría que pasar a la máquina virtual Java, al ejecutar el servidor, la siguiente opción:

   –Djava.rmi.server.codebase=http://siul02.si.ehu.es/~alfredo/iso/stubs/

2.- Al lanzar el servidor RMI, el stub (EntradaSistemaBDRemoto_Stub)  tiene que estar disponible en su CLASSPATH. Si no, dará un error, aunque se haya definido la opción –Djava.rmi.server.codebase=http://siul02.si.ehu.es/~alfredo/iso

3.- Se puede comprobar que el único caso en el que en realidad se necesita tener creado el gestor de seguridad es en este donde se carga en el cliente la clase STUB desde una URL, y no desde su CLASSPATH. Intentad quitar la instrucción

Página 6

PRESENTACIÓN DE JDEVELOPER

no desde su CLASSPATH. Intentad quitar la instrucción System.setSecurityManager(new RMISecurityManager()) del cliente (PresentacionRemoto) y veréis que se produce un error de seguridad.

Si quitamos el gestor de seguridad en PresentacionRemoto:

Y ejecutamos PresentacionRemoto, veremos que da un error por no haber definido el gestor de seguridad:

4.- De igual modo, se puede comprobar que si se vuelve a poner el Stub en el CLASSPATH del Cliente, copiando la clase  C:\LabRMI\classes\LabRMI\esconderStub\EntradaSistemaBDRemoto_Stub.class

en C:\LabRMI\classes\LabRMI\EntradaSistemaBDRemoto_Stub.class, entonces se puede quitar la instrucción System.setSecurityManager(new RMISecurityManager()) de la clase PresentacionRemoto y funciona.

5.- También se puede comprobar que, si se quita la instrucción System.setSecurityManager(new RMISecurityManager())de la clase EntradaSistemaBDRemoto también funciona, ya que en ese caso tampoco se carga de manera dinámica una clase que no esté en el CLASSPATH.

6.- Por último, se puede comprobar que, si se define el gestor de seguridad System.setSecurityManager(new RMISecurityManager()), entonces necesariamente hay que dar los permisos a la máquina virtual Java la opción

–Djava.rmi.server.codebase=“C\LabRMI\java.policy”

 

Página 7