Etiqueta: JEE

Publicado Glassfish 3.1

28 feb 2011

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 .

Tips: Obtener la conexión JDBC de un EntityManager (en JPA 2.0)

11 feb 2011

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();

Tips: WELD-001400 Normal scoped bean is not proxyable

09 feb 2011

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.

Tipos de estrategias de generación de identificadores con JPA

06 feb 2011

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;

Por fin un JavaEE6 para dominarlos a todos

16 nov 2010

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).

Plataforma de autenticación y firma digital sobre WebLogic

18 jun 2010

La nueva versión de Viafirma, coincidiendo con su instalación en dos importantes entidades bancarias,  ofrece soporte oficial para Oracle WebLogic 11. De esta forma, junto con las plataformas ya soportadas por Viafirma (Tomcat 5, Tomcat 6, Websphere, etc…), ahora se incluye:

El proceso de instalación es muy sencillo,  por lo que siguiendo los pasos del manual de instalación de Viafirma para Weblogic podremos disponer de sus servicios de autenticación (DNIe o cualquier otro certificado digital) y firma digital (XAdES, PAdES, CMS, CAdES, facturae, firma en lotes,…) desplegados sobre Weblogic .

WebSphere 6.1 y Viafirma

12 may 2010

Aunque ya contábamos con alguna instalación “custom” de Viafirma en Websphere,   con la nueva versión de Viafirma 2.6 y coincidiendo con su instalación en una importante entidad, pasamos a ofrecer soporte oficial tanto de la plataforma como de los kit de desarrollo en IBM Websphere 6.1.

Por lo que junto con las plataforma ya soportadas por Viafirma, ahora se incluyen:

  • WebSphere 6.0 y 6.1
  • IBM Websphere e IBM Rational Application Developer
  • JVM IBM 5.
  • SO: Linux, AIX, Windows Server

Viafirma en websphere

Por otro lado cabe destacar que el proceso de instalación es realmente sencillo, por lo que siguiendo los pasos del manual de instalación de Viafirma para Websphere podremos disponer de sus servicios de autenticación y firma digital (XAdES, PAdES, CMS, CAdES, facturae, firma en lotes,…)  en complejos entornos en cluster listos para producción en un tiempo record.

Creando una aplicación web basada en OSGI con Eclipse

29 abr 2010

A continuación se describen los pasos básicos a dar para crear una aplicación web  que en lugar de ser desplegada sobre la típica pila JEE, sea desplegada como un componente más dentro de un contenedor OSGi.

Jee tradicional vs OSGi

Para ello se mostrará como construir con Eclipse un bundle OSGi que haciendo uso de Jetty nos permita correr un servlet sobre Equinox.

  • Crear el proyecto base

En primer lugar, necesitaremos crear un plugin, indicando que es de tipo OSGI (implementación Equinox).

Crear un proyecto OSGi en Eclipse

  • Definición de las dependencias

Una vez que tengamos el proyecto creado, necesitaremos declarar las dependencias que necesitará nuestro módulo para poder funcionar como un servidor de aplicaciones. Las dependencias serán como mínimo:

  • javax.servlet
  • org.eclipse.equinox.http.jetty
  • org.eclipse.equinox.http.servlet
  • org.mortbay.jetty.server
  • org.eclipse.equinox.http.registry

Dependencias Eclipse OSGI Jetty

  • Construcción del servlet de ejemplo

Una vez tengamos declaradas los módulos dependientes, Eclipse se encarga de actualizar nuestro classpath y ya podremos programar nuestro primer servlet sin problemas de compilación.

/** * Osgi Example Servlet. * */
public class HolaMundoOsgiServlet extends HttpServlet{
 protected void doGet(HttpServletRequest req, HttpServletResponse resp) throws ServletException, IOException {
        System.out.println("Petición al Servlet OSGi");
 	resp.getWriter().append("Respuesta desde un Servlet Osgi");
 }}

Como podemos ver, se trata de un servlet normal, que debería ser mapeado en el web.xml y desplegado dentro de un contenedor de servlets.

  • Activación del servlet

A diferencia del modelo tradicional (definido por la especificación JEE), la activación del servlet no requiere ningún web.xml. En su lugar, definiremos (al igual que cualquier otro servicio OSGI) un nuevo punto de extensión de nuestra aplicación. Para ello accederemos a la pestaña “Extension” y añadiremos la extensión “org.eclipse.equinox.http.registry.servlet” a nuestro módulo. Con esto le hemos indicado a OSGi que nuestro módulo hace uso del contenedor de Servlet.

Añadir extension point para definir un servicio de tipo servlet

El siguiente paso será indicar la clase que implementa el nuevo servlet y el mapeo, para ello simplemente definiremos la propiedad alias y class del nuevo servlet asociado a la extensión creada previamente.

Configurar extensiones OSGi

Con esto ya tenemos nuestra primera aplicación web OSGi.

  • Probando nuestra aplicación.

Para probar la aplicación sólo es necesario ejecutar el proyecto (Run As…>OSGi Framework) y acceder con el navegador a http://localhost:8080/exampleSi todo ha funcionado correctamente, en consola deberemos ver algo como lo siguiente:

Persistence bundle started.
Activado módulo OSGi: Ejemplo OSGI!!
Activado Servlet OSGiProviderTracker: New service detected...
ProviderTracker: Added service org.eclipse.persistence.jpa.osgi.PersistenceProviderOSGi
Petición al Servlet OSGi

Aunque aquí sólo se muestra un ejemplo muy básico, OSGI ya nos ha demostrado ser de mucha utilidad en proyectos reales muy complejos.

Java / JEE : Firma digital y autenticación con Viafirma (I)

29 abr 2009

Este artículo pretende ser una guía rápida qué explique cómo realizar una operación de autenticación con Viafirma, de cara a obtener los datos del certificado digital del usuario.

Aunque Viafirma ofrece todos sus servicios mediante métodos estándar (Servicios Web y OpenID), también disponemos  de un cliente para Java que permite de una forma muy sencilla integrar aplicaciones desarrolladas en esta tecnología con los servicios que ofrece Viafirma.

En este artículo mostraremos cómo añadir las dependencias necesarias a un proyecto web Java para hacer uso de los diferentes servicios de firma digital (XAdES, Facturae, PDF sign, etc… ), autenticación (FNMT, Camerfirma, Firma profesional, Ancert, ACA, Izempe,  DNIe, etc…),  custodia (integridad, etc…)  y verificación (CRLS, OCSP, etc…).

El procedimiento sería el siguiente:

1.- Añadir las dependencias

Viafirma está preparado para trabajar con Maven; en este tipo de proyectos sólo será necesario añadir la dependencia a viafirma-client de la siguiente manera:


<!--  Dependencias para el cliente viafirma con soporte de OpenID -->
<dependency>
 <groupId>org.viafirma</groupId>
 <artifactId>viafirma-client</artifactId>
 <version>[2.2.3,2.3.0)</version>
</dependency>

Y poner el repositorio de librerías de VIAVANSI para poder recuperar esta librería:

http://repositorio.viavansi.com/repo

Si el proyecto no está basado en Maven, necesitaremos añadir manualmente los .jar que se incluyen en el directorio dependency dentro del distribuible de viafirma-client.

2.- Crear la página de acceso a la autenticación

A modo de ejemplo básico vamos a crear una jsp que inicialice el cliente de Viafirma y permite al usuario iniciar el proceso de autenticación pulsando en un enlace. Este cliente utilizará el servidor público de pruebas de Viafirma desplegado en las instalaciones de Viavansi.

<%@page import="org.viafirma.cliente.ViafirmaClientFactory"%>
<%@page import="org.viafirma.cliente.ViafirmaClient"%>
<body>
<%
if (!ViafirmaClientFactory.isInit()) {
 // Configuración básica del cliente.
 ViafirmaClientFactory.init("http://viafirma.viavansi.com/viafirma","http://viafirma.viavansi.com/viafirma");
}

if(request.getParameter("autenticar")!= null){ ViafirmaClient viafirmaClient = ViafirmaClientFactory.getInstance(); // Iniciamos la autenticación indicando la uri de retorno. viafirmaClient.solicitarAutenticacion(request, response,"/viafirmaClientResponseServlet"); } %> <p><a href="?autenticar=true">Solicitar autenticación</a></p> </body>

Cuando el usuario pulse sobre el enlace “Solicitar autenticación” el usuario será redirigido a Viafirma, donde se le solicitará su certificado digital. Viafirma validará y tratará el certificado del cliente y retornará el resultado de la autenticación a la aplicación cliente que estamos desarrollando. En la jsp de ejemplo le indicamos a Viafirma que la url de retorno (donde Viafirma debe mandarnos el resultado de la autenticación) es /viafirmaClientResponseServlet .

3.- Procesar la respuesta

Una vez que Viafirma obtenga la información contenida en el certificado digital, retornará los datos a la url que la aplicación cliente le indicó, por lo que el siguiente paso será definir un servlet (cuya URL en este ejemplo es /viafirmaClientResponseServlet) que se encargue de gestionar la respuesta. Para ello crearemos un servlet que extiende de org.viafirma.client.ViafirmaClientServlet, e implementaremos los métodos error(…), cancel(…) y authenticateOK(…):


public class ViafirmaClientResponseServlet extends ViafirmaClientServlet{

@Override public void authenticateOK(UsuarioGenericoViafirma usuario,HttpServletRequest request, HttpServletResponse response) { // Lógica específica de la aplicación para gestionar el resultado de la autenticación request.setAttribute("usuarioAutenticado", usuario); request.getRequestDispatcher("/resultadoAutenticacion.jsp").forward(request, response); }

@Override public void cancel(HttpServletRequest request, HttpServletResponse response) { // Gestiónn de cancelaciónn del usuario al autenticar o firmar request.setAttribute("error", "El usuario ha cancelado la autenticación"); request.getRequestDispatcher("/resultadoAutenticacion.jsp").forward(request, response); }

@Override public void error(CodigoError codError, HttpServletRequest request, HttpServletResponse response) { // Gestión de error al autenticar o firmar request.setAttribute("codError", codError); request.getRequestDispatcher("/resultadoAutenticacion.jsp").forward(request, response); }

}

En este ejemplo vemos un ejemplo de implementación, en el que la aplicación simplemente guarda en request el objeto UsuarioGenericoViafirma que contiene todos los datos que aparecen en el certificado digital. Obviamente cada aplicación, en función de su lógica de negocio, deberá realizar la implementación específica que requiera.

4.- Adaptar la plataforma al skin de la aplicación cliente.

La página donde se solicita el certificado digital reside en Viafirma. Sin embargo, a través de CSS podremos conseguir que el usuario no aprecie un cambio de interfaz, de forma que el salto de la aplicación a Viafirma parezca transparente a nivel estético.

Para hacer que Viafirma se adapte fácilmente al estilo visual de nuestra aplicación cliente, sólo tendremos que colocar el fichero viafirmaStyle.css en el raíz de nuestra aplicación y redefinir el aspecto visual de la interfaz  de Viafirma.

5.- Descarga el cliente y pruébalo tu mismo

Descargar ejemplo de autenticación utilizando el cliente Java para obtener los datos del certificado digital.

Próximamente: Java / JEE : Firma digital XADES y facturae con Viafirma (II)

Sun’s RI for JSF vs MyFaces

21 ene 2008

Época de despedidas, hoy le toca el turno a MyFaces

Después de más de dos años utilizando la implementación Apache Myfaces JSF, ha llegado el momento de las despedidas, en adelante todos nuestros proyectos se pasan a la implementación JSF 1.2 de Sun. No existe un motivo principal, pero si muchos pequeños problemas que finalmente nos han hecho decidirnos por la migración. Sin intención de entrar en detalle, estas son las motivaciones principales:

- En el momento de tomar la decisión, la implementación de Sun de la especificación 1.2 era mucho mas madura que la de Myfaces. En las pruebas realizadas pudimos comprobar que el numero de bugs es mucho mayor en la implementación Myfaces. En general Sun’s RI es una implementación mucho mas pulida.

- El número de incompatibilidades que hemos sufrido al migrar de la especificación 1.1 a 1.2 ha sido mucho menor con la implementación de Sun.

- Es posible seguir utilizando las librerías Tomahawk  con la implementación de Sun.

- La implementación de Sun parece ofrecer mejor rendimiento que la implementación de Myfaces.

- La integración con Seam es mucho mas sencilla utilizando la implementación de Sun.

- Gracias a la filosofía una especificación, múltiples implementaciones; el cambio era posible.