Il framework OSGi

OSGi definisce un sistema modulo dinamico per Java™. La piattaforma di servizio OSGi ha un'architettura a livelli ed è progettata per essere eseguita su vari profili Java standard.

Le applicazioni OSGi distribuite su WebSphere® Application Server vengono eseguite su un profilo Enterprise Java fornito come parte dell'ambiente di runtime del server. Questo ambiente fornisce anche il framework OSGi in cui vengono eseguite le applicazioni OSGi. Eclipse Equinox è l'implementazione di riferimento di OSGi Service Platform Release 4 Versione 4.2 Enterprise Specification e WebSphere Application Server utilizza Equinox come framework per OSGi Applications. La versione precisa di Equinox dipende dal livello di servizio di WebSphere Application Server.

Il framework OSGi integrato in WebSphere Application Server fornisce supporto per ciascuno dei livelli dell'architettura OSGi:

Livello moduli

L'unità di distribuzione in OSGi è un bundle. Il livello dei moduli è il punto in cui OSGi Framework elabora gli aspetti modulari di un bundle. I metadati che consentono al framework OSGi di eseguire questa elaborazione vengono forniti in un file manifest del bundle. Per ulteriori informazioni su questo file, consultare Esempio: file manifest del bundle OSGi.

Un vantaggio chiave di OSGi è il suo modello di programma di caricamento classi, che usa i metadati nel file manifest. Non esiste alcun percorso di classe globale in OSGi. Quando i bundle vengono installati nel framework OSGi, i loro metadati vengono elaborati dal livello del modulo e le loro dipendenze esterne dichiarate vengono riconciliate rispetto alle esportazioni con versione dichiarate da altri moduli installati. Il framework OSGi gestisce tutte le dipendenze e calcola il percorso classe richiesto indipendente per ciascun bundle. Questo approccio risolve le carenze del caricamento della classe Java semplice assicurando che i seguenti requisiti siano soddisfatti:
  • Ogni bundle fornisce visibilità solo ai pacchetti Java che esporta esplicitamente.
  • Ciascun bundle dichiara esplicitamente le proprie dipendenze del package.
  • I package possono essere esportati in versioni specifiche e importati in versioni specifiche o da un intervallo specifico di versioni.
  • Più versioni di un pacchetto possono essere disponibili contemporaneamente per client diversi.

Livello ciclo di vita

Il livello di gestione del ciclo di vita dei bundle in OSGi consente ai bundle di essere installati, avviati, arrestati e disinstallati in modo dinamico, indipendentemente dal ciclo di vita del server delle applicazioni. Il livello del ciclo di vita assicura che i bundle vengano avviati solo se tutte le loro dipendenze sono risolte, riducendo il verificarsi di eccezioni ClassNotFoundException in fase di esecuzione. Se ci sono dipendenze non risolte, il framework OSGi le riporta e non avvia il bundle.

Ciascun bundle può fornire una classe attivatore del bundle, identificata nel manifest del bundle, che il framework richiama sugli eventi di avvio e arresto. In questo modo, un bundle può fornire un codice di inizializzazione e ripulitura speciale, se necessario, anche se la maggior parte delle applicazioni OSGi distribuite su WebSphere Application Server non dovrebbe essere necessaria. Se un bundle necessita di un attivatore di bundle di template, è possibile utilizzare IBM® Rational® Application Developer Versione 8.5 per generarne uno.

Livello servizi

Il livello dei servizi in OSGi supporta intrinsecamente una SOA (service - oriented architecture) tramite il relativo componente di registro dei servizi non durevole. I bundle pubblicano i servizi nel registro di servizio e altri bundle possono rilevare tali servizi dal registro di servizio.

Questi servizi sono il principale mezzo di collaborazione tra i bundle. Un servizio OSGi viene implementato utilizzando uno dei seguenti modelli di componenti supportati:
  • Un bean gestito da Blueprint.
  • Un bean enterprise.
Un servizio OSGi viene pubblicato nel registro del servizio sotto uno o più nomi di interfaccia Java, con metadati facoltativi memorizzati come proprietà personalizzate (coppie nome / valore). Un bundle di rilevamento può cercare un servizio nel registro del servizio in base a un nome interfaccia e può potenzialmente filtrare i servizi che vengono ricerati in base alle proprietà personalizzate.

I servizi sono completamente dinamici e generalmente hanno lo stesso ciclo di vita del bundle che li fornisce. Le applicazioni OSGi in WebSphere Application Server generalmente interagiscono con il registro del servizio OSGi tramite una definizione del modulo Blueprint. I componenti del bean POJO descritti nella definizione del modulo Blueprint possono essere registrati come servizi tramite un elemento < service> o possono avere riferimenti di servizio inseriti in essi tramite un elemento < reference>.