java - OSGi: ¿Cuál es la diferencia entre Import-Package/Export-Package y Require-Capability/Provide Capability?

requirements

Question

Actualmente estoy trabajando con el marco OSGi pero tengo una pregunta sobre algunos conceptos que no me resultan 100% claros. Lo busqué yo mismo pero no pude encontrar una respuesta decente que lo explique claramente.

En un paquete, su encabezado manifiesto 2 de los encabezados que se utilizan son Import-Package y Export-Package . Los nombres hablan por sí mismos: una demanda de un paquete determinado y una oferta de un paquete determinado. Para obtener ese paquete (o dar ese paquete), el paquete completo debe instalarse en el marco donde se necesita la importación .

Pero luego llegamos a la parte del modelo Requirements-Capabilities . Esto prácticamente puede hacer lo mismo que los encabezados Import-Package y Export-Package . También hay encabezados para este modelo de Requirements-Capability Provide-Capability . Nuevamente, estas representan exigir algo y proporcionar algo.

Sé que el modelo Requirements-Capability solo se introdujo más adelante en el desarrollo de las especificaciones OSGi. No puedo encontrar exactamente en qué año y versión se presentó.

Pero,

• ¿Por qué se ha agregado esto a la especificación? No veo qué tiene más para ofrecer que lo que ya ofrecía el Export-package Import / Export-package : ¿crear dependencias en otros paquetes / paquetes?

• ¿Podría alguien darme una mejor comprensión de la diferencia (pro y contra) entre estos 2 conjuntos de conceptos?

Answer 1

Cuando comenzamos con OSGi en 1998, teníamos algunos requisitos claros pero, por supuesto, no teníamos una visión clara de lo que saldría de ello. Entonces comenzamos a modelar explícitamente los requisitos y capacidades que teníamos: paquetes. El paquete de importación requiere una capacidad y esa capacidad es proporcionada por un paquete de exportación.

En 2003 Eclipse quería comenzar a usar OSGi pero necesitaban una instalación para requerir otro paquete, no les gustaba la idea de exportar e importar todos sus paquetes. En realidad, en ese momento no pudieron ver el beneficio de los paquetes. Para satisfacerlos, agregamos Require-Bundle y Fragment-Host (otro de sus deseos que resultó no ser tan bueno).

Después de especificar OSGi 4.x con estas extensiones, comenzamos a pensar en un repositorio, Richard había desarrollado el repositorio Oscar Bundle. Al analizar la situación con los nuevos encabezados en OSGi 4.0, quedó claro que la implementación de Import-Package se parecía mucho a Require-Bundle, e incluso se parecía al procesamiento Fragment-Host.

En 2006, Richard S. Hall y yo escribimos RFC 112 proponiendo un modelo más genérico que capturaba la semántica del modelo de dependencia existente pero que no era específico para cada tipo de requisito. Es decir, para la resolución de Framework, Import-Package y Require-Bundle solo difieren en su espacio de nombres . Pensar en Import-Package como un requisito genérico y Export-Package como una capacidad genérica hizo que el modelo de repositorio fuera extremadamente simple. Aún mejor, era extensible ya que siempre podíamos agregar más espacios de nombres. Esto hizo que el resolutor sea completamente independiente de los espacios de nombres reales utilizados.

Después de algunas discusiones muy acaloradas, el Grupo de Expertos de la Plataforma Core de OSGi decidió aceptar la idea básica y desarrolló las especificaciones de Requisitos y Capacidades. Aunque originalmente era un modelo para el repositorio, resultó ser muy útil para el propio Framework. Por lo tanto, decidimos adaptar las especificaciones existentes a este modelo. OSGi 4.3 modela internamente el paquete de importación, el paquete de exportación, el paquete de requisitos, etc., como requisitos y capacidades de un recurso (el paquete). Por compatibilidad con versiones anteriores, conservamos los encabezados existentes, pero se traducen internamente en requisitos y capacidades.

Luego finalmente a la respuesta a su pregunta. Con el tiempo, las especificaciones OSGi agregaron más y más espacios de nombres . Un espacio de nombres es como un tipo para un Requisito y una Capacidad. Define la semántica de un conjunto de propiedades de una Capacidad en ese espacio de nombres. Un requisito es una expresión de filtro que se afirma en esas propiedades. Un recurso tiene un conjunto de capacidades que se proporcionan al tiempo de ejecución cuando se cumplen todos sus requisitos. El Resolver tiene la tarea de encontrar un conjunto de recursos que estén satisfechos con las capacidades y capacidades del otro proporcionadas por el tiempo de ejecución.

Por ejemplo, agregamos el espacio de nombres osgi.ee que define exactamente en qué VM se puede ejecutar el paquete. osgi.extender espacio de nombres osgi.extender que modela una dependencia en un programa externo como el Service Component Runtime (SCR). La mayoría de los componentes SCR no requieren ningún paquete del SCR en sí, nos esforzamos por hacerlos lo más independientes posible. Sin embargo, un componente SCR quedará inútil a menos que algún paquete en el tiempo de ejecución proporcione la funcionalidad SCR. Tenga en cuenta que esto no puede usar Require-Bundle porque hay múltiples implementaciones de SCR. Creo que hay unos 20 espacios de nombres. Cada espacio de nombres se define en una clase de Namespace .

Este modelo le ha dado a OSGi una serie de ventajas:

• Cohesión Aunque la especificación ha agregado muchos espacios de nombres, las implementaciones de resolución nunca tuvieron que cambiar ya que trabajaron en el modelo genérico.
• Los paquetes OSGi de grano fino son únicos en cómo describen sus dependencias de una manera muy fina. Todos los sistemas de módulos que conozco tienden a usar la dependencia simple de módulo a módulo que no permite la sustitución.
• Flexible Dado que el Framework reifica las dependencias entre paquetes, en tiempo de ejecución es posible aprovechar estas dependencias. Por ejemplo, en OSGi enRoute vinculé un paquete a su página web atravesando estos cables de tiempo de ejecución.

Personalmente considero el modelo de Requisitos y Capacidad de OSGi uno de sus secretos mejor guardados. Hasta donde puedo ver, podría usarse en muchas áreas para mejorar muchos proyectos de desarrollo en el mundo de la ingeniería de software.

La única parte decepcionante de esta pregunta es que pensé que lo habíamos descrito bastante bien en la especificación Core . :-)

Answer 2

El modelo de requisitos y capacidades es una extensión del modelo de paquete Importar / Exportar. En realidad, puede expresar una importación de paquete como un requisito y una exportación de paquete como una capacidad.

La exportación / importación de paquetes permite un acoplamiento suelto. Exporta una API y el cliente la importa. De esta manera, el cliente solo necesita saber acerca de la API para lograr un acoplamiento flexible.

En una etapa posterior, cuando ensambla la aplicación de paquetes, este acoplamiento flojo dificulta la automatización del proceso.

Si solo proporciona su paquete de cliente a un resolutor, entonces solo puede encontrar automáticamente que necesita el paquete que proporciona la API. Si la implementación de la API está en un paquete diferente, el solucionador no tiene forma de saber que la necesita.

Aquí es donde los requisitos pueden ayudar. Tomemos el modelo de pizarra blanca HTTP . Un paquete que desee publicar un servlet debe importar el paquete de la API de servlet, pero también debe expresar que desea una implementación de la pizarra de http osgi.

Esto puede expresarse mediante el requisito con namespace = "osgi.implementation", name = "osgi.http", version = "1.1.0". Como esto es difícil de escribir a mano, hay soporte para anotaciones.

@HttpWhiteboardServletPattern("/myservlet")
@Component(service = Servlet.class)
public class MyServlet extends HttpServlet {
    protected void doGet(HttpServletRequest req, HttpServletResponse resp) 
            throws IOException {
        resp.getWriter().println("Hello");
    }
}

La anotación @HttpWhiteboardServletPattern se traduce indirectamente al requisito anterior.

Entonces, cuando crea un paquete con esta clase, importará el paquete de API de servlet y también tendrá un requisito para una implementación de pizarra blanca http.

Ahora, si observa un paquete de implementación como el servicio felix http, verá que proporciona la capacidad para la pizarra impl.

Entonces, si tiene un repositorio OSGi con su paquete, la API de servlet y el servicio http de felix. Entonces, el solucionador puede proporcionarle una aplicación completa si solo le da su paquete.