An overview and remarks on OSGI modularity and dynamism within RCP and JEE projects: from bundle and OSGi specific concepts (with java modularity and dynamism explanations), to enterprise application features and points of contact between JEE and OSGi.
1. Uno scorcio sul mondo OSGi e OSGi enterprise:
modularita' e dinamismo
Giacomo Pallotti
giacomo.pallotti@gmail.com
2. abstract...
Modularità e Dinamismo
Modularità e Dinamismo in Java e JEE
Diario di un bravo sviluppatore JEE
Cosa è OSGI
OSGI Alliance
Layer
Specifiche OSGi Alliance
Eclipse ed il framework OSGi
Container osgi e osgi enterprise open source
Casi d'esempio
→ bundle
→ service provider
→ service client
→ web app (servlet)
LinuxDay 2010 Giacomo Pallotti - OSGI e OSGI Enterprise 2
3. Modularità
E' la scomposizione logica di un sistema in un insieme di
sottosistemi più piccoli che collaborano tra di loro.
A1
A A2
A'
A3
LinuxDay 2010 Giacomo Pallotti - OSGI e OSGI Enterprise 3
4. Dinamismo
E' la capacità di variare un sistema in maniera indipendente
senza coinvolgere (e stravolgere...) tutte le altre parti del
sistema.
A B D
D'
D C
LinuxDay 2010 Giacomo Pallotti - OSGI e OSGI Enterprise 4
5. Modularità in Java
ll linguaggio Java non è nato con lo scopo di supportare una
programmazione modulare; il suo più grande pregio, oltre al “Write
Once Run Anywhere (o Everywhere)”, è la capacità di costruire
applicazioni di tutti i tipi, da embedded a mobile, da rich client a
enterprise.
Quindi il criticare Java per una caratterista che non faceva parte delle
sue specifiche sarebbe quanto meno non giusto.
Java ha introdotto i concetti di package e visibilità (public, protected,
private) in relazione all' “encapsulation” (incapsulamento), cioè la
possibilità di impacchettare in una singola entità i dati e le azioni che
sono riconducibili ad un singolo componente.
Il fine NON era quello del partizionamento logico di un sistema, ma di
una organizzazione finalizzata al singolo componente
LinuxDay 2010 Giacomo Pallotti - OSGI e OSGI Enterprise 5
6. La divisione delle classi in package, e la visibilità dei metodi e delle
variabili delle classi all'interno dello stesso package oppure da
package diversi, obbligano a definire spesso “public” o al massimo
“protected” (se le classi sono in gerarchia) tali metodi.
In pratica la scelta di uno sviluppatore è:
1 - mandare a quel paese la struttura logica della propria applicazione
accorpando nello stesso package classi che non sono in relazione tra
di loro, per evitare di esporre metodi non public.
2 – Mantenere la struttura logica utilizzando però package multipli con
il costo di esporre metodi public che possono essere acceduti anche
dalle classi degli altri package
LinuxDay 2010 Giacomo Pallotti - OSGI e OSGI Enterprise 6
7. Dinamismo in Java
Un'applicazione Java (sia una stand alone application, sia una webapp più o
meno complessa) è composte da componenti interni (classi, risorse varie, file di
configurazioni, ...) e da liberie (jar) esterne. Queste librerie verosimilmente
hanno una versione e certe dipendenze da altre librerie.
La VM e il class loader non supportano la possibilità di avere versioni diverse di
uno stesso jar → viene caricato il primo che viene trovato nel claspath.
Classpath → Compile Time vs Runtime
LinuxDay 2010 Giacomo Pallotti - OSGI e OSGI Enterprise 7
8. Diario di un bravo JEE developer …
C'era una volta un bravo sviluppatore java enterprise.
Ha sviluppato una web application sul suo workspace, ha fatto
le prove sull' application test server sulla sua macchina, e si
appresta a deployare la sua applicazione sul server ufficiale di
test. Che sia Tomcat o Websphere.
Installa la sua webapp, configura tutto per benino, avvia il
server e alla prima chiamata alla sua jsp …
LinuxDay 2010 Giacomo Pallotti - OSGI e OSGI Enterprise 8
10. “cavolo, vuoi vedere che ho messo nelle lib del war i jar
sbagliati? “
“Opps, non è possibile, ho copiato solo il war, le lib sono quelle
che già c'erano quindi forse le lib vecchie non sono uguali a
quelle nuove...” (Tomcat)
“I jar non sono dentro al WAR/EAR , utilizzo una shared lib sul
server che punta ad una cartella condivisa da altri
applicazioni... “ (Webshpere)
… in tutti i modi le libreria che il nostro JEE developer ha sul
server non ha il metodo che le classi si aspettano.
Il jar incriminato è la libreria pippolib
Sul suo workspace uso la versione 1.4.19
Il file si chiama: pippolib.jar
LinuxDay 2010 Giacomo Pallotti - OSGI e OSGI Enterprise 10
11. E sul server che versione c'è? come si chiamerà il file ?!
pippolib.jar
… perfetto :(
“Almeno hanno data e dimensione diverse”
LinuxDay 2010 Giacomo Pallotti - OSGI e OSGI Enterprise 11
12. … quindi ?!
1. decide di mettere tutte le lib all'interno del suo ear/war, per
essere sicuri di avere la versione giusta
Avrà le librerie comuni replicate dentro ogni
applicazione
LinuxDay 2010 Giacomo Pallotti - OSGI e OSGI Enterprise 12
13. 2. Cerca di ricordarsi di rinominare le librerie
aggiungendo al nome del file il suffisso v_X_X_X.jar
per riuscire a capire che versione è …
3. Crea cartelle di shared lib personalizzate con le
versioni di librerie common dentro, e le fa puntare
come shared lib in più server (es. Websphere), così
da avere più versioni delle stesse lib in cartelle
diverse …
Nessuna di queste soluzioni
è standardizzata, soprattutto se
il nostro bravo developer non lavora da solo
LinuxDay 2010 Giacomo Pallotti - OSGI e OSGI Enterprise 13
14. non esiste l'aggiornamento a caldo delle lib
il class loader carica la prima che trova
si avranno librerie uguali replicate
Modularità e dinamismo ?!
LinuxDay 2010 Giacomo Pallotti - OSGI e OSGI Enterprise 14
15. OSGi Alliance
Acronimo di Open Service Gateway Initiative, è un consorzio fondato
nel 1999 da Oracle, Ericsson, Ibm ed altre aziende, il cui obiettivo è
quello di creare un framework che implementi un modello a
componenti completo e dinamico.
Con il tempo altre aziende si sono aggiunte al progetto
LinuxDay 2010 Giacomo Pallotti - OSGI e OSGI Enterprise 15
16. Cosa è OSGi ?!
OSGi è uno strato modulare per la piattaforma Java
Il framework OSGi è un sistema modulare ed una piattaforma di servizio per Java che
implementa un modello a componenti completo e dinamico. Applicazioni o componenti
(bundle) possono essere installate, avviate, arrestate, aggiornate e disinstallate senza
richiedere un riavvio.
Le specifiche OSGi sono andate oltre l'obiettivo originario che avevano, cioè di gateway
di servizi (portale di servizi) → sono ora utilizzate in applicazioni per ambienti diversi
(mobile, embedded, rcp, enterprise).
La gestione dei package Java che i componenti utilizzano è gestita e implementata
dettagliatamente. La gestione del ciclo di vita dei moduli stessi utilizza API che ne
permettono la gestione remota.
Il Service Registry permette ai bundle di rilevare l'aggiunta di nuovi servizi, o
l'eliminazione dei servizi, e adeguarsi di conseguenza.
LinuxDay 2010 Giacomo Pallotti - OSGI e OSGI Enterprise 16
17. Concetti fondamentali
Dunque l'idea dell'OSGi Alliance è la implementazione di un
framework che sia...
modulare: per la piattaforma Java e JEE
dinamico: consenta la distribuzione, l'avvio, lo stop e la
rimozione dei bundles a runtime, senza dover riavviare il
container OSGi
orientato ai servizi: che possano essere dinamicamente
registrati ed utilizzati.
→ Introduzione e definizione del concetto di bundle (modulo)
→ Gestione automatica delle dipendenze
→ Gestione del ciclo di vita del codice (configurazione e
distribuzione dinamica).
LinuxDay 2010 Giacomo Pallotti - OSGI e OSGI Enterprise 17
18. Qualsiasi applicazione che è stato progettata in maniera modulare può trarre beneficio
dalle specifiche e dal framework OSGi: si potranno avviare, arrestare, aggiornare i
singoli moduli con un impatto minimo sugli altri.
Riduzione della complessità: sviluppare con la tecnologia OSGi significa sviluppare
bundle, che sono semplici Jar.
Riutilizzo, Distribuzione, aggiornamenti dinamici (senza riavviare il container)
Versioning: la tecnologia OSGi risolve l'inferno delle librerie JAR. Nell'ambiente OSGi,
tutti i package sono accuratamente versionati e soltanto i bundles che sono dipendenti
sono collegati tra loro.
Semplice: Il nucleo API è solo un pacchetto e meno di 30 classi/interfacce
Veloce e Lazy (Pigro): L'essere Lazy è una qualità vincente nell'ambito del software e la
tecnologia OSGi ha molti meccanismi per fare le cose solo quando sono realmente
necessarie
La flessibilità delle specifiche OSGi è dimostrato da come si può persino eseguire
all'interno di un Application Server J2EE
Versioni multiple: Le applicazioni possono avere più di una versione di un particolare
bundle in esecuzione al momento stesso
LinuxDay 2010 Giacomo Pallotti - OSGI e OSGI Enterprise 18
20. OSGi Module (o Bundle) layer
Definisce il concetto di moduli o bundle, che sono semplici file JAR con
informazioni aggiuntive (metadata) nel file MANIFEST.MF . Un bundle contiene
le classi e le risorse aggiuntive per quel modulo. Concettualmente un bundle
non è un intera applicazione impachettata in un jar, ma è un modulo di una
applicazione, che assieme agli altri bundles si combina per formare
l'applicazione stessa.
Un bundle, con i suoi metadata, estende il concetto di access modifiers che ha
java, introducendo informazioni come ad esempio quali packages di quel
modulo devono essere visibili all'esterno, oppure quali altri moduli o package
di altri moduli sono indispensabili per quel dato bundle (imported e exported
packages).
Il framework OSGi in questo modo può gestire e verificare la consistenza dei
bundle automaticamente.
LinuxDay 2010 Giacomo Pallotti - OSGI e OSGI Enterprise 20
21. OSGi Lifecycle layer
Definisce come i bundle sono dinamicamente installati e gestiti dal framework
OSGi.
→ esternamente all'applicazione definisce come avvengono le operazioni di
install, update, start, stop e uninstall per amministrare dinamicamente i
bundle
→ internamente all'applicazione fornisce un modo per interagire con il
framework OSGi e i servizi che esso fornisce durante l'esecuzione
LinuxDay 2010 Giacomo Pallotti - OSGI e OSGI Enterprise 21
22. OSGi Service Layer
Supporta un approccio alla programmazione flessibile e orientato ai servizi
(concetto presente nel framework OSGi prima che le architetture SOA
diventassero popolari...).
I service providers (che sono sempre bundle...) pubblicano i loro servizi su un
service registry, e i service client (bundles...) utilizzano il registry per
ricercare servizi da utilizzarli → bind interaction pattern.
Promuove uno sviluppo centrato sulla separazione tra interfaccia e
implementazioni → i servizi OSGi sono semplicemente delle interfacce Java
che rappresentano un contratto tra service provider e service client.
Gli OSGi service, che sono bundle, possono dunque dinamicamente essere
avviati o stoppati.
LinuxDay 2010 Giacomo Pallotti - OSGI e OSGI Enterprise 22
23. approccio OSGi allo sviluppo...
1. Progettare l'applicazione dividendola in interfacce che espongono
un servizio e client che lo usano (approccio interface-based)
2. Implementare i service provider e i client component utilizzando i
tools che normalmente si usano
3. Impacchettare le i service provider e i client in JAR separati.
4. Aggiungere ad ogni JAR l'appropriato OSGi metadata.
6. Avviare l' OSGi framework.
7. Installare e avviare tutti i propri bundle.
LinuxDay 2010 Giacomo Pallotti - OSGI e OSGI Enterprise 23
24. Specifiche OSGi
- OSGi Service Platform R4 Version 4.0 → October 2005
- OSGi Service Platform R4 Version 4.1 → May 2007
- OSGi Service Platform R4 Version 4.2 → March 2010:
OSGi Service Platform Release 4 Version 4.2 Core Specification
OSGi Service Platform Release 4 Version 4.2 Compendium Specification
OSGi Service Platform Release 4 Version 4.2 Enterprise Specification
OSGi Service Platform Release 4 Version 4.2 Core Companion Code
OSGi Service Platform Release 4 Version 4.2 Compendium Companion Code
OSGi Service Platform Release 4 Version 4.2 Enterprise Companion Code
OSGi Service Platform Release 4 Version 4.2 Minimum Execution Environment
OSGi Service Platform Release 4 Version 4.2 Foundation Execution Environment
LinuxDay 2010 Giacomo Pallotti - OSGI e OSGI Enterprise 24
25. JaxLondon and
OSGi DevCon 2010
LinuxDay 2010 Giacomo Pallotti - OSGI e OSGI Enterprise 25
26. OSGI manifest.mf
Bundle-Activator
Questa classe viene utilizzata per avviare e stoppare il bundle.
Bundle-ClassPath
Questa proprietà specifica il CLASSPATH da utilizzare per il bundle. La struttura può
contenere riferimenti a directory o file jar all'interno del bundle.
Bundle-Version
Specifica il numero di versione del bundle. Package imports e required bundle possono
includere anche l'informazione sulla versione del package o del bundle.
Export-Package
Questa proprietà specifica tutti i package da esporre pubblicamente ad altri plug-in.
Import-Package
Specifica tutti i package necessari da importare in modo esplicito dal bundle.
Require-Bundle
Questa proprietà specifica quali bundle e quali loro
exported package siano da importare per essere utilizzati
nel bundle.
LinuxDay 2010 Giacomo Pallotti - OSGI e OSGI Enterprise 26
28. Container OSGi open source
Equinox è un progetto di Eclipse che implementa le specifiche
OSGi core framework release 4.
E' un runtime modulare che consente di deployare e avviare
un'applicazione organizzata come una serie di bundle
utilizzando i servizi e l'infrastruttura comune
Dalla versione 3.0 di Eclipse, Equinox è diventato il runtime per
i plugin che è appunto utilizzato da Eclipse stesso, ed è oggi la
reference implementation delle specifiche del framework OSGi.
Altri container utilizzati sono Knoplerfish e Apache Felix,
sviluppato dall'Apache Foundation.
LinuxDay 2010 Giacomo Pallotti - OSGI e OSGI Enterprise 28
29. Eclipse ed il framework OSGi
Eclipse utilizza OSGI come base per il suo sistema di plug-in
dalla versione 3.0 Le prime versioni di Eclipse erano state
concepite come un insieme di plug-in. Tuttavia, poiché i
requisiti sono cresciuti, è diventato necessaria una gestione dei
plugin più robusta ed efficace. Tra i requisiti di base di questo
nuovo sistema si voleva avere la possibilità di gestire
dinamicamente l'aggiunta di nuovi plug-in e l'arresto plug-in
esistenti. Dopo ampie ricerche, gli sviluppatori Eclipse hanno
optato per utilizzare le specifiche del framework OSGi per
realizzarlo.
Eclipse fornisce una delle implementazioni possibili di questa
specifica ed è l'implementazione di riferimento delle specifiche
OSGi R4.
LinuxDay 2010 Giacomo Pallotti - OSGI e OSGI Enterprise 29
30. Nelle versioni precedenti alla 3.0, le dipendenze dei plug-in,
le extensions e gli extension points erano definiti nei file
plugin.xml di ogni plugin.
Con l'introduzione delle specifiche OSGi, le informazioni sulle
dipendendenze sono state spostate nel file manifest.mf,
lasciando nel plugin.xml solo le definizioni di extensions ed
extension points.
Il progetto Eclipse è stato sviluppato interamente sul
framework Equinox ed è quindi un esempio completo di
sviluppo "a bundle", modulare, a componenti e a servizi.
Un nuovo progetto plugin non è che un bundle nell’accezione
OSGi, e i plugin di Eclipse non sono altro che bundle e
seguono tutti gli standard e le caratteristiche degli stessi.
LinuxDay 2010 Giacomo Pallotti - OSGI e OSGI Enterprise 30
31. Equinox si propone come il framework di riferimento in
quanto supporta un progetto delle dimensioni di Eclipse.
È infatti grazie a questa tecnologia che diventa semplice
sviluppare estensioni di Eclipse, agganciandosi alle
funzionalità già offerte dall’IDE in modo da personalizzarne il
comportamento.
Lanciando Eclipse con “-console” si avvia la console OSGi dei
bundle in parallelo all'IDE dalla quale sarà possibile
amministrare i bundle disponibili nella distribuzione.
Il jar che racchiude il core del framework è:
org.eclipse.osgi.[versione].jar.
LinuxDay 2010 Giacomo Pallotti - OSGI e OSGI Enterprise 31
32. Container OSGi enterprise
Negli ultimi anni molti vendor si sono affacciati sul mondo OSGI enterprise
(IBM, Oralcle, Progress, Sap, VMWare, …) e attualmente supportano la OSGi
Alliance attivamente. Parallelamente molti progetti Enterprise Open Source
con le comunità Eclipse e Apache sono nati
Tutto questo fermento non ha fatto altro che aumentare il numero di
sviluppatori che hanno utilizzato e hanno sperimentano le nuove
specifiche/features, e con l'introduzione dalle specifiche 4.2 l'attività della
comunity è notevolmente aumentata.
Attualmente la parte OSGi che si occupa di enterprise è l' OSGI Enterprise
Expert Group (OSGi EEG)
Accanto ai progetti di open source di osgi container, sono nati altri progetti
come:
Apache Aries: implementazione del Blueprint Container , che estende
specifiche definite dalla OSGI Enterprise Expert Group incluso: convertitore
bundle ↔ WAR; integrazione per JPA, JTA, JMX, …
(IBM Websphere 7 lo utilizza)
Eclipse Gemini
LinuxDay 2010 Giacomo Pallotti - OSGI e OSGI Enterprise 32
34. Blueprint Container
È una specifica OSGI EEG 4.2
Introduce il concetto di dependency injection framework for
OSGI
Si utilizzano semplici Java object (POJOs), che possono essere
utilizzati sia all'interno del framework OSGi che esternamente,
ed un file blueprint.xml
E' basato su Spiring DM Dynamic Model framework
I produttori di OSGi container (es Apache Aries che IBM con
WebSphere7 utilizza) si stanno orientando verso questo tipo di
approccio
LinuxDay 2010 Giacomo Pallotti - OSGI e OSGI Enterprise 34
35. Casi d'esempio (Eclipse Helios 3.6 SR1 + Equinox)
Bundle osgi jar helloworld
Bundle service provider getTime: servizio
interfaccia/implementaizone OSGi che restituisce il time
Bundle client getTime: client del servizio getTime
Bundle webapp helloservlet: WebApp con una servlet
Bundle webapp client getTime: WebApp con servlet e
chiamata al servizio
LinuxDay 2010 Giacomo Pallotti - OSGI e OSGI Enterprise 35
37. osgi service provider Activator
LinuxDay 2010 Giacomo Pallotti - OSGI e OSGI Enterprise 37
38. osgi service client Activator
LinuxDay 2010 Giacomo Pallotti - OSGI e OSGI Enterprise 38
39. osgi servlet vs WAR
E' una semplice classe che estende HttpServlet.
La differenza con una web application implementata come WAR, è che la servlet è
impacchettata in un package di un bundle osgi, e il jar è deployato sull'osgi framework
come un semplice bundle appunto.
La servlet è registrata nel container osgi (dato che non abbiamo un web container)
tramite extension point di org.eclipse.equinox.http.registry.servlets
Nelle opzioni di lancio del osgi framework, vanno aggiunti tutti i bundle che servono:
com.example.servlet
javax.servlet
org.eclipse.equinox.common
org.eclipse.equinox.http
org.eclipse.equinox.http.registry
org.eclilpse.equinox.registry
org.eclipse.osgi
org.eclipse.osgi.services
Nei program arguments -console nei VM args -Dorg.osgi.service.http.port=8080
LinuxDay 2010 Giacomo Pallotti - OSGI e OSGI Enterprise 39
40. osgi servlet con Jetty
Jetty è un http server ed un servlet container basato su java. Jetty è open source rilasciato con
licenza Apache 2.0.
Si può scegliere di utilizzare un container più robusto, come Jetty ad esempio, che è compatibile con
le specifiche Servlet 2.4 nella versione 7 e con quelle 3.0 per la versione Jetty 8, utilizzando questi
bundle:
org.eclipse.equinox.http.jetty
org.eclipse.equinox.http.servlet
org.mortbay.jetty.server
org.mortbay.jetty.util
al posto di:
org.eclipse.equinox.http
LinuxDay 2010 Giacomo Pallotti - OSGI e OSGI Enterprise 40