Duda ¿Qué es OSGi?

Tengo esta duda desde hace algún tiempo.

He visto continuamente que OSGi por aquí y OSGi por allá, pero no me queda muy claro.

El hecho de que cada tecnología/framework/aplicación/whatever usa las mismas palabras para definirse no ayuda en mucho:

__________ es framework que ayuda a reducir complejidad, acelerar el desarrollo, disminuir costos, aumentar ganancias, eliminar dependencias, te ayuda a dormir mejor sabiendo que tu software esta seguro, lava, seca, plancha, pica, ralla y se guarda en cualquier lugar etc. etc. etc

Ver:

Sucede que como en muchas cosas, cuando sabes que es, la explicación resulta clara y correcta, pero cuando no tienes una idea clara ( como yo ) cada parrafo que leo me hacen imaginarme distintas cosas.

Por lo que logro entender de:

Sirve para administrar aplicaciones permitiendoles instalar/actualizar/detener/reiniciar los componentes que la integran. ¿Es como un estándar de aplicaciones grandes o algo así? ( se me ocurre algo como POSIX para los sistemas operativos, pero para aplicaciones :-S No sé esa es mi duda )

Aquí hay un gráfico de la arquitectura de servicios de OSGi:


OSGi Service Gateway Architecture

Pero si le cambio el título sirve igual:


Next Generation Super Framework Architecture


Ultra Xyz library Architecture


Magic Operating System Architecture


Mazinger Z Robot Arquitecture

Ya sé, ya sé, estoy exagerando, pero he de admitirlo, yo aprendo mejor con ejemplos más concretos.

Así que, ¿alguién podría explicar con palabras más sencillas y de preferencia con un ejemplo concreto, qué es OSGi? Por ejemplo sé que Eclipse, GlashFish y Spring usan OSGi, pero como que nomás no logro entender como.

Saludos!

Opciones de visualización de comentarios

Seleccione la forma que prefiera para mostrar los comentarios y haga clic en «Guardar las opciones» para activar los cambios.

Cómo dirían algunos de esta

Cómo dirían algunos de esta comunidad: "aquí encontre la eTZplicación".

Super whishmaster.. Aunque

Super whishmaster..

Aunque parezca ridículo, esto es lo que me ayudó e entenderlo ( más bien a encontrar un simil )

"Este paradigma es similar a la solución definida en SOA, por ello se dice que: OSGi = SOA en una JVM"

Ahora todo va cobrando sentido, unas cuantas leídas más y listo!

Gracias.

Imagen de Sr. Negativo

OSGi ???

Estos términos extraños y nada útiles muchas veces dificultan el aprendizaje.

¿Para qué ponerle un nombre rídiculo a lo que ya existe?, es como ponerle zxinlongos (no existe la palabra me la inventé) a los perros y yumixcy a los gatos. Pero como se escuchan muy extravagantes han de ser más interesantes.

Imagen de luxspes

OSGI: Para que? Para modularizar

Tal vez un modo de entender OSGI es conocer uno de los problemas que que resuelve: ClassPathHell. Básicamente, Java no tiene incluido un mecanismo para representar modulos, (los .jar son conjuntos de .class enzipados, pero no son modulos realmente), por que NO habia (hasta antes de OSGi) un entandar de facto (no de jure) para definir las reglas de versionamiento, dependencias entre modulos, carga y descarga dinamica de modulos, etc).

Se supone que muchas de las ideas de OSGi se estan convirtiendo en el Java Module System ... pero no se que tan bien este resultando este esfuerzo de estandarizacion (mucha gente dice que simplemente deberia haberse dicho "OSGi sera el estandar" en ves de entrar en todo el choro de hace un JSR...)

Re: OSGI: Para que? Para modularizar

Exacto, con lo último más de uno comentan:

mucha gente dice que simplemente deberia haberse dicho "OSGi sera el estandar" en ves de entrar en todo el choro de hace un JSR...

Pero porqué en realidad JSR es un choro.

Imagen de Sr. Negativo

Yo no le entiendo nada al OSGi


"
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.
"

¿Alguien le entendio? yo no.

Al igual que la promesa de los Frameworks de "facilitarte las cosas y dejar de escribir tanto código".

Imagen de ezamudio

Problema y solución

OSGi resuelve (o intenta resolver) un problema que es bastante complejo. La solución a dicho problema no es sencilla, tampoco. Si no has tenido que usar OSGi es porque no te has topado con el problema, y está bien y qué bueno. No veo la necesidad de "echarle tierra" a algo porque no se entiende lo que hace. Yo nunca he tenido que hacerme una resonancia magnética, no por eso digo que eso es una jalada y que no sirve para nada y que con puras aspirinas me la he llevado bien tranquilo toda mi vida.

El problema que OSGi pretende resolver, visto de manera muy simplista, es de conflictos de versiones. Tienes dos aplicaciones conviviendo en un contenedor. Resulta que una utiliza la biblioteca chido-1.0.jar y la otra utiliza una versión más nueva, chido-1.5.jar. Hubo cambios en el API de la biblioteca desde la versión 1.0 a la 1.5 por lo tanto la aplicación A no puede usar la versión 1.5 sin recompilar, y la aplicación B tampoco puede usar la versión 1.0 sin recompilar.

Ambas aplicaciones están en el mismo contenedor. Normalmente esto se puede resolver "bien fácil", metiendo en cada aplicación la biblioteca con su correspondiente versión, y ya. Las broncas empiezan cuando resulta que ambas aplicaciones tienen componentes en común que deben compartir (a nivel deployment, no fuentes), o cuando resulta que el contenedor mismo trae incluido algo como chido-1.3.jar y lo necesita para funcionar; y aunque pudieras cambiarlo por chido-1.0 o chido-1.5, eso sólo le resuelve la bronca a una de las dos aplicaciones.

A grandes rasgos, lo que OSGi permite es que la aplicación A pueda cargar chido-1.0.jar sin importar que el contenedor tenga chido-1.3.jar y la aplicación B puede cargar chido-1.5.jar sin importar que el contenedor tenga chido-1.3.jar o que la A tenga la 1.0.

Es un problema aburrido, tedioso, y cuando te topas con él agradeces que exista algo como OSGi.

Justo como "SOA dentro de una

Justo como "SOA dentro de una JVM" :) Entiendo que el que te resuelve esos problemas debe de ser "algo" como el service bus :P

Imagen de luxspes

Module Hell

Justo como "SOA dentro de una JVM" :) Entiendo que el que te resuelve esos problemas debe de ser "algo" como el service bus :P

En realidad, este problema deberia resolverlo la JVM misma.... o cuando menos tu Servlet o tu EJB container... pero no lo hacen, y por eso tuvieron que inventar OSGI y por eso Java 7... (o tal ves 8... o 9... o 10? ;-)) tendra esta caracteristica. Yo si he vivido los problemas de tener conflictos de .jars y de verdad es desesperante...

Ahora... la analogia OSGi SOA.. como que no me acaba de hacer click... yo mas bien diria que OSGi le da algo como los Assemblies de .NET a Java.

Imagen de ezamudio

OSGi DSL

Aquí un DSL para OSGi, en Groovy. Tal vez con esto quede un poco más claro lo que hace OSGi...

Imagen de Sr. Negativo

Re:Problema y solución

...
"El problema que OSGi pretende resolver, visto de manera muy simplista, es de conflictos de versiones. Tienes dos aplicaciones conviviendo en un contenedor. Resulta que una utiliza la biblioteca chido-1.0.jar y la otra utiliza una versión más nueva, chido-1.5.jar. Hubo cambios en el API de la biblioteca desde la versión 1.0 a la 1.5 por lo tanto la aplicación A no puede usar la versión 1.5 sin recompilar, y la aplicación B tampoco puede usar la versión 1.0 sin recompilar.

Ambas aplicaciones están en el mismo contenedor. Normalmente esto se puede resolver "bien fácil", metiendo en cada aplicación la biblioteca con su correspondiente versión, y ya. Las broncas empiezan cuando resulta que ambas aplicaciones tienen componentes en común que deben compartir (a nivel deployment, no fuentes), o cuando resulta que el contenedor mismo trae incluido algo como chido-1.3.jar y lo necesita para funcionar; y aunque pudieras cambiarlo por chido-1.0 o chido-1.5, eso sólo le resuelve la bronca a una de las dos aplicaciones.

A grandes rasgos, lo que OSGi permite es que la aplicación A pueda cargar chido-1.0.jar sin importar que el contenedor tenga chido-1.3.jar y la aplicación B puede cargar chido-1.5.jar sin importar que el contenedor tenga chido-1.3.jar o que la A tenga la 1.0.

Es un problema aburrido, tedioso, y cuando te topas con él agradeces que exista algo como OSGi."

Buena explicación. Pero aun asi creo que es bastante tedioso. Que bueno que nunca me he tenido que usarlo.

Imagen de neko069

Yo alguna vez me topé con una

Yo alguna vez me topé con una bronca así.... y la solución fué bajar los fuentes de ambos jar, cambiar el empaquetado de cada versión para distinguir entre versiones, y usar el nombre calificado de los objetos que se necesitaban .... eso tiene más de 2 años y medio, y todavía tengo pesadillas al respecto....