Xnoccio.com

Llevamos varios años trabajando con la Diputación de Cádiz en varios proyectos de presencia web y tramitación telemática, y podemos afirmar que da gusto trabajar con personas con nombres y apellidos con un nivel profesional y humano como el suyo.

La revista Socinfo ha galardonado a la Diputación de Cádiz con un premio que valora la colaboración fomentada entre instituciones públicas, destacando el esfuerzo que la Diputación hace para ayudar a los Ayuntamientos gaditanos.

Desde VIAVANSI les felicitamos y nos sentimos honrados de haber podido participar aunque sea de un poquito de esa estrategia de modernización que tan bien están ejecutando.

Nuestros compañeros de OpenCms han sacado el nuevo sitio web de la Consejería de Turismo, Comercio y Deporte de la Junta de Andalucía. Ha sido un duro proyecto trabajado en equipo entre el personal de VIAVANSI (enhorabuena Tino, Carlos, Antonio, Cristina, Javi, Álvaro, Juan, Enrique, Fernando, Silvia, Diego…) y el del cliente, que ha trabajado como un miembro más del equipo. Gracias por ello a Joaquín Vázquez, Mercedes Soto, Manolo Martín Matas, Alberto Díaz, Pepe Campos, etc. etc.).

El portal la verdad es que mejora mucho al anterior, y dentro de las férreos marcos que rodean a los sitios web de las instituciones públicas, introduce algunos conceptos que, si bien son comunes en otro tipo de portales, resultan innovadores en un sitio oficial; por ejemplo, la zona más expuesta al público y central la ocupan una serie de vídeos multimedia servidos vía streaming.

El portal ha sido desarrollado bajo tecnología OpenCms 7.0.4 / Oracle.

Le deseamos una excelente andadura al nuevo portal.

Dice la competencia que después de la fusión entre Sun y Oracle tal vez el nuevo logo de Java EE vaya a ser como el que sigue:

Con el título de este post poco más hay que explicar

En la URL http://twitter.com/viavansi tenéis ya disponible el Twitter corporativo de VIAVANSI. A través de los tweets pondremos a disposición de todos noticias informales del día a día de nuestra empresa, el sector TIC, etc.

Invitamos a todos nuestros lectores a ser followers!

Namasté.

Aunque pueda parecer sorprendente, una de las principales novedades de la próxima versión 2.2 de Viafirma, que va a ser liberada en pocos días, es su integración con la plataforma @Firma v5.

Para el lector que no conozca @Firma (también conocido como aFirma), se trata de una plataforma de similares características funcionales a Viafirma, teniendo como principales responsabilidades el facilitar a terceras aplicaciones (que se integran con @Firma a través de un API cliente) el soporte de autenticación y firma digital con certificados digitales. Su desarrollo fue dirigido por la Junta de Andalucía, donde es la plataforma corporativa de autenticación y firma digital, y también así ha sido escogida por el MAP (Ministerio de Administraciones Públicas) como su herramienta base para este tipo de funcionalidades, cediendo su uso a cualquier de Administración Pública española. Hablamos por ello sin ninguna duda de una plataforma con una gran relevancia en el mercado y un más que importante número de implantaciones.

¿Por qué comentamos que “puede parecer sorprendente” esta nueva funcionalidad de Viafirma?  Pues porque, como el lector habrá advertido, en principio Viafirma y @Firma “se dedican a lo mismo”, es decir, a facilitar a aplicaciones el soporte de autenticación y firma electrónica. Entonces, ¿para qué integrar ambas plataformas?

La idea de su integración surge de la posibilidad de aislar responsabilidades dentro del proceso de autenticación y firma digital, haciendo que ambas plataformas interoperen en un ambiente SOA y se encarguen cada una de las funcionalidades en las que destacan. En nuestra empresa, VIAVANSI, hemos desarrollado una gran multitud de aplicaciones que se integran con @Firma para la Junta de Andalucía. Quizás podríamos destacar algunas debilidades que bajo nuestro punto de vista hemos advertido en esta plataforma:

• Su matriz de compatibilidad (a día de hoy la última es consultable en este enlace del portal Pluton de la Junta de Andalucía) es relativamente reducida para la Administración Pública, que busca poder dar servicio al 100% de la ciudadanía. Se quedan por ejemplo fuera de ella usuarios de Mac (como el que escribe), hemos observado problemas en función de las versiones de JRE, no hay actualmente soporte de Firefox 3, etc.
• La apariencia (look&feel) del cliente es mejorable.
• Cada aplicación que se integre con @Firma debe disponer en sus librerías del cliente de @Firma, y desarrollar código para utilizar dicho cliente. Ello implica que, cada vez que hay una actualización de este cliente de @Firma, hay que realizar un esfuerzo bastante importante de mantenimiento de aplicaciones para introducir el nuevo cliente, realizar los cambios que sean necesarios, probar y desplegar de nuevo las aplicaciones, etc.

Precisamente, esas debilidades son de hecho puntos fuertes de Viafirma, que la hacen sin duda destacar. Tal vez por ser una plataforma de desarrollo más reciente, Viafirma dispone de una enorme matriz de compatibilidad, pudiendo operar en prácticamente cualquier combinación de sistema operativo / navegador / versión de Java Runtime Environment (JRE) / autoridad de certificación / disposición del certificado (software, tarjeta -DNIe-, token)… Por ejemplo, firma en Mac sin problemas Como ejemplo, en las dos primeras semanas de funcionamiento en la aplicación de “Acciones formativas de las Empresas” de la Fundación Tripartita para la Formación en el Empleo se superaron las 300.000 operaciones de autenticación y firma digital sin apenas incidencias. De hecho, el sistema “Acciones formativas de las Empresas” es probablemente, junto a las aplicaciones de Renta de la Agencia Tributaria, la aplicación pública con más operaciones de firma digital de España, ya que prácticamente cualquier empresa española puede ser usuaria del sistema.

Por otro lado, Viafirma incluye un concepto “push” de su cliente de firma, lo cual es una ventaja crucial para la estrategia de mantenimiento de aplicaciones. La librería cliente reside en un único nodo central (servidor de Viafirma), de forma que cuando se libera una nueva versión de dicha librería, sólo se debe realizarse la actualización en ese nodo. Todas las aplicaciones que utilicen el cliente quedan en ese momento automáticamente actualizadas, reduciéndose así enormemente el impacto de los nuevos desarrollos. Sin duda se evitan así fallos de actualización difícilmente controlables, redundando finalmente todas estas ventajas en la ciudadanía, que en todo caso es -somos- los usuarios de estos sistemas.

Esta nueva característica de Viafirma 2.2 permite utilizar la plataforma para las operaciones más relacionadas con el usuario de la aplicación (la detección y lectura de certificados,  y la operación de firma digital en local). Viafirma se comunica con los API’s Web Services nativos de @Firma para el resto de operaciones de núcleo: la validación de certificados con las CRL’s o servicios OCSP de las diversas autoridades de certificación, la custodia de los documentos firmados, etc.

De esta forma, se consigue una integración rápida y no intrusiva en “modo bridge”. Se podría decir que Viafirma se encarga de la “capa de cliente” del proceso, interactuando con el usuario y su almacén de certificados, y @Firma se encarga de la “capa de servidor”, responsabilizándose de la conexión con las diversas CA’s, la custodia de las firmas (opcionalmente), etc.

Las ventajas de este escenario son así muchas:

• Las instituciones disponen de un cliente de firma universal, que soporta prácticamente cualquier combinación de sistema operativo (Windows, incluyendo incluso la beta de Windows 7, Linux, Mac OS), navegador (Internet Explorer -6, 7 e incluso a nueva versión 8…-, Firefox-incluyendo la versión 3-, Safari, Google Chrome…), versión de JRE (5, 6, etc.), CA’s (FNMT, DNI-e, Camerfirma, ANCERT, Izenpe, Firma Profesional, ANF-AC, etc.), disposiciones (software, tarjeta incluyendo DNI-e, token, etc.)… La matriz de compatibilidad se ve ampliada en una gran magnitud, resultando principalmente favorecida la ciudadanía.
• El cliente de firma de Viafirma soporta incluso la utilización de un certificado exportado en formato P12 (formato de exportación usual en Linux o Mac) o PFX (este último típico de Windows), sin necesidad de importarlo en el almacén de certificados del sistema operativo o navegador. Un típico caso de uso sería, por ejemplo, que tengamos nuestro certificado personal exportado en un pendrive USB y queramos realizar una operación de autenticación o firma digital en un ciber-café, donde tal vez no tengamos permisos para instalar el certificado (o simplemente no lo deseemos por motivos de seguridad). El usuario puede escoger la ubicación del fichero P12 o PFX de una ruta local (como por ejemplo en ese pendrive), y utilizarlo así como si el certificado estuviese instalado en la máquina.
• Se reduce enormemente el coste de mantenimiento de aplicaciones, ya que como se ha comentado anteriormente el cliente de firma sólo reside en un nodo central y la actualización de versiones del cliente se realiza de forma automática en las aplicaciones.
• La institución mantiene su instalación de @Firma plenamente operativa, y en ella reside precisamente la responsabilidad de ejecutar operaciones críticas como la validación de los certificados (revocados, caducados, conexión a CRL’s y servicios OCSP, etc.), custodia de los documentos firmados, y en general, toda la lógica de servidor. Eso sí, la custodia podría ser opcional si se desea que los ficheros y/o sus firmas digitales sean custodiados por la aplicación o incluso por Viafirma, que soporta custodia en sistemas NFS, en ECM’s como Alfresco, y incluso en campos de base de datos tipo LOB.
• Se crea una disposición plenamente coherente con una política de interoperabilidad entre plataformas basadas en arquitecturas SOA, aprovechando los puntos fuertes de cada una de ellas, dispuestos a modo de servicio.

La nueva versión 2.2 de Viafirma además soporta el formato CMS y el formato 3.1 de factura-e e incluye otras actualizaciones menores.

Acaba de salir publicada la nueva versión 2.1.0 de Maven. Se pueden consultar las modificaciones incluidas en las Release Notes de la versión.

Está calentito calentito; esta misma semana empezamos a trabajar con esta versión, e iremos comentando las novedades que vemos. De momento os puedo anticipar que por fin las contraseñas almacenadas en el settings.xml están ofuscadas

Como muchos de nuestros lectores sabrán, el día 19/03/2009 a las 18h se vio publicada la nueva versión 8 del navegador de Microsoft, Internet Explorer.

Viafirma ya soporta la autenticación y firma digital con el nuevo Internet Explorer 8, del mismo modo que es 100% compatible con las versiones beta publicadas de Windows 7.

Adjuntamos una captura de pantalla con una operación satisfactoria de firma realizada sobre este navegador.

En VIAVANSI estamos de enhorabuena, ayer lunes 16/03/2009 entró en producción la Aplicación de gestión de las Acciones formativas de las empresas, de la Fundación Tripartita para la Formación en el Empleo (antiguo FORCEM). En esta institución han escogido Viafirma para introducir las funcionalidades de autenticación con certificados digitales con multitud de CA’s como DNI electrónico, FNMT, IZENPE, Camerfirma, ANCERT, Firma Profesional, etc.

La aplicación permite a las empresas que realicen actividades de formación comunicar el inicio y finalización de las mismas a la Fundación, como establece la Orden Ministerial que las regula. El alcance final de la aplicación abarca a toda empresa española que tenga planes internos de formación, por lo que el volumen de transacciones que debe soportar es de una enorme magnitud. Pasadas unas horas de la presentación y puesta en marcha de la aplicación ya hemos podido comprobar que se han efectuado varios miles de operaciones de autenticación y firma digital satisfactoriamente. Las estimaciones de carga previstas sobrepasan las 80.000 firmas digitales diarias en momentos de uso masivo de la aplicación.

Gracias al uso de Viafirma, la Fundación Tripartita garantiza un acceso universal a los usuarios. Ello es debido a la gran universalidad de Viafirma, que permite a los usuarios autenticarse y firmar con sus certificados digitales en cualquier sistema operativo (Windows, Linux, Mac, etc.), navegador (Internet Explorer, Firefox, Safari, Google Chrome, etc.), tipo de certificado y disposición en software, tarjeta criptográfica, token USB, etc.

En las últimas semanas varias instituciones han optado por Viafirma como solución de autenticación y firma digital. Además de la propia Fundación Tripartita, Viafirma ha sido implementado en Toyota España, Col·legi Oficial de Farmacèutics de les Illes Balears (COFIB), en el proyecto de factura electrónica Pymetronica de ETICOM…

Reciéntemente he estado revisando la arquitectura técnica de un proyecto Java EE que estaba teniendo serios problemas de escalabilidad. En Desarrollo todo iba como un tiro, pero con un número importante pero no escandaloso de registros (apenas 100.000) nos encontrábamos con tiempos de respuesta de algunas de las operaciones online que se podían ir a los 5 minutos. Obviamente esos tiempos no son admisibles para una operación web, por lo que urgía detectar fuentes de problemas y optimizar los procesos.

Realmente no había ninguna parte del código culpable al 100%, sino que la funcionalidad implementada, excesivamente flexible para el usuario,  le permitía a éste realizar búsquedas y operaciones que finalmente implicaban una sucesión de consultas, filtrados, operaciones de unión/intersección de listas enormes, persistencia…

Para muchas de las listas que se manejaban, se podía garantizar su invariabilidad en un tiempo elevado. Datos, por ejemplo, relativos a provincias. Por ello daba la sensación de que implementar una caché de estas listas, y sobre todo de los resultados finales después de las mencionadas operaciones de unión/intersección, etc., podría ser oportuno. Es cierto que Hibernate permite caché de resultados (y de hecho utiliza Ehcache), pero en este caso hablamos de resultados post-procesados, por lo que no sería suficiente.

Cachear objetos en una aplicación Java EE es algo básicamente trivial: siempre disponemos de la opción de ubicar el objeto en contexto de aplicación (ServletContext) y recuperarlo cuando queramos. Sin embargo esta aproximación no deja de ser algo “de juguete”. Decidimos utilizar Ehcache en primer lugar porque sabíamos que Hibernate sacaba un buen provecho de él, pero sobre todo porque, con un desarrollo extremadamente sencillo, obtenemos importantes ventajas funcionales como:

• Gestión de caducidad del contenido. Pasado un tiempo determinado, la caché elimina el objeto cacheado y comienza a devolver NULL a las peticiones posteriores. Nos elimina la responsabilidad de persistir el tiempo de vida de un objeto cacheado.
• Configuración del máximo número de objetos a cachear en memoria. Podemos dimensionar la cantidad de objetos que deseamos cachear en memoria. Ehcache se encarga de serializar a disco todo lo que le sobra, y recuperarlo cuando sea necesario. Ni que decir tiene que todos los objetos a cachear deberán ser serializables.
• Posibilidad de despliegue en cluster.
• Eliminación de la caché durante el shutdown del servidor de aplicaciones.
• ¡No reinventar la rueda!

Al final desarrollamos una sencilla clase tipo Manager, implementando el patrón Singleton, que interactúa con Ehcache. Y en determinadas zonas de la aplicación, invocar a la cache para recuperar los objetos que anteriormente se generaban online.

Paso a poner el código, que al final sin chicha esto se queda en nada Eso sí, me gustaría recalcar que el proceso de 5 minutos al final, con un poco de cariño, ha pasado a responder en menos de 10 segundos. Una ganancia de un 3000%…

/*
* File: CacheUtil.java
*
* Created on march 2009
*
*
* Copyright 2006-2029 Javier Echeverría Usúa (javieu at gmail.com)
*
* Licensed under the Apache License, Version 2.0 (the "License");
* you may not use this file except in compliance with the License.
* You may obtain a copy of the License at
*
*     http://www.apache.org/licenses/LICENSE-2.0
*
* Unless required by applicable law or agreed to in writing, software
* distributed under the License is distributed on an "AS IS" BASIS,
* WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
* See the License for the specific language governing permissions and
* limitations under the License.
*
*/
package com.viavansi.framework.core.cache;

import net.sf.ehcache.Cache;
import net.sf.ehcache.CacheManager;
import net.sf.ehcache.Element;

import org.apache.commons.logging.Log;
import org.apache.commons.logging.LogFactory;

import com.viavansi.framework.core.persistencia.servicios.excepciones.ExcepcionServicio;


/**
* @author Javier Echeverria Usua (javieu at gmail.com)
* @author Felix Garcia Borrego (borrego at gmail.com)
* @author Alexis Castilla Armero (pencerval at gmail.com)
*/
public class CacheUtil {

public Object getCachedObject(String key) throws Exception{

if(minutosVidaDefault == 0)
minutosVidaDefault = MINUTOS_DEFAULT;

return getCachedObject(key, minutosVidaDefault);
}

public void putCachedObject(String key, Object info) throws Exception{

if(minutosVidaDefault == 0)
minutosVidaDefault = MINUTOS_DEFAULT;

putCachedObject(key, info, minutosVidaDefault);
}

public Object getCachedObject(String key, int minutosCache) throws Exception{

Cache cacheCustodia = getInstance(minutosCache);
Element element = cacheCustodia.get(key);
if(element != null){
return cacheCustodia.get(key).getValue();
}
else{
return null;
}
}

public void putCachedObject(String key, Object info, int minutosCache) throws Exception{

Cache cacheCustodia = getInstance(minutosCache);
cacheCustodia.put(new Element(key,info));
}

private Cache getInstance(int minutosCache) {
Cache cache = null;
//Todavía no existe
int timeTolife = minutosCache * 60;

CacheManager manager = CacheManager.getInstance();

String nombreCache = "viavansiCachedInfo" + minutosCache;

if (manager.cacheExists(nombreCache)) {
cache = manager.getCache(nombreCache);
} else {
// Configuramos el apagado en caso de Error de la JVM o parada inesperada.
System.setProperty("net.sf.ehcache.enableShutdownHook", "true");
manager.addCache(new Cache(nombreCache, 100, true, false, timeTolife, timeTolife));
cache = manager.getCache(nombreCache);
}

return cache;
}

public static void shutDown() {
CacheManager.getInstance().shutdown();
}

private int MINUTOS_DEFAULT = 60;

private static int minutosVidaDefault = 0;

protected CacheUtil(int minutosVida) {
minutosVidaDefault = minutosVida;
}

public static void init(int minutosVida) {
minutosVidaDefault = minutosVida;
}

/*
* Constructor y accesores
*/

// Patrón Singleton
private static CacheUtil singleton;

//Instancia de Commons Logging
private Log log = LogFactory.getFactory().getInstance(this.getClass().getName());

/**
* private constructor (solo una instancia).
* @return AmbitoBO
*/
protected CacheUtil() throws ExcepcionServicio {
super();
log.debug("Creando nueva instancia de CacheUtil");
}

/**
* Devuelve instancia activa de AmbitoBO.
* Típico método de implementación de patrón singleton
* @return AmbitoBO
* @throws ExcepcionServicio
*/
public static CacheUtil getCurrentInstance() throws ExcepcionServicio {
if (singleton == null) {
try {
singleton = new CacheUtil();
} catch (ExcepcionServicio e) {
throw e;
}
}
return singleton;
}

}

Un saludo a todos, y poned una caché en vuestros corazones

Desde VIAVANSI, los redactores de Xnoccio os deseamos felices fiestas y que para el 2009 todo vaya bien o mejor. Gracias por vuestra fidelidad!