He leído en Wikipedia y otros sitios sobre OSGi , pero realmente no veo el panorama general. Dice que es una plataforma basada en componentes y que puede recargar módulos en tiempo de ejecución. También el "ejemplo práctico" dado en todas partes es el Marco del plugin de Eclipse.

Mis preguntas son:

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

2. ¿Qué problemas comunes resuelve?

Por "problemas comunes" me refiero a los problemas que enfrentamos todos los días, como "¿Qué puede hacer OSGi para hacer que nuestros trabajos sean más eficientes / divertidos / simples?"

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

Complejidad reducida: desarrollar con tecnología OSGi significa desarrollar paquetes: los componentes OSGi. Los paquetes son módulos. Ocultan sus componentes internos de otros paquetes y se comunican a través de servicios bien definidos. Ocultar lo interno significa más libertad para cambiar más tarde. Esto no solo reduce la cantidad de errores, sino que también hace que los paquetes sean más simples de desarrollar porque los paquetes del 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 componente OSGi facilita el uso de muchos componentes de terceros en una aplicación. Un número cada vez mayor de proyectos de código abierto proporciona sus JAR listos para OSGi. Sin embargo, las bibliotecas comerciales también están disponibles como paquetes preparados.

Mundo real -El marco OSGi es dinámico. 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 dinámico y tener servicios dinámicos 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, se registra el servicio. Si el dispositivo desaparece, el servicio no está registrado. Hay una sorprendente cantidad de escenarios del mundo real que coinciden con este modelo de servicio dinámico. Por lo tanto, las aplicaciones pueden reutilizar las poderosas primitivas del registro de servicios (registrarse, obtener, enumerar con un lenguaje de filtro expresivo y esperar a 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 funcionalidad de la que hubiera implementado para una solución dedicada. Escribir código en un entorno tan dinámico suena como una pesadilla, pero afortunadamente, hay clases de soporte y marcos que le quitan la mayor parte, si no todo, el dolor.

Implementación sencilla: la tecnología OSGi no es solo un estándar para los 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 administración. Este agente de administración puede ser tan simple como un shell de comandos, un controlador de protocolo de administración TR-69, un controlador de protocolo OMA DM, una interfaz de computación en la nube para EC2 de Amazon o un sistema de administración IBM Tivoli. La API de administración estandarizada facilita la integración de la tecnología OSGi en los sistemas existentes y futuros.

Actualizaciones dinámicas : el modelo de componente OSGi es un modelo dinámico. Los paquetes se pueden instalar, iniciar, detener, actualizar y desinstalar sin derribar todo el sistema. Muchos desarrolladores de Java no creen que esto se pueda hacer de manera confiable y, por lo tanto, inicialmente no lo usan en la producción. Sin embargo, después de usar esto en el desarrollo durante algún tiempo, la mayoría comienza a darse cuenta de que realmente funciona y reduce significativamente los tiempos de implementación.

Adaptativo: el modelo de componentes OSGi está diseñado desde cero para permitir la mezcla y combinación de componentes. Esto requiere que se especifiquen las dependencias de los componentes y que los componentes vivan en un entorno donde sus dependencias opcionales no siempre estén disponibles. El registro de servicio OSGi es un registro dinámico donde los paquetes pueden registrar, obtener y escuchar servicios. Este modelo de servicio dinámico permite a los paquetes descubrir 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 cómo está conectado a otros paquetes. Por ejemplo, la mayoría de los marcos proporcionan un shell de comandos que muestra este estado interno. Se pueden detener partes de las aplicaciones para depurar un determinado problema, o se pueden incorporar 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.

Control de versiones: la tecnología OSGi resuelve el infierno JAR. JAR infierno es el problema de que la biblioteca A funciona 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 versionados cuidadosamente y solo los paquetes que pueden colaborar están conectados en el mismo espacio de clase. Esto permite que los paquetes A y C funcionen con su propia biblioteca. Aunque no se recomienda diseñar sistemas con este problema de versiones, en algunos casos puede ser un salvavidas.

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

Pequeño: el marco OSGi Release 4 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, hasta pequeños, hasta mainframes. Solo pide una máquina virtual Java mínima para ejecutarse y agrega muy poco encima.

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

Lazy: el software Lazy es bueno y la tecnología OSGi tiene muchos mecanismos para hacer las cosas solo cuando realmente se necesitan. Por ejemplo, los paquetes se pueden iniciar con entusiasmo, pero también se pueden configurar para que solo se inicien cuando otros paquetes los estén usando. 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 potente en la parte inferior, pero resultó muy difícil de configurar en la práctica. 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 grano fino, pero mejora la usabilidad (además de fortalecer el modelo original) al hacer 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 proporcione uno de los entornos de aplicaciones más seguros que todavía se puede usar por debajo de las plataformas informáticas protegidas por hardware.

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

Corre por todas partes - Bueno, eso depende. El objetivo original de Java era correr en cualquier lugar. Obviamente, no es posible ejecutar todo el código en todas partes porque las capacidades de las máquinas virtuales Java difieren. Una máquina virtual en un teléfono móvil probablemente no admitirá las mismas bibliotecas que un mainframe de IBM que ejecuta una aplicación bancaria. Hay dos problemas que resolver. Primero, las API OSGi no deben usar clases que no están disponibles en todos los entornos. En segundo lugar, un paquete no debería iniciarse si contiene código que no está disponible en el entorno de ejecución. Ambos problemas se han solucionado en las especificaciones OSGi.

Fuente: www.osgi.org/Technology/WhyOSGi

He encontrado los siguientes beneficios de OSGi:

• Cada complemento es un artefacto versionado que tiene su propio cargador de clases.
• Cada complemento depende de los frascos específicos que contiene y también de otros complementos versionados específicos.
• Debido al control de versiones y cargadores de clases aislados, se pueden cargar diferentes versiones del mismo artefacto al mismo tiempo. Si un componente de su aplicación se basa en 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 plugin versionados que se cargan a pedido. Cada complemento es un componente independiente. Al igual que Maven lo ayuda a estructurar su compilación para que sea repetible y definido por un conjunto de versiones específicas de artefactos por los que fue creado, OSGi lo ayuda a hacer esto en tiempo de ejecución.

No me importa demasiado la capacidad de conexión en caliente de los módulos OSGi (al menos actualmente). Es más la modularidad forzada. No tener millones de clases "públicas" disponibles en el classpath en ningún momento protege bien de las dependencias circulares: debe pensar realmente en sus interfaces públicas, no solo en términos de la construcción del lenguaje java "público", sino en términos de su biblioteca / módulo: ¿Cuáles son (exactamente) los componentes que desea que estén disponibles para otros? ¿Cuáles son (exactamente) las interfaces (de otros módulos) que realmente necesita para implementar su funcionalidad?

Es bueno, ese hotplug viene con él, 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. Ver 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.
• Puede construir componentes con el concepto de caja negra. Otros componentes no necesitan saber acerca de las interfaces ocultas, solo ven las interfaces publicadas.
• Puede usar en el mismo sistema varios componentes iguales, pero en diferentes versiones, sin comprometer la aplicación. OSGi resuelve el problema de Jar Hell.
• Con OSGi, desarrolla el pensamiento para diseñar sistemas con CBD

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

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

Una respuesta simple: una plataforma de servicio OSGi proporciona un entorno informático estandarizado y orientado a componentes para servicios de red cooperantes. Esta arquitectura reduce significativamente la complejidad general de construir, mantener e implementar aplicaciones. La plataforma de servicio OSGi proporciona las funciones para cambiar la composición dinámicamente en el dispositivo de una variedad de redes, sin necesidad de reiniciar.

En una estructura de aplicación única, digamos el IDE de Eclipse, no es un gran problema reiniciar cuando instala un nuevo complemento. Al usar la implementación de OSGi por completo, 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, el uso de aplicaciones pequeñas.

Pero, cuando comienzas a mirar marcos de aplicaciones distribuidas para múltiples computadoras, ahí es donde comienza a ponerse interesante. Cuando tiene que tener un tiempo de actividad del 100% para sistemas críticos, es útil la capacidad de intercambiar componentes o agregar nueva funcionalidad en tiempo de ejecución. Por supuesto, hay capacidades para hacerlo ahora en su mayor parte, pero OSGi está tratando de agrupar todo en un pequeño marco agradable con interfaces comunes.

¿OSGi resuelve problemas comunes? No estoy seguro de eso. Quiero decir, puede, pero los gastos generales pueden no valer la pena para problemas más simples. Pero es algo a tener en cuenta cuando comienzas a lidiar 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 asíncronas (usamos felix dentro de la confluencia). En comparación con un resorte puro (sin DM) donde [main] se ejecuta prácticamente a través de toda la sincronización.

2) Las clases no son iguales después de una carga caliente. Digamos, por ejemplo, que tiene una capa de caché de tangosol en hibernación. Está lleno de Fork.class, fuera del alcance de OSGi. Carga en caliente un nuevo tarro y Fork no ha cambiado. Class [Fork]! = Clase [Fork]. 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 arquitectura se vea defectuosa.

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

Se reinicia

OSGi hace su lanzamiento de código NoClassDefFoundErrory ClassNotFoundExceptionsin razón aparente (probablemente porque olvidó exportar un paquete en el archivo de configuración OSGi); dado que tiene ClassLoaders, puede hacer que su clase com.example.Foono se pueda convertir com.example.Fooya 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 complemento Eclipse.

Para mí, OSGi solo agregaba complejidad (porque agregaba un modelo mental más para mí), añadía molestias debido a excepciones; Realmente nunca necesité la dinámica que "ofrece". Fue 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 alejarme de ese monstruo, muchas gracias. Prefiero sufrir el infierno de la dependencia del tarro, ya que es mucho más fácil de entender que el infierno del cargador de clases que introduce OSGi.

Todavía tengo que ser un "fan" de OSGi ...

He estado trabajando con una aplicación empresarial en las compañías Fortune 100. Recientemente, el producto que utilizamos se ha "actualizado" a una implementación OSGi.

comenzando el despliegue local de cba ... [18/02/14 8: 47: 23: 727 EST] 00000347 CheckForOasis

finalmente desplegado y "los siguientes paquetes se suspenderán y luego se reiniciarán" [18/02/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 el código cambia ... La versión anterior (no OSGi) se implementaría en menos de 5 minutos en máquinas de desarrollo más antiguas.

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

El "beneficio" de esta actualización se vendió como mejoras en las implementaciones (de producción), una actividad que hacemos aproximadamente 4 veces al año con quizás 2-4 implementaciones de arreglos pequeños al año. Agregar 45 minutos por día a 15 personas (control de calidad y desarrolladores) no puedo imaginarme justificado. En las aplicaciones de grandes empresas, si su aplicación es una aplicación central, entonces cambiarla es correcto (pequeños cambios tienen el potencial de impactos de largo alcance, deben comunicarse y planificarse con los consumidores de toda la empresa), una actividad monumental: arquitectura 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 golpee su propio silo de datos en su propia base de datos de silo y se ejecute en un servidor que aloja muchas aplicaciones, entonces quizás mire OSGi. Al menos,

Si una aplicación basada en Java requiere agregar o quitar módulos (extendiendo la funcionalidad básica de la aplicación), sin cerrar la JVM, se puede emplear OSGI. Por lo general, si el costo de cerrar JVM es mayor, solo para actualizar o mejorar la funcionalidad.

Ejemplos :

1. Eclipse : proporciona una plataforma para que los complementos se instalen, desinstalen, actualicen e interdependan.
2. AEM : aplicación WCM, donde el cambio de funcionalidad será impulsado por el negocio, lo que no puede permitir tiempos de inactividad por mantenimiento.

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

He estado trabajando con OSGi casi 8 años más o menos y debo decir que debe considerar OSGi solo si tiene una necesidad comercial de actualizar, eliminar, instalar o reemplazar un componente en tiempo de ejecución. Esto también significa que debe tener una mentalidad modular y comprender lo que significa modularidad. Hay algunos argumentos de que OSGi es liviano; sí, eso es cierto, pero también hay algunos otros marcos que son livianos y más fáciles de mantener y desarrollar. Lo mismo va a asegurar Java, bla, bla.

OSGi requiere una arquitectura sólida para usarse correctamente y es bastante fácil crear un sistema OSGi que podría ser fácilmente un jar ejecutable independiente sin que esté involucrado ningún OSGi.

El OSGi proporciona el siguiente beneficio:

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

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

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

■ Una solución ligera y escalable

También se está utilizando para brindar 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 funciones del dispositivo, puede fragmentarse.

Como mínimo, OSGi te hace PENSAR sobre la modularidad, la reutilización de código, el control de versiones y, en general, la fontanería de un proyecto.

Otros ya han descrito los beneficios en detalle, por la presente explico los casos de uso prácticos que he visto o usado OSGi.

1. En una de nuestras aplicaciones, tenemos un flujo basado en eventos y el flujo se define en complementos basados ​​en la plataforma OSGi, así que mañana si algún cliente quiere un flujo diferente / adicional, entonces solo tiene que implementar un complemento más, configurarlo desde nuestra consola y listo. .
2. Se usa para implementar diferentes conectores de la Tienda, por ejemplo, supongamos que ya tenemos un conector Oracle DB y mañana se debe conectar mongodb, luego escribir un nuevo conector y desplegarlo y configurar los detalles a través de la consola y nuevamente habrá terminado. El despliegue de los conectores se maneja mediante el marco del complemento OSGi.

Ya hay una declaración bastante convincente en su sitio oficial, puedo citar como

La razón clave por la que la tecnología OSGi es tan exitosa es que proporciona un sistema de componentes muy maduro que realmente funciona en un sorprendente número de entornos. El sistema de componentes OSGi se usa realmente para crear aplicaciones altamente complejas como IDEs (Eclipse), servidores de aplicaciones (GlassFish, IBM Websphere, Oracle / BEA Weblogic, Jonas, JBoss), marcos de aplicaciones (Spring, Guice), automatización industrial, puertas de enlace residenciales, teléfonos y mucho más.

¿En cuanto a los beneficios para el desarrollador?

DESARROLLADORES: OSGi reduce la complejidad al proporcionar una arquitectura modular para los sistemas distribuidos a gran escala de hoy en día, así como para aplicaciones pequeñas e integradas. La construcción de sistemas a partir de módulos internos y comerciales reduce significativamente la complejidad y, por lo tanto, los gastos de desarrollo y mantenimiento. El modelo de programación OSGi cumple la promesa de los sistemas basados ​​en componentes.

Consulte los detalles en Beneficios del uso de OSGi .