La opinión del creador de Spring sobre OSGi

Acabo de leer en un extracto de las declaraciones del fundador de Spring sobre OSGi.

La parte de las declaraciones es esta:

"What we found in the server space, is frankly, TC server is a much better fit for what people want. It doesn’t have the advanced module system, but it’s got an incredibly small footprint. The benefit that most users want is a server that has a really small memory footprint, good management, fast startup time,and you can get those things without the complexity of OSGi."

En palabras de JavaHispano “Según Rod Johnson, OSGi sencillamente no puede ser hecho lo suficientemente sencillo y productivo para ser consistente con los valores del framework Spring. Para él, con el tiempo ha quedado claro que esta tecnología es una tecnología para nichos muy acotados, pero que nunca va a ser mainstream.”

Seguro que a Pedro le hace gracia leerlo, u otra cosa, pero seguro que puede corroborarlo, porque invocar a un servicio OSGI dentro de un WAS es casi una labor de ingeniería…

Spring tenía un proyecto interesante basado en OSGi: Spring Dynamic Modules for OSGi que han cedido a la fundación Eclipse, yo pensé que con la idea de convertirlo en estándar

Javolution, libreria java determinista.

Esta librería tiene como objetivo hacer las aplicaciones Java más rápidas y con un comportamiento predecible, lo cual consigue  a través de:

• Clases java de alto rendimiento para util, lang, text, io y xml.

• Contextos programados para permitir una mayor separación de los características de ciertas partes de nuestro código, ConcurrenContext, StackContext…

• Un framework de test unitarios orientado también a rendimiento y test de regresión.
• Capacidades de computación paralela de bajo nivel sencilla de usar a través del ConcurrentContext.
• Clases base Struct y Union para permitir interfaces directos con clases nativas de C/C++.
• El serializador XML más rápido y el primero determinista.
• Gestión de la configuración simple y flexible

Para utilizarlo solo necesitaríais añadir la siguiente dependencia en vuestro pom.xml:

       <dependency>
          <groupId>javolution</groupId>
          <artifactId>javolution</artifactId>
          <version>5.5.1</version>
      </dependency>

Esta preparada para OSGi con lo cual puede resultar una opción muy interesante para desarrollos de sistemas muy ligeros con necesidades de tiempo real.

Esta librería es usada por varios proyectos entre ellos el más conocido por nosotros es Oval, y podéis obtener más información sobre la misma en http://javolution.org/

OSGi y Spring Dynamic Modules

Siguiendo con los posts sobre OSGI:

- OSGi: Primeros pasos y el inevitable Hello World

- OSGi y Apache Karaf

Hay va una referencia a un buen artículo sobre cómo iniciarse en OSGi con Spring Dynamic Modules, sin duda la forma más sencilla de introducirse en los entresijos de OSGi.

Spring 2.5 ya ofrece declaraciones para Servicios OSGi:

OSGi y Apache Karaf

Últimamente he estado investigando sobre las posibilidades de OSGi para la integración y me he topado con el proyecto Felix que es el enfoque de Apache para la implementación de OSGi. Este proyecto dispone de un entorno de ejecución llamado Karaf, el cual me ha llamado la atención muy positivamente por la sencillez de uso y la flexibilidad que nos ofrece, además de permitir el uso de Felix o Eclipse Equinox como contenedores OSGi

Apache Felix Karaf nos proporciona las siguientes funcionalidades:

• Despliegue en caliente. Se monitoriza el contenido de los ficheros del directorio deploy y cada vez que copia un jar en este directorio el componente es instalado en el entorno de ejecución. De igual manera si se actualiza o borra el mismo estos cambios se controla automáticamente.
• Configuración dinámica. Los servicios se configuran habitualmente a traves del servicio OSGi ConfigurationAdmin el cual es alimentado por karaf a partir de los ficheros properties incluidos en el directorio etc. Y si alguno de estos ficheros es modificado el sistema se encarga de propagar ese cambio a los servicios.
• Sistema de Logging. Dispone de un backend centralizado de jogging gestionado por Log4j.
• Suministro. El suministro de librerías y aplicaciones se puede realizar de diferentes formas a través de las cuales las mismas se descargaran localmente, instalaran e iniciaran.
• Integración nativa con el sistema operativo. Se puede integrar en tu sistema operativo como servicio de cara a vincularlo al ciclo de vida del mismo.
• Consola de shell extensible. Dispone de una consola de texto para gestionar servicio e instalar nuevas funcionalidades así como gestionar su estado. Siendo la misma fácilmente extensible con nuevas características.
• Acceso remoto. Permite el uso de clientes ssh para acceder remotamente a su consola.
• Framework de seguridad. Basado en JAAS.
• Gestión de instancias. Permite gestionar múltiples instancias de karaf a través de la consola.
• Soporta los siguientes contenedores OSGi 4.2: Apache Felix 2.0.0 y Eclipse Equinox 3.5

La consola que nos proporciona dispone de una buena ayuda a la escritura de comandos y es fácilmente extensible:

Es por ello que recomiendo este entorno para aquellos que hagan su primera aproximación a OSGi.