Acerca de OSGi por Jorge Medina

OSGi no reemplaza a Spring, no proporcionan la misma funcionalidad.

Spring esta basado principalmente sobre de el concepto de Inyección de Dependencias (ignoro si este es el termino en español comunmente usado para "dependency injection"). Esto permite el usar POJOs (plain java objects, objectos java simples), dejando que Spring inyecte otros objectos requeridos por el POJO.

OSGi proporciona funciones mas parecidas a un contenedor web, pero es mas versatil. Un contenedor web (Tomcat) te permite cargar varias aplicaciones que trabajan de manera independiente. El aislamiento de las aplicaciones se logra a través de diferentes "class loaders" (cargadores de clases?). De esta forma, una aplicación queda aislada de los efectos de otras -ya que las clases son cargadas en memoria de manera independiente-. OSGi proporciona dicha funcion, pero no pone restricciones en las aplicaciones (no tienen que ser servlets o aplicaciones web). OSGi es mas flexible. OSGi permite que aplicaciones cooperen con otras a traves de interfaces declaradas en archivos de configuracion. Asi, por ejemplo, puedes cargar dos aplicaciones que comparten la mismos componentes comunes, sin que las clases se cargen independientemente en memoria pero sin que una afecte a la otra.

En otras palabras, OSGi te permite crear aplicaciones a partir de componentes. Estos componentes son cargados en distintos class loaders. Dos ( o mas componentes) pueden interactuar entre si unicamente a traves de interfaces declaradas explicitamente en archivos de configuracion (en xml).

OSGi te permite el cargar o descargar componentes. O cargar diferentes versiones de dos componentes y reenlazar los componentes existentes de manera dinamica. (Tal como Tomcat te permite el cargar y descargar una aplicación web, pero con mucha mayor flexibilidad)

OSGi es utilizado en teléfonos celulares y PDA; me parece que fue esta industria la que creo el concepto y las primeras espeficicaciones. El aislamiento proporcionado por OSGi permite que la falla en una aplicacion o componente no afecte a las aplicaciones que no los usan.

Si has desarrollado plugins para Eclipse entonces ya te habras dado cuenta de que aporta OSGi. Netbeans usa un framework con funcionalidad similar, pero no es OSGi. Mientras que Eclipse esta basado en OSGi (por lo menos el kernel de Eclipse). Cabe mencionar que OSGi no tiene ninguna relacion con desarrollo de IDEs o GUIs, pero que el concepto utilizado pro Eclipse y/o Netbeans para cargar los plugins es similar a la funcionalidad proporcionada por OSGi.

OSGi tambien proporcina especificaciones para seguridad. (Por ejemplo, para cargar unicamente componentes que han sido firmados y verificados en su integridad).

Sin embargo, yo no he notado que se generalize el uso de OSGi. (Basta con buscar empleo con la palabra OSGi como termino de busqueda para darse cuenta que aun no se usa mas que en ciertos nichos o en en algunos start-up).

Yo trabajé para una compañia que tenia un "framework" con funcionalidad similar pero muy limitada, y que no tenia recursos para mantenerlo y expandirlo. Lo ideal habria sido el moverse hacia OSGi, pero eso implicaba reescribir muchos modulos...y generar la experiencia en el grupo de desarrollo. Mi sugerencia realmente nunca fue considerada como viable, pero yo creo que OSGi es una herramienta potente y que muchos esfuerzos de desarrollo pueden beneficiarse usandola. Sin embargo, creo que aun falta mucho para que se generalize su uso.

OSGi es solo una especificación. Hay diferentes implementaciones. Wikipedia puede darte mas información al respecto.

En terminologia OSGi, los componentes o aplicaciones son llamados "bundles". (Eclipse los llama "plugins", Netbeans tiene el concepto de "modulos", pero en general son la misma cosa). Las interfaces son llamadas "Servicios" en OSGi. ( por interface, no me refiero a interfaces Java, pero en la practica los Servicios son expuestos a traves de interfaces Java)

Yo espero haberlos confundido y despertar su curiosidad. Los invito a leer la "OSGi Service Platform Specification" disponible en www.osgi.org

Saludos,
Jorge Medina

Olvide mencionar algunos puntos interesantes:

Cuando tu aplicacion es desarrollada como OSGi "bundles", esto permite que sea posible integrarla en diferentes plataformas (implementaciones) OSGi. (Claro, asumiendo que las dependencias de tu aplicacion (bundle, bundles) esten disponibles en dicho contenedor OSGi). Pero aun si no lo estan, es posible escribir otros "bundles" que actuen de adaptadores.

Yo veo OSGi como un habilitador de desarrollo modular expandido a tiempo de ejecución. (Puedes cambiar componentes sin tener que detener la aplicacion, simplemente cargas la nueva version, actualizas las dependencias y listo! Es como cambiar de llantas a un automovil en movimiento! 8-) No necesitas recompilar, no necesitas reiniciar el contenedor.

Obviamente, el desarrollo efectivo de OSGi requiere el diseñar la aplicación sobre el concepto de "bundles" que proporcionan servicios a otros "bundles". Puedes usar "bundles" desarrollados por otras organizaciones, pero si no quieren depender en su interface, puedes crear otro bundle que sirva solo como enlace.

Yo creo que algunas de las metas de OSGi es evitar el tener que reiniciar todo el sistema (JVM); disminuir el consumo de memoria (como en los PDA y celulares) y hacer que el sistema sea robusto a fallas en applicaciones...Todo esto usando dentro de la misma JVM. En mi opinion, esto fue lo que motivo su desarrollo dentro de la industria de dispositivos moviles. Sin embargo, la flexibilidad que porporciona mediante interfaces declarativas (xml) ha expandido su uso a otros campos. (IDEs, software para automoviles, o para administracion de edificios inteligentes, etc) Por ejemplo, yo creo que el uso de una sola JVM es util para un dispositivo movil, pero no es una necesidad ni en un automovil, ni en una aplicación de escritorio donde la memoria o energia no es una limitante importante.

Saludos nuevamente!

Jorge