Osgi

Intro / Java Classloading y sus problemas

  • Modularidad:
    • división del trabajo,
    • abstracción
    • reuso
    • mantenimiento.
  • Módulo:
    • autocontenido
    • cohesivo
    • desacoplado:
  • Java
    • Classloader:
      • busca las clases físicas y las carga a su representación de Class en el ambiente (VM).
      • Jerarquía de classloading en forma de arbol. Limitante (como pasa con la jerarquía de clases)
      • Delega en el padre primero.
    • JARs: formato de empaquetado de classes & recursos, basado en ZIP + metadata extensible.
    • Problemas:
      • El concepto de JAR o módulo se pierde en runtime. Solo existe en tiempo de build & deploy.
      • No declaran/modelan las dependencias entre sí.
      • No tienen versiones. (El esquema de classloading no las diferencia)
      • No pueden existir múltiples versiones simultaneamente.
    • Todo esto a causa de ? "Global Flat Classpath"

OSGi: Open Service Gateway initiative

Modulos y Dependencias

  • Module System.
  • Modela la idea de módulos y cómo interactúan.
  • Modulo es Bundle.
  • Bundle
    • Simple JAR, backward compatible.
    • Con metadata: nombre de bundle, version, imports & exports (dependencias de classes), etc
  • Dependencias:
    • Elimina el "flat classpath":
    • Cada modulo tiene su propio "classpath" aislado de los demás módulos..
    • La forma de compartir classes (dependencias entre bundles) es completamente controlada y explícita.
      • Requiero tal bundle
      • Requiero tales packages (regular expression)
      • Requiero tales classes
    • Todas las dependencias pueden incluir versión (rangos, y mayor.minor.micro.qualifier).
    • Classpath isolation y dependencias versionadas permiten tener múltiples versiones del mismo bundle conviviendo.
    • Utiliza un grafo de dependencias(classloaders), en lugar de un arbol. Así es más flexible y permite compartir clases en cualquier direccion (no solo vertical).
  • Permite encapsulamiento de bundles (por default todo es private).

Modulos dinámicos: Ciclo de Vida

lifecycle.png
  • Ambiente vivo:
    • Agregar nuevos bundles. (install)
    • Remover bundles. (un-install)
    • Refrescar bundles (update)
    • TODO SIN REINICIAR EL AMBIENTE!
  • Interaccion con el framework (API):
    • Introspectar los bundles instalados.
    • Manipularlos: start, stop, un-install, update.
    • Instalar nuevos
    • Des/Registrar Listeners de Bundles
    • Des/Registrar Listeners de Servicios
    • Des/Registrar Listeners de Framework

Servicios

soa.png
  • Plain Java Objects
  • Arquitectura SOA pura (sin webservices, SOAP, ni XML ;)
  • No estan "cableados" (vs. Depedency Injection o Factories), sino que…
  • Se des/registran dinamicamente (ServiceRegistry)
  • OSGi maneja esta asociacion entre ServiceProvider y Consumer (tiene poder sobre ellas).
  • Binding de servicios:
    • Ask: obtener/pedirlos explicitamente.
    • Listeners: observer pattern.
    • ServiceTracker: encapsula la complejidad. No es un listener pasivo sino que trackea un servicio activamente.
  • Mayor complejidad pero mayor poder.

Yapa

  • Fragments
  • Classloading de bundles: bootstrap, import packages, bundles, internal classpath, fragments.
  • Servicios Declarativos.

Material complementario

TODO's

//AGREGAR CODIGO DE EJEMPLO

Links

Unless otherwise stated, the content of this page is licensed under Creative Commons Attribution-ShareAlike 3.0 License