Xnoccio

Hace tiempo que abandone el “Mantra Web services para todo“, y me horrorizo al escuchar a los que piensan que RMI es cosa del pasado, aunque reconozco que a menudo es fácil tomar la decisión y elegir SOAP, en ocasiones la elección no es tan clara.

Dejo aquí mis criterios para elegir:

- Si algunas de las aplicaciones que se van a integrar no son Java, evidentemente la opción RMI se elimina, ya que salvo casos excepcionales, si soy de los que piensan que RMI/IIOP es cosa del pasado.

- Si el rendimiento, la eficiencia y los tiempos de respuesta son una preocupación, a falta de tener en cuenta otros criterios, RMI es la mejor opción. A modo de ejemplo, nuestra plataforma de Formularios ( Formul@) ofrece ambas implementaciones, y la implementación RMI es un orden de magnitud mas rápida que su homóloga SOAP. En en un bucle de 1000 iteraciones, el cliente basado en web services tardo en promedio un total de 10186ms en renderizar los formularios, mientras que la versión basada en RMI tardo de media 946ms.

- Si ambas aplicaciones son Java y ademas se ejecutan en la misma máquina o subred, la opción RMI es sin duda mi preferida.

- Si se pretende construir o evolucionar en el futuro a un ambiente SOA, aunque SOA no descarta RMI (la mayoría de los ESBs lo contemplan), la mejor opción es implementar un servicio basado en Web Services.

- Si las aplicaciones son desarrolladas por diferentes proveedores, la opción sería Web Services, ya que el desarrollo “primero contrato” se hace imprescindible.

- En otro caso, utilizo mi moneda de la suerte para decidir :), aunque la moneda suele tiene en ambas caras “Web Service”.

Si usas Thunderbird como cliente de correo una de las funciones qué más se echa de menos respecto al Outlook por ejemplo es la capacidad de minimizarse al System Tray, para no tener siempre ocupando espacio en la barra de tareas.

Esto ya no es problema con un complemento muy útil para Thunderbird, Firefox, Mozilla y Nvu que permite minimizar estos programas en el System Tray, e incluso mandarlos ahí cuando cerramos la aplicación. Para restaurarlo basta un simple doble click.

¿Dónde pillo el artefacto? Aquí:

https://addons.mozilla.org/es-ES/firefox/addon/2110?application=thunderbird&id=2110

Para instalarlo desde Thunderbird vamos a Herramientas -> Complementos -> Instalar e instalamos el .xpi que acabamos de bajar. Reiniciamos Thunderbird y si vamos a Herramientas -> Complementos veremos el nuevo plugin instalado. En sus opciones podemos configurar que se minimice al System Tray.

A mí me parece muy útil el cacharrito.

Si existiese un portátil flotante, no llevaría el portátil colgado del hombro derecho y no parecería gilipollas en la foto.

Este post no da para más, salvo para ver a Félix con traje, que no es poco.

Como bien anunció Félix hace unos días, Viafirma ya soporta la validación del DNI electrónico.

Para aquellos lectores que no lo sepan, Viafirma es uno de nuestros productos ASVPDM (Aplicaciones Software de Viavansi Para Dominar el Mundo). Es una VA (Validation Authority) Open Source; una VA permite abstraer las operaciones de autenticación y firma digital con certificados digitales. Tras la última release, se convierte en la primera plataforma 100% software libre que permite la validación del DNI electrónico.

Viafirma es un servicio externo que se encarga de estas operaciones, y da un API a terceras aplicaciones que necesitan autenticación o firma digital. Es decir, podemos disponer de una sola instancia de Viafirma en una red, y varias aplicaciones cliente.

Durante el proceso de desarrollo de la última release hemos hecho diferentes pruebas de soporte. En este post voy a tratar de explicar el sencillo proceso para utilizar el DNI electrónico (DNIe) sobre Windows. En mi caso he usado Windows XP, aunque en principio Vista está perfectamente soportado.

Los pasos a seguir son los siguientes:

1. Tener un DNI electrónico :-D Esto es sencillo, lo hacen sobre la marcha en varias comisarías de Policía de España. Además, no hace falta que tengas caducado el anterior. La tasa es de 6,70€. Me fijé que tardó muchísimo en la escritura de los certificados (unos 10 minutos). Con el DNIe te dan un sobre con un PIN que protege la tarjeta. Lo mejor es cambiarlo inmediatamente. En la Comisaría donde lo saqué (Oviedo) tenían un par de kioskos interactivos donde se podía cambiar de forma sencilla.
2. Instalar los drivers de algún lector de tarjetas criptográficas. En mi caso instalé 2 que tenía antiguos para la lectura de tarjetas donde había alojado mi certificado de la FNMT-RCM; en concreto, un lector de C3PO (el típico del CryptoKit) y un lector de Bit4id. Aprovecho para recomendar encarecidamente este proveedor, son gente realmente seria y rápida.
3. Instalar librerías del DNI electrónico. En la web del proyecto se puede descargar un fichero ZIP instalable que contiene el CSP (”Cryptographic Service Provider”). En Linux, Unix o MAC usaríamos un PKCS#11.
4. Listo para probar!!! Tras reiniciar (mérito de nuestro MS Windows) enchufamos el lector al USB e insertamos el DNI electrónico. Probamos con la demo de Viafirma tanto la autenticación como la firma. La demo es una sencillísima aplicación cliente de Viafirma que simplemente solicita el certificado para autenticar, lo valida y muestra su contenido (también permite una firma de fichero). Para acceder a la lectura, la librería CSP del DNIe nos pide de vez en cuando el PIN de la tarjeta que ya habíamos modificado en la Comisaría de Policía. Escogemos el certificado adecuado, y voilá! Todo funcionando perfectamente

A este respecto cabe destacar algunos aspectos:

• El DNI electrónico incorpora 2 certificados, uno destinado a autenticación y otro destinado a Firma.
• Para la validación del DNIe se ha implementado la validación mediante OCSP. No existe la posibilidad de validar directamente el estado del certificado contra una CRL.
• El acceso a la tarjeta es tremendamente lento (minutos). No sé si será cosa de Windows, o porque ninguno de los 2 lectores que probé están optimizados para el DNIe, pero el hecho de que tardase 10 minutos en generar los certificados durante la emisión me hace sospechar que es que es así. Sinceramente, si se confirma, me parece un freno terrible para la universalización del DNI electrónico.

Seguiremos posteando los pasos para utilizar el DNI electrónico en otros sistemas operativos (Linux y Mac).

Llevo unos meses atrapado en una serie de proyectos [tremendamente aburridos] en los que me estoy enfrentando a problemas de velocidad de ejecucion y, sobre todo, de carga de memoria. Uno de esos dias en los que te sientes con fuerzas para cuestionar la filosofia de tu aplicacion que tiene meses de trabajo detras, me puse a buscar por ahi, a ver si daba con alguna explicacion razonable.

Y asi llegue a la pagina de los Sorensens y concretamente a este post: http://www.thesorensens.org/?p=14

Recomiendo la lectura de dicho articulo porque es muy interesante. Yo voy a ser bastante mas breve. Y probablemente para entender completamente este articulo, si se carecen de ciertos conocimientos, haya que leerse el otro.

Al parecer los parseadores de XML hacen uso de String.intern que resulta ser mucho mas eficiente a la hora de coparar Strings que un a.equals(b) caracter a carater; con String.intern esta comparacion es canonica. Desgraciadamente, para esta optimizacion de velocidad se hace uso del espacio Pergem de memoria.

Resulta que si bien mi caso no es tan extremo como el que tenia esta gente, si que me enfrento al parseo de un XML que puede llegar a ser de hasta 10Mb y cuyo XSD tiene 8600 lineas.

Es por esto que me enfrento a esos problemas de memoria. Tambien de velocidad, ya que el String.intern es mas eficiente que la comparacion caracter a caracter cuando tienes pocos Strings guardados en el pool, pero cuando este numero es masivo, el hecho de buscar los Strings en el pool es mas costoso que las comparaciones caracter a caracter.

La solucion que emplearon los Sorensens fue finalmente no usar parseadores de XML, ya que despues de todo no estaban parseando un XML real. En su lugar usaron expresiones regulares ganando espectacularmente en velocidad y uso de memoria.

En nuestro caso si se trata de XML reales, pero resulta que hay un 40% de los tags del XSD no los usamos en absoluto, y lo que nos sobra del XML es mas variable, pero en muchos casos ronda ese mismo porcentaje… quizas, despues de todo no necesitasemos parsear.

Probablemente ya sea tarde para plantearselo, pero si algun dia hay una segunda fase, quizas nos lancemos a reescribir esta parte del codigo. Si asi lo hacemos os comentaremos los resultados.

Hala pues,

Con el lanzamiento de la versión 1.2 de Viafirma, nuestra plataforma de validación y firma electrónica ya soporta el uso del DNI electrónico de la Dirección general de la Policía y de la Guardia Civil.

Con esta funcionalidad, Viafirma se convierte en la primera plataforma software libre con soporte para el eDNI.

Si lo desea puede probar su dni electrónico en la aplicación de demostración.

Gracias a Viafirma 1.2 ahora es mucho mas fácil que otras aplicaciones hagan uso del eDNI para autenticar a sus usuarios o solicitarles que autoricen o firmen documentos y transacciones.

Principales cambios en la versión 1.2:

• Soporte para la validación de certificados utilizando OCSP (Online Certificate Status Protocol RFC 2560)
• Soporte para la autenticación utilizando el DNI electrónico.
• Soporte para la firma de documentos utilizando el DNI electrónico.
• API cliente WebSercice, con lo que ahora tenemos disponibles tres APIs: RMI, WebService y OpenId.
• Admite la configuración offline, desactivando la validación de certificados revocados.

Una vez alcanzadas las funcionalidades básicas, y con la experiencia adquirida en las instalaciones y adaptaciones que hemos realizado de la plataforma, en la próxima versión nos centraremos en mejorar la documentación pública, crear una guía con los errores mas comunes encontrados y mejoras en los ejemplos de integración.

Cuando solo necesitamos acceder a nuestro gestor documental para gestionar ficheros y no vamos a utilizar toda la potencia que ofrece su interfaz web, Alfresco nos ofrece la posibilidad de ser montado como una unidad Webdav sobre la que trabajar de forma remota.

Para hacer esto desde Linux, solo es necesario abrir una ventana con el explorador de ficheros Nautilus y escribir en la barra de direcciones la url en la que se encuentra publicado de la siguiente forma: dav://ipServidor/alfresco/webdav.

Por otro lado, este acceso webdav también lo estamos usando desde nuestras aplicaciones Java (gracias a la implementación Apache Slide) para permitir la subida a Alfresco de ficheros de gran tamaño, ya que el API Webservices con ficheros grandes tiene graves problemas de rendimiento, velocidad y estabilidad.