viernes, marzo 26, 2010 at 10:05AM A continuación se presenta un artículo sobre las características principales de Spring Security 3.0.
El artículo lo podéis encontrar en la siguiente dirección:
http://federicojcdm.wordpress.com/2010/03/23/un-recorrido-por-spring-security-3-0/
Espero que os resulte de utilidad.
Federico Caro (Paradigma Tecnológico)
jueves, marzo 25, 2010 at 8:23AM
La idea es prácticamente similar a la de los Applet Java, sólo que el código no se termina ejecutando una máquina virtual, sino que se traduce al código máquina y es ejecutado directamente por el sistema operativo. En el servidor habría una representación intermedia entre el código fuente y el ejecutable final a la que llaman "bitecode" (qué originales). El navegador web se bajaría ese bitecode y lo transformaría a código nativo, qué sería lo que finalmente ejecutaría el equipo.
Por supuesto, en la traducción se podría inspeccionar el código y asegurarse de que no hace cosas raras, proporcionando un modelo de seguridad similar al actualmente empleado por los Applet Java. Básicamente, la idea de Google es la misma que la de los Applet, sólo que la máquina virtual sería "todo JIT y nada intérprete".
No tengo claro que esto sea una buena estrategia a seguir. Por un lado, requiere que todos los fabricantes de navegadores web lo soporten, o en su defecto que el usuario se baje algún tipo de plugin. Por otro lado, no tengo muy seguro de cómo de efectivos era un modelo de seguridad en el cual una vez realizada la traducción al código máquina no hay ningún tipo de "supervisión" de un entorno de ejecución, como sucede con la máquina virtual Java. ¿Qué pasa si el código máquina se manipula asimismo para transformarse y hacer cosas diferentes? ¿O si se le da por ejecutar áreas que inicialmente se suponía que eran áreas de datos?
La única forma en la que creo que esto podría funcionar es si Google proporciona los compiladores diferentes para las aplicaciones. Uno que compile a HTML, css y JavaScript, y otro que compile a bitecode. La aplicación funcionaría aunque el navegador no tenga soporte para Native Client. Pero sería más rápida si el navegador lo soporta.
¿Cual es son vuestras opiniones sobre este proyecto?
miércoles, marzo 24, 2010 at 3:15PM En la EclipseCon 2010 Red Hat ha anunciado una actualización mayor para su entorno de desarrollo, JBoss Developer Studio 3.0, y para su plataforma de Middleware, JBoss Enterprise SOA Platform 5.0. JBoss Enterprise SOA incluye actualizaciones importantes en el ESB y en mensajería donde recientemente la solución de JBoss (HornetQ 2.0) ha establecido un nuevo récord de rendimiento.
JBoss Developer Studio 3.0 está basado en Eclipse 3.5 e incluye un amplio número de plugins para trabajar con los productos de JBoss. Las novedades de esta versión son sobretodo herramientas para construir e integrar servicios web.
¿Cuantos por aquí empleais soluciones de Red Hat/JBoss?
miércoles, marzo 24, 2010 at 9:14AM Krystian Lider ha publicado en Javalobby dos artículos (Parte I y Parte II) comparando varias soluciones de Cloud/Grid computing: Hadoop, GridGain, Hazelcast, DAC. Según el autor, GridGain y Hazelcast son las soluciones que ofrecen un mejor precio para tareas que requieran un alto consumo de CPU, sean fáciles de paralelizar y no procesen un volumen de datos muy grande. Hazelcast es muy eficiente en cuanto a uso de CPU y ancho de banda, mientras que GridGain lo es en cuanto a consumo de memoria. Hadoop tiene su punto fuerte en el procesamiento de grandes conjuntos de datos.
El artículo incluye bastante gráficas evaluando distintas métricas de cada uno de los cuatro frameworks. También contiene todo el código fuente empleado en los test en los que se basa el artículo. Un excelente recurso; una pena que no incluye el servicio de Amazon.
martes, marzo 23, 2010 at 5:28AM Esta semana se celebra el EclipseCon 2010. En el primer día del evento la empresa Sonatype (creadora de Maven) anunció un proyecto nuevo que esperan mejore el soporte enterprise de Maven. Puedes ver aquí el comunicado de prensa.
Maven Studio una suite de plugins para Eclipse basado en m2 el plugin creado para Sonatype enfocado a facilitar el montar un ambiente de desarrollo. La idea es que tu desarrolles tu proyecto usando Maven y Eclipse y lo compartas simplemente enviando un mail y un link (a un jnlp). Los otros desarrolladores darán clic a dicho link y el ambiente configurado al 100% se instalará en su ordenador dejando listo para empezar a programar.
De esta forma se reduciría drásticamente el tiempo de replicar ambientes de desarrollo. Además, Maven Studio viene ya listo con integración con Tomcat, Confluence y Hudson. Que permite utilizar estos servidores con solo unos cuantos clics desde tu Eclipse.
Adicionalmente, se prepara una versión especial de Hudson con mayor soporte e integración con Apache Maven llamado Hudson for Maven. La unión de Maven Studio y Hudson for Maven se llamará Maven Enterprise Studio y estará disponible en el segundo cuatrimestre del año. Ambos productos serán comerciales y de pago, por ahora no se han revelado los precios.
Otra noticia que aparece en DZone es que dado el interés de Sonatype de actuar como hosting del repositorio de Maven para los proyectos de java.net, Oracle los ha contactado y les ha comisionado crear el repositorio de java.net lo que involucra organizarlo y limpiar las versiones. Sonatype publicará esta semana el repo público con dichos proyectos. Así que Oracle se convertirá en el primer cliente de Nexus Cloud, el producto en la nube para hosting de repositorios Maven de la empresa.
j2ee