PDF de programación - OSGI Roberto Montero

[email protected]
OSGI

1


 OSGI
 
 


 

Roberto
 Montero
 Miguel
 











 





INDICE

[email protected]
OSGI

2

2.1.4.1
 

2.2
 

2
 

1.1
 

2.1
 

2.1.2.1
 


Modularidad en Java--------------------------------------------------------------------------- 3
 
Introducción a OSGI ---------------------------------------------------------------------- 4
 
1
 
Introducción al documento -------------------------------------------------------------- 6
 
Especificación OSGI-----------------------------------------------------------------------11
 
OSGI Layers -------------------------------------------------------------------------12
 
Security Layer--------------------------------------------------------------------13
 
2.1.1
 
2.1.2
  Module Layer --------------------------------------------------------------------14
 
Bundle ----------------------------------------------------------------------16
 
2.1.2.1.1
  Orden de búsqueda de clases -----------------------------------------------18
 
2.1.2.1.2
  MANIFEST.MF -----------------------------------------------------------19
 
2.1.3
  LifeCicle Layer -------------------------------------------------------------------25
 
Service Layer---------------------------------------------------------------------27
 
2.1.4
 
System Services --------------------------------------------------------------29
 
Ejemplos Básicos---------------------------------------------------------------------29
 
2.2.1
  Clase Activator -------------------------------------------------------------------30
 
Listado-2.5 Activator con threads ------------------------------------------------------------32
 
Bundle que expone un servicio ----------------------------------------------------32
 
2.2.2
 
2.2.3
  Bundle que consume un servicio -----------------------------------------------------34
 
3
  Entornos de desarrollo y ejecución OSGI. --------------------------------------------------36
 
Entornos de Ejecución----------------------------------------------------------------37
 
3.1.1
  Eclipse Equinox ------------------------------------------------------------------37
 
Línea de Comandos Equinox--------------------------------------------------40
 
3.1.2
  Apache Felix ---------------------------------------------------------------------45
 
Repositorios de Apache Felix -------------------------------------------------46
 
Línea de comandos en Apache Felix -------------------------------------------47
 
Consola Web de Administración Felix -----------------------------------------49
 
3.1.3
  Knopflerfish----------------------------------------------------------------------52
 
Entornos de desarrollo ---------------------------------------------------------------54
 
Instalando Eclipse -----------------------------------------------------------55
 
3.2.1.1
 
Creando un nuevo proyecto---------------------------------------------------55
 
3.2.1.2
 
3.2.1.3
  Manifest File Editor----------------------------------------------------------59
 
Ejecutando nuestros bundles--------------------------------------------------66
 
3.2.1.4
 
3.2.2
  Maven: Pax Contructor Plugin ----------------------------------------------------68
 
Instalando Pax-Construct-----------------------------------------------------69
 
Configurando nuestro proyecto con Pax-Construct -----------------------------71
 
Crear bundles con Pax Construct ---------------------------------------------74
 
3.2.2.3.1
  BND - Bundle Tool --------------------------------------------------------75
 
Despliegue bundles con Pax Construct -----------------------------------------75
 
4
  ANEXO I: INDICE DE FIGURAS---------------------------------------------------------77
 
5
  ANEXO II: INDICE DE LISTADOS DE CODIGO FUEN TE -------------------------------79
 









3.2.2.1
 
3.2.2.2
 
3.2.2.3
 

3.1.2.1
 
3.1.2.2
 
3.1.2.3
 

3.2.2.4
 

3.1.1.1
 

3.1
 

3.2
 






Modularidad en Java

[email protected]
OSGI

3

la

ejecución del nuevo programa que queremos

Actualmente, la tendencia del desarrollo de aplicaciones camina hacia la construcción de
aplicaciones más complejas, pero con arquitecturas modulares que nos permitan gestionar
sus dependencias, así como ampliar la aplicación mediante la construcción de nuevos
módulos. Un claro ejemplo de éxito de este tipo de aplicaciones, es el proyecto eclipse, que
proporciona mecanismos para ampliar y personalizar fácilmente la plataforma mediante el
desarrollo de plugins. Otro caso de éxito, esta vez no basado en java, es la gestión de
dependencias que realizan algunos sistemas operativos como UBUNTU. Con Ubuntu y el
gestor de paquetes Synaptic, podremos instalar fácilmente nuevos programas, delegando en
el Synaptic la gestión de dependencias. Synaptic descargará de los repositorios los paquetes
necesarios para
instalar.


Desgraciadamente la plataforma Java 6, en si misma tiene escasos mecanismos de
modularización, limitada básicamente a la gestión de paquetes, clases y métodos. Es cierto,
que existen algunos herramientas como Spring o algunos patrones de diseño, que nos
pueden dar la sensación de que estamos construyendo una aplicación modular, ya que por
ejemplo Spring realiza inyección dependencias que permite un acoplamiento débil de las
clases mediante el uso de interfaces. Digo que “Spring nos dada la sensación de estar
construyendo aplicaciones modulares”, por que por ejemplo, en el caso de las aplicaciones
WEB, el uso de Spring nos permite dividir nuestro código en diferentes componentes, pero
finalmente los desplegamos en el servidor bajo un único modulo monolítico (WAR).


En teoría, una aplicación totalmente modular, nos debería permitir sustituir un modulo de
dicha aplicación por otro sin afectar al resto de los módulos. Por ejemplo, que yo sustituya
un módulo de la aplicación, no me debería de obligar a recompilar el resto de módulos.
Otro ejemplo, en una aplicación Web, que yo sustituya un módulo, no me debería obligar a
parar la aplicación por completo, ni siquiera deberían de dejar de dar servicio los módulos
que
sustituido.


Podemos


aplicación modular

proporcionaría

asegurar

que

una

del

módulo

no

dependen

nos

• Facilidad al cambio: Si cada módulo de una aplicación sólo se conoce
a través de su interfaz (y no por su aplicación interna), entonces es fácil de cambiar
una módulo con otro.

• Facilidad de Comprensión: Si una aplicación esta compuesta por módulos
perfectamente definidos y delimitados, resulta mas sencillo la comprensión y el
estudio de cada módulo de forma individual, y por lo tanto mas fácil la compresión
de la totalidad de la aplicación.

[email protected]
OSGI

4



• Desarrollo en paralelo: Los módulos pueden

ser desarrollados casi
independientemente unos de otros, haciendo posible que los equipos de desarrollo
de dividir las tareas.

• Aplicaciones fáciles de testear: Podremos probar cada módulo de forma

independiente.

• Reutilización: Al tratarse de módulos independientes, podremos usar fácilmente las

funcionalidades de un módulo de una aplicación en otro aplicativo.


Para escribir estas primeras líneas del tutorial, me he apoyado en el libro “Modular Java:
Creating Flexible Applications with OSGI and Spring”, libro totalmente recomendado para
aquel que quiera indagar un poco mas en sistemas modulares basados en java como OSGI
(Claro está, lo recomiendo, pero siempre después de haberse leído mi tutorial ;-D ).































1 Introducción a OSGI

[email protected]
OSGI

5


OSGI (Open Services Gateway Initiative), podríamos definirlo como un sistema (o
framework) modular para Java que establece las formas de crear módulos y la manera en
que estos interactuaran entre sí en tiempo de ejecución. OSGI intenta solventar los
problemas del tradicional "classloader" de la máquina virtual y de los servidores de
aplicaciones Java. En OSGI, cada módulo tiene su propio classpath separado del resto de
classpath de los demás módulos.

Este framework proporciona a los desarrolladores un entorno orientado a servicios y basado
en componentes, ofreciendo estándares para manejar los ciclos de vida del software.

La arquitectura OSGI se divide en capas, tal y como se representan en la figura 1.1, las
cuales se estudiarán detalladamente a lo largo de este documento.

Figura 1.1- Arquitectura OSGI



OSGI fue creado en Marzo de 1999, su objetivo es definir las especificaciones abiertas de
software que permitan diseñar plataformas compatibles que puedan proporcionar múltiples
servicios. Fue pensado principalmente para su aplicación en redes domésticas, con clara
orientación a ser introducido en pequeños y grandes dispositivos como por ejemplo, set-top
boxes, cable módems, electrodomésticos, PCs, coches, teléfonos móviles ..

La OSGi Alliance es un consorcio de empresas tecnológicas a nivel mundial que trata de
asegurar la interoperabilidad de las aplicaciones y servicios basados en esta plataforma
Entre las empresas que componen este consorcio, podemos encontrar compañías de diversa
índole: automoción, aeronáutica, fabricantes de electrodomésticos, telecomunicaciones,
fabricantes de teléfonos... Algunos ejemplos de miembros: Motorola, Nokia, Mitsubishi
Electric Corporation, Vodafone Group Services, LinkedIn, LG Electronics...

La alianza proporciona las especificaciones, las implementaciones de referencia, las suites
de prueba y la certificación.

Montero.