En esta primera parte hablaremos únicamente de la motivación y la mención de las herramientas de las que echaremos mano para lograrlo, dejando para una segunda parte (seguramente muy interesante) un ejemplo de la implementación mas detallado para que puedas probarlo por tu cuenta.
La motivación de llevar a cabo este ejercicio es el buscar la posibilidad de reutilizar nuestros sistemas hechos para un contenedor Web, ya sea Tomcat, Glassfish, etc. El mayor problema de portabilidad de estos sistemas es que forzosamente necesitan dicho contenedor instalado en el sistema para poderse ejecutar. Entonces es un paso un tanto tedioso si lo que queremos es que nuestro sistema lo pueda utilizar un usuario final en la comodidad de su computadora, sin importar si hay conexión a internet o que tenga los servicios de base de datos o servidor web instalados en su sistema local.
Como comentaba anteriormente, la manera más fácil de llevar a cabo esto es utilizar una aplicación de escritorio. En la actualidad, con java, además de swing tenemos herramientas como JavaFX (de las que después hablaremos seguramente) que sumamente nos facilitan la implementación de sistemas de escritorio. Pero la idea es la reutilización, y si ya tenemos un sistema Web que facilita la vida para usuarios que acceden a él por medio de la red, porque no otorgar esta posibilidad a usuarios que lo quieran utilizar de manera local.
Es aquí donde entra Jetty, que como en un post anterior lo mencionamos, es un contenedor para aplicaciones web de Java. Lo singular de ésta aplicación es la facilidad para poder integrar una aplicación web cualquiera, aún utilizando diversos frameworks (yo hasta el momento lo he utilizado con Hibernate, Struts2 y Spring sin ningún problema). Con unas simples configuraciones queda completamente funcionar como aplicación de solo lectura, y así también las aplicaciones que éste contiene.
Después de haber sorteado este problema nos enfrentamos a un nuevo reto, lograr utilizar un manejador de base de datos para nuestra aplicación, sin tener que instalar uno forzosamente. Es aquí donde entra Derby, que como también anteriormente habíamos mencionado, es un manejador de base de datos hecho en Java y que puede trabajar de manera embebida. Inicialmente había elegido HSQL, sin embargo la característica de que sea un manejador que trabaja en memoria, en el momento que lo implementé aparecieron mas contras que pros de su utilización, así que decidí utilizar Derby, sin embargo tu eres libre de utilizar el manejador que mejor te plazca.
Obviamente si nuestra intención es crear un sistema que corra en CD, la base de datos solo tendrá atribuciones de lectura, no podremos escribir en ella. Derby permite ser utilizado como base de datos de solo lectura, incluso por su integración con java, es posible agregar nuestra base de datos a un jar agregadolo simplemente al classpath.
Para concluir esta primera parte del post, quisiera agregar que estas herramientas es posible utilizarlas en conjunto para una aplicación potable. Sin embargo, es necesario aplicar ciertas configuraciones para que funcionen como solo lectura y además requieren un directorio temporal en el sistema local para su disposicion tanto Jetty como Derby (Esto es algo chafa, pero si queremos utilizarlo de la manera fácil es necesario que se usen directorios temporales), y si a esto le agregamos algún lanzador automatico para correr la aplicación en un navegador una vez iniciados los servicios, ¡listo! tenemos nuestra aplicación portable, que fácil ¿no?.
Este post continuará con el ejemplo práctico, dentro de poco. Recuerda, cualquier comentario es bienvenido... cambio y fuera...
pazzzzzzz
Aquí puedes ver la continuación de esta entrada
No hay comentarios:
Publicar un comentario