¿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