¿Qué soluciona OSGi?

He leído en Wikipedia y en otros sitios sobre OSGi , pero realmente no veo el outlook completo. Dice que es una plataforma basada en componentes y que puede volver a cargar los módulos en tiempo de ejecución. También el “ejemplo práctico” dado en todas partes es el Marco de complemento de Eclipse.

Mis preguntas son:

  1. ¿Cuál es la definición clara y simple de OSGi?

  2. ¿Qué problemas comunes soluciona?

Por “problemas comunes” me refiero a los problemas que enfrentamos todos los días, como “¿Qué puede hacer OSGi para hacer que nuestro trabajo sea más eficiente / divertido / simple?”

He encontrado los siguientes beneficios de OSGi:

  • Cada complemento es un artefacto versionado que tiene su propio cargador de clases.
  • Cada complemento depende tanto de los archivos jar específicos que contiene como de otros complementos con versiones específicas.
  • Debido a las versiones y los cargadores de clase aislados, se pueden cargar diferentes versiones del mismo artefacto al mismo tiempo. Si un componente de su aplicación depende de una versión de un complemento y otro depende de otra versión, ambos pueden cargarse al mismo tiempo.

Con esto, puede estructurar su aplicación como un conjunto de artefactos de plugins versionados que se cargan a pedido. Cada complemento es un componente independiente. Así como Maven te ayuda a estructurar tu construcción para que sea repetible y esté definida por un conjunto de versiones específicas de artefactos creados por él, OSGi te ayuda a hacerlo en tiempo de ejecución.

¿Qué beneficios le proporciona el sistema de componentes de OSGi?
Bueno, aquí hay una buena lista:

Complejidad reducida: Desarrollar con la tecnología OSGi significa desarrollar paquetes: los componentes OSGi. Los paquetes son módulos. Ocultan sus partes internas de otros paquetes y se comunican a través de servicios bien definidos. Ocultar las partes internas significa más libertad para cambiar más tarde. Esto no solo reduce el número de errores, sino que también hace que los paquetes sean más simples de desarrollar porque los paquetes de tamaño correcto implementan una funcionalidad a través de interfaces bien definidas. Hay un blog interesante que describe lo que hizo la tecnología OSGi para su proceso de desarrollo.

Reutilización: el modelo de componentes OSGi hace que sea muy fácil utilizar muchos componentes de terceros en una aplicación. Un número cada vez mayor de proyectos de código abierto proporciona sus archivos JAR preparados para OSGi. Sin embargo, las bibliotecas comerciales también están disponibles como paquetes preparados.

Mundo real: el marco OSGi es dynamic. Puede actualizar paquetes sobre la marcha y los servicios pueden ir y venir. Los desarrolladores acostumbrados a Java más tradicional ven esto como una característica muy problemática y no ven la ventaja. Sin embargo, resulta que el mundo real es altamente dynamic y tener servicios dynamics que pueden ir y venir hace que los servicios sean una combinación perfecta para muchos escenarios del mundo real. Por ejemplo, un servicio podría modelar un dispositivo en la red. Si se detecta el dispositivo, el servicio se registra. Si el dispositivo se va, el servicio no está registrado. Hay una cantidad sorprendente de escenarios del mundo real que coinciden con este modelo de servicio dynamic. Por lo tanto, las aplicaciones pueden reutilizar las poderosas primitivas del registro de servicios (registrar, obtener, enumerar con un lenguaje expresivo de filtro y esperar que los servicios aparezcan y desaparezcan) en su propio dominio. Esto no solo ahorra código de escritura, sino que también proporciona visibilidad global, herramientas de depuración y más funcionalidades que las implementadas para una solución específica. Escribir código en un entorno tan dynamic suena como una pesadilla, pero, afortunadamente, hay clases de apoyo y marcos que le quitan la mayor parte, si no todo, el dolor.

Implementación fácil: la tecnología OSGi no es solo un estándar para componentes. También especifica cómo se instalan y administran los componentes. Esta API ha sido utilizada por muchos paquetes para proporcionar un agente de gestión. Este agente de gestión puede ser tan simple como un shell de comandos, un controlador de protocolo de gestión TR-69, un controlador de protocolo OMA DM, una interfaz de computación en la nube para el EC2 de Amazon o un sistema de gestión IBM Tivoli. La API de administración estandarizada hace que sea muy fácil integrar la tecnología OSGi en sistemas existentes y futuros.

Actualizaciones dinámicas : el modelo del componente OSGi es un modelo dynamic. Los paquetes pueden instalarse, iniciarse, detenerse, actualizarse y desinstalarse sin desmantelar todo el sistema. Muchos desarrolladores de Java no creen que esto se pueda hacer de manera confiable y, por lo tanto, inicialmente no lo utilicen en producción. Sin embargo, después de usar esto en desarrollo durante un tiempo, la mayoría comienza a darse cuenta de que realmente funciona y reduce significativamente los tiempos de implementación.

Adaptativo: el modelo de componente OSGi está diseñado desde cero para permitir la mezcla y el emparejamiento de los componentes. Esto requiere que las dependencias de los componentes se especifiquen y requiera que los componentes vivan en un entorno en el que sus dependencias opcionales no estén siempre disponibles. El registro de servicio OSGi es un registro dynamic donde los paquetes pueden registrar, obtener y escuchar servicios. Este modelo de servicio dynamic permite a los paquetes averiguar qué capacidades están disponibles en el sistema y adaptar la funcionalidad que pueden proporcionar. Esto hace que el código sea más flexible y resistente a los cambios.

Transparencia: los paquetes y servicios son ciudadanos de primera clase en el entorno OSGi. La API de administración proporciona acceso al estado interno de un paquete, así como a la forma en que está conectado a otros paquetes. Por ejemplo, la mayoría de los marcos proporcionan un shell de comandos que muestra este estado interno. Algunas partes de las aplicaciones pueden detenerse para depurar un cierto problema o pueden enviarse paquetes de diagnóstico. En lugar de mirar millones de líneas de salida de registro y largos tiempos de reinicio, las aplicaciones OSGi a menudo se pueden depurar con un shell de comandos en vivo.

Versiones: la tecnología OSGi resuelve el infierno JAR. JAR es el problema de que la biblioteca A funcione con la biblioteca B; versión = 2, pero la biblioteca C solo puede funcionar con B; versión = 3. En Java estándar, no tienes suerte. En el entorno OSGi, todos los paquetes están cuidadosamente versionados y solo los paquetes que pueden colaborar están conectados entre sí en el mismo espacio de clase. Esto permite que ambos paquetes A y C funcionen con su propia biblioteca. Aunque no se aconseja diseñar sistemas con este problema de control de versiones, en algunos casos puede ser un salvavidas.

Simple: la API OSGi es sorprendentemente simple. La API central es solo un paquete y menos de 30 clases / interfaces. Esta API básica es suficiente para escribir paquetes, instalarlos, iniciarlos, detenerlos, actualizarlos y desinstalarlos e incluye todas las clases de escucha y seguridad. Hay muy pocas API que proporcionan tanta funcionalidad para tan poca API.

Pequeño: el OSGi Release 4 Framework se puede implementar en un archivo JAR de aproximadamente 300 KB. Esta es una pequeña sobrecarga para la cantidad de funcionalidad que se agrega a una aplicación al incluir OSGi. Por lo tanto, OSGi se ejecuta en una amplia gama de dispositivos: desde muy pequeños a pequeños, a mainframes. Solo solicita una Java VM mínima para ejecutarse y agrega muy poco en la parte superior.

Rápido : una de las principales responsabilidades del marco OSGi es cargar las clases de los paquetes. En Java tradicional, los JAR son completamente visibles y se colocan en una lista lineal. Buscar una clase requiere buscar a través de esta lista (a menudo muy larga, 150 no es poco común). Por el contrario, OSGi precablea los paquetes y sabe para cada paquete exactamente qué paquete proporciona la clase. Esta falta de búsqueda es un factor de aceleración significativo al inicio.

Lazy – Lazy en software es buena y la tecnología OSGi tiene muchos mecanismos para hacer cosas solo cuando realmente se necesitan. Por ejemplo, los paquetes se pueden iniciar con entusiasmo, pero también se pueden configurar para que comiencen solo cuando otros paquetes los estén utilizando. Los servicios se pueden registrar, pero solo se crean cuando se usan. Las especificaciones se han optimizado varias veces para permitir este tipo de escenarios perezosos que pueden ahorrar enormes costos de tiempo de ejecución.

Seguro: Java tiene un modelo de seguridad de grano fino muy poderoso en la parte inferior, pero en la práctica resultó muy difícil de configurar. El resultado es que las aplicaciones Java más seguras se ejecutan con una opción binaria: sin seguridad o capacidades muy limitadas. El modelo de seguridad OSGi aprovecha el modelo de seguridad de granularidad fina pero mejora la usabilidad (además de reforzar el modelo original) haciendo que el desarrollador del paquete especifique los detalles de seguridad solicitados en una forma fácilmente auditada mientras el operador del entorno permanece completamente a cargo. En general, es probable que OSGi ofrezca uno de los entornos de aplicaciones más seguros que aún se puede utilizar, salvo las plataformas informáticas protegidas por hardware.

No intrusivo: las aplicaciones (paquetes) en un entorno OSGi se dejan a su suerte. Pueden usar virtualmente cualquier instalación de la máquina virtual sin que OSGi los restrinja. La mejor práctica en OSGi es escribir objetos antiguos simples de Java y, por esta razón, no se requiere una interfaz especial para los servicios OSGi, incluso un objeto Java String puede actuar como un servicio OSGi. Esta estrategia hace que el código de la aplicación sea más fácil de transportar a otro entorno.

Corre por todas partes – Bueno, eso depende. El objective original de Java era ejecutar en cualquier lugar. Obviamente, no es posible ejecutar todos los códigos en todas partes porque las capacidades de las máquinas virtuales de Java son diferentes. Es probable que una VM en un teléfono móvil no admita las mismas bibliotecas que una computadora central IBM que ejecuta una aplicación bancaria. Hay dos asuntos de los que ocuparse. Primero, las API de OSGi no deben usar clases que no estén disponibles en todos los entornos. Segundo, un paquete no debería comenzar si contiene código que no está disponible en el entorno de ejecución. Ambos problemas se han tenido en cuenta en las especificaciones OSGi.

Fuente: http://www.osgi.org/Technology/WhyOSGi

No me importa demasiado la compatibilidad de los módulos OSGi (al menos en la actualidad). Es más la modularidad forzada. No tener millones de clases “públicas” disponibles en el classpath en cualquier momento protege bien de las dependencias circulares: tienes que pensar realmente en tus interfaces públicas, no solo en términos de la construcción del lenguaje java “public”, sino en términos de tu biblioteca / módulo: ¿Cuáles (exactamente) son los componentes que quieres poner a disposición de los demás? ¿Qué (exactamente) son las interfaces (de otros módulos) que realmente necesita para implementar su funcionalidad?

Es bueno, ese hotplug viene con eso, pero prefiero reiniciar mis aplicaciones habituales que probar todas las combinaciones de hotplugability …

  • Puede, analógicamente hablando, cambiar el motor de su automóvil sin apagarlo.
  • Puede personalizar sistemas complejos para los clientes. Vea el poder de Eclipse.
  • Puede reutilizar componentes completos. Mejor que solo objetos.
  • Utiliza una plataforma estable para desarrollar aplicaciones basadas en componentes. Los beneficios de esto son enormes.
  • Puedes construir Componentes con el concepto de caja negra. No es necesario que otros componentes conozcan las interfaces ocultas, solo ven las interfaces publicadas.
  • Puede usar en el mismo sistema varios componentes iguales, pero en versiones diferentes, sin comprometer la aplicación. OSGi resuelve el problema Jar Hell.
  • Con OSGi desarrollas pensando en sistemas de architecture con CBD

Hay muchos beneficios (recordé estos ahora), disponibles para todos los que usan Java.

editado para mayor claridad La página OSGi dio una respuesta más simple que la mía

Una respuesta simple: una plataforma de servicios OSGi proporciona un entorno informático orientado a componentes estandarizado para servicios de red cooperativos. Esta architecture reduce significativamente la complejidad general de crear, mantener e implementar aplicaciones. OSGi Service Platform proporciona las funciones para cambiar dinámicamente la composición en el dispositivo de una variedad de redes, sin necesidad de un reinicio.

En una única estructura de aplicación, digamos Eclipse IDE, no es un gran problema reiniciar cuando instala un nuevo complemento. Usando completamente la implementación de OSGi, debería poder agregar complementos en tiempo de ejecución, obtener la nueva funcionalidad, pero no tener que reiniciar eclipse en absoluto.

Una vez más, no es un gran problema para todos los días, uso de aplicaciones pequeñas.

Pero, cuando comienzas a mirar frameworks de aplicación distribuida y multi-computadora, ahí es donde comienza a ser interesante. Cuando tiene que tener un 100% de tiempo de actividad para sistemas críticos, la capacidad de enrutar componentes o agregar nuevas funcionalidades en tiempo de ejecución es útil. Por supuesto, hay capacidades para hacer esto ahora en su mayor parte, pero OSGi está tratando de agrupar todo en un pequeño y agradable marco con interfaces comunes.

OSGi resuelve problemas comunes, no estoy seguro de eso. Quiero decir, puede, pero la sobrecarga puede no valer la pena por problemas más simples. Pero es algo a tener en cuenta cuando comienzas a tratar con aplicaciones más grandes y conectadas en red.

Algunas cosas que me vuelven loco en OSGi:

1) Las implementaciones y sus cargadores de contexto tienen muchas peculiaridades, y pueden ser algo asincrónicas (usamos Felix dentro de la confluencia). Comparado con un resorte puro (sin DM) donde [main] corre prácticamente a través de todas las sincronizaciones.

2) Las clases no son iguales después de una carga caliente. Digamos, por ejemplo, que tienes una capa de caché de tangosol en hibernación. Está lleno de Fork.class, fuera del scope de OSGi. Has cargado un nuevo jar, y Fork no ha cambiado. Clase [Tenedor]! = Clase [Tenedor]. También aparece durante la serialización, por las mismas causas subyacentes.

3) Agrupación.

Puede evitar estas cosas, pero es un gran problema, y ​​hace que su architecture tenga fallas.

Y para aquellos de ustedes que anuncian el hotplugging … ¿el cliente # 1 de OSGi? Eclipse. ¿Qué hace Eclipse después de cargar el paquete?

Se reinicia.

Todavía tengo que ser un “fan” de OSGi …

He estado trabajando con una aplicación empresarial en compañías Fortune 100. Recientemente, el producto que utilizamos se “actualizó” a una implementación de OSGi.

comenzando el despliegue de Cba local … [2/18/14 8: 47: 23: 727 EST] 00000347 CheckForOasis

finalmente implementado y “los siguientes paquetes se inmovilizarán y luego se reiniciarán” [2/18/14 9: 38: 33: 108 EST] 00000143 AriesApplicat I CWSAI0054I: Como parte de una operación de actualización para la aplicación

51 minutos … cada vez que cambia el código … La versión anterior (no OSGi) se implementaría en menos de 5 minutos en las máquinas de desarrollo anteriores.

en una máquina con 16 gig ram y 40 gig gig gratis y CPU Intel i5-3437U 1.9 GHz

El “beneficio” de esta actualización se vendió como implementaciones de mejora (producción), una actividad que hacemos unas 4 veces al año con quizás 2-4 pequeñas implementaciones de arreglos al año. Agregar 45 minutos por día a 15 personas (control de calidad y desarrolladores) no me puedo imaginar alguna vez justificado. En grandes aplicaciones empresariales, si su aplicación es una aplicación principal, entonces cambiarla es, con razón (pequeños cambios tienen potencial para impactos de largo scope; deben comunicarse y planificarse con consumidores de toda la empresa), una actividad monumental: architecture incorrecta para OSGi. Si su aplicación no es una aplicación empresarial, es decir, cada consumidor puede tener su propio módulo adaptado que probablemente llegue a su propio silo de datos en su propia base de datos con silos y se ejecute en un servidor que hospede muchas aplicaciones, entonces tal vez consulte OSGi. Al menos, esa es mi experiencia hasta ahora.

Si una aplicación basada en Java requiere agregar o eliminar módulos (ampliando la funcionalidad base de la aplicación), sin apagar la JVM, se puede emplear OSGI. Por lo general, si el costo de apagar JVM es más, solo para actualizar o mejorar la funcionalidad.

Ejemplos :

  1. Eclipse : proporciona una plataforma para que los complementos se instalen, desinstalen, actualicen y dependan entre sí.
  2. AEM : aplicación WCM, donde el cambio de funcionalidad será impulsado por el negocio, que no puede permitirse tiempos de inactividad para el mantenimiento.

Nota : Spring framework dejó de admitir paquetes de resortes OSGI, por considerarlo una complejidad innecesaria para aplicaciones basadas en transacciones o para algún punto de estas líneas. Personalmente no considero OSGI a menos que sea absolutamente necesario, en algo grande como construir una plataforma.

El OSGi proporciona el siguiente beneficio:

■ Un entorno de ejecución portátil y seguro basado en Java

■ Un sistema de administración de servicios, que se puede usar para registrar y compartir servicios entre paquetes y desacoplar proveedores de servicios de los consumidores de servicios.

■ Un sistema de módulo dynamic, que se puede usar para instalar y desinstalar dinámicamente módulos de Java, que OSGi llama paquetes

■ Una solución ligera y escalable

También se está utilizando para llevar portabilidad adicional de middleware y aplicaciones en el lado móvil. El lado móvil está disponible para WinMo, Symbian, Android, por ejemplo. Tan pronto como se produce la integración con las características del dispositivo, puede fragmentarse.

Por lo menos, OSGi te hace pensar en modularidad, reutilización de código, control de versiones y en general la instalación de un proyecto.

Otros ya han delineado los beneficios en detalle, por la presente explico los usos prácticos que he visto o usado OSGi.

  1. En una de nuestras aplicaciones, tenemos flujos y flujos basados ​​en eventos que se definen en complementos basados ​​en la plataforma OSGi, así que mañana si algún cliente quiere un flujo diferente / adicional, entonces solo tiene que desplegar un plugin más, configurarlo desde nuestra consola y listo .
  2. Se usa para implementar diferentes conectores de Tienda, por ejemplo, supongamos que ya tenemos el conector Oracle DB y mañana se requiere que mongodb esté conectado, luego escriba un nuevo conector y despliéguelo y configure los detalles a través de la consola y nuevamente habrá terminado. la implementación de los connnectors es manejada por OSGi plugin framework.

OSGi hace que su código arroje NoClassDefFoundError y ClassNotFoundException sin ningún motivo aparente (muy probablemente porque olvidó exportar un paquete en el archivo de configuración OSGi); dado que tiene ClassLoaders, puede hacer que su clase com.example.Foo no se pueda convertir en com.example.Foo ya que en realidad son dos clases diferentes cargadas por dos cargadores de clases diferentes. Puede hacer que su Eclipse arranque en una consola OSGi después de instalar un plugin de Eclipse.

Para mí, OSGi solo agregó complejidad (porque me agregó un modelo mental más para asimilar), agregó molestias debido a las excepciones; Realmente nunca necesité la dinámica que “ofrece”. Era intrusivo ya que requería la configuración del paquete OSGi para todos los módulos; Definitivamente no fue simple (en un proyecto más grande).

Debido a mi mala experiencia, tiendo a mantenerme alejado de ese monstruo, muchas gracias. Prefiero sufrir un infierno de dependencia de jar, ya que es mucho más fácil de entender que el infierno de cargador de clase que presenta OSGi.