¿Qué hay de nuevo en OSGi 4.2?

Question

OSGi 4.2 tiene just been released que actualiza la especificación 4.1 con algunas nuevas RFC. Entonces, ¿qué hay de nuevo en particular con OSGi 4.2, qué frameworks soportan 4.2 (o están cerca de) y por qué debería apuntar a nuevos desarrollos contra un framework 4.2 en lugar de un 4.1?

Answer 1

En la mayoría de los casos, un punto de desenganche 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 problemas. Lo nuevo es que algunos artículos se han estandarizado, lo que debería permitir una mejor interoperabilidad entre diferentes motores OSGi (como Equinox, Felix y Knopflerfish).

De hecho, a pesar de OSGi 4.2 solamente fue lanzado oficialmente el 16 de septiembre de 2009, los primeros borradores han estado disponibles para que otros se refieren a, por lo que las versiones anteriores de los productos (como Equinox 3.5, Felix 1.8) ya tiene un apoyo razonable el estandar. Al igual que los productos 802.11n, se ajustaron a borradores anteriores, pero la expectativa es que serán certificados como totalmente compatibles con la versión 4.2 en un futuro no muy lejano.

¿Qué hay de nuevo en 4.2?

• Servicio Ganchos
• marco de lanzamiento

Y, en el compendio

• servicios remotos
• Bundle Rastreador
• Servicio Blueprint

Servicio Ganchos

El servicio API Hook le permite escoger a día sobre los acontecimientos que ocurren en la capa de servicio. Por ejemplo, puede conectar cuando se solicita un servicio, cuando un servicio tiene un evento entregado, y así sucesivamente. También puede provocar que no se entreguen los eventos (por ejemplo, ocultar eventos que no está autorizado a ver) pero no puede cambiar ningún evento (ya que esto complicaría las clases entregadas). Los enlaces de servicio son parte de la especificación principal, por lo que todas las versiones de OSGi necesitarán que esto sea compatible.

Marco de lanzamiento

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

servicios remotos

La API de servicios a distancia permite a los servicios OGSI para la comunicación 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 de otras tecnologías distribuidas (como Corba) que dictan específicamente un formato de conexión. 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 sean distribuibles si es necesario.

Bundle Rastreador

Al igual que el ServiceTracker antes de que en el apartado 4.1, el BundleTracker se puede utilizar para mantener un ojo en la cual los paquetes van y vienen en el sistema. Esto puede ser utilizado por GUI dinámicas para mostrar el estado evolutivo del motor OSGi sin ningún conocimiento específico de la plataforma.

Servicio Blueprint servicio

El modelo es similar a la primavera, ya que proporciona un mecanismo de inyección de dependencias para la configuración de paquetes. En algunos aspectos, es similar a los servicios declarativos; pero el servicio blueprint hace las cosas de una manera diferente. Además, a diferencia de los servicios declarativos (que solo pueden ocuparse de los servicios que están presentes), el servicio de planos 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 del servicio se bloquearán hasta que se pueda completar el servicio (en lugar de devolver 'nulo' como lo harán los servicios declarativos). Si está cómodo o familiarizado con Spring IOC e inyección de dependencia similar, entonces el servicio de Blueprint será inmediatamente comprensible.

Answer 2

This article detalla los RFC de interés. Para citar,

En primer lugar se tiene que notar que esto no es una versión menor que el número de versión puede sugerir. La versión 4.2 es en realidad mucho más significativa que la versión R4.1 del año pasado. En algunos puntos, incluso diría que es más importante que la versión R4, porque con ese uso se convierte en manera más fácil, especialmente para ninguno expertos OSGi.

Answer 3

Los primeros cambios fueron highlighted here.

En particular, el RFC 119 - Distributed característica OSGi es interesante:

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

que combinado con el EventAdmin (introducido en 41), permitirá implementaciones más fáciles de servicios distribuidos basados ​​en OSGi (implementados actualmente with ECF)

Answer 4

¿Los servicios declarativos realmente devuelven nulo cuando un enlace de referencia no está disponible? En Equinox, incluso si establezco el modo en dinámico, mi componente nunca se instancia si no se puede "conectar". Prefiero que se configure como "nulo" como dices, para poder tener enlaces de referencia opcionales y usar el 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, repetir y comparar, no práctico). Aunque tal vez me esté perdiendo algo.