Apache Wave In A Box

Cuando Wave fue abandonado, se comentaba que Google liberaría el proyecto con el nombre de Wave In A Box, pero sin seguir desarrollándolo. Pus bien, hoy Wave In A Box ya tiene a alguien que le empuje: la fundación Apache.

La fundación va a alojar el proyecto junto a los demás y va a impulsarlo con un equipo de desarrollo al igual que se hace con el servidor Apache. El producto se llamará Apache Wave In A Box, y la idea es que sirva para que cualquiera lo pueda instalar en un servidor sin problemas.

Según Apache, adoptan Google Wave porque hay bastante gente interesada en la continuidad del proyecto. Entre ellos están la recién comprada Novell, SAP o incluso la Marina de los EEUU.

Aunque Google Wave no tuvo una muy buena acogida, su tecnología es muy buena y compleja, y merece la pena ser guardada y desarrollada. Habrá que ver cómo evoluciona ahora Apache Wave y el tratamiento que le da la fundación Apache, y si consigue que Wave sea más aceptado de lo que lo fue con Google.

Dejo link:

http://wiki.apache.org/incubator/WaveProposal

¿Porque optar por soluciones Open Sources a la hora de desarrollar?

Como principal ventaja del software Open Sources se pensaría en el bajo costo dado que se relaciona Open Sources como gratis y esto no es así. Es un error pensar en el Open Sources como una solución barata dado que el software puede tener costo, pero además el software tanto Open Sources como comercial tiene costos ocultos. Como costo oculto podríamos nombrar la falta de soporte, o falta de documentación. Estos costos ocultos hay que tenerlos en cuenta a la hora de optar por un software.

El uso de frameworks open sources para el desarrollo de aplicaciones trae aparejado muchos beneficios que dependen de la comunidad que respalde el framework; cuanto mayor es la comunidad mayor va a ser el soporte, la documentación, calidad y los usuarios que usan el framework:

• Soporte: El soporte brindado puede ser mayor a una aplicación comercial y la información suministrada por foros de problemas es basta.

• Documentación: Si bien no es común que un software open source este bien documentado, la información suministrada por blogs, foros, libros es mayor que productos comerciales.

• Calidad de código: La calidad del código de framework open source es mayor ya que el código es visto por decenas de programadores y revisados por una comunidad de usuarios.

A la vez existen beneficios intrínsecos del software open sources:

• Usar el programa: podemos usar el programa sin ninguna restricción, ni siquiera comecial ya que podemos vender nuestro desarrollo, pero una restricción es que debemos incluir el código fuente en la venta.

• Libertad de aprender: podemos aprender del código fuente, aprender como fue hecho el framework y saber como realmente funciona. De esta forma el grupo de trabajo no esta limitada a ver solo la documentación sino que puede debugear el código fuente y palpar lo que hace realmente.

• Libertad de modificar: Si existe un bug, es posible corregirlo y publicar su corrección para que se encuentre en futuras versiones. Además podemos extender el framework como queramos, desarrollando nueva funcionalidad que luego podemos publicar para que la comunidad la pruebe y use.

Estas ventajas no son menores, dado que el conocimiento es el arma más importante en un grupo de desarrollo informático y el open source permite cultivar el conocimiento, dando nos el privilegio de leer las lineas de código y ver como funciona.

Apostar a el software open source es apostar al capital humano, con un grupo consolidado puede aprender y desarrollar mejor a partir del código fuente. Los desarrolladores aprenden como funciona el framework viéndolo funcionar.

Utilizar software Open Source no solo beneficia a quien lo usa sino a toda una comunidad.

Spring Dynamic Modules for OSGi(tm) Service Platforms

Spring Framework es el principal contenedor de aplicaciones Java / JEE. Proporciona un contenedor ligero y un modelo de programación no invasiva, esto es posible gracias al uso de la inyección de dependencia, AOP, abstracciones y portátiles servicio. La Plataforma de Servicios OSGi ofrece un entorno de ejecución de aplicaciones dinámicas en las que los módulos (paquetes) puede ser instalado, actualizado, eliminado sobre la marcha. También cuenta con un excelente apoyo para la modularidad y control de versiones.

Spring DN hace que sea fácil crear aplicaciones que se puedan implementar en un entorno de ejecución de OSGi, y que pueden aprovechar los servicios que ofrece el marco OSGi

Spring DN es un proyecto para hacer más fácil la construcción de aplicaciones que corren en un framework OSGI. Una aplicación hecha con spring DN provee un perfecto camino para la separación de la aplicación en módulos. usando OSGI podemos levantar en caliente un modulo y a la vez tener diferentes versiones de los modulos levantado.

OSGi 4.2 introduce the Blueprint Service especificación basada en Spring Dynamic Modules.

Dejo el link:

http://www.springsource.org/osgi

Apache Aries

El proyecto Aries ofrecerá un conjunto de componentes enchufables (plugins) Java que permite a una aplicación empresarial utilizar estos plugins usando modelo de programación OSGi . Esto incluye la implementación y extensión de las especificaciones definidas por OSGi Alliance Enterprise Expert Group (EEG)

Apache Aries nos permitirá consumir por medio de OSGI módulos que nos brinden la persistencia JPA por ejemplo. Pluging que le den valor agregado a la aplicaciones o frameworks que nos ayuden a desarrollar podrán ser utilizados usando OSGI.

OSGi es una tecnología de modularidad madura de Java, que es muy usado en muchos ambientes, pero, en el ámbito empresarial, ha sido tradicionalmente más explotados por la parte interna, infraestructura runtime. Esto es principalmente debido a la falta de un claro modelo de programación empresarial OSGi, y la falta de aplicación e implementación de OSGi para la tecnología JEE.
Especificaciones OSGi son dictadas y mantenidas por la OSGi Alliance, que reconoce este estado de cosas hace varios años y estableció un grupo de expertos en aplicaciones enterprice dentro de la Alianza para centrarse específicamente en las necesidades de aplicaciones empresariales. El objetivo de este proyecto es entregar implementaciones de código abierto de estas tecnologías centradas en la aplicación para permitir el desarrollo de componentes, en beneficio de la modularidad de OSGi en combinación con modelos de programación basados en estándares, que pueden ser desplegados en tiempo de ejecución.

Es un objetivo del proyecto Aries proporcionar un hogar natural para las implementaciones de código abierto de las actuales y futuras especificaciones OSGi EEG, incluyendo la oportunidad para el desarrollo colaborativo de pruebas de cumplimiento, y un entorno para demostrar la composición de estas tecnologías y explorar áreas EEG donde carecen de cobertura de las especificaciones. Otro objetivo de este proyecto es aprovechar la experiencia adquirida a informar a las contribuciones a OSGi requisitos EEG y documentos de especificaciones.

Apache Aries esta en la incubadora esperemos que pronto salga de ahí y nos sorprenda con nuevos módulos para nuestra aplicación.

OSGI y SCA

Antes de empezar vamos a describir estas tecnologías.

OSGI (Open Services Gateway Initiative), podríamos definirlo como un sistema (o framework) modular para Java que establece las formas de crear módulos y la manera en que estos interactuaran entre sí en tiempo de ejecución. OSGI intenta solventar los problemas del tradicional "classloader" de la máquina virtual y de los servidores de aplicaciones Java. En OSGI, cada módulo tiene su propio classpath separado del resto de

classpath de los demás módulos.

SCA (Service Component Architecture) es un estándar de OASIS originalmente creado por diferentes vendedores como BEA, IBM, Oracle, SAP, etc. La especificación SCA define como crear un componente y como estos componentes interactúan para formar una aplicación. Los componentes en SCA pueden ser construidos en Java o en otros lenguajes y además permite interactuar con otras tecnologías como JEE, Spring o BPEL. SCA define un mecanismo común de ensamblaje que indica como los componentes son combinados dentro de la aplicación.

El objetivo de SCA es a nivel alto o de negocios en ca

mbio el objetivo de OSGI esta centrado en la modularidad por lo tanto es de más bajo nivel.

Los Micro-Kernels se volvieron cada vez más populares (jboss, glassfish, ...). OSGi ha estandarizado muchos de los "servicios del núcleo" (registro, configuración, aprovisionamiento) de móviles, y ahora comienza a entrar en la empresas. Considerando que el enfoque JEE fue en la infraestructura de middleware, OSGi provee muchas ventajas que quedaban a cargo de los desarrolladores. La Carga dinámica (Dynamic loading) de OSGi hace perfecto los micro-núcleo, dado que no es necesario bajar el servidor para cargar un modulo, el nucleo tiene solo lo necesario y los módulos se van cargando a medida que se los demande.

La composición de los servicios/componetes se llevará a cabo y se expone como un servicio de negocios con múltiples puntos finales. Este es el lugar donde podemos ver que la pareja OSGi / SCA aporta mucho y ayuda a centrarse en su negocio. Módulos OSGi para gestionar los componentes técnicos para mantener los principios DRY (Don't Repeat Yourself) y SCA para exponer punto final de negocios con conexión automática y la seguridad habilitada.

Este esquema tomado de la página de Apache Tuscany expresa como SCA cablea los servicios de negocio. Como SOA típico, expondrá su "contrato". Dentro de SCA, va a configurar, además, cómo quieres que lo exponga (usando RMI, WS o cualquier tipo de protocolo).

Al hacerlo, le permiten decidir el protocolo en la fase de implementación, no en la fase de desarrollo. Esto hace que su software sea muy flexible y le permiten centrarse en el código de negocio.

Gestión de módulos y componentes y hay dependencias requieren el uso de una herramienta automatizada (Maven, nexus).

Apache Tuscany es una implementación de SCA que en su versión 2.0 traera el esquema OSGI. Apache Tuscany 2.0 fue totalmente reescrito para soportar OSGi.

Manual de OSGI

Javahispano publico unos manuales de OSGI que vale la pena leer:

http://www.javahispano.org/contenidos/archivo/14922/OSGI_Roberto_Montero.pdf

http://www.javahispano.org/OSGI_II_Roberto_Montero.pdf

Muy recomendables espero que les guste!!

Mi nuevo vicio

No soy adicto a nada electrónico, ni este blog, ni twitter, ni facebook, ni nada. Cuando tiempo le meto a estas cosas pero no me sacan el sueño. Algo que me esta sacando el sueño es un juego llamado GNU Chess, un ajedrez hecho para GNU/Linux, es muy muy bueno.

GNU Chess es un programa de computadora para jugar ajedrez. Es uno de los más antiguos juegos de ajedrez en computadora para los sistemas basados en Unix y ha sido portado hacia otras plataformas. El GNU Chess project (Proyecto de Ajedrez GNU) es una de las partes más viejas del paquete de software GNU, habiendo comenzado en 1984. La primera versión del GNU Chess fue escrita por Stuart Cracraft.¹ Todas las versiones subsecuentes antes de la versión 5 fueron escritas por John Stanback.

Todavía no le gano pero ya va a llegar el momento!!

Wow ebook

wowebook es una pagina web en la cual se comentan, describen y comparten libros de programación, soa, web, etc.

Muy buena pagina, se las recomiendo:

http://www.wowebook.com

Manual de Json

JSON, acrónimo de JavaScript Object Notation, es un formato ligero para el intercambio de datos. JSON es un subconjunto de la notación literal de objetos de JavaScript que no requiere el uso de XML.

La simplicidad de JSON ha dado lugar a la generalización de su uso, especialmente como alternativa a XML en AJAX. Una de las supuestas ventajas de JSON sobre XML como formato de intercambio de datos en este contexto es que es mucho más sencillo escribir un analizador semántico de JSON.

Es importante hoy en día en que el mundo web es un mundo ajax tener en claro que es json; por lo tanto dejo un link interesante:

http://www.slideshare.net/Emmerson_Miranda/json-short-manual-5732305

Algo que no dice el manual es que json es más rápido que xml, cuando lo usamos con ajax y esto es razonable dado que no tenes el tiempo de parseo del xml o algun otro formato.

Por lo tanto usen json!!!

maven 3

Los desarrolladores de Apache Maven (en su mayoría empleados de Sonatype) han estado trabajando desde hace tiempo en la versión 3 de esta popular herramienta para compilación de proyectos Java. La semana pasada han liberado la primera versión beta y Michel Pronschinske en DZone ha hecho un breve repaso de lo nuevo que viene en Maven 3.

Lo más importante para los usuarios de Maven, es que se ha puesto especial énfasis en conservar la compatibilidad con las versiones previas. Por lo que prácticamente para empezar a usarlo en tus proyectos hechos con Maven 2, no tendrás que hacer ninguna modificación, más allá de corregir declaraciones de dependencias duplicadas y la forma de declarar los plugins.

En cuanto a características nuevas la más interesante es el soporte para extension points. Herramientas que colaborarán de forma integral con Maven 3 para añadir funcionalidades.

Entre estas herramientas, destaca Polyglot Maven (http://polyglot.sonatype.org/), que permite construir los POM ya no en XML sino usando lenguajes soportados por la JVM. Por ahora, Groovy, Scala y Clojure. Un poco en la línea en que Gradle hace uso de Groovy para estos fines.

Otra herramienta que hace uso del extension point es Maven Shell. Un shell para ejecutar maven que da ciertos beneficios como caching de archivos POM, integración con arquetipos, integración con nexus, con hudson, etc. La idea es que si lo usas podrás reducir tus tiempos de compilación y construcción de proyectos Maven.

También han mejorado m2Eclipse, el plugin oficial para integración con el IDE Eclipse. Ahora prometen mejorar el desempeño de Maven dentro de Eclipse en rango del 200 al 300%. Además de mejorar el soporte para las tareas de Maven.

Internamente, Maven 3 ha sufrido una completa reestructuración que ha llevado a cambios tan importantes como quitar a Plexus como libreria IoC (Inversión de Control) y ahora usan Google Guice y ya tienen soporte para OSGi.

Ya puedes probar Maven 3 descargándolo del sitio de Apache (http://maven.apache.org/download.html) Por el momento no hay mucha documentación sobre las nuevas features del producto, pero seguramente y como Sonatype ha hecho con Maven 2, en el futuro próximo la tendremos.