¿Qué hay de nuevo en OSGi 4.2?

Question

OSGi 4.2 tiene recién lanzado que actualiza la especificación 4.1 con algunos RFC nuevos. Entonces, ¿qué hay de nuevo en OSGi 4.2, que marcos soportan 4.2 (o están cerca) y por qué debería enfocarse en nuevos desarrollos en un marco 4.2 en lugar de un 4.1?

Answer 1

En la mayoría de los casos, un lanzamiento puntual de OSGi (como 4.1- > 4.2) realmente no cambia mucho el comportamiento existente, por lo que es seguro decir que si tiene una aplicación que depende de 4.1, se ejecutará en 4.2 sin problema. Lo nuevo es que algunos elementos se han estandarizado, lo que debería permitir una mejor interoperabilidad entre los diferentes motores OSGi (como Equinox , Felix y Knopflerfish ).

De hecho, aunque OSGi 4.2 solo se lanzó oficialmente el 16 de septiembre de 2009, los primeros borradores han estado disponibles para que otros los consulten, por lo que las versiones anteriores de los productos (como Equinox 3.5, Felix 1.8) ya tienen un soporte razonable para el estándar. Al igual que los productos 802.11n, se ajustaban a borradores anteriores, pero se espera que se certifiquen como totalmente compatibles con la versión 4.2 en un futuro no muy lejano.

Entonces, ¿qué hay de nuevo en 4.2?

• Ganchos de servicio
• Lanzamiento de marco

Y, en el compendio

• Servicios remotos
• Rastreador de paquetes
• Servicio de planos

Ganchos de servicio

La API de enlace de servicio le permite detectar eventos que ocurren en la capa de servicio. Por ejemplo, puede conectarse cuando se solicita un servicio, cuando un servicio tiene un evento entregado, etc. También puede hacer que los eventos no se entreguen (por ejemplo, ocultar eventos que no está autorizado para ver) pero no puede cambiar ningún evento (ya que esto complicaría las clases que se entregan). Los enlaces de servicio son parte de la especificación central, por lo que todas las versiones de OSGi necesitarán que sea compatible.

Lanzamiento del marco

Aunque es posible iniciar mediante programación una instancia de OSGi desde una aplicación Java existente, la forma en que lo hace depende del tiempo de ejecución de OSGi que esté utilizando. En particular, los elementos de configuración (como dónde almacenar datos transitorios, cuál debería ser la política de delegación de arranque del paquete, etc.) se definieron de manera específica del motor. Esto consolida las propiedades que se configuran en el marco mediante cualquier utilidad de inicio.

Servicios remotos

La API de servicios remotos permite que los servicios OGSi se comuniquen entre máquinas virtuales (posiblemente en diferentes máquinas). El mecanismo exacto de cómo se comunican (RMI, WebServices, etc.) está abierto a los proveedores, por lo que es diferente a otras tecnologías distribuidas (como Corba) que dictan específicamente un formato en el cable. Claramente, los servicios distribuidos tienen una semántica diferente a la local (errores de comunicación, problemas de serialización) y se deja que los servicios individuales se distribuyan si es necesario.

Rastreador de paquetes

Al igual que el ServiceTracker anterior a 4.1, el BundleTracker se puede usar para vigilar qué paquetes van y vienen en el sistema. Esto puede ser utilizado por las GUI dinámicas para mostrar el estado en evolución del motor OSGi sin ningún conocimiento específico de la plataforma.

Servicio de planos

El servicio blueprint es similar a Spring, ya que proporciona un mecanismo de inyección de dependencia para configurar paquetes. En algunos aspectos, es similar a los servicios declarativos; pero el servicio de planos hace las cosas de manera diferente. Además, a diferencia de los servicios declarativos (que solo pueden ocuparse de los servicios que están presentes), el servicio de anteproyecto puede crear un marcador de posición por adelantado para un servicio que se pondrá en línea más adelante. Las llamadas al proxy de servicio se bloquearán hasta que se pueda completar el servicio (en lugar de devolver 'nulo' como lo harán los servicios declarativos). Si se siente cómodo o familiarizado con Spring IOC y una inyección de dependencia similar, entonces el servicio Blueprint será inmediatamente comprensible.

Answer 2

Este artículo detalla las RFC de interés. Para citar,

  

En primer lugar uno tiene que notar que   este no es un lanzamiento menor ya que el   El número de versión puede sugerir. Lanzamiento   4.2 es en realidad mucho más significativo que la versión R4.1 del año pasado. A   algunos puntos incluso diría que es   más importante que la versión R4,   porque con ese uso se convierte   mucho más fácil, especialmente para ninguno   Expertos en OSGi.

Answer 3

Los primeros cambios fueron destacado aquí .

En particular, la función RFC 119 - Distribuida OSGi es interesante:

  

Esta solución define un nivel mínimo de característica / función para el procesamiento distribuido de OSGi, incluido el descubrimiento de servicios y el acceso ay desde entornos externos.

Eso combinado con EventAdmin (introducido en 41), permitirá implementaciones más fáciles de servicios distribuidos basados ??en OSGi (actualmente implementado con ECF )

Answer 4

¿Los servicios declarativos realmente devuelven nulo cuando un enlace de referencia no está disponible? En Equinox, incluso si configuro el modo en dinámico, mi componente nunca se instancia si no se puede "cablear". Prefiero que se establezca en "nulo" como usted dice, para poder tener enlaces de referencia opcionales y usar descubrimiento dinámico ...

Además, echo de menos la posibilidad de encontrar fácilmente las propiedades de los componentes cuando un servicio está vinculado (tengo que ir al contexto Bundle, obtener referencias de servicio, iterar y comparar, no es práctico). Tal vez me falta algo.