2010-10-08 31 views

risposta

11

Si potrebbe voler guardare questa domanda: OSGI runtime inside traditional Java EE server.

In questo modello di bridge, viene installato un servlet speciale e Tomcat richiama questo servlet per gestire la richiesta. Un runtime OSGi viene generato da questo servlet, ma il runtime OSGi stesso (ad esempio equinozio) è agnostico di cose come HTTP. Viene installato anche un bundle di servizi HTTP OSGi e dovrai registrare la tua app Web (servlet, jsp, ...) contro questo servizio HTTP OSGi per gestire le richieste in arrivo. Pertanto, non è come se ci fosse un "server web" separato per parlare di ciò che ascolta sulla propria porta e gestisce HTTP da solo all'esterno di Tomcat. Il tuo chilometraggio può variare, ma il sovraccarico è fondamentalmente limitato a qualsiasi cosa il servizio HTTP OSGi possa aggiungere quando inoltra la richiesta dal connettore Tomcat al servlet.

Questo modello di bridge è necessario se non è possibile modificare il modello di distribuzione esistente. A lungo termine, un modello migliore deve avere prima il runtime OSGi e Tomcat (o qualsiasi altro contenitore compatibile con OSGi) collegare al runtime OSGi come pacchetti.

+0

Vedo, è interessante. Quindi vuoi dire che un altro modo è quello di eseguire OSGI come un "web server" di sua proprietà? Ma in che modo le prestazioni dei server di osgi sono paragonabili a qualcosa come Apache? – drozzy

+0

È possibile utilizzare qualcosa come Jersey con OSGi, che ispeziona le classi annotate e inoltra la richiesta all'url dato alla classe appropriata? – drozzy

+0

Non posso dire perché non ho giocato molto con Jersey, ma la ricerca sul web per jersey + osgi sembra portare molti contenuti. – sjlee