Domanda

Di recente ho esaminato OSGi e penso che sembri davvero una buona idea per app Java modulari.

Tuttavia, mi chiedevo come avrebbe funzionato OSGi in un'applicazione web, in cui non devi solo preoccuparti del codice, anche HTML, immagini, CSS, questo genere di cose.

Al lavoro stiamo costruendo un'applicazione che ha più "schede", ciascuna delle quali fa parte dell'app. Penso che questo potrebbe davvero trarre vantaggio dall'adozione di un approccio OSGi, tuttavia non sono davvero sicuro di quale sarebbe il modo migliore per gestire tutte le solite risorse delle app Web.

Non sono sicuro che faccia alcuna differenza, ma stiamo usando JSF e IceFaces (che aggiunge un altro livello di problemi perché hai regole di navigazione e devi specificare tutti i file di configurazione di facce nel tuo web.xml ... doh!)

Modifica: secondo questa discussione , i file faces-config.xml possono essere caricato da file JAR - quindi è possibile avere più file faces-config.xml inclusi senza modificare web.xml, purché divisi in file JAR.

Eventuali suggerimenti sarebbero molto apprezzati :-)

È stato utile?

Soluzione

Hai ragione nel pensare che ci siano sinergie qui, abbiamo un'app Web modulare in cui l'app stessa viene assemblata automaticamente da componenti indipendenti (bundle OSGi) in cui ogni bundle contribuisce con le proprie pagine, risorse, css e facoltativamente javascript.

Non utilizziamo JSF (Spring MVC qui), quindi non posso commentare la complessità aggiunta di quel framework in un contesto OSGi.

La maggior parte dei framework o degli approcci là fuori aderisce ancora al "vecchio" quot modo di pensare: un file WAR che rappresenta la tua webapp e poi molti bundle e servizi OSGi ma quasi nessuno si preoccupa della modularizzazione della GUI stessa.

Prerequisiti per un design

Con OSGi la prima domanda da risolvere è: qual è il tuo scenario di distribuzione e chi è il contenitore principale? Quello che voglio dire è che puoi distribuire la tua applicazione su un runtime OSGi e usare la sua infrastruttura per tutto. In alternativa, è possibile incorporare un runtime OSGi in un server di app tradizionale e quindi sarà necessario riutilizzare alcune infrastrutture, in particolare si desidera utilizzare il motore servlet dell'AppServer.

Il nostro design è attualmente basato su OSGi come contenitore e utilizziamo il servizio HTTPS offerto da OSGi come nostro contenitore servlet. Stiamo cercando di fornire una sorta di ponte trasparente tra un contenitore servlet esterno e il servizio HTTPS OSGi, ma tale lavoro è in corso.

Architectural Sketch of a Spring MVC + OSGi modular webapp

Quindi l'obiettivo non è solo quello di servire un'applicazione web su OSGi, ma anche di applicare il modello di componente di OSGi all'interfaccia utente Web stessa, per renderlo componibile, riutilizzabile, dinamico.

Questi sono i componenti nel sistema:

  • 1 bundle centrale che si occupa del collegamento di Spring MVC con OSGi, in particolare utilizza il codice di Bernd Kolb per consentirti di registrare il Spring DispatcherServlet con OSGi come servlet.
  • 1 URL Mapper personalizzato che viene iniettato nel DispatcherServlet e che fornisce il mapping delle richieste HTTP in entrata al controller corretto.
  • 1 JSP decoratore centrale basato su Sitemesh che definisce il layout globale del sito, nonché le librerie centrali CSS e Javascript che vogliamo offrire come valori predefiniti.

  • Ogni bundle che desidera contribuire con pagine alla nostra interfaccia utente Web deve pubblicare 1 o più controller come servizi OSGi e assicurarsi di registrare il proprio servlet e le proprie risorse (CSS, JSP, immagini, ecc. ) con OSGi HTTPService. La registrazione viene effettuata con HTTPService e i metodi chiave sono:

    httpService.registerResources () e httpService.registerServlet ()

Quando un bundle web ui che contribuisce attiva e pubblica i suoi controller, questi vengono automaticamente raccolti dal nostro bundle ui web centrale e il summenzionato URL Mapper personalizzato raccoglie questi servizi del controller e mantiene una mappa aggiornata degli URL alle istanze del controller.

Quindi, quando arriva una richiesta HTTP per un determinato URL, trova il controller associato e invia la richiesta lì.

Il Titolare fa i suoi affari e quindi restituisce tutti i dati che dovrebbero essere resi e il nome della vista (un JSP nel nostro caso). Questo JSP si trova nel bundle del controller ed è accessibile e reso dal bundle dell'interfaccia utente web centrale esattamente perché siamo andati e abbiamo registrato la posizione delle risorse con HTTPService. Il nostro risolutore di viste centrale unisce quindi questo JSP con il nostro decoratore centrale di Sitemesh e distribuisce il codice HTML risultante al client.

Sapendo che si tratta di un livello piuttosto elevato, ma senza fornire l'implementazione completa è difficile da spiegare completamente.

Il nostro punto di apprendimento chiave per questo è stato quello di guardare cosa ha fatto Bernd Kolb con il suo esempio di conversione JPetstore in OSGi e di utilizzare tali informazioni per progettare la nostra architettura.

IMHO al momento c'è troppa pubblicità e attenzione per far sì che OSGi sia in qualche modo incorporato nelle tradizionali app basate su Java EE e pochissimo pensiero venga effettivamente utilizzato facendo uso degli idiomi di OSGi e del suo eccellente modello di componenti per consentire davvero la progettazione di web componentizzato applicazioni.

Altri suggerimenti

Dai un'occhiata a SpringSource dm Server - un server di applicazioni costruito interamente in termini di OSGi e che supporta il web modulare applicazioni. È disponibile in versioni gratuite, open source e commerciali.

È possibile iniziare distribuendo un file WAR standard e quindi suddividere gradualmente l'applicazione in moduli OSGi o "bundle" in OSGi-speak. Come ci si potrebbe aspettare da SpringSource, il server offre un eccellente supporto per il framework Spring e i relativi prodotti del portfolio Spring.

Dichiarazione di non responsabilità: lavoro su questo prodotto.

Essere consapevoli del server Spring DM licenze .

Abbiamo utilizzato Restlet con OSGi con buoni risultati con un servizio Http incorporato (sotto le copertine in realtà è Jetty, ma è disponibile anche tomcat).

Restlet ha esigenze di configurazione XML da zero a minime e qualsiasi configurazione che facciamo è nel BundleActivator (registrazione di nuovi servizi).

Quando costruiamo la pagina, elaboriamo solo le implementazioni di servizio pertinenti per generare l'output, stile decoratore. I nuovi bundle che verranno collegati aggiungeranno nuove decorazioni / widget per la pagina al prossimo rendering.

REST ci fornisce URL puliti e significativi, rappresentazioni multiple degli stessi dati e sembra una metafora estensibile (pochi verbi, molti nomi).

Una caratteristica bonus per noi era l'ampio supporto per la memorizzazione nella cache, in particolare ETag.

SpringSource sembra funzionare su un interessante framework web modulare basato su OSGi chiamato SpringSource Slices . Ulteriori informazioni sono disponibili nei seguenti post di blog:

Dai un'occhiata a RAP! http://www.eclipse.org/rap/

Dai un'occhiata a http://www.ztemplates.org che è semplice e facile da imparare. Questo ti permette di mettere tutti i modelli correlati, javascript e css in un vaso e usarlo in modo trasparente. Significa anche che non ti devi preoccupare di dichiarare il javascript necessario nella tua pagina quando usi un componente fornito, poiché il framework lo fa per te.

Interessante serie di post. Ho un'applicazione web personalizzata per cliente. Ogni cliente riceve un set base di componenti e componenti aggiuntivi a seconda di ciò per cui si è registrato. Per ogni versione dobbiamo "assemblare" il set corretto di servizi e applicare la corretta configurazione del menu (usiamo il menu struts) in base al cliente, che è noioso per non dire altro. Fondamentalmente è la stessa base di codice ma semplicemente personalizziamo la navigazione per esporre o nascondere determinate pagine. Questo ovviamente non è l'ideale e vorremmo sfruttare OSGi per rendere più efficienti i servizi. Mentre posso vedere come questo viene fatto per le API di servizio e capire in che modo potrebbero essere raggruppate risorse come CSS e java script e controller (usiamo Spring MVC), come faresti per affrontare le questioni "trasversali" come la navigazione delle pagine e flusso di lavoro generale soprattutto nello scenario in cui si desidera distribuire in modo dinamico un nuovo servizio e è necessario aggiungere la navigazione a quel servizio. Potrebbero esserci anche altre preoccupazioni "trasversali" come i servizi che abbracciano altri servizi. Grazie, Declan.

Autorizzato sotto: CC-BY-SA insieme a attribuzione
Non affiliato a StackOverflow
scroll top