Download PRESENTACIÓN DE JDEVELOPER

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
PresentacionRemoto).
IP_Servidor.
Compilar
y
ejecutar
la
presentación
(la
clase
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.class
a
C:\LabRMI\classes\LabRMI\esconderStub\EntradaSistemaBDRemoto_Stub.cla
para 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/~alfredo
que es la URL donde se han dejado disponibles tanto la clase stub como la interfaz
Página 5
PRESENTACIÓN DE JDEVELOPER
que 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