OSGi, un Futuro para SOA?
En 1999 se creo la Alianza OSGi (Open Services Gateway Initiative) en un intento de crear un modelo de componentes dinámicos para sistemas embebidos de red; orientado principalmente a la plataforma JAVA y que permitía la gestión de la carga dinámica, el versionado y los ciclos de vida de servicios en forma de paquetes (o componentes).
Con el tiempo, OSGi ha evolucionado más allá de un simple uso para redes domésticas (como fue concebido inicialmente) a un modelo de contenedor capaz de solucionar muchos de los problemas que existen actualmente en los servidores de aplicaciones (empaquetado, abstracción de los paquetes, carga dinámica de los mismos, dependencias, gestión del ciclo de vida, versionados, etc…).
En OSGi, un paquete o componente es poco más que un jar tradicional de Java, con sus interfaces, implementaciones y un fichero manifiesto. Dicho componente se podrá definir por cierta meta-información de su fichero manifiesto que especificará los servicios exportados y los permisos necesarios para poder ser reutilizados por otros componentes.
Además, OSGi nos permitirá la gestión del ciclo de vida del software (tales como instalación, parada, redespliegue, arranque o desinstalación de paquetes) chequeando las dependencias existentes para el paquete tratado y evitando conflictos de ejecución.
Nos permite también la gestión de versiones de los paquetes, permitiendo la coexistencia de distintas versiones según necesidades y dependencias establecidas.
Por último, OSGi nos permite un modelo de Programación Orientado a Servicios (aquí basa su modelo en SOA), ya que (al contrario de EJB o RMI que necesita definir interfaces remotas) los servicios son publicados y registrados en el contenedor automáticamente durante la carga de los mismos.
Actualmente, todos los que usamos el framework de Eclipse 3.0, estamos usando OSGi de manera indirecta (Eclipse lo adoptó y de hecho fue uno de los mayores propulsores de OSGi en su momento; ahora evolucionado al Proyecto Equinox).
Lo importante, es la adopción de este modelo como parte de las estrategias para los productos de diversos fabricantes (Apache Felix, Newton, BEA mSA, etc…) y principalmente en el lado del servidor (que es donde OSGi puede sacar su mayor potencial a relucir como parte de los servidores de aplicaciones).
Algunos hablan de OSGi como el próximo middleware universal, las posibilidades de descubrimiento y reutilización de servicios y las posibles alianzas entre OSGi y Spring (suma todas las características enunciadas sobre OSGi a la facilidad de uso de Spring a base de inyección de dependencias y la programación orientada a aspectos) o entre OSGi y SCA (en este sentido OASIS tiene pendiente la estandarización de SCA).
Links interesantes:
OSGi Alliance
An Introduction to OSGi on the Server Side
Interesante discusión sobre si OSGi es SOA
Power Combination: SCA, OSGi and Spring
On SOA, OSGi and More
Universal Middleware: What’s Happening With OSGi and Why You Should Care
Está claro que el empaquetado y versionado de librerías mediante simples jar, a pesar de haber sido útil todos estos años, ha puesto también de manifiesto muchas carencias.
OSGi da solución a estos problemas, además de ofrecer más funcionalidades, como la carga dinámica de paquetes, etc. Además, lleva ya bastante tiempo en el mercado y es por tanto una especificación madura que, según veo yo, va camino de convertirse en un estándar de facto.
Por otro lado, Sun ha definido una especificación alternativa, Java Module System (JSR 277), prevista para ser lanzada en Java 7. ¿Hasta qué punto tiene eso sentido, cuando OSGi ofrece ya solución a esos problemas? Hay quien espera que al final Sun aproveche lo que ya hay (OSGi) en lugar de crear un nuevo estándar compitiendo absurdamente con una especificación que ha demostrado su solvencia.
La realidad es que OSGi está siendo adoptado no solo para el middleware de servidor, sino como plataforma de ejecución en plataformas cliente, como nuestros windows, linux, etc. llegando incluso hasta plataformas móviles como Windows Mobile, etc.
Esta evolución permite la creación de cosas, como, por ejemplo, un solo modelo de programación (J2EE) en entornos servidor, ordenador personal y PDA, haciendo que los servlets y jsps corran en estos entornos.
Además el esquema de OSGi, permite una interacción entre distintas aplicaciones hasta ahora no experimentada. Para muestra echad un vistazo al RCP de Eclipse.
Gente como IBM ya empieza a comercializar su Lotus Notes 8 y Sametime, Sinphony (basado en el openOffice), etc con la plataforma RCP por debajo.