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
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!
- Inicie sesión o regístrese para enviar comentarios
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.
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.
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:
Pero porqué en realidad JSR es un choro.
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".
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
Module Hell
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.
OSGi DSL
Aquí un DSL para OSGi, en Groovy. Tal vez con esto quede un poco más claro lo que hace OSGi...
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.
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....