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.  

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

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 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

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

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.

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/stubs/

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 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