Tale pratica consente la distribuzione del carico elaborativo su più JVM, migliorando le performance generali delle applicazioni, abbassandone di conseguenza i tempi di risposta.

Vediamo in sequenza i passi per ottenere quanto descritto, considerando che il carico verrà bilanciato su due servlet container Tomcat 4.x:

Passo 1: Download del software necessario

• Apache 2.x (binari)
• Tomcat 4.x (binari)
• Modulo jk (mod_jk.so)

Passo 2: Installazione del software

Per le procedure di installazione di Apache 2.x e Tomcat 4.x seguire le indicazioni fornite nella documentazione ufficiale, mentre il modulo mod_jk-2.0.42.so va rinominato in mod_jk.so e copiato nella directory modules presente nella root di installazione di Apache 2

Passo 3: Configurazione di Apache 2.x

Aprire il file httpd.conf contenuto nella directory conf di Apache 2.x, ed aggiungere le seguenti linee, subito dopo l’ultimo LoadModule :

#
# Load mod_jk
#
LoadModule jk_module modules/mod_jk.so

#
# Configure mod_jk
#
JkWorkersFile conf/workers.properties
JkLogFile logs/mod_jk.log
JkLogLevel info

Inserire sotto la linea relativa alla DocumentRoot, le seguenti linee:

JkMount /*.jsp loadbalancer
JkMount /servlet/* loadbalancer

Creare un file workers.properties, sempre nella directory conf di Apache 2.x, questo file in pratica elenca i vari Tomcat su cui verrà bilanciato il carico di lavoro e su quali porte Apache 2.x attraverso il mod_jk comunicherà con essi:

#
# workers.properties
#
# In Unix, we use forward slashes:
ps=/

# list the workers by name
worker.list=tomcat1, tomcat2, loadbalancer

# ------------------------
# First tomcat server
# ------------------------
worker.tomcat1.port=11009
worker.tomcat1.host=localhost
worker.tomcat1.type=ajp13

# Specify the size of the open connection cache.
#worker.tomcat1.cachesize

#
# Specifies the load balance factor when used with
# a load balancing worker.
# Note:
# ----> lbfactor must be > 0
# ----> Low lbfactor means less work done by the worker.
worker.tomcat1.lbfactor=100

# ------------------------
# Second tomcat server
# ------------------------
worker.tomcat2.port=12009
worker.tomcat2.host=localhost
worker.tomcat2.type=ajp13

# Specify the size of the open connection cache.
#worker.tomcat2.cachesize

#
# Specifies the load balance factor when used with
# a load balancing worker.
# Note:
# ----> lbfactor must be > 0
# ----> Low lbfactor means less work done by the worker.
worker.tomcat2.lbfactor=100

# ------------------------
# Load Balancer worker
# ------------------------

#
# The loadbalancer (type lb) worker performs weighted round-robin
# load balancing with sticky sessions.
# Note:
# ----> If a worker dies, the load balancer will check its state
# once in a while. Until then all work is redirected to peer
# worker.
worker.loadbalancer.type=lb
worker.loadbalancer.balanced_workers=tomcat1, tomcat2

#
# END workers.properties
#

Passo 4: Configurazione di Tomcat 4.x

Aprire il file server.xml presente nella directory conf di Tomcat 4.x ed effettuare le seguenti modifiche:

Modificare la linea:

<Engine name="Standalone" defaultHost="localhost" debug="0">

in:

<Engine jvmRoute="tomcat1" name="Standalone" defaultHost="localhost" debug="0">

per il secondo Tomcat specificare “tomcat2″ per il parametro jvmRoute.

Modificare l’attributo:

<Server port="8005"

in:

<Server port="11005"

per il secondo Tomcat specificare la porta 12005

Modificare poi la porta del connettore AJP13, da:

port="8009"

in:

port="11009"

per il secondo Tomcat, specificare la porta 12009

queste impostazioni rispecchiano ciò che è stato indicato nel file workers.properties visto in precedenza

Se non si desidera che i due Tomcat possano essere utilizzati direttamente, è necessario disabilitare il loro connector HTTP commentando il blocco XML:

<!-- Define a non-SSL HTTP/1.1 Connector on port 8080 -->
<!--
<Connector className="org.apache.catalina.connector.http.HttpConnector" port="8080" minProcesssors="5" maxProcessors="75" enableLookups="true" redirectPort="8443" acceptCount="10" debug="0" connectionTimeout="60000"/>
-->

Se si decide di non commentare questa parte è necessario modificare l’attributo port per uno dei due Tomcat o per tutti e due indicando ad esempio per il primo Tomcat port="11080" e per il secondo Tomcat port="12080"

Passo 5: Avvio dei servizi nel corretto ordine

Avviare nella sequenza riportata i servizi:

1. Tomcat 4.x n.1
2. Tomcat 4.2 n.2
3. Apache 2.x

Conclusioni

Il load balancing funziona grazie al meccanismo del session affinity, (opzione jvmRoute di Tomcat) che consente, dopo la prima richiesta di continuare ad inoltrare le successive richieste del browser allo stesso Tomcat per non perdere le informazioni create in sessione e gestite dal servlet container che ha risposto appunto alla richiesta iniziale di un browser.

Uno strumento che può essere utilizzato per moltissimi scopi, alcuni esempi: tracciatura e Logging delle attività utente, localizzazione, compressione dati, autenticazione.

Cosa Sono?

Come si intuisce dal nome, sono delle particolari classi Java che consentono di filtrare le richieste del browser verso le Servlets di una web applications e la risposta della Servlet al browser.

La “filtratura” avviene intercettando la richiesta HTTP in modo da poterla manipolare, prima che questa arrivi alla Servlet destinataria o modificando la risposta prima di essere ritornata al browser.

Come abbiamo detto i Servlet Filters sono classi Java, una classe per poter essere utilizzata come filtro deve implementare l’interfaccia javax.servlet.Filter, che definisce tre metodi di base:

init(FilterConfig fc)
doFilter(ServletRequest req, ServletResponse res, FilterChain chain)
destroy()

Nei Servlet Filters esiste il concetto di “catena”, per ogni web application possono essere configurati più filtri a formare una catena, invocata in sequenza in base alla mappatura dei singoli filtri che la compongono, sulle risorse (Servlet/JSP) della web applications.

Ogni Servlet Filter deve essere configurato e mappato nel deployment descriptor della web application (web.xml), mediante l’uso dei tag xml <filter> e <filter-mapping>

Il tag <filter> consente di specificare un nome logico assegnato al filtro, la classe che lo implementa i sui eventuali parametri di inizializzazione, questo il formato:

<filter>
<filter-name>LogicalFilterName1</filter-name>
<filter-class>[package.]FilterClass1</filter-class>
<init-param>
<param-name>param1</param-name>
<param-value>value</param-value>
</init-param>
...
<init-param>
<param-name>paramN</param-name>
<param-value>value</param-value>
</init-param>
</filter>

Il tag: <filter-mapping> consente di mappare il filtro, attraverso il suo nome logico, su le risorse per cui deve filtrare le richieste, questo il formato:

<filter-mapping>
<filter-name>LogicalFilterName1</filter-name>
<url-pattern>WebResourceURL(es./*)</url-pattern>
</filter-mapping>

Il Ciclo di Vita

Il ciclo di vita di un Servlet Filters è gestito direttamente dal Java Application Server, che invoca i suoi metodi nella sequenza:

Al boot dell’applicazione il Java Application Server:

• istanzia le classi dei vari filtri configurati nel deployment descriptor, se un filtro prevede dei parametri di configurazione, istanzia una classe che implementa l’interfaccia FilterConfig che consente l’accesso a tali parametri.
• istanzia una classe che implementa l’interfaccia FilterChain e rappresenta la catena dei filtri da invocare
• invoca il metodo init(FilterConfig fc) passandogli l’eventuale configurazione del filtro mediante la classe FilterConfig istanziata

Quando un utente attraverso il suo browser effettua una richiesta HTTP verso una Servlet o un a JSP, o l’applicazione in seguito ad una richiesta dell’utente produce una nuova richiesta HTTP verso un’altra Servlet o JSP, il Java Application Server, controlla dal deployment descriptor se ci sono filtri mappati per quella risorsa attraverso i tag <filter-mapping>, trovato il primo, ne invoca il metodo doFilter(ServletRequest req, ServletResponse res, FilterChain chain), questo metodo è il cuore di un Servlet Filter e deve essere implementato con la logica di manipolazione dell’oggetto request.

Dall’interno del metodo doFilter(ServletRequest req, ServletResponse res, FilterChain chain) del Servlet Filter, si può decidere di chiamare il metodo doFilter(ServletRequest req, ServletResponse res) dell’oggetto FilterChain chain passato al filtro dal Java Application Server, che passa il controllo e gli oggetti request e response, al prossimo filtro della catena, mappato per la risorsa richiesta dal browser.

Ma si può anche decidere di non invocare tale metodo e “spezzare” così la catena, facendo così in modo che la richiesta arrivi a destinazione evitando che l’oggetto request venga ulteriormente manipolato da eventuali altri Servlet Filter successivi della catena.

E’ anche possibile come detto inizialmente manipolare l’oggetto request che viene restituito al browser facendo in modo che prima di arrivare a destinazione passi nuovamente, attraverso i filtri.

Ciò si ottiene inserendo il codice di manipolazione dell’oggetto response subito dopo la chiamata del metodo doFilter(ServletRequest res, ServletResponse res) sull’oggetto FilterChain chain effettuata nel metodo doFilter(ServletRequest res, ServletResponse res, FilterChain chain) di ogni Servlet Filter.

Tale pratica ci consente di effettuare ad esempio operazioni di compressione di eventuali files (come PDF, txt, etc.) prodotti, in ritorno al browser, o tracciatura in logs, di ciò che è stato ritornato al browser.

Buona lettura, e speriamo che sia proficua!