# OSGi

OSGi Alliance,conocida formalmente como Open Services Gateway initiative, es un conjunto de estándares abiertos creado en marzo de 1999 cuyo objetivo es definir las especificaciones abiertas de software que permitan diseñar plataformas compatibles que puedan proporcionar múltiples servicios.
Aunque OSGi define su propia arquitectura, ha sido pensada para su compatibilidad con Jni o Universal Plug and Play (UPnP).
La arquitectura de OSGi posee dos elementos fundamentales de los cuales el Service Platform está situado en la red local y conectada al proveedor de servicios a través de una pasarela en la red del operador. Este elemento será el responsable de permitir la interacción entre dispositivos o redes de dispositivos que podrían utilizar distintas tecnologías para comunicarse.
La especificación de OSGi se ha definido con una serie de interfaces de programación de aplicaciones (API) básicas para el desarrollo de servicios, como los de logging, servidor web (HTTP) y el Device Access Specification (DAS), que permite descubrir los dispositivos y servicios ofrecidos por estos.
Las especificaciones OSGi han evolucionado más allá de los propósitos originales de pasarela de servicios, y actualmente se utilizan en un amplio abanico de aplicaciones desde telefonía móvil hasta el entorno de programación Eclipse. Otras áreas de aplicación incluyen automoviles, automatización industrial, Inmótica, PDAs, computación en malla, entretenimiento, gestión de flotas y servidor de aplicaciones.

## Proceso de especificación

El proceso de especificación OSGi fue desarrollado por los miembros de un proceso abierto y se dispuso que sea libre de cargos al público bajo la "Licencia de Especificación OSGi". OSGi Alliance tiene un programa de cumplimiento normativo que es solo abierto a sus miembros. Desde noviembre de 2010, hay siete implementaciones certificadas del framework OSGi.

## Arquitectura

OSGi es un framework de Java para desarrollar y desplegar módulos de software. Cada bundle es un conjunto acoplado, una colección que de clases, jars, y archivos de configuración que se pueden cargar dinámicamente, en las cuales se declara explícitamente sus dependencias externas, si es necesario.
El framework está dividido conceptualmente en las siguientes partes:

### Bundles

    Los bundles son componentes en formato de archivos JAR con el agregado de archivos cabecera llamados manifest headers (manifiesto de encabezado).

### Servicios

    La capa de servicios conecta los bundles en forma dinámica que ofrece un modelo para publicación, búsqueda y enlace para interfaces POJO o plain old Java object (POJO).

### Registro de servicios

    La api para administración de servicios.

### Ciclo de vida

    La api para la administración de ciclos de vida para los bundles(instalación, inicio, fin, actualización, y desinstalación).

### Módulos

    La capa que define la encapsulación y la declaración de dependencias (cómo un bundle importa y exporta código).

### Seguridad

    La capa que maneja los aspectos de seguridad limitando la funcionalidad del bundle a ciertas capacidades predefinidas.

### Ambiente de ejecución

    Define de qué métodos y clases se didsponen en una plataforma en particular. No existe una lista prefijada de ambientes de ejecución, ya que está sujeta a cambios siempre que el Java Community Process vaya creando nuevas versiones y ediciones de Java. Sin embargo, actualmente la mayoría de las implementaciones OSGi soporta los siguientes ambientes:
   * CDC-1.0/Foundation-1.0
   * CDC-1.1/Foundation-1.1
   * OSGi/Minimum-1.0
   * OSGi/Minimum-1.1
   * JRE-1.1
   * Desde J2SE-1.2 hasta J2SE-1.6

## Bundles

Un bundle es un conjunto de clases Java y de recursos adicionales que incluye el agregado de un archivo manifiesto detallado MANIFEST.MF que informa de todo el contenido, así como de los servicios adicionales que son necesarios para dar al grupo de clases de Java comportamientos más sofisticados, hasta el punto de considerar a todo el agregado como un componente.
El siguiente ejemplo es el código de un archivo MANIFEST.MF para el encabezado OSGi:
El ejemplo detalla lo siguiente :
* Bundle-Name: Define un nombre para el bundle, se le asigna un nombre corto.
* Bundle-SymbolicName: El único encabezado obligatorio, esta entrada debe especificar un identificador único para un bundle, basedo en la notación de nombre de dominio inverso (usada también en los paquetes de java).
* Bundle-Description: Una descripción de la funcionalidad del bundle.
* Bundle-ManifestVersion: Indica la especificación OSGi utilizada para leer el bundle.
* Bundle-Version: Designación de un número de versión al bundle.
* Bundle-Activator: Indica el nombre de la clase que será invocada por el bundle cuando sea activada.
* Export-Package: Expresa qué paquetes Java están contenidos en el bundle los cuales estárán disponibles para el mundo exterior.
* Import-Package: Indica qué paquetes Java se necesitan en el mundo exterior para satisfacer las dependencias necesarias del bundle.

## Ciclo de vida

Una capa de Ciclo de Vida agrega bundles las cuales pueden dinámicamente ser instaladas, iniciadas, finalizadas, actualizadas y desinstaladas. Los bundles están sobre la capa del módulo para cargar la clase pero agrega una API para administrar los módulos en tiempo de ejecución. La capa de ciclo de vida introduce una dinámica que normalmente no es parte de una aplicación. Usa mecanismos de dependencia extensiva para asegurar el correcto funcionamiento del ambiente. Las operaciones del ciclo de vida están protegidas completamente con una arquitectura de seguridad.
| Estado del Bundle | Descripción |
| INSTALLED (INSTALADO) | El bundle fue instalado exitosamente. |
| RESOLVED (RESUELTO) | Todas las clases Java que necesita el bundle están instaladas. Este estado indica que el bundle está listo para iniciar o finalizar. |
| STARTING (INICIANDO) | El bundle está iniciando, el método BundleActivator.start fue llamado el método de inicio no ha terminado. Cuando el bundle tiene una política de activación, el bundle queda en el estado STARTING hasta que el bundle se active according según su política de activación. |
| ACTIVE (ACTIVO) | El bundle ha sido activado exitosamente y está en ejecución; su método de inicio Bundle Activator fue llamado y ha terminado. |
| STOPPING (FINALIZACIÓN) | EL bundle está siendo finalizado. Se ha llamado al método BundleActivator.stop pero este aun no ha terminado.. |
| UNINSTALLED (DESINSTALADO) | El bundle fue desinstalado. No se puede pasar a otro estado. |
El siguiente ejemplo es una clase Java títpica que implemeta el código de una interfaz de BundleActivator:

## Implementaciones actuales del framework OSGi

| Nombre | Licencia |
| Apache Felix | Código abierto |
| Concierge OSGi | Código abierto |
| Equinox OSGi | Código abierto |
| Knopflerfish | Código abierto |
| Bosch IoT Gateway Software | Comercial |
| Eclipse Gemini | Código abierto |

## Versiones de la especificación

* OSGi Release 1 (R1): mayo de 2000
* OSGi Release 2 (R2): octubre de 2001
* OSGi Release 3 (R3): marzo de 2003
* OSGi Release 4 (R4): octubre de 2005 / septiembre de 2006
** Core Specification (R4 Core): octubre de 2005
** Mobile Specification (R4 Mobile / JSR-232): septiembre de 2006
* OSGi Release 4.1 (R4.1): mayo de 2007 (AKA JSR-291)
* OSGi Release 4.2 (R4.2): septiembre de 2009
** Enterprise Specification (R4.2): marzo de 2010
* OSGi Release 4.3 (R4.3): abril de 2011
** Core: abril de 2011
** Compendium and Residential: mayo de 2012
* OSGi Release 5 (R5): junio de 2012
** Core and Enterprise: junio de 2012
* OSGi Release 6 (R6): junio de 2015
** Core: junio de 2015
* OSGi Release 7 (R7): abril de 2018
** Core and Compendium: abril de 2018
* OSGi Release 8 (R8): Draft marzo de 2020