JBoss Web Server

Le tecnologie più comuni nella creazione di web application sono le JSP e le servlets che vivono all’interno di web container dei quali il più popolare è Apache Tomcat.
JBoss AS 5 fa uso di un nuovo prodotto Red Hat chiamato JBoss Web Server che combina la velocità di Apache HTTP Server con la versatilità di Apache Tomcat.
Nel caso di directory esplose, la cartella a livello più alto definisce il nome del package e deve avere suffisso .war, nel caso di web archive il nome del package è dato dal nome dell’archivio che deve terminare con il suffisso .war.
La directory top-level contiene file statici o specifici del livello presentazione come html, xml, immagini, jsp …
Tali file possono risiedere anche in sottodirectory ad eccezione delle cartelle META-INF e WEB-INF.
Infatti la directory WEB-INF cotniene tutti i file di configurazione della web application (che non sono accessibili dall’esterno), il deployment descriptor standard (web.xml) e quello specifico di JBoss Web Server (jboss-web.xml) e un file deployment descriptor di Tomcat (context.xml).

La directory WEB-INF contiene inoltre due sottocartelle:

• classes contenente tutte le classi compilate utilizzate dall’applicazione
• lib contenente le librerie jar dalle quali dipende il codice dell’applicazione

La directory META-INF anch’essa non accessibile dall’esterno contiene un file manifest.mf che contiene metadati relativi ai file dell’archivio.
Il file WEB-INF/web.xml contiene le informazioni di configurazione per servlet e le JSP e dal momento che è parte delle specifiche Java EE, risulta portabile fra differenti application server ed è noto come deployment descriptor standard.

Il seguente codice dichiara una servlet presente nella web application:

  Hello Servlet
  
    miopackage.MiaServlet
  
  
    MiaServlet
    /servlet
  

Il file WEB-INF/jboss-web.xml definisce invece il deployment descriptor proprietario di JBoss per le web application e viene tipicamente utilizzato per definire le opzioni di sicurezza.

  java:/jaas/miosecuritydomain

L’elemento radice è jboss-web e gli elementi più importanti che possono essere presenti al suo interno sono:

• security-domain: specifica il security domain che l’applicazione usa per l’autenticazione e l’autorizzazione.
• context-root: definisce l’URL radice usato per il mapping dell’applicazione rispetto alle richieste http (se non viene definito il context root è dato dal nome del file war).
• virtual-host: specifica il virtual host al quale l’applizioe appartiene e deve corrispondere al virtual host definito nel file server.xml
• use-session-cookies: un flag booleano che indica se la sessione deve essere mantenuta in cookie lato client
• replication-config: specifica quando replicare lo stato di una sessione http in un cluster
• resource-env-ref: mappa il nome ENC per un resource-ref-env definito nel file web.xml nel namespace JNDI globale
• resource-ref: mappa il nome ENC per un resource-ref definito nel file web.xml nel namespace JNDI globale
• ejb-ref: mappa il nome ENC per un ejb-ref definito nel file web.xml nel namespace JNDI globale
• ejb-local-ref: mappa il nome ENC per un ejb-local-ref definito nel file web.xml nel namespace globale JNDI.
• servlet: viene usato per personalzzare la configurazione delle servlet.

File di configurazione

Una singola istanza di JBoss può ospitare diverse web application, pertanto occorre definire la configurazione per ciascuna di queste.
In linea teorica si potrebbero duplicare i file di configurazione di ogni applicazione, ma è possibile evitare questa procedura grazie al fatto che JBoss Web Server fornisce file di configurazione globali il cui contenuto si applica a tutte le applicazione nel server.

• deployers/jbossweb.deployer/web.xml: è la versione globale del file WEB-INF/web.xml
• deploy/jbossweb.sar/context.xml: è la versione globale del file WEB-INF/context.xml

A differenza del file web.xml per il quale abbiamo detto esiste un file di configurazione globale, per il file jboss-web.xml non esiste alcun file di configurazione globale pertanto eventuali opzioni di configurazione comuni a diverse applicazioni vanno di voota in volta ripetute.

Altri file importanti per la configurazione delle web application sono:

• deploy/jboss.sar/server.xml: viene usato per configurare i componenti del server come virtual host, protocolli, porte e filtri di richieste.
• deploy/jbossweb.sar/jsf-libs: directory contenente le librerie necessarie per lo sviluppo JSF
• deployers/jbossweb.deployer/META-INF/war-deployers-jboss-beans.xml file di configurazione del micro container usato per inizializzare il deployer WAR e per aggiungere opzioni di configurazione addizionali come sicurezza, class loading e clustering.

Configurazione di JBoss Web Server

Il file di configurazione principale di JBoss Web Server ovvero il file server.xml è posizionato nella cartella server/xxx/deploy/jbossweb.sar ed è usato per la maggior parte delle configurazioni del server.
Dal momento che JBoss Web Server è costuito su Tomcat, questo file è quasi identico al file server.xml di Tomcat.

  
    
    
      
      
        hostname.com 
        
      
    
  

Gli elementi presenti al suo interno sono:

• Server: rappresenta l’intero web container
• Service: container per connettori multipli
• Connector: collega ad una particolare posta ed ascolta eventuali richieste entranti usando un determinato protocollo
• Engine: riceve ed elabora tutte le richieste da tutti i connettori nello stesso Service
• Realm: definisce come le informazioni di sicurezza sono gestite
• Host: definisce virtual host
• Alias: definisce un altias per un elemento Host
• Valve: intercetta richieste entranti eseguendo determinate operazioni prima che la richiesta raggiunga il componente target.

Nella configurazione di base sono definiti due connettori: uno supporta il traffico http sulla porta 8080, e l’altro supporta il traffico dal web server nativo usando il protocollo AJP sulla porta 8009.
Il protocollo AJP è un protocollo basato su TCP/IP creato appostitamente per Tomcat come alternativa all’invio di messaggi http al web container.
Nel precedente esempio l’elemento Host gestisce il traffico verso il dominio www.hostname.com.
Se si ha più di un dominio che punta all’indirizzo IP di una data macchina è possibile aggiungere diverse configurazioni host per gestirli ed è possibile anche fornire alias per un dato host mediante l’elemento Alias.
L’elemento Valve fornisce un log di tutte le richieste dirette all’elemento Host: definisce cioè interceptor che possono essere eseguiti per le richieste entranti nel server.

Configurazione del deployer WAR

Il file di configurazione del microcontainer per il deployer WAR è war-deployers-jboss-beans.xml ed è situato nella cartella server/xxx/deployers/jbossweb.deployer/META-INF.
Tale file configura un bean chiamato WarDeployer che è il deployer principale usato per le web application e definisce diverse proprietà che influenzano il modo in cui l’applicazione viene deployata nel Web Server JBoss.
Se la proprietà deleteWorkDirOnContextDestroy è posta a true allora il container cancella la directory server/xxx/work quando l’application context viene distrutto.
L’application context è un oggetto usato per memorizzare informazioni di configurazione e runtime sull’applicazione, che il server crea quando l’applicazione viene eseguita e distrugge quando l’applicazione cessa di essere in esecuzione.
La directory work è usata da JBoss Web Server per memorizzare i file JSP compilati e altri dati temporanei.
In linea teorica potremmo avere la necessità di fare riferimento a questi file quando il server è stoppato pertanto il valore di default è false.
defaultSecurityDomain indica il security domain di default se non se ne indica alcuno nel file WEB-INF/jboss-web.xml

Descrizione degli URL

Una singola istanza JBoss AS può ospitare domini multipli o hostname ciascuno dei quali può eseguire applicazioni multiple.
Quando un URL viene inviato dal browser web di un utente al server, questo determina come instradare la richiesta verso l’appropriato hostname, applicazione e risorsa alla quale l’utente vuole accedere.
Il protocollo definisce come avviene la comunicazione col server: in si fa uso di http e di https per le comunicazioni sicure.
La porta specifica su quale porta del OS il server è in ascolto per eventuali richieste entranti.
Il domain name instrada la richiesta attraverso internet verso la macchina che ospita JBoss AS: diversi domain name possono essere instradati in una singola istanza del server.
Il context path comunica all’application server a quale web application l’utente sta provando ad accedere: se si hanno applicazioni multiple in esecuzione sullo stesso sever queste devono avere un context path differente così che il server possa capire a chi indirizzare le richiesta.
L’ultima parte dell’URL è la risorsa alla quale l’utente vuole accedere sia questa una pagina HTML, un’immagine, una servlet…
Se viene richiesto un web component allora questa porzione dell’URL dipende dalla logica di mapping definita nel file web.xml.
Quando una richiesta perviene a JBoss AS, un componente detto request dispatcher esamina la richiesta e decide a chi indirizzarla.

Virtual host

Domain name multipli o nomi di sottodomini possono puntare alla stessa istanza di JBoss AS.
I domain name devono essere registrati con un server Domain Name Service (DNS) così che possano essere risolti nell’indizitto IP del server.
Di default se si effettua il deploy di un’applicazione chiamata miaapp.war al server che ha dominio www.site1.com, essa può essere acceduta usando l’ indirizzio www.site1.com/miaapp.
Se si vogliono specificare differenti domini per lo stesso server ma esporre specifiche applicazioni su un solo dominio è necessario configurare l’applicazione così che possa essere collegata ad uno specifico host name usando i virtual host.
Un virtual host è un meccanismo che consente di segmentare il web container così da esporre un sottoinsieme delle applicazioni su certi domini.

Per usare i virtual host è necessario

• configurare il connector così da usare i virtual host
• definire il virtual host nel file di configurazione del server
• collegare l’applicazione al virtual host mediante il file di configurazione dell’applicazione.

Per abilitare i virtual host è necessario abilitare l’attributo IPVHosts sul connettore usato dall’applicazione in questione.
Il valore di default è false, se questo viene posto a true il connettore determina il domain name di destinazione della richiesta entrante e la invia al virtual host configurato per gestire quel domain name.
Nel file di configurazione del server server/xxx/deploy/jbossweb.sar/server.xml, i virtual host sono definiti dall’elemento Host che è un sottoelemento dell’elemento Engine.

L’attributo defaultHost dell’elemento Engine punta al virtual host che gestisce le richieste per le applicazioni che non hanno un collegamento con alcun virtual host.
Se definiamo più virtual host allora uno di questi deve corrispondere a quello definito dall’attributo defaultHost.
L’attributo name dell’elemento Host specifica il domain name per il quale il virtual host è definito, questo dovrebbe corrispondere al domain name registrato nel server DNS.
Per default l’attributo name è settato a localhost consentendo al virtual host di gestire ogni richiesta che arriva al server.
Per definire il proprio virtual host occorer aggiungere un altro elemento Host nel file server.xml.

  www.hostname.com

L’unica cosa che occorre specificare è quindi il nome del virtual host mediante l’attributo name.
E’ possibile anche aggiungere un sottoelemento Alias che viene usato per mappare domain name multipli sullo stesso virtual host.
Tutti gli attributi di deploy sono settati a false perché questi sono specifici di Tomcat e JBoss AS usa il proprio meccanismo di deployment.
Infine per collegare un’applicazione al virtual host è necessario infine l’elemento virtual-host nel file WEB-INF/jboss-web.xml

  www.hostname.com

Configurare i connettori

Il protocollo HTTP è il protocollo di comunicazione standard fra browser e web server, JBoss supporta anche il protocollo AJP che consente di effettuare richieste in formato binario ottenendo un miglioramento dei tempi di risposta.
I Sistemi Operativi consentono a più programmi di comunicare sulla rete e per separare il traffico fanno uso delle porte logiche (i web server ad esempio sono tipicamente collegati alla porta 80).
Per collegare una porta al traffico relativo ad un determinato protocollo JBoss usa i connettori che possono essere di due tipi:: HTTP e AJP.
Anche il protocollo HTTPS è supportato definendo un connettore http con attributi di configurazione extra.
I connettori sono definiti come sotto elementi dell’elemento Server nel file server/xxx/deployers(jbossweb.deployer/server.xml.
Se si apre questo file possiamo vedere una configurazione simile alla seguente:

  
  
  
  
  
  ...

Il primo connettore è un connettore http ed è configurato per essere in ascolto sulla porta 8080.

• l’attributo protocol definisce il protocollo in qusto caso http/1.1.
• l’attributo port invece definisce il numero di porta al quale il connettore effettua il binding.

Il secondo connettore usa il protocollo AJP/1.3 con porta 8009.
Il terzo connettore gestisce il traffico HTTPS: affinchè ciò sia possibile deve esistere un keystore.
I connettori sono progettati per gestire connessioni concorrenti con diversi browser.
Esistono due attributi principali a tal proposito: maxThreads e acceptCound.
maxThread definisce il massimo numero di thread in esecuzione contemporaneamente, questo parametro limita il numero di utenti concorrenti
acceptCount o backlog definisce la lunghezza di una coda quando tutti i thread sono occupati.
Http usa acceptCount mentre AJP usa backlog, se la coda è piena il connettore rifiuta la richiesta.
L’attributo connectionTimeout consente di specificare il numero di millisecondi massimo che si attende per una data richiesta.
Se si vuole usare un proxy si possono usare gli attributi proxyName e proxyPort

Uso dell'elemento Valve

A volte si ha la necessita di eseguire un insieme di azioni quando una richiesta arriva al server.
JBoss fornisce la possibilità di definire degli interceptor per le richieste entranti che possono essere configurati nel file server.xml mediante l’elemento Valve, sottoelemento di Engine o Host.

  
  ...

Alcuni dei valori possibili per l’attributo className sono:

• org.apache.catalina.valves.RequestDumperValve: effettua il log di tutte le informazioni sulla richiesta prima e dopo che questa venga processata
• org.apache.catalina.valves.AccessLogValve: scrive in un file di log simile al file di log di accesso di un web server
• org.apache.catalina.valves.FastCommonAccessLogValve: simile a AccessLogValve ma molto più veloce e più limitato nella configurazione
• org.apache.catalina.valves.RemoteAddrValve: consente il filtraggio delle richieste sulla base dell’indirizzo IP del client
• org.apache.catalina.valves.RemoteHostValve: consente il filtraggio delle richieste in base all’hostname del client

Configurare JavaServer Faces (JSF)

L’implementazione di riferimento di JSF 1.2 è Mojarra,per configurare JSF occorre modificare il file WeB-INF/web.xml nel seguetne modo:

  ...
  
    Faces Servlet
    javax.faces.webapp.FacesServlet
    1
  
  
    Faces Servlet
    *.faces
  
  ...

Se si vogliono aggiornare le librerie JSF occorre fare rfimentimento alla cartella server/xxx/deploy/jbossweb.sar/jsf-libs.