¿Cuáles son las diferencias fundamentales entre OSGi y Java EE?

Question

Así que esta tarde me tomé un tiempo para finalmente sentarme y comenzar a leer el misterioso y elusivo "OSGi" y sus llamados paquetes .

OK, entonces yo creo Lo entiendo. Un "paquete" de OSGi es básicamente un JAR con cierta información de manifiesto adicional. Y, en lugar de implementarlo en un servidor de aplicaciones normal (u otro contenedor), lo despliega en un servidor OSGi como Apache Felix. Se ejecuta y luego proporciona servicios a usuarios/clientes.

¿Cómo es esto diferente de un EAR normal que se implementa en un servidor de aplicaciones?

OSGi parece estar en aumento (¡Me sigo topando!), Pero por mi vida no entiendo lo que ofrece (a nivel de característica) sobre cualquier cosa que pueda hacer con la empresa real servidor como GlassFish o Spring.

Sé que el mundo no se ha vuelto loco, así que obviamente me falta algo. Simplemente no he podido averiguar qué. Gracias por cualquier ayuda o visión!

Answer 1

Un paquete OSGi es más un "módulo de software" que un archivo "jar", "war" u "ear". Los paquetes OSGi raramente proporcionan beneficios si agrupan una aplicación completa; sin embargo, son muy beneficiosos para la automatización y el manejo correcto de conectar muchas bibliotecas.

Así que considere el problema que OSGi intentó resolver, y comprenderá mejor dónde encaja. Es el equivalente de Java del patrón de "herencia de diamantes" de C++. Incluye dos bibliotecas, cada una de las cuales necesita una biblioteca de registro común, pero en este caso no se debe a la herencia múltiple, sino a múltiples instrucciones de inclusión.

Si las dos bibliotecas funcionan con la misma versión de la biblioteca de registro común, tiene suerte. Si no es así, para que cada biblioteca funcione correctamente de forma independiente, debe cargar dos copias de la misma biblioteca, cada una de las cuales probablemente use los mismos espacios de nombre (y, a menudo, los mismos nombres de clase).

OSGi es un medio de agrupamiento que permite que se carguen dos versiones de la misma biblioteca que usan los mismos espacios de nombre, los mismos nombres de clase, pero se crearon en momentos diferentes. También conecta la versión "correcta" al paquete OSGi "correcto", evitando que un paquete use la versión "incorrecta" de la biblioteca "derecha".

Java EE hace mucho, pero esto no es algo a lo que Java EE siquiera se dirige. En el mejor de los casos, el proyecto Jigsaw estaba trabajando en el mismo problema. Donde entra en juego la confusión de Java EE/OSGi es que la mayoría de los primeros en adoptar OSGi bundling eran aquellos que estaban implementando funcionalidades similares a algunas de las bibliotecas que se ofrecen en Java EE. Dicho esto, el marco de conexión de contenedor real (OSGi) no tenía nada que ver con la funcionalidad del paquete (aunque parte del descubrimiento se modificó estructuralmente para cumplir con los requisitos de agrupamiento de OSGi).

Answer 2

La mayoría de los principales beneficios, al menos los motivos por los que usamos OSGi, se enumeran en http://karaf.apache.org/, notablemente los dos primeros.

Además, la alianza OSGi tiene una larga lista de beneficios: https://www.osgi.org/developer/benefits-of-using-osgi/.

Answer 3

Comparar Java EE con OSGi es como comparar manzanas y naranjas con la ventaja adicional de no saber qué es qué.

Java EE focus se basa en aplicaciones comerciales escalables de varios niveles en entornos heterogéneos e integración de sistemas de información para toda la empresa.

OSGi comenzó en otra esquina mediante la integración de varias bases de código independientes en una JVM (discúlpeme por ser extremadamente breve).

Por supuesto algunos problemas de (por ejemplo, implementación en caliente) son comunes a ambos entornos, pero en mayor o menor grado.

Por supuesto, puede actualizar, degradar y cruzar ambos y se encontrarán en algún lugar en el medio.

Así que la pregunta no debería ser "¿Qué beneficio tiene A sobre B?" Sino algo así como "¿En qué campo A tiene claras ventajas sobre B y viceversa?" Permítanme reformular eso: "¿Cuándo necesito un martillo y cuándo necesito una sierra?"

Answer 4

Lo siento, pero TODAS las respuestas aquí son completamente irrisorias. ¿Problemas de versión de dependencia resueltos con OSGi? Pooooohlease ... ¿Has oído hablar de las políticas de cargador de clases en los servidores de aplicaciones?

OSGi parece una idea para seguir vendiendo libros nuevos y capacitación, mientras que las necesidades funcionales han estado cubiertas durante eones por el empaque de JAR/EAR & despliegue en JEE. Aquellos que lo compran simplemente nunca llegaron a entender cómo están siendo manipulados. También hay una cuestión de tendencias y moda. Es decir. consideraciones no de ingeniería que son una vergüenza para esta industria.

Reinventar la rueda es rentable porque hay toneladas de tontos por ahí. Desafortunadamente, hay toneladas de simplones de tipo gerencial que quieren estar al "borde de la tecnología" que gustosamente financiarán los cursos de sus empleados, absorberán la curva de aprendizaje y luego pagarán por su nariz en "reingeniería" de las cosas eso no tenía nada de malo con ellos para empezar.

No se trata de "usar un destornillador de martillo". Es más una cuestión de "hola jefe, hay algo nuevo llamado HEMMAR, ¡y es genial!". "¿No es un HAMMER?", "No, no, es mejor, es un HEMMAR, es para clavar clavos en tableros, revolucionará el mundo".