kit - java jee api
¿Cuáles son las diferencias fundamentales entre OSGi y Java EE? (4)
Así que me tomé un tiempo esta tarde para finalmente sentarme y comenzar a leer sobre el misterioso y elusivo "OSGi" y sus llamados paquetes .
OK, entonces creo que lo entiendo. Un "paquete" de OSGi es básicamente un JAR con información de manifiesto adicional. Y, en lugar de implementarlo en un servidor de aplicaciones normal (u otro contenedor), lo implementa en un servidor OSGi como Apache Felix. Se ejecuta y luego proporciona servicios a los usuarios / clientes.
¿En qué se diferencia esto de un EAR normal que se implementa en un servidor de aplicaciones?
OSGi parece estar en aumento (¡me lo estoy encontrando!), Pero por mi vida no entiendo lo que ofrece (en cuanto a características) sobre cualquier cosa que pueda hacer con un servidor empresarial de ofertas reales como GlassFish o Spring .
Sé que el mundo no se ha vuelto loco, así que obviamente me estoy perdiendo algo. Simplemente no he podido averiguar qué. Gracias por cualquier ayuda o visión!
Comparar Java EE con OSGi es como comparar manzanas y naranjas con la ventaja adicional de no saber qué es qué.
Java EE se centra en aplicaciones empresariales escalables de múltiples niveles en entornos heterogéneos y en la integración de sistemas de información en toda la empresa.
OSGi comenzó en otra esquina al integrar varias bases de código independientes en una JVM (discúlpeme por ser extremadamente breve).
Por supuesto, algunos problemas (por ejemplo, el despliegue en caliente) son comunes en ambos entornos, pero en un grado variable.
Por supuesto, puede actualizar, rebajar y cruzar ambos y se encontrarán en algún lugar en el medio.
Entonces, la pregunta no debe ser "¿Qué beneficio tiene A sobre B" sino algo 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?"
La mayoría de los beneficios principales, al menos los motivos por los que usamos OSGi, se enumeran en http://karaf.apache.org/ , en particular los dos primeros.
Además, la alianza OSGi tiene una larga lista de beneficios: https://www.osgi.org/developer/benefits-of-using-osgi/ .
Lo siento pero TODAS las respuestas aquí son completamente ridículas. ¿Problemas de versión de dependencia resueltos con OSGi? Pooooohlease ... ¿Has oído hablar de las políticas de carga de clases en los servidores de aplicaciones?
OSGi parece ser una idea para seguir vendiendo nuevos libros y capacitación, mientras que las necesidades funcionales se han cubierto por eones con el despliegue y despliegue de JAR / EAR 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, las 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 a la vanguardia de la tecnología y que con gusto financiarán los cursos de sus empleados, absorberán la curva de aprendizaje y luego pagarán por su nariz en la "reingeniería" de las cosas que no tenía nada de malo con ellos para empezar.
No se trata de "debo usar un destornillador de un martillo". Es más una cuestión de "hey jefe, hay algo nuevo por ahí llamado HEMMAR, ¡y es realmente genial!". "¿No es un MARTILLO?", "No, no, es mucho mejor, es un HEMMAR, es para clavar clavos en tablas, revolucionará el mundo".
Un paquete OSGi es más un "módulo de software" que un archivo "jar", "war" u "ear". Los paquetes OSGi rara vez proporcionan beneficios si agrupan una aplicación completa; sin embargo, son muy beneficiosos en la automatización y el manejo correcto de la conexión de muchas bibliotecas.
Entonces, considere el problema que OSGi intentó resolver, y comprenderá mejor dónde encaja. Es el equivalente de Java del patrón de "herencia de diamante" 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, se debe a varias declaraciones de inclusión.
Si las dos bibliotecas funcionan con la misma versión de la biblioteca de registro común, estás de suerte. Si no lo hacen, para que cada biblioteca funcione correctamente de forma independiente, debe cargar dos copias de la misma biblioteca, cada una de las cuales probablemente utilice los mismos espacios de nombres (y con frecuencia los mismos nombres de clase).
OSGi es un medio de agrupación que permite cargar dos versiones de la misma biblioteca que utilizan los mismos espacios de nombre, los mismos nombres de clase, pero que 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 "correcta".
Java EE hace mucho, pero esto no es algo que Java EE aborde. En el mejor de los casos, el proyecto Jigsaw estaba trabajando en el mismo problema. Donde la confusión de Java EE / OSGi entra en juego es que la mayoría de los primeros en adoptar el paquete OSGi fueron aquellos que estaban implementando una funcionalidad similar a algunas de las bibliotecas que se ofrecen en Java EE. Dicho esto, el marco de conexión del contenedor real (OSGi) no tuvo nada que ver con la funcionalidad del paquete (aunque parte del descubrimiento se modificó estructuralmente para cumplir con los requisitos del paquete del OSGi).