Cluster In Jboss Lato Client

Questa pagina spiega in breve come collegarsi al cluster su jboss.
Per impostare il cluster lato server leggere la parte relativa al cap 12.
Bisogna fare in modo che venga fatto un jndi verso la batteria di macchine del cluster da parte della nostra applicazione web in maniera simile a come viene fatto da client che si vede nel capitolo 12.

Solitamente il frontend dell'applicazione è dato da tutte le applicazioni .war mentre il backend da quelle .jar. Il passaggio da front a back avviene nel momento che il primo richiama un EJB con interfaccia remota. Vediamone il percorso in modo da capire dove viene introdotta la parallelizzazione.
Ho visto due modi di richiamare i bean.

Tramite spring siamo nella classe del frontend ContactServiceImpl

private FagioloSessionRemote _fagioloSessionBean;

Che è un session bean con interfaccia remota. O meglio FagioloSessionRemote è proprio l'interfaccia remote che viene implements dal bean FagioloSessionBean. La forma di caricamento che viene usata principalmente è quella fatta tramite spring che comporta oltre a quella dichiarazione un file xml con delle informazioni di caricamento. Che si trova nella cartella principale di src il file per il session bean indicato è applicationContext-contact.xml e la parte che effettua il caricamento al suo interno è questa

<jee:jndi-lookup id="ejb.contactService" jndi-name="nomeear/FagioloSessionBean/remote" cache="true" >
<jee:environment>
java.naming.provider.url=t3://192.168.10.70:1099
</jee:environment>
</jee:jndi-lookup>
<bean id="contactService" class="com.applic.frontend.services.ContactServiceImpl">
<property name="fagioloSessionBean" ref="ejb.contactService" />
</bean>

In questo modo si effettua il caricamento dal cluster specificando un nodo di tale sistema. Per curiosità t3 è un protocollo di comunicazione chiuso e particolarmente adatto a comunicazioni Questo metodo di specificare informazioni di caricamento dentro un file xml è una maniera superata di applicare le impostazioni ed è stata abbandonata passando dalla tecnologia EJB 2 a EJB 3 che è l'ultima al momento in cui si scrive ed è quella in uso nel progetto. Causa una dispersione delle informazioni nei file xml e nel caso specifico se è necessario cambiare l'ip per effettuare il jndi lookup su un altra macchina lo si deve fare per ogni bean definito. Se non viene specificato il parametro <jee:enviroment> il lookup viene fatto di default su localhost. Un altra maniera per effettuare il tutto è tramite annotazioni

@EJB private FagioloSessionRemote _fagioloSessionBean;

e dentro la dir src (nella stessa posizione dove vi sono gli xml di spring) va aggiunto il file jndi.properties con il seguente contenuto

java.naming.factory.initial=org.jnp.interfaces.NamingContextFactory
java.naming.factory.url.pkgs=org.jboss.naming
java.naming.provider.url=192.168.10.70\:1099

lo \ prima dei due punti lo mette in automatico eclipse su quel progetto, penso perché vede i : come metacarattere, la cosa strana è che sul client per il test del backend non lo aggiungeva. Tutte le chiamate sul bean adesso verranno eseguite dal backend che nel nostra caso si trova su un cluster. Per la configurazione del cluster rimando alla pagina web del mio sito di appunti (per la configurazione vedere direttamente il paragrafo 12.2 Setting up a simple cluster) che poi è un riassunto tradotto in italiano del libro jboss in action. Per permettere la distribuzione di carico delle chiamate (strategia di default round robin), bisogna applicare ai bean che si vogliono distribuire la notazione @Clustered nella loro implementazione ecco l'esempio

import org.jboss.ejb3.annotation.Clustered;

@Clustered
@Stateless
public class FagioloSessionBean implements FagioloSessionRemote
{
//resto dell'implementazione della classe dichiarazioni e metodi

L'applicazione che va caricata sul backend è un .ear dove vengono eliminati da application.xml tutti i file .war, ovviamente conviene eliminarli anche fisicamente dall'ear per non portarsi dietro file inutili che poi sono anche i più pesanti. Nel frontend invece non sono riuscito ad eliminare i .jar a causa di errori in fase di deploy, ma questi in esecuzione non vengono usati neanche se il backend cade infatti se tutte le macchine cluster divengono indisponibili e si prova ad eseguire un'operazione che lo richiama si ottiene un'eccezione. Si sono avuti dei problemi lanciando il frontend in configurazione all, invece usando la default il richiamo delle macchine cluster funziona perfettamente. Se deployamo sul frontend con configurazione default (che al momento è l'unica che funziona in cluster) i moduli del backend con la notazione @Clustered otteniamo degli errori in deploy, dovremmo quindi commentare la riga dove ci è questa annotazione prima di preparare l'ear che va a finire sul frontend. Ogni macchina del backend deve essere eseguita con l'opzione -b sull'interfaccia remota invece il frontend riesce a comunicare anche se si esegue su localhost.

Salvo diversa indicazione, il contenuto di questa pagina è sotto licenza Creative Commons Attribution-ShareAlike 3.0 License