Come modularizzare un'applicazione Enterprise con OSGi ed EE6?

Question

So che ci sono già alcune domande relative a questo argomento ma non sono riuscito a trovare una soluzione reale.

Attualmente sto sviluppando applicazioni con EE6, utilizzando JPA, CDI, JSF. Vorrei adottare un approccio più modulare rispetto al confezionamento di tutto in WAR o EAR e distribuire il tutto su un server applicazioni.

Sto cercando di progettare le mie applicazioni più modulare possibile separando un modulo in 3 progetti Maven:

• API - contiene le interfacce per i servizi (Stateless)
• Modello - contiene le entità JPA per il modulo specifico
• Impl - Contiene l'implementazione delle API, fagioli soprattutto CDI

la logica vista di ogni modulo è attualmente bundeled all'interno di un grande progetto web, che è brutto. Ho già pensato ai web fragmets, ma se diffondessi le mie classi bean e i file xhtml nei file jar, avrei dovuto implementare un hook in modo che le risorse potessero essere cercate da un'applicazione web padre. Questo tipo di soluzione mi permetterebbe almeno di avere un quarto progetto per modulo che contenga tutte le logiche di visualizzazione relative al modulo, il che è un buon inizio.

Quello che voglio non è solo quello di poter avere quei 4 tipi di progetti, ma anche che ogni progetto è hot swappable. Questo mi ha portato a OSGi, che è stato inizialmente molto interessante fino a quando ho capito che le tecnologie EE6 non sono molto ben supportate all'interno di un contenitore OSGi.

JPA

Guardiamo dell'APP prima. Ci sono alcuni tutorial [1] in giro che spiegano come creare un pacchetto OSGi abilitato per JPA, ma nessuno di questi tutorial mostra come distribuire le entità in diversi pacchetti (il progetto del modello di un modulo). Vorrei avere ad esempio tre diversi moduli

• Nucleo
• utente
• Blog

Il progetto di modello del modulo blog ha una dipendenza (a tempo di compilazione) sul modello di progetto di utente. Il progetto del modello del modulo utente ha una dipendenza (in fase di compilazione) sul progetto del modello di core.

Come posso far funzionare JPA in uno scenario del genere senza dover creare un'unità di persistenza per ogni progetto di modello di un modulo? Voglio un'unità di persistenza che sia a conoscenza di tutte le entità disponibili al runtime. I progetti modello in cui dovrebbero essere le entità dovrebbero ovviamente essere scambiabili a caldo. Forse avrò bisogno di creare un progetto separato per ogni cliente che importa tutte le entità necessarie dei progetti e contiene un persistence.xml che include tutte le cose necessarie per la configurazione. Sono disponibili plugin Maven per la realizzazione di tali progetti o anche altri approcci per risolvere tale problema?

CDI

CDI è molto bello. Lo adoro davvero e non voglio più perderlo! Uso estensioni CDI come MyFaces CODI e DeltaSpike che sono fantastiche! Inserisco i miei servizi (senza stato) in altri servizi o nel livello di vista che è semplicemente fantastico. Dato che i miei servizi sono senza stato, non dovrebbe essere un problema usarli come servizi OSGi, ma per quanto riguarda l'integrazione CDI in OSGi? Ho trovato un'estensione CDI glassfish [2] che farebbe l'iniezione di servizi OSGi in bean CDI, ma vorrei anche che i servizi OSGi potessero essere fagioli CDI. Non sono del tutto sicuro di come farlo, probabilmente dovrei usare il BeanManager per istanziare le implementazioni e quindi registrare ogni implementazione per la sua interfaccia in ServiceRegistry all'interno di un BundleActivator. C'è un modo standard per farlo? Vorrei evitare qualsiasi dipendenza (in fase di compilazione) del framework OSGi.

Vorrei anche utilizzare i miei servizi proprio come li uso in questo momento, senza modificare nulla (implementazioni non annotate e punti di iniezione non qualificati). C'è un'estensione/sottoprogetto JBoss Weld [3] che sembra mirare a quel problema ma sembra essere inattivo, non riesco a trovare alcuna best practice o how-to. Come posso lasciare la mia implementazione così com'è ma essere ancora in grado di usare OSGi? Voglio dire, non sarebbe un grosso problema aggiungere un'annotazione alle implementazioni poiché ogni implementazione è già annotata con un'annotazione stereotipata, comunque vorrei evitarlo.

JSF

Come accennato prima mi piacerebbe essere in grado di diffondere il mio modulo logico vista saggia. Per quanto ne so, questo non è realmente possibile out of the box. Pax Web [4] dovrebbe risolverlo in qualche modo, ma non mi è familiare.

Mi piacerebbe avere un progetto "CoreWeb" nel modulo "core" che contiene un modello Facelet, chiamiamolo "template.xhtml". Una pagina JSF in un progetto chiamato "BlogWeb" nel modulo "blog" dovrebbe quindi essere in grado di fare riferimento a tale modello e applicare una composizione.

Per poter estendere la vista, introdurrei un'interfaccia java "Extension" che può essere implementata da una classe specifica di un modulo. Un controller per una vista dovrebbe quindi iniettare tutte le implementazioni dell'estensione. Un'estensione fornirebbe per esempio una lista di sottoview che saranno incluse in una vista principale.

Il meccanismo di estensione descritto può essere implementato facilmente, ma i seguenti requisiti devono essere soddisfatti:

• quando si aggiungono nuovi OSGi fasci per il server di applicazione, l'insieme di estensioni disponibili potrebbero cambiare, le estensioni deve essere disponibile per il controller della vista.
• Le sottoview (da un bundle separato) che dovrebbero essere incluse in una vista principale dovrebbero essere accessibili.

Il concetto di un singolo host ma più applicazioni slice di Spring Slices [5] è molto interessante, ma sembra limitato a Spring DM Server e il progetto sembra non essere attivo.

Sommario

Dopo che tutti gli esempi e comportamenti che ho descritto Spero che tu sappia cosa vorrei achive. È semplicemente un'app EE6 molto dinamica e modulare.

Quello che cerco alla fine è almeno una documentazione su come far funzionare tutto come mi aspetterei o anche meglio una soluzione già funzionante!

[1] http://jaxenter.com/tutorial-using-jpa-in-an-osgi-environment-36661.html

[2] https://blogs.oracle.com/sivakumart/entry/typesafe_injection_of_dynamic_osgi

[3] http://www.slideshare.net/TrevorReznik/weldosgi-injecting-easiness-in-osgi

[4] http://team.ops4j.org/wiki//display/paxweb/Pax+Web

[5] https://jira.springsource.org/browse/SLICE

Answer 1

di rispondere ad alcune delle vostre domande , usando una singola unità di persistenza ma diffondendo le tue entità su più unità bundle is not recommended, but may occasionally work. Tuttavia, se le entità sono così strettamente correlate da dover condividere un'unità di persistenza, la suddivisione tra moduli potrebbe non avere senso. Inoltre, non dimenticare che puoi gestire le dipendenze in fase di compilazione separando l'implementazione e l'interfaccia per ciascuna entità: l'interfaccia e l'implementazione non devono essere nello stesso pacchetto.

Per l'iniezione dipendente, è possibile che Blueprint. Sono disponibili diverse implementazioni e la maggior parte dei server applicazioni con supporto OSGi aziendale supportano Blueprint immediatamente. Usa XML per aggiungere metadati, quindi le classi stesse non avranno bisogno di alcuna modifica.