¿Qué resuelve OSGi?

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

Complejidad reducida: desarrollar con tecnología OSGi significa desarrollar paquetes: los componentes OSGi. Los paquetes son módulos. Ocultan sus componentes internos a otros paquetes y se comunican a través de servicios bien definidos. Ocultar aspectos internos significa más libertad para cambiar más adelante. Esto no solo reduce la cantidad de errores, sino que también simplifica el desarrollo de paquetes porque los paquetes del tamaño correcto implementan una parte de la funcionalidad a través de interfaces bien definidas. Hay un blog interesante que describe lo que hizo la tecnología OSGi en 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 proporcionan sus JAR listos para usar para OSGi. Sin embargo, las bibliotecas comerciales también están disponibles en paquetes ya preparados.

Mundo real: el marco OSGi es dinámico. Puede actualizar paquetes sobre la marcha y los servicios pueden aparecer y desaparecer. Los desarrolladores acostumbrados al 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 muy dinámico y tener servicios dinámicos que pueden aparecer y desaparecer 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 queda registrado. Si el dispositivo desaparece, el servicio se da de baja. 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 potentes 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 escritura de código, sino que también proporciona visibilidad global, herramientas de depuración y más funcionalidades que las que se habrían implementado para una solución dedicada. Escribir código en un entorno tan dinámico suena como una pesadilla, pero afortunadamente, existen clases y marcos de soporte que eliminan la mayor parte, si no la totalidad, del dolor.

Fácil implementación: la tecnología OSGi no es solo un estándar para componentes. También especifica cómo se instalan y administran los componentes. Muchos paquetes han utilizado esta API 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 gestión estandarizada hace que sea muy fácil integrar la tecnología OSGi en sistemas existentes y futuros.

Actualizaciones dinámicas : el modelo de componentes OSGi es un modelo dinámico. Los paquetes se pueden instalar, iniciar, detener, actualizar y desinstalar sin desactivar todo el sistema. Muchos desarrolladores de Java no creen que esto se pueda hacer de forma fiable y, por lo tanto, inicialmente no lo utilizan en producción. Sin embargo, después de usar esto en 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 servicios 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 resultados 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. El infierno JAR 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 cuidadosamente versionados y sólo los paquetes que pueden colaborar se conectan entre sí en el mismo espacio de clase. Esto permite que tanto el paquete A como el C funcionen con su propia biblioteca. Aunque no se recomienda diseñar sistemas con este problema de versiones, en algunos casos puede salvar vidas.

Simple: la API OSGi es sorprendentemente simple. La API principal es solo un paquete y menos de 30 clases/interfaces. Esta API principal 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 proporcionen tanta funcionalidad para tan poca API.

Pequeño: el marco OSGi versión 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 mainframes. Solo solicita la ejecución de una máquina virtual Java mínima 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 ubican en una lista lineal. Buscar una clase requiere buscar en esta lista (a menudo muy larga, 150 no es infrecuente). Por el contrario, OSGi precablea paquetes y sabe para cada paquete exactamente qué paquete proporciona la clase. Esta falta de búsqueda es un factor importante de aceleración en el inicio.

Lazy: Lazy en el software es bueno y la tecnología OSGi cuenta con muchos mecanismos para hacer las cosas sólo cuando son realmente necesarias. 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 sólo se crean cuando se utilizan. Las especificaciones se han optimizado varias veces para permitir este tipo de escenarios lentos que pueden ahorrar enormes costos de tiempo de ejecución.

Seguro: Java tiene un modelo de seguridad detallado muy potente en la parte inferior, pero ha resultado muy difícil de configurar en la práctica. El resultado es que la mayoría de las aplicaciones Java seguras se ejecutan con una opción binaria: sin seguridad o con capacidades muy limitadas. El modelo de seguridad OSGi aprovecha el modelo de seguridad detallado pero mejora la usabilidad (además de reforzar el modelo original) al hacer que el desarrollador del paquete especifique los detalles de seguridad solicitados en una forma fácilmente auditable mientras el operador del entorno permanece totalmente a cargo. En general, OSGi probablemente proporciona uno de los entornos de aplicaciones más seguros que aún se puede utilizar sin plataformas informáticas protegidas por hardware.

No intrusivo: las aplicaciones (paquetes) en un entorno OSGi se dejan solas. Pueden utilizar prácticamente cualquier instalación de la VM sin que OSGi los restrinja. La mejor práctica en OSGi es escribir objetos Java antiguos 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 trasladar a otro entorno.

Corre por todas partes Bueno, eso depende. El objetivo original de Java era ejecutarse 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. Es probable que una máquina virtual en un teléfono móvil no admita las mismas bibliotecas que una computadora central IBM que ejecuta una aplicación bancaria. Hay dos cuestiones de las que ocuparse. En primer lugar, las API de OSGi no deberían utilizar 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. Ambas cuestiones se han solucionado en las especificaciones OSGi.

Fuente: www.osgi.org/Technology/WhyOSGi

Jul 26 '2013 08:07 Abhishek Goel