HA-Singleton è un particolare servizio di JBoss che consente ad una applicazione distribuita in un cluster di essere eseguita come singleton (una sola istanza in esecuzione) e, nel contempo, garantire alta disponibilità. Come è facile intuire si tratta di una soluzione adatta per tutte quelle applicazioni che, per motivi progettuali, non possono essere eseguite in istanze multiple. Si prenda ad esempio un semplice job schedulato.

Il principio si basa sulla presenza di un nodo master (allo startup è il primo nodo avviato) su cui vengono eseguite tutte queste applicazioni. In caso di failure del nodo master, il cluster procede ad una elezione di un nuovo master fra i nodi esistenti e su quello vengono avviate le applicazioni.

Il modo più semplice per avere una applicazione in HA-Singleton è di fare il deploy nella directory deploy-hasingleton. Questa directory viene monitorizzata esclusivamente alla partenza del nodo master e il deploy delle applicazioni in essa contenute viene effettuato solo in quel nodo. Lo svantaggio principale di questo tipo di deploy consiste nel fatto che non è possibile fare deploy a caldo in quanto tale directory non viene letta dal deployer in nessun altro momento se non all’avvio del nodo master.

Se prendiamo ad esempio il seguente file scheduler-service.xml che rappresenta un semplice job schedulato:

<?xml version="1.0" encoding="UTF-8"?>
<server>
    <mbean code="org.jboss.varia.scheduler.Scheduler" name="it.test:service=Scheduler">
        <attribute name="StartAtStartup">true</attribute>
        <attribute name="SchedulableClass">it.test.SchedulableClass
        </attribute>
        <attribute name="InitialStartDate">NOW</attribute>
        <attribute name="SchedulePeriod">5000</attribute>
        <attribute name="InitialRepetitions">-1</attribute>
        <depends>
            <mbean code="javax.management.timer.Timer" name="jboss:service=Timer" />
        </depends>
    </mbean>
</server>

Posto all’interno della directory deploy di uno dei nodi, il risultato sarà che il nostro scheduler andrà in esecuzione esclusivamente nel nodo dove l’abbiamo pubblicato. Ma in caso di failure di questo nodo avremo il problema che il nostro scheduler si ferma inesorabilmente.

Se invece lo poniamo all’interno della directory farm avremo che il nostro scheduler andrà distribuito in tutto il cluster, ma anche che sarà avviato su tutti i nodi. E questo, con ogni probabilità, è un effetto indesiderato.

Ponendolo infine nella directory deploy-hasingleton di ciascun nodo (è importante!) e analizzando le varie jmx-console, vedremo che il servizio sarà presente solo e soltanto su un nodo e nella fattispecie il primo avviato.

Questo metodo come abbiamo avuto modo di ricordare non consente deploy a caldo, salvo forzare manualmente il deploy tramite la jmx-console e il servizio MainDeployer. Un po’ una scocciatura. Esiste però un altro metodo, basato sempre sullo stesso servizio, che consente di ottenere lo stesso risultato pratico facendo il canonico deploy della applicazione in farm. E’ sufficiente aggiungere al deployment descriptor la seguente dipendenza:

<depends>jboss.ha:service=HASingletonDeployer,type=Barrier</depends>

Una volta fatto questo, l’applicazione distribuita in farm ha un comportamento interessante: viene effettivamente distribuita sul cluster e su ciascun nodo viene effettuato il deploy, ma viene avviata solo sul nodo master. L’alta disponibilità è garantita dal fatto che nel momento in cui il nodo master andrà down l’applicazione verrà avviata sul neo-eletto master. Inutile dire che questo è il mio modo preferito di pubblicare applicazioni HA-Singleton.

Da notare che il deploy tramite Barrier ha effetto solo sullo start/stop del servizio, non sulla sua creazione o distruzione.

Problema: supponiamo di avere una applicazione (web o non web) basata su Spring e di voler pubblicare come web service su JBoss uno o più degli oggetti business gestiti da Spring.
La prima cosa che salta all’occhio è che qualora si utilizzino le comodissime annotazioni standard per fare il deploy del web service, il vostro oggetto manager non viene istanziato tramite l’IOC container di Spring, quindi diventa sostanzialmente inutilizzabile.
Una soluzione potrebbe essere convertire il progetto a Ejb3, chi può farlo lo faccia, ma chi non può? Per non parlare di chi non vuole…
In questi casi il metodo conveniente è quello di derivare la vostra classe che esporrà il web service da una n-esima classe di supporto di Spring, la SpringBeanAutowiringSupport. Questa classe astratta abilita l’annotazione @Autowire su qualsiasi istanza di oggetto purchè creata all’interno di una Web Application Spring-based. In questo modo potete “iniettare” oggetti configurati nel vostro IOC container di Spring nel vostro Web Service, esattamente come se fosse esso stesso un oggetto di Spring, continuando quindi ad utilizzare il paradigma del inversion of control.