He implementado lo que sería la interfaz gráfica de la aplicación que se encarga de la configuración y lanzado de ProyectGr, LanzadorGr.
En este momento no tiene ninguna funcionalidad programada pero nos da una idea de cómo está organizado todo.
Antes de llegar a este punto había diseñado otra interfaz más compleja, con botones para abrir y cerrar los puertos manualmente, lanzar y parar los servicios, generar los class con rmic, etc., pero tengo una obsesión, facilidad cara al usuario (aunque sea yo mismo) en la medida de lo posible.
Esta versión (la de la imagen) pretende que todo sea automático.
Modo:
Destinado para indicar el perfil del usuario.
- Participante pasivo: no ejecutará su Gr ningún servicio, siempre actuará como cliente. No le hará falta tener los class de rmic. Ejecutará directamente jar empaquetado.
- Participante activo: su Gr ejecutará servicios remotos, podrá ser coordinador, le hará falta los class de rmic y ejecutará también jar empaquetado.
- Desarrollador: semejante al participante activo pero además podrá ejecutar tanto jar empaquetado como los class compilados del proyecto directamente. Será el único que mediante rmic generará los class de los servicios remotos y los distribuirá.
Y para no tener que identificar a los ordenadores que se encuentren conectados por su IP, una etiqueta Usuario.
Comunicaciones:
Se refiere a los puertos e IPs que se utilizan.
- GR: puerto por el que deberá escuchar ProyectGr localmente a LanzadorGr. Gestionado automáticamente buscando un puerto libre para ello.
- LC: puerto por el que escuchará a ProyectGr, también local y automático.
- OYENTE: puerto que por el que permanecerán a la escucha todos los ProyectGr para las consultas de quién es el coordinador, para los ingresos al sistema a más usuarios. Sólo el desarrollador podrá cambiar su valor.
- RMIREGISTRY: aunque por defecto este servicio funciona a través del puerto 1099, como todos los participantes activos y el desarrollador tendrán este servicio trabajando pero también serán clientes entre ellos, a cada pc se le asignará un puerto distinto. Para ello el coordinador preguntará a todos los miembros si tienen libre un puerto determinado, si todos lo tienen, lo asignará al nuevo pc. En caso contrario buscarán otro puerto.
- BASE DE DATOS: puerto por el que escucha mysql. Este valor sólo puede ser modificado por el desarrollador. También se indica su IP.
- COORDINADOR: son dos puertos, uno por el que escucha el ProyectGr remoto (o local si coincide con que el coordinador es el ProyectGr local) que esté realizando el servicio de coordinador y otro que escucha el ProyectGr local. Son gestionados automáticamente y distintos entre ordenadores. Se indicará el IP que tiene ese servicio.
Base de Datos:
Son los parámetros para poder conectarse a la base de datos de mysql: usuario y contraseña. Estos valores sólo puede modificarlos el desarrollador.
Rutas:
Las rutas de los class y jar.
- Proyecto Nedbeands: sólo para el desarrollador. Ruta hacia el proyecto que contiene toda la estructura con el código fuente, los .java, los .class y .jar.
- Jar: ruta hacia el ejecutable empaquetado.
- Destino rmic: en el caso de ser el desarrollador será la ruta donde se depositarán los archivos generados por rmic. Y en el caso de ser participante activo, ruta donde se guardarán estos archivos al ser enviados por el coordinador desde el desarrollador.
Security.Policy:
Mostrará el contenido de este fichero. La primera vez que se ejecute no existirá pero lo traerá del desarrollador y lo guardará en el directorio home del computador. Sólo el desarrollador podrá modificar su contenido. Es imprescindible para poder compartir objetos remotos.
Distribución de servicios:
Mostrará una lista de todos los servicios (y réplicas) que se estén ejecutando y en qué PC lo hace.
Ejecución de comandos:
El LanzadorGr no hará otra cosa que lanzar comandos por consola, capturará las salidas e interpretará. Usará comandos de Linux como netstat, firewall-cmd o rmic, entre otros.
Ahora mismo sólo trabajo con Fedora, cuando lo extienda a otras distribuciones haré que trabaje en función de su firewall específico o a través de iptables.
ProyectGr:
Si es el desarrollador podrá ejecutar tanto el jar empaquetado o sin empaquetar.
Es aquí cuando si se trata del desarrollador generará todos los class de rmic y los colocará en su ruta correspondiente.
Al ejecutar le pasará el parámetro de seguridad Security.Policy a java.
Y para terminar la aplicación será notificado el coordinador para que redistribuya los servicios y datos generados antes de cerrar la conexión. Después volverá a cerrar todos los puertos que ha utilizado.
Ahora que ya estoy ultimando el código de un Diccionario Genérico Distribuido usando RMI he de decir que con la versión actual de Java ya no se usa rmic. De forma automática VM genera los ficheros que necesita. Esto significa que cuando tenga que usar esta interfaz de usuario tendré que destino rmic, el seleccionar ejecutar class o jar (ya que ahora no hace falta, se lanza siempre jar), etc.
ResponderEliminar