2011-07-01 14 views
7

Mi equipo está tratando de desarrollar un nuevo sistema basado en OSGi, y ahora tenemos más de 50 paquetes y contando. El problema es que hay una dependencia entre los paquetes. Por ejemplo, cuando se inicia el paquete A, se registrará un servicio en OSGi, y cuando se inicie el paquete B, usará ese servicio. Por lo tanto, necesito el inicio del paquete A antes que el paquete B. Para que esto ocurra, establezco el nivel de inicio del paquete A menor que el paquete B.¿Es razonable usar diferentes niveles de inicio para administrar las dependencias entre los paquetes OSGi?

Intentamos utilizar ServiceTracker para evitar establecer niveles de inicio, pero cuando los servicios cuentan cada vez más hasta se vuelve difícil de administrar y comprender todo el sistema.

Sin embargo, he encontrado este artículo en Internet: OSGi and Start Levels. No estoy seguro de que con dos frases en ella:

  • orden de salida en el nivel de inicio es indeterminado!
  • En general, al trabajar con niveles de inicio, nunca dependa de la orden de inicio. Piense en los niveles de inicio como un problema de gestión, no como un problema de tiempo de desarrollo.

¿Significa que el nivel de inicio no decidirá la orden de inicio? Entonces, cuando debería usarlo?

¿Es razonable usar diferentes niveles de inicio para administrar las dependencias entre los paquetes OSGi?

Es posible hacer que todos los paquetes sean un módulo dinámico (use ServiceTracker para rastrear todos los servicios que utiliza), pero lleva más tiempo y demanda desarrolladores senior, y el sistema se vuelve difícil de depurar.

Respuesta

9

Mi respuesta es similar a Bertrand: usted debe considerar el uso de una abstracción basada en componentes de más alto nivel para su solución: SCR, iPOJO, Blueprint, etc.

El uso de niveles de arranque para controlar las dependencias es un poco como el uso prioridades de subprocesos en Java para corregir las condiciones de carrera. Claro, puedes hacer que las cosas funcionen, más o menos, por un tiempo, pero te volverás loco en el proceso y eventualmente perderás.

Los niveles de inicio son útil. El ejemplo canónico es si necesita mostrar una pantalla de bienvenida al iniciar su aplicación GUI basada en OSGi al poner el código en un paquete. Sin los niveles de inicio, no hay forma de garantizar que la pantalla de bienvenida termine visualizándose cuando se supone que debe estar, pero al usar los niveles de inicio, esto se vuelve trivial.

Dicho esto, utilicé los niveles de inicio para resolver los errores de ordenamiento de dependencia encontrados en paquetes de terceros (por ejemplo, Spring), aunque esto no implicaba pedidos de servicio sino suposiciones sobre cómo encontrar recursos (con Spring, un XSD para el espacio de nombres personalizado de Spring Integration).

+0

Mi equipo ha utilizado niveles de inicio para problemas similares. Es una excelente manera de buscar problemas y es una solución útil a corto plazo si no tienes tiempo para solucionar el problema subyacente de inmediato. – Jon7

+0

+1 a la respuesta de rsteele. Según el orden de inicio, se presenta una fragilidad extrema. Otro caso de uso para los niveles de inicio es la optimización. Sus paquetes siempre deben * TRABAJAR * independientemente del orden en el que se inicien ... sin embargo, a veces un paquete puede necesitar más o menos trabajo dependiendo de su orden de inicio. Para que pueda utilizar los niveles de inicio para optimizar el rendimiento de su aplicación, simplemente no dependa de ellos para la funcionalidad real. –

+0

Gracias Neil. No había considerado el problema de la eficiencia, pero tiene mucho sentido. –

7

Usar niveles de inicio para administrar dependencias entre servicios es una mala idea: el Runtime de componentes de servicios (SCR) es una forma mucho mejor de administrar eso, y si se hace bien se ocupará de todas las dependencias, orden de arranque y reinicio de componentes cuando se reinician sus servicios requeridos, etc.

Si está utilizando Maven, el plugin SCR de Apache Felix (http://felix.apache.org/site/scr-annotations.html) hace que sea fácil crear servicios administrados por SCR usando solo unas pocas anotaciones Java. El código de Apache Sling (http://sling.apache.org) está lleno de ejemplos al usar esto.

+0

No estamos utilizando Maven, y UES equinoccio en lugar de Felix. ¿Alguna otra sugerencia? –

+0

Equinox no debería hacer ninguna diferencia en lo que respecta a SCR, y si no está utilizando Maven puede usar Bnd directamente (http://www.aqute.biz/Bnd/Bnd) - eso es lo que los plugins de Maven que mencioné usar debajo del capó. –

Cuestiones relacionadas