Xnoccio

* Sólo Chuck Norris puede hacer una clase  abstracta y final.
* Chuck Norris serializa los objetos directamente en cráneos humanos.
* Chuck Norris no despliega aplicaciones web, él las mete a patadas en el servidor.
* Chuck Norris siempre utiliza sus propios patrones de diseño, y su favorito es la Patada Voladora Chuck.
* Chuck Norris puede usar para matarte cualquier clase de java.util .* , incluido el javadocs.
* Chuck Norris puede golpear tan fuerte que tu aplicación web se convierta en una aplicación swing, y es muy probable que sea una aplicación swing con una gran cantidad de iconos de cráneos humanos.
* Chuck Norris demostró el significado de Float.POSITIVE_INFINITY contando hasta él, dos veces.
* La sincronización no protege frente a Chuck Norris, si quiere el objeto, él lo toma.
* Chuck Norris no usa javac, él edita directamente los .class con un editor binario.
* El código Java de Chuck Norris nunca necesita ser optimizado. Su código es tan rápido que rompió la velocidad de la luz durante una prueba en los laboratorios de Sun matando a 37 personas.
* Cuando alguien intenta utilizar un método deprecated hecho por Chuck Norris , el método no avisa de que está deprecado. Automáticamente te pega una patada voladora en la cara en tiempo de compilación.
* El paquete java.lang originalmente contenía una ChuckNorris clase, pero fue quitado del paquete durante la revisión ya que Bill Joy recibió una patada voladora en la cara.
* Chuck Norris no tiene un error en su código, EVER!
* Chuck Norris no escribe código. Él mira a la pantalla de un ordenador hasta que obtiene el PROGRAMA que quiere.
* El código funciona más rápido cuando Chuck Norris lo mira.
* Chuck Norris modifica binarios .class ignorando el verificador de bycodes de Java.
* Chuck Norris no captura excepciones porque nadie tiene el coraje para lanzar ninguna.
* Chuck Norris puede hacer un casting a cualquier objeto sólo mirándolo.
* Si usted recibe un ChuckNorrisException lo más probable es que muera.
* Chuck Norris es el único que puede utilizar GOTO y const en Java.
* Chuck Norris puede compilar el código Java en . NET Framework, evidentemente, sólo mirándolo.
* Chuck no necesita capturar ninguna excepción de Java porque cuando va a lanzar la excepción Java tiene miedo de su patada voladora.
* Los niveles de visibilida Java son public,default, protected, private y protected By Chuck Norris “, no intente tener acceso a un campo con este último modificador!
* Chuck Norris come crudos JavaBeans y da patadas voladoras a JavaServer Faces!
* Chuck Norris puede dividir por 0!
* Recolector de basura sólo se ejecuta sobre el código de Chuck Norris para recoger los cadáveres.
* Cada línea de código de Chuck Norris se ejecuta en tiempo real. Incluso en una aplicación multi-thread.
* Cuando una CRU carga un .class de Chuck Norris duplica la velocidad.
* Chuck Norris puede ejecutar instrucciones de 64 bits en una CPU de 32 bits.
* Chuck Norris implementa “Indestructible”. Todas las demás criaturas implementan “Killable”.
* Chuck Norris sólo programa aplicaciones web en Java para conseguir ganar el .WAR!
* Chuck Norris dio una vez una patada voladora a una clase Java. El resultado es conocido como las inner class.
* Chuck Norris puede hacer herencia múltiple en Java.
* JVM no arroja excepciones a Chuck Norris, ya no. Que matara a 753 ingenieros de Sun fue suficiente.
* Chuck Norris no necesita unidad de pruebas, porque su código siempre funciona. Siempre.
* Chuck Norris extiende a Dios. ( Y Dios que era final no pudo hacer nada para evitarlo)
* Chuck Norris tiene tanta memoria de trabajo y es tan poderoso que puede ejecutar todas las aplicaciones Java en el mundo y obtener el 2% de uso de los recursos.
* Chuck Norris ya usaba en su código genéricos en la versión 1.3.
* Una clase Chuck Norris no puede ser decompilada… no se moleste en intentarlo.

Traducción libre de: http://www.ovisual.com/4/

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)

Continuamos con la guía iniciada en  Guía de Ingles Zuburbial (I):

LIGANDO
En los zuburbios, es imprescindible relacionarse. Para caer bien a las chicas, tienes que alagarlas. Y ¿qué mejor forma de alagar que los típicos piropos de tu tierra? Son universales y calarán en cualquier país. Algún ejemplo:

• Pretty you are, doughter! (¡Guapa ere… hija!)
• Girl, go here what you hear (Niña, ven pacá que te vas a enterá)
• I’m more hot that sanjacobos’s chease (Estoy más caliente que er queso de los sanjacobo)
• Cuando la tengas en el bote, podrás cantar victoria: “This night, you don’t scape with wings”  (Esta noche no te escapas ni con alas).

VIAVANSI EN INGLÉ
Por último, es importante exportar siempre las peculiaridades de tu entorno de trabajo. Por lo tanto, en los zuburbios ingleses utiliza tus expresiones de siempre pero de forma que se te entienda:

• In zero-comma-two (En cero coma dos). Hacer algo muy rápido.
• To be a big border (Ser un filón). Una ganga, vamos.
• To be strange (Ser arcano), o Find a stranged (encontrarse una arcanidad)
• King Kong’s shit (Mojón de King Kong). Algo hecho rematadamente mal.
• To make you the bed (Hacerte la cama). No dejes nunca que te la hagan. Es malo.
• You are a person without arm! (¡Eres un muñón!). Para los malos programadores.
• Withfather (Compadre). Para los compañeros del alma.

Espero que sea suficiente para que tu estancia en la tierra de Ckeck’s Pierre sea lo menos traumática posible y te puedas integrar con lo más bajo del país.

Dentro del escenario de la web semántica, el estándar del Cool URIs se centra en definir el mecanismo de acceso a recursos basados en URIs, así como concretar el protocolo de negociación para el acceso a dichos recursos.

Este estándar, facilita la interoperabilidad del contenido web en el contexto de la web semántica, indicando como publicar la información sobre los recursos de manera que tanto máquinas como humanos puedan acceder a ella de una forma sencilla.

Para conseguir esto, el estándar define un conjunto de pautas básicas a seguir a la hora de publicar URIs, de este conjunto de pautas, las más interesantes son:

• Las URIs deben ser semánticas, de forma que teniendo sólo las URIs tanto máquinas como personas puedan obtener una descripción del tipo de recurso identificado.
• A una misma URI, las máquinas deben obtener RDF y las personas una visión legible en HTML. De forma más general se recomienda adaptar la respuesta al cliente que solicita el recurso, de forma que los humanos obtengan contenido inteligible por ellos y las máquinas obtengan algun tipo de recurso fácilmente procesable.
• Las URIs no deben ser ambiguas. Hay que distinguir entre documentos web e identificadores de recursos. No se deben utilizar URIs a documentos para identificar recursos reales. Se recomienda usar un mecanismo de resolución que en función de un identificador de recurso (URI) redirija al contenido RDF o al contenido HTML en función del tipo de cliente que solicita el recurso.
• Uso de Hash URIs o 303 URIs para el acceso a recursos parciales (zonas de documentos, o recurso no reales)
  • Hash URIs: Utilizando el símbolo “#” para referenciar fragmentos o partes especiales de una URI. Esta es la opción preferída.

• Uso del estado HTTP 303 para la redirección del usuario al recurso o fragmento indicado.

• Las URIs deben ser simples y fáciles de recordar.
• Las URIs deben ser estables y pensadas para continuar durante años. Por este motivo no deben aparecer extensiones relacionadas con la tecnología (.jsp, .asp, .php, etc… ).

Los programadores se enfrentan a una paradoja de valores básicos. Todos los desarrolladores con algunos años de experiencia saben que desordenes previos son causas de retraso. Y sin embargo todos los desarrolladores sienten que la presión les hace dejar mal algunas cosas para conseguir alcanzar las fechas de entrega. En resumen, no se toman el tiempo necesario para ir rápido.

Los verdaderos profesionales saben que la segunda parte de la paradoja está mal. No llegarás a la fecha haciendo mal las cosas. Es más, hacer las cosas mal te retrasará instantáneamente, y te forzará a incumplir la fecha de entrega. La única manera de llegar a la fecha -la única manera de ir rápido- es mantener el código tan limpio como sea posible durante todo el tiempo.

Parrafos del libro “Clean Code”,  leido en el blog de José Manuel Beas

Imágenes tomadas por nuestra cámara de seguridad :p.    Con varios proyectos a las espaldas y todavía le queda tikitaka!

• Vernor Vinge escribió:
  “ Dentro de 30 años tendremos los  medios tecnológicos para crear una inteligencia superhumana…Algún tiempo después, la era humana habrá terminado”
• Moravec escribió:
  “De manera bastante rápida, podríamos quedar desplazados y fuera de la existencia…Al igual que los hijos biológicos de generaciones anteriores, las máquinas representan la mejor esperanza de la humanidad para un futuro a largo plazo. Nos corresponde a nosotros ofrecerles todas las ventajas y cómo retirarnos cuando ya no podamos contribuir”
• I.J. Good escribió:
  Vamos a definir una máquina ultrainteligente como una máquina que puede sobrepasar como mucho todas las actividades intelectuales de cualquier hombre, por muy inteligente que sea. Puesto que el diseño de las máquinas es una de estas actividades intelectuales, una máquina ultrainteligente podría diseñar máquinas incluso mejores; entonces existiría incuestionablemente una “explosión tecnológica”, y la inteligencia del hombre quedaría bastante atrás. Así pues la primera máquina ultrainteligente es la última invención que haya hecho nunca el hombre, siempre que la máquina sea lo suficientemente dócil como para decirnos cómo controlarla.
• Anónimo:
  “La inteligencia artificial nunca podrá competir con la estupidez natural.”

 Para comprobar el rendimiento de nuestra plataforma de firma, hemos realizado una serie de pruebas de estrés sobre el API Web Service de Viafirma. El objetivo de estas pruebas ha sido obtener métricas de comportamiento y limites de carga para los diferentes servicios ofrecidos, para determinar el rango de operaciones en los que el servicio es estable.

Para las pruebas se han realizado firmas en servidor XADES de ficheros xml de 20k, utilizando como sistema de custodia ficheros y firmando con un certificado de Firma Profesional en software.

Se han realizado en dos tipos de entornos, el primero bastante precario en recursos y el segundo un entorno de producción real. En ambos casos pudimos comprobar que el comportamiento de Viafirma, ante un gran numero de peticiones fue más que aceptable.

Rendimiento de Viafirma con los requisitos Mínimos de Hardware

El entorno donde se realizaron las pruebas  es un portátil con un procesador Turion a 2 GHz y 2 gigas de RAM, con el servidor de aplicaciones  configurado para permitir 200 hilos concurrentes y con un máximo de 512 MB asignados.

Las pruebas se realizaron configurando un grupo de hilos simulando 100 peticiones por segundo en un bucle infinito.

A continuación se muestran los resultados obtenidos en la misma máquina y misma configuración en un entorno Windows y en un entorno Linux.

Pruebas sobre Windows XP SP 3 en JRE 6.0.11 de Sun

Como se observa en la gráfica, Viafirma mantuvo la cantidad constantes de 1.200 peticiones por minuto con una media de cerca de 5 segundos desde la entrada de la petición hasta su resolución y respuesta.  Mientras se realizaros las pruebas, Jconsole marcó en todo momento un consumo de memoria estable.

Pruebas sobre Ubuntu 8.10 en JRE 6.0.10 de Sun

Repetimos las pruebas en un entorno Unix, y observando que el rendimiento es algo mayor. Respondiendo una media de 2.100 peticiones por minuto.

Rendimiento de Viafirma con la configuración de Hardware recomendada

Después de haber hecho estas pruebas “de andar por casa”, hemos repetido la misma batería de pruebas sobre un entorno de producción, un  Ubuntu Server con 8 nucleos, 6 Gb de memoria y una configuración optimizada de la JVM 6.

Como podemos observar,  el comportamiento es excelente, alcanzando casi más de 7.500 firmas por minuto, manteniéndose totalmente estable la JVM y con el procesador nunca superando el 50% ( debido a los tiempos de espera impuestos por la red).

Esta mañana nuestro compañero Tino nos ha sorprendido con su nuevo diseño!

Después de la evaluación por nuestro departamento de calidad hemos podido verificar que cumple con todos los requisitos de accesibilidad y usabilidad.

Estos últimos días hemos estado realizando pruebas para comprobar el comportamiento de Viafirma en el nuevo sistema operativo de Microsoft, y los resultados no han podido ser mejores, el sistema se comporta perfectamente en Internet Explorer 8 sobre el nuevo Windows 7!!!.

Os dejo algunas capturas de pantalla:

• En caso de que el usuario no tenga instalado Java en su sistema, la detección de componentes inicial corrige esta situación e instala automáticamente la JRE.

• El componente de firma busca los certificados instalados en el sistema, detecta  los certificados presentes (en este caso un certificado de la FNMT) y nos permite realizar sin problemas la firma digital del documento.