Codecriticon

Frameworks de persistencia.Diferencias (I)

2011-10-19T14:28:00.006+02:00

Existen varios frameworks de persistencia como Hibernate, Ibatis, OpenJPA, etc... pero hoy voy a tratar las principales direfencias entre los dos primeros.

Antes de nada aclarar que un framework de persistencia es un marco de trabajo que se situa entre la logica de negocio y la capa de base de datos, abstrayendo uno del otro.

Comencemos por Hibernate.

Hibernate es una herramienta ORM que facilita el mapeo de los atributos de una base de datos relacional con el modelo de datos de la aplicación.

Este mapeo se hace mediante archivos XML o anotaciones en los beans.

Tambien ofrece la posibilidad de utilizar un lenguaje de consulta de datos HQL (Hibernate Query Lenguage).

Por su parte, Ibatis , asocia los beans del modelo de la aplicación con sentencias SQL contenidos en ficheros XML.

Veamos sus diferencias

Entre sus diferencias principales destaca que Hibernate es ORM e Ibatis no lo es, basicamente por que Ibatis no hace el mapeo directo de los atributos de la base de datos con los beans del modelo de datos e Hibernate es plenamente capaz de hacerlo. Ibatis necesita que hagamos una sentencia SQL para la relacion entre ambas capas.

Debido a esto mismo, Ibatis genera menos problemas de funcionamiento o desarrollo ya que siempre sabes que es lo que se está lanzando a la base de datos.

Es cierto que Hibernate facilita el desarrollo al no tener por que tener conocimiento alguno acerca de SQL, pero el no conocer lo que se hace de una manera tan clara como en Ibatis, lo desaconseja para desarrollos en los que la definición del modelo de datos está ya definido o si las relaciones en el modelo de datos van a ser complejas.

Otra diferencia, en este caso, mas positiva para Hibernate es que al utilizar su propio lenguage de consulta de datos, lo convierte en multimotor de base de datos.

Ibatis por su parte, soporta el cacheado de consultas incluso en distribuido para entornos con contenedores en cluster.

Por otro lado Ibatis consta con soporte para procedimientos almacenados e Hibernate solo a partir de la version 3.

En definitiva, son cosas parecidas, con un resultado similar, sin embargo, Hibernate podemos decir que sigue mas orientado a la filosofía basica de los frameworks, ya que nos separa mas esas capas permitiendo que se encargue el mismo de hacer las consultas e Ibatis hace que tengas que "definir" tu mismo el enlace, esto hace que se tenga mucho mas control sobre lo que estamos haciendo, pero nos separa de esa abstraccion de los framworks MVC.

<\O,_,O/>

La Nube y lo cerca que nos queda.

2011-10-19T10:30:00.002+02:00

Cuántas veces hemos hablar de este concepto relativamente nuevo y cuantas de nosotros entendemos la nube como una vuelta de turca a lo que ya hacíamos en la web 2.0. Una “nueva” forma de trabajar, un nuevo concepto para el desarrollo, la productividad, ocio y relaciones por Internet. Pero cuánto hay de verdad en el apelativo “nuevo”. Presentando una serie de servicios “en la nube” veremos cuánto hay de cierto en esta aseveración.

Las ventajas del concepto “en la nube” son de todos conocidas y evidentes a cualquiera. Como mas importante sobre todas las demás, cabe destacar la portabilidad de los datos. Esa posibilidad de recupera cualquier información desde prácticamente cualquier maquina, ordenadores públicos, teléfonos móviles, tablet, TV, etc…. , evidentemente hay otras ventajas. A citar entre ellas, la liberación de espacio en nuestro ordenadores, la facilitación para trabajar de forma colaborativa. Evidentemente hay una serie de desventajas o por lo menos una serie de dudas que siempre nos rondan cuando utilizamos estos servicios. La más destacable es la privacidad. ¿Cuánto de nuestra información está segura en la nube?

Correos Electrónicos

De todas las funcionalidades que nuestros ordenadores pueden realizar, posiblemente la que más importancia tenga en todos los ámbitos (laboral, ocio, social…) sea el correo electrónico y en este área “la nube” tiene un extenso camino ya recorrido. Servicios como Windows Live Hotmail, Yahoo! Mail, Gmail... son veteranos, con años de vida, mejora y aumento de capacidad. Con este concepto las empresas responsables de estos servicios han dado en el clavo. La cantidad de correos que podemos recibir, la gestión de estos correos, la sincronizad que necesitamos dado el alto número de dispositivos que tenemos y la facilidad para acceder, sin configurar engorrosas cuentas, a todo nuestro correo. Hacen de este servicio algo, hoy en día, imprescindible.

Gestión de archivos.

La gestión de nuestros documentos es, de una forma subyacente, una función básica en nuestra vida informática. Ordenados o desordenados guardamos mucha información en nuestras maquinas, la compartimos, colaboramos en su creación y edición. Era necesario y el concepto en la nube ha cumplido con lo prometido así han surgido algunos servicios (Droxbop) que nos permiten compartir documentos de forma sencilla e intuitiva, hasta llegar a la utilización de estos servicios como algo más dentro de nuestras maquinas en forma de carpeta sincronizada o cualquier otra forma, un servicio que nos proporciona la portabilidad de los documentos que nos interesan.

Vida Social y Comunicaciones.

Debemos rendirnos a la evidencia, pocos son los que resisten sin una o todos las redes sociales (Facebook, Twitter,…). Las ventajas son incuestionables en cuanto a muchas aéreas. Difusión más rápida, comunicación instantánea,… es simplemente un apartado mas de nuestra vida, algo que mirar después de leer tus correos. Si posiblemente estas redes sociales se han centrado más en la vida personal de los usuarios, aunque no faltan las redes sociales laborales (Linkedin, etc…), no ocurre asi con servicios de mensajería instantánea. Conocidos servicios de mensajería (Google Talk, Skype,…) son utilizados a partes iguales por empresas y particulares, todo ello “en la nube”, sin problemas de espacio, servidores o configuraciones engorrosas.

Otros servicios.

Existen otra gran cantidad de servicios que se centran en otras aéreas de suma importancia y así gestionan documentos, agenda, calendario, multimedia, juegos, etc… y muchos de ellos son referencia para todos (Spotify, iTunes Match, Google Music,….). El mayor auge y a la vez la mayor de los éxitos es la aparición de los “market”. Estos servicios de venta de aplicaciones a sin licencias simples y los precios excesivos, nos permiten tener mucha más información a dos click.

El futuro

Google lo tiene claro o esos nos gustaría pensar. Chrome OS el sistema operativo en la red es su apuesta, en cambio otras empresas siguen confiando en sus sistemas operativos locales, aligerándolos y haciéndolos mas rápidos moviendo sus aplicaciones a la nube.

Ejecutable con Maven (II)

2011-10-18T16:33:00.000+02:00

La continuación al post anterior se centra en la formación de una estructura de archivos, que contendrá el archivo empaquetado (.jar) y una carpeta con las librerías necesarias para el proyecto. Este proceso es más laborioso en una primera instancia, porque debemos configurar los plugin de maven para hacer diferentes procesos.

Empaquetar un ejecutable con las librerías exterior.

Generar un jar con el manifiesto necesario; esto es, que indique la clase con el punto de entrada main y las dependencias y obtener todos los jars de las dependencias, directas y transitivas, en un directorio de salida aparte (lib, por ejemplo).

Por lo tanto teniendo generado el proyecto generado, debemos asumir que están referenciadas todas las dependencias del proyecto y creado el punto de entrada de la aplicación y en ese caso incluiremos en el archivo pom.xml el siguiente código:

<properties>
<install-dir>${build.directory}</install-dir>
</properties>

Vamos lo primero a identificar con esta orden la carpeta donde se compilar el ejecutable, simplemente por generar todos los archivos en una carpeta conjunta y con cierto orden.

<artifactId>maven-jar-plugin</artifactId>
<version>2.2</version>
<configuration>
<archive>
<manifest>
<mainClass>com.ClaseMain</mainClass>
<addClasspath>true</addClasspath>
<classpathPrefix>lib</classpathPrefix>
</manifest>
</archive>
</configuration>
</plugin>

El primer plugin lo configuramos para que genere el ejecutable, con su punto de entra y le indicamos que las librerías se encontraran en la carpeta “lib”, este valor, como otros se puede parametrizar en el tag properties.

<artifactid>maven-dependency-plugin</artifactid>
<version>2.0</version>
<executions>
<execution>
<id>copy-dependencies</id>
<phase>install</phase>
<goals>
<goal>copy-dependencies</goal>
</goals>
<configuration>
<outputdirectory>${install-dir}/${artifactId}/lib</outputdirectory>
<overwritereleases>false</overwritereleases>
<overwritesnapshots>false</overwritesnapshots>
<overwriteifnewer>true</overwriteifnewer>
</configuration>
</execution>
</executions>
</plugin>

En el segundo plugin, vamos a realizar un install con una configuración específica indicándole que las dependencias deben guardarse en la ruta indicada. Lanzaremos este proceso, utilizado el siguiente comando.

mvn install:install

Esto generara una carpeta con el nombre de la aplicación y dentro de ella el ejecutable y una carpeta “lib” con los archivos/librerías de la aplicación, solo queda copiar estos dos elementos y lanzar la aplicación.

Como empaquetar GWT en un WAR

2011-10-18T14:35:00.024+02:00

Google Web Toolkit, es un framework de desarrollo web caracterizado por funcionar sin cambios en el codigo en todos los navegadores, o eso dice su publicidad...(¬¬) .

La ultima versión del development kit esta disponible aqui, por si quieres actualizarte a la última versión disponible, aunque lo más habitual para comenzar es descargar el plugin para utilizarlo en el IDE Eclipse (Eclipse Plugin+GWTSdk).

Veamos como podemos empaquetar nuestro proyecto en un simple .WAR

Una vez generemos nuestro proyecto GWT, para esta entrada me he servido del propio ejemplo que se nos genera al crear un nuevo Web Application Project con Eclipse

Como bien sabréis, lo que hace Google con nuestros javas de nuestro proyecto es generar numerosos documentos HTML y JS.

Es cierto que si queremos dejar la estructura generada tal cual en nuestro servidor de aplicaciones, funcionará sin problemas, aunque si vais a tener mas de un proyecto, a mi gusto, queda mucho mas limpio si lo empaquetamos dentro de un .war, por ejemplo.

Y como muchos os habreis dado cuenta, si pinchamos encima de nuestro proyecto GWT e intentamos exportarlo como .war, no nos encontrara el proyecto.

Desconozco si se puede llegar a hacer esto mismo modificando algun parametro del web.xml o quizas añadiendo algun otro documento, es posible que existan más maneras de hacerlo, yo voy a mostrar una bastante sencilla.

La idea es empaquetar la parte de los javas como si fueran un .JAR, asi conseguiremos una libreria que añadiremos dentro del .WAR, el cual contendrá las clases generadas de nuestro proyecto.

Recordar empaquetar en el .JAR solamente lo que exista en el src del proyecto.

Una vez hayamos generado el .JAR, lo dejaremos dentro de la carpeta /war/WEB-INF/lib

y lo añadiremos a nuestro buildPath.

A continuación crearemos un antFile para que nos genere el .WAR

Este antFile, lo añadiremos a nuestro proyecto y ejecutaremos usando boton derecho sobre el xml que acabamos de crear, Run as -->Ant Build.

Asi conseguimos un .WAR con nuestro proyecto GWT.

<\O,_,O/>

Ejecutable con Maven (I)

2011-10-18T14:33:00.000+02:00

La generación de un paquete java ejecutable conlleva en muchos casos la utilización de paquetes. La diferencia entre radica en la forma de ordenar estas paquetes o librerías.

Queremos desempaquetar estos paquetes dentro del ejecutable y tener todas las clases disponibles dentro de un solo archivo, que nos permite portarlo a cualquier entorno, de una forma sencilla o por el contrario queremos tener las librerías ordenadas en una carpeta aparte y de esta forma tener más control sobre el proyecto.

Evidentemente la elección queda del lado del desarrollador, pero vamos a disgregar las dos formas de hacerlo utilizado la potente herramienta de gestión de proyectos maven.

Empaquetar un ejecutable con las librerías en su interior.

Teniendo generado el proyecto generado, debemos asumir que están referenciadas todas las dependencias del proyecto y creado el punto de entrada de la aplicación y en ese caso incluiremos en el archivo pom.xml el siguiente código:

<plugin>
 <groupId>org.apache.maven.plugins</groupId>
 <artifactId>maven-assembly-plugin</artifactId>
 <configuration>
  <archive>
   <manifest>
    <mainClass>myPackage.MyMainClass</mainClass>
   </manifest>
  </archive>
  <descriptorRefs>
   <descriptorRef>jar-with-dependencies</descriptorRef>
  </descriptorRefs>
 </configuration>
</plugin>

Para empaquetar el proyecto debemos ejecutar el comando el comando assembly

mvn assembly:assembly

Esto generara dos archivos empaquetados uno de ellos definido con las dependencias, solo nos queda ejecutar ese archivo y comprobar que la aplicación funciona correctamente.

Java 7 una evolución lógica

2011-10-17T15:05:00.000+02:00

El pasado mes de julio se publico después de 4 años desde su última actualización la nueva versión de Java. Esta versión no solo se destina a depurar una serie de bug, sino a mejoras y cambios que generan una nueva revisión del antiguo, pero no extinto lenguaje de programación.

Java 7, como ya he comentado no es solo una solución a los errores de otras versiones. Incluso me atrevería a decir que es una versión para alcanzar los nuevos estándares y así poder gestionar los nuevos de recursos que se disponen a día de hoy. Siendo así, Oracle ha incluido nueva API para el sistema de archivos y un nuevo enfoque para el trabajo con varios núcleos. Además en esta versión se permite utilizar otros lenguajes, mejor gestión de recursos, más compatibilidades con los estándares y otras funcionalidades.

Algunos de las implementaciones, mejoras o cambios que ha sufrido este lenguaje pueden resultar simples evoluciones que hace años este lenguaje debería haber ofrecido pero eso no cambia su importancia. Es el ejemplo del proyecto Coin que simplifica el lenguaje de tareas que se realizan diariamente. Entre estas mejoras tenemos la posibilidad de hacer un “switch” con tipos String, gestionar recursos automáticamente, simplificar el uso de lista de parámetros o mejorar la gestión de excepciones.

Oracle no ha cumplido el cupo de todos los programadores, posiblemente porque el numero de detractores de otras ideas es alto y necesitan más tiempo para limar los últimos detalles, así pues tendremos que esperar al JSE8 para ver otras mejoras, como el proyecto Lambda o, dicho de otro modo, utilización de clousures.

Personalmente voy a ponerme manos a la obra a “trastear” la nueva actualización.