Xnoccio.com

Que recuerdos me trae aquella época en la que todo lo que necesitábamos cabía en unos cuantos diskettes.

Por suerte para algunas cosas no pasa el tiempo y yo sigo pudiendo guardar todo lo que necesito en mi escritorio de trabajo en unos cuantos Diskettes!

Ahora que ya tenemos dos implementaciones de Java EE6 Web profile preparadas para un entorno de producción (Jboss 6 y Glassfish 3.x), Java EE6 por fin puede dar el salto y convertirse en nuestro marco de referencia para todos los proyectos Java.

Hasta ahora, la mayoría de nuestros proyectos estaban siendo desarrollados sobre Tomcat, pero aunque hemos conseguido montar proyectos JEE6 en Tomcat 7 resultan demasiado complejos de mantener y producen demasiados conflictos de librerías. En los casos en los que podamos elegir, Java EE6 sobre Glassfish 3.1 será una gran opción.

Una de las grandes ventajas de Glassfish 3.x es que ha conseguido mejorar enormemente los tiempos de arranque y en general la ligereza del sistema, haciendo cosa del pasado los pesados procesos de carga asociados a los contenedores Java EE .

Normalmente la conexión JDBC utilizada por JPA queda totalmente oculta para el programador, pero en ocasiones puede ser necesario acceder ella.
Con JPA 1.0, teníamos que hacer algunos “trucos de mágia” con el Delegate para conseguirlo, pero ahora con JPA 2.0 disponemos del método unwrap que nos permite tener acceso entre otras cosas a la conexión JDBC.

    entityManager.getTransaction().begin();
    java.sql.Connection connection = entityManager.unwrap(java.sql.Connection.class);
    // TODO interactuamos con la conexión JDBC.

    entityManager.getTransaction().commit();

Este error ocurre cuando por algún motivo Weld (la implementación para CDI) no es capaz de modificar alguno de nuestros beans para inyectarle comportamiento.

En la práctica la solución a este problema es muy sencilla, es suficiente con revisar la clase (o la jerarquia de clases afectada) buscando algún método, atributo o clase interna marcada como final. Ya que si cualquiera de nuestros métodos está marcado como final la “mágia” CDI no podrá modificar nuestra clase.

Un motivo mas para convencer a los responsables de calidad de lo absurdo que resultan muchas de las reglas de calidad de código, como en este caso la reglas de validación de código “Design For Extension” que obliga a que todos los métodos no preparados para ser extendidos sean finales.

Los identificadores para entidades JPA (@Id mapeados como Primary Keys) pueden ser identificadores naturales con algún tipo de significado para la aplicación (NIF, email, etc…) o generados por el sistema y automáticamente asignados al objeto (normalmente utilizando la anotación @GeneratedValue).
Hasta aquí nada nuevo, pero ahora vamos a repasar las diferentes estratégias disponibles:

Secuencia basada en TABLA
En esta estrategia hacemos uso de una tabla auxiliar con la que gestionar los identificadores secuenciales. En la tabla aparecerá una nueva fila por cada objeto de secuencia y cada ver que se necesite un nuevo identificador se incrementará la secuenca almacenada en la tabla y asignará dicho identificador.
Este mecanismo es uno de los más portables y es recomendable en casos de que deseemos maximizar la portabilidad de nuestra aplicación.


@Id
@GeneratedValue(strategy = GenerationType.TABLE)
public Long id;


En cuanto a rendimiento, esta solución ofrece un buen rendimiento ya que permite reservar grupos de identificadores de forma que se minimicen los accesos a dicha tabla y el comportamiento es muy bueno ya que permite conocer los identificadores sin necesidad de realizar el commit.
El único problema que plantea es que en determinadas ocasiones puede causar bloqueos. En concreto en las situaciones en las que el propio acceso a la tabla de secuencias se realice de forma transaccional y podamos tener otros procesos a su vez consumiendo dicha tabla. Por este motivo esta solución no es recomendable a no ser que se utilicen conexiones no-JTA para el acceso a la tabla de secuencias.

Identit

Esta estratégia de generación hace uso de un tipo de columna especial IDENTITY que está disponile en la mayoría de las bases de datos (desgraciadamente no está disponible en ORACLE).

Respecto a la portabilidad, este método de generación es portable ya a pesar de no estar disponible en Oracle puede ser facilmente simulado mediante trigers. Ofreciendo de una forma muy sencilla su potabilidad en el resto de bases de datos.
A pesar de ser un mecanismo muy utilizado, el principal problema de este mecanismo es su que no resulta nada eficiente, ya que dado que es la base de datos la que se encarga de autogenerar el valor, necesitaremos hacer un segundo acceso (en lectura) para conocer el identificador asignado. Al no poder realizar pre reserva de identificadores, este método es muy ineficiente y en general no recomendable.

Objeto de Secuencia
En este caso se hace uso de un tipo de recurso específico de las base de datos dedicado a la generación de secuencias. El principal problema que plantéa este método es que no está disponible en todas las bases de datos por lo que el código puede puede resultar no portable.
En cuento a rendimiento, ofrece una solución optima ya que permite definir bloques de identificadores reservados, de forma que se minimicen los accesos a la secuencia.


@Id
@GeneratedValue(strategy = GenerationType.SEQUENCE)
public Long id;


Aunque ya contábamos con soporte para .NET, Java y PHP, ha sido necesaria la implementación de un cliente nativo para c++ para facilitar su integración en un importante proyecto del sector bancario.

Aunque quedan muchos detalles por pulir, ya está disponible la primera beta del API nativa para c++ en http://code.google.com/p/viafirma-client-cpp/

A continuación os mostramos un ejemplo de código que realiza una firma de un documento desde c++.

                //************************
                // Configuration
                //**************************
                std::string urlViafirma("http://services.viafirma.com/viafirma");

                // create instance of Viafirma client (dont share between threads)
                viafirmaClient v(urlViafirma);

                // Call to server
                result=v.signByServer(nameFile,dataToSign,dataSize,alias,password,
                           TYPE_FILE_BINARRY,TYPE_FORMAT_SIGN_BINARRY);
                std::cout << "TEST Sign method. Id sign:"<<result;
                std::cout<<"\nYou can see the verification info in:\n "<<urlViafirma<<"/v/"+result;

                //***************
                // get signed Document (CMD/PKCS7 format)
                //***************

                std::string idSign=result;
                SignedDocument info=v.getSignedDocument(idSign);
                // Signed Document Data: CMD/PKCS7 data: info.data;
                std::cout<<"\n id:"<<info.id;
                std::cout<<"\n name Document:"<<info.name;
                std::cout<<"\n typeFile:"<<info.typeFile;
                std::cout<<"\n Type Format Sign:"<<info.typeFormatSign;
                std::cout<<"\n Signed Document size:"<<info.data;
                std::cout<<"\n Signed Document size:"<<sizeof(info.data);

Instalación del driver
Descargamos el driver JDBC desde http://jdbc.postgresql.org y lo copiaremos al directorio glassfish/lib o si preferimos utilizarlo unicamente en uno de los dominios lo copiaremos en glassfish/domains/domain1/lib/ext

Configuración del Datasource

Una vez reiniciado el servidor, accedemos a la consola de administración y seleccionamos crear un nuevo pool de conexiones (Resources/JDBC/Connection Pools), indicando el nombre del pool y el tipo de conexión.

Configuramos los parámetros de conexión a la base de datos.

Para terminar comprobamos que la conexión a la base de datos puede realizarse intentando un ping.

Configuración del recurso

Una vez tengamos creado el pool de conexiones y hayamos comprobado que la configuración es correcta, definimos un recurso datasource que podrá ser consumido por nuestras aplicaciones mediante JNDI.

Uso del datasource

Para ello solo tendremos que indicar en nuestro persistence.xml el nombre JDNI de recurso, en este caso jdbc/default.

<?xml version="1.0" encoding="UTF-8"?>
<persistence version="2.0" xmlns="http://java.sun.com/xml/ns/persistence" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://java.sun.com/xml/ns/persistence http://java.sun.com/xml/ns/persistence/persistence_2_0.xsd">
    <persistence-unit name="default" transaction-type="JTA">
        <jta-data-source>jdbc/default</jta-data-source>
    </persistence-unit>
</persistence>

Las grandes deficiencias que hasta ahora tenía la plataforma J2EE/JEE han hecho que históricamente fuese imprescindible utilizar un framework web del estilo de Struts, Seam o Spring para realizar una aplicación JEE. Esta situación hacía que la estandarización del desarrollo de software dentro de una organización fuese muy compleja e incluso improductiva, pero ahora la situación se ha vuelto un poco más clara y manejable gracias a la definición de JEE6.

Por primera vez JEE ofrece un framework “real” con injección de dependencias, motor de plantillas, seguridad, persistencia, cache, etc…
A modo de ejemplo, ya no necesitamos iBatis o Hibernate (JPA 2.0 nos proporciona un acceso a datos consistente), ya no necesitamos facelets (ahora forma parte del estandar JSF 2.0), ya no necesitamos Spring IoC o Google Guice (ahora la inyección forma parte del estandar con CDI) y en general da soluciones a la mayoría de los problemas que antes requerían de algún truco o framework externo.

En definitiva, podremos decir que nuestro framework es JEE 6 en lugar de Spring o Seam. Y no se trata de dejar de utilizar Seam o Spring, sino de poder utilizarlos como un añadido, apoyando  el desarrollo sobre JEE6. En este sentido hemos reescrito el propio “Framework Viavansi” para que pase a ser una pieza más sobre JEE6.

Por supuesto siempre existirán caminos alternativos totalmente válidos como Spring, pero ahora ya disponemos de un “camino estandar” que debería ayudarnos si nuestro objetivo es la homogenización de los desarrollos en una organización.

Por nuestra parte llevamos bastante tiempo realizando pruebas con JEE6 Web profile  y estamos listos para empezar utilizarlo en todos nuestros nuevos proyectos a principios de 2011 (Si los clientes nos dejan :p).

En el espacio temático “Hablamos de…” de Cibersur.tv, esta semana hablan de la Firma Electrónica y sus ventajas para comunicarnos con la Administración Pública.

Para ello contaron con la colaboración de Viafirma en este vídeo que os invitamos a ver.

Quizás también te interese conocer nuestro Framework perfecto o como saber cuando una tecnología está desfasada.

Nota: Para los que no capten la sutil diferencia, pueden consultar los originales en Amazon: Cryptography with Java y J2EE Developement without EJB.