java - que - osgi service
¿Qué resuelve OSGi? (13)
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 volver a cargar módulos en tiempo de ejecución. También el "ejemplo práctico" dado en todas partes es el Marco de Complementos de Eclipse.
Mis preguntas son:
¿Cuál es la definición clara y simple de OSGi?
¿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 bastante:
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 después. Esto no solo reduce el número de errores, sino que también hace que los paquetes sean más fáciles de desarrollar 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 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 creciente de proyectos de código abierto proporcionan sus archivos JAR preparados para OSGi. Sin embargo, las bibliotecas comerciales también están disponibles como paquetes ya hechos.
Mundo real - El marco OSGi es dinámico. Puede actualizar los 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 logran ver la ventaja. Sin embargo, resulta que el mundo real es muy dinámico y contar con servicios dinámicos que pueden ir y venir hace que los servicios sean perfectos 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, listar con un lenguaje de filtro expresivo y esperar a que aparezcan y desaparezcan los servicios) en su propio dominio. Esto no solo ahorra el código de escritura, sino que también proporciona visibilidad global, herramientas de depuración y más funcionalidad que la que habría 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 sacan la mayor parte del 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 el EC2 de Amazon o un sistema de administración de 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 pueden instalarse, iniciarse, detenerse, actualizarse y desinstalarse sin destruir todo el sistema. Muchos desarrolladores de Java no creen que esto pueda hacerse de manera confiable y, por lo tanto, inicialmente no lo usan 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 deban especificar las dependencias de los componentes y que los componentes vivan en un entorno donde las dependencias opcionales no siempre están disponibles. El registro de servicios OSGi es un registro dinámico donde los paquetes pueden registrarse, 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 los 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 comando que muestra este estado interno. Se pueden detener partes de las aplicaciones para depurar un determinado problema, o se pueden incluir 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 de JAR. JAR hell es el problema de que la biblioteca A funciona con la biblioteca B; versión = 2, pero la biblioteca C solo puede trabajar con B; la versión = 3. En Java estándar, estás fuera de 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 los paquetes A y C funcionen con su propia biblioteca. Aunque no se recomienda diseñar sistemas con este problema de versiones, puede ser un salvavidas en algunos casos.
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, 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: OSGi Release 4 Framework se puede implementar en aproximadamente un archivo JAR de 300 KB. Esta es una pequeña sobrecarga por la cantidad de funcionalidad que se agrega a una aplicación al incluir OSGi. OSGi, por lo tanto, se ejecuta en una gran variedad de dispositivos: desde muy pequeños hasta pequeños, hasta mainframes. Solo pide que se ejecute una máquina virtual Java mínima y agrega muy poco sobre ella.
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 en 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 factor significativo de aceleración en el inicio.
Lazy: Lazy en software es buena y la tecnología OSGi tiene muchos mecanismos para hacer las cosas solo 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 utilizando. Los servicios se pueden registrar, pero solo crear cuando se usan. Las especificaciones se han optimizado varias veces para permitir este tipo de escenarios perezosos que pueden ahorrar tremendos costos de tiempo de ejecución.
Seguro: Java tiene un modelo de seguridad muy potente en la parte inferior, pero en la práctica ha resultado muy difícil de configurar. El resultado es que la mayoría de las aplicaciones Java 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 (así como el fortalecimiento del modelo original) al hacer que el desarrollador del paquete especifique los detalles de seguridad solicitados en una forma fácilmente auditada, mientras que el operador del entorno sigue siendo totalmente responsable. En general, es probable que OSGi proporcione uno de los entornos de aplicación más seguros que aún se puede usar por debajo de las plataformas informáticas protegidas por hardware.
No intrusivo: las aplicaciones (paquetes) en un entorno OSGi se dejan a sí mismas. Pueden usar virtualmente cualquier instalación de la VM sin que OSGi los restrinja. La mejor práctica en OSGi es escribir objetos Java antiguos simples y, por este motivo, 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 portar 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 de Java son diferentes. Es probable que una máquina virtual en un teléfono móvil no admita las mismas bibliotecas que un mainframe de IBM que ejecuta una aplicación bancaria. Hay dos cuestiones que cuidar. Primero, las API de OSGi no deben usar clases que no estén disponibles en todos los entornos. En segundo lugar, un paquete no debe iniciarse si contiene código que no está disponible en el entorno de ejecución. Ambas cuestiones han sido atendidas en las especificaciones de OSGi.
Fuente: www.osgi.org/Technology/WhyOSGi
Algunas cosas que me vuelven loco en OSGi:
1) Las implicaciones y sus cargadores de contexto tienen muchas peculiaridades, y pueden ser algo asíncronos (usamos felix dentro de la confluencia). Comparado con un resorte puro (sin DM) donde [principal] se está ejecutando prácticamente a través de la sincronización de todo.
2) Las clases no son iguales después de una carga caliente. Digamos que, por ejemplo, tiene una capa de caché de tangosol en hibernación. Se llena con Fork.class, fuera del ámbito OSGi. Usted carga un nuevo tarro y Fork no ha cambiado. Clase [Fork]! = Clase [Fork]. También aparece durante la serialización, por las mismas causas subyacentes.
3) Agrupación.
Puedes solucionar estas cosas, pero es un gran problema, y hace que tu arquitectura parezca defectuosa.
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.
Como mínimo, OSGi le hace PENSAR sobre la modularidad, la reutilización de código, el control de versiones y, en general, la instalación de un proyecto.
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 a los proveedores de servicios de los consumidores de servicios
■ Un sistema de módulos dinámicos, que se puede usar para instalar y desinstalar dinámicamente módulos de Java, a los que OSGi llama paquetes.
■ Una solución ligera y escalable.
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 archivos jar específicos que contiene y también de otros complementos específicos con versiones.
- Debido a las versiones y los 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 complementos versionados que se cargan a pedido. Cada plugin es un componente independiente. Del mismo modo que Maven lo ayuda a estructurar su compilación de manera que sea repetible y esté definido por un conjunto de versiones específicas de los artefactos con los que fue creado, OSGi lo ayuda a hacerlo en tiempo de ejecución.
No me importa demasiado la conectividad en caliente de los módulos OSGi (al menos en la actualidad). Es más la modularidad impuesta. No tener millones de clases "públicas" disponibles en la ruta de clase en ningún momento protege bien de las dependencias circulares: tiene que pensar realmente en sus interfaces públicas, no solo en términos de la construcción "pública" del lenguaje java, sino en términos de su biblioteca / módulo: ¿Cuáles (exactamente) son los componentes que desea que estén disponibles para otros? ¿Cuáles (exactamente) son las interfaces (de otros módulos) que realmente necesita para implementar su funcionalidad?
Está bien, ese hotplug viene con él, pero prefiero reiniciar mis aplicaciones habituales en lugar de probar todas las combinaciones de hotplugability ...
Otros ya han descrito los beneficios en detalle, a continuación, explico los casos prácticos que he visto o usado OSGi.
- En una de nuestras aplicaciones, tenemos flujo basado en eventos y el flujo se define en complementos basados en la plataforma OSGi, por lo que mañana, si algún cliente desea un flujo diferente / adicional, solo tendrá que implementar un complemento más, configurarlo desde nuestra consola y listo. .
- Se utiliza para desplegar diferentes conectores de la Tienda, por ejemplo, supongamos que ya tenemos el conector DB de Oracle y mañana se requiere que mongodb esté conectado, luego escriba un nuevo conector, despliéguelo y configure los detalles a través de la consola. Una vez más, ya está listo. El despliegue de conectores es manejado por el marco del complemento OSGi.
Si una aplicación basada en Java requiere agregar o eliminar módulos (ampliando la funcionalidad básica de la aplicación), sin apagar la JVM, se puede emplear OSGI. Generalmente, si el costo de apagar la JVM es mayor, solo para actualizar o mejorar la funcionalidad.
Ejemplos :
- Eclipse : proporciona una plataforma para que los complementos se instalen, desinstalen, actualicen e inter-dependan.
- AEM : la 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 OSGI spring, considerándolo como una complejidad innecesaria para aplicaciones basadas en transacciones o para algún punto en estas líneas. Personalmente, no considero OSGI a menos que sea absolutamente necesario, en algo grande como construir una plataforma.
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 características del dispositivo, puede fragmentarse.
Todavía tengo que ser un "fan" de OSGi ...
He estado trabajando con una aplicación empresarial en compañías de Fortune 100. Recientemente, el producto que utilizamos se ha "actualizado" a una implementación OSGi.
iniciando el despliegue de cba local ... [18/02/14 8: 47: 23: 727 EST] 00000347 CheckForOasis
finalmente implementado y "los siguientes paquetes se desactivará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 de 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 máquinas de desarrollo más antiguas.
en una máquina con un disco RAM de 16 gigas y 40 discos libres y una CPU Intel i5-3437U a 1.9 GHz
El "beneficio" de esta actualización se vendió como implementaciones de mejoramiento (producción), una actividad que realizamos aproximadamente 4 veces al año con quizás 2-4 implementaciones de pequeñas correcciones al año. Agregando 45 minutos por día a 15 personas (control de calidad y desarrolladores) no puedo imaginarme que alguna vez haya sido justificado. En las aplicaciones de grandes empresas, si su aplicación es una aplicación central, entonces cambiarla sí lo es, con razón (los pequeños cambios tienen un potencial de impacto de gran 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 personalizado que probablemente llegue a 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 busque OSGi. Al menos, esa es mi experiencia hasta ahora.
Editado para mayor claridad. La página de OSGi dio una mejor respuesta simple que la mía.
Una respuesta simple: una plataforma de servicios OSGi proporciona un entorno informático estandarizado orientado a componentes para los servicios en red de cooperación. Esta arquitectura reduce significativamente la complejidad general de crear, mantener y desplegar 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 OSGi por completo, debería poder agregar complementos en tiempo de ejecución, obtener la nueva funcionalidad, pero no tener que reiniciar el eclipse.
Una vez más, no es un gran problema para todos los días, uso de pequeñas aplicaciones.
Pero, cuando empiezas a mirar los frameworks de aplicaciones distribuidas en múltiples computadoras, ahí es donde empieza a ser interesante. Cuando tiene que tener un tiempo de actividad del 100% para los sistemas críticos, la capacidad de intercambiar componentes o agregar una nueva funcionalidad en el 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 marco agradable con interfaces comunes.
¿OSGi resuelve problemas comunes, no estoy seguro de eso? Quiero decir, puede, pero la sobrecarga puede no valer la pena para problemas más simples. Pero es algo a tener en cuenta cuando está empezando a lidiar con aplicaciones más grandes y conectadas en red.
OSGi hace que su código lance NoClassDefFoundError y ClassNotFoundException sin ninguna razón aparente (probablemente porque se olvidó de exportar un paquete en el archivo de configuración OSGi); ya que tiene ClassLoaders puede hacer que su clase com.example.Foo no se com.example.Foo 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 complemento de Eclipse.
Para mí, OSGi solo agregó complejidad (porque agregó un modelo mental más para que yo asimile), agregó molestias debido a las excepciones; Nunca realmente necesité la dinamismo 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 mantenerme alejado de ese monstruo, muchas gracias. Prefiero sufrir de la dependencia del tarro, ya que es mucho más fácil de entender que el cargador de clases que OSGi introduce.
- De manera análoga, puede cambiar el motor de su automóvil sin apagarlo.
- Puede personalizar sistemas complejos para los clientes. Ver el poder de Eclipse.
- Puede reutilizar componentes enteros. 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. Otros componentes no necesitan conocer las interfaces ocultas, solo ven las interfaces publicadas.
- Puede utilizar 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 desarrollas el pensamiento para diseñar sistemas con CBD
Hay muchos beneficios (solo los recordé ahora), disponibles para todos los que usan Java.