¿Cuál es la relación entre OSGi y Dependency Injection

Question

¿Qué son el uno del otro?

• Especificación e implementación?
• Competidores?
• ¿Está relacionado?

Answer 1

No están relacionados.

Editar:

DI es a conecpt descrito por primera vez por Martin Fowler, OSGi is a module system for Java that implements a complete and dynamic component model especificado por el OSGi Alliance.

• DI se puede utilizar en diferentes idiomas de Java, OSGi es específico de Java
• OSGi trata de resolver el problema de los componentes versionados, DI es una alternativa al viejo patrón Service Locator.

Answer 2

Están conceptualmente relacionados ya que ambos proporcionan mecanismos de "separación de preocupaciones".

OSGI lo hace a nivel de módulo: piense en la arquitectura Eclipse con múltiples complementos, cada uno de los cuales es responsable de la preocupación/característica específica.

DI está orientado al nivel del objeto: proporciona los medios para construir aplicaciones a partir de múltiples objetos conectados entre sí, con cada objeto responsable de su funcionalidad específica.

Tecnológicamente son diferentes. OSGI es una especificación que tiene múltiples implementaciones. DI solía ser un patrón de diseño con múltiples implementaciones y API. Sin embargo, hay algunos trabajos recientes en JCP para tratar de estandarizar DI API (JSR 330)

Answer 3

La especificación OSGi se compone de dos partes separadas: núcleo y compendio.

La parte central es la especificación de un sistema de módulo para Java. Como tal, la especificación del núcleo no tiene relación con el concepto de DI.

La parte del compendio, en el otro lado, especifica una serie de servicios que un contenedor OSGi puede proporcionar. Entre estos servicios, encontrará la "Especificación de servicios declarativos" (Servicios de Compendio OSGi, Capítulo 112) que es el primer intento de llevar el concepto familiar de DI a OSGi. La idea es simple: dado que OSGi permite al desarrollador implementar, definir y registrar servicios, la Especificación de servicios declarativos le brinda al desarrollador la posibilidad de definir un servicio que depende de una serie de otros servicios subyacentes. Ese es un problema particularmente interesante (y difícil) en OSGi, porque los servicios son por definición poco confiables, y pueden aparecer y desaparecer.

Al lado de la Especificación de Servicios declarativa, hay al menos dos solución popular tratar de proporcionar una más potente marco DI en OSGi:

• Peaberry, una extensión del marco Guice para OSGi
• Spring Dynamic Modules for OSGi (aka Spring DM), la extensión OSGi del Spring Framework

Vale la pena señalar que la próxima versión R4.2 de la especificación OSGi contendrá un nuevo compendi um especificación llamada Blueprint Services, que proporcionará una solución DI completa para OSGi basada en el marco Spring DM (el equipo Spring ha contribuido en gran medida a esta nueva especificación)