Software richiesto per l’esempio:

• Java Developement Kit 1.4.
• WLS server8.1 con licenza cluster(Evaluation version).
• Una base dati compatibile JDBC con relativo driver.

Una destination distribuita(DD) consiste in un gateway che permette di dispacciare messaggi JMS tra diverse destination fisiche. Le DD offrono due algoritmi per dispacciare fisicamente i messaggi: Round-Robin e Random. Ogni destination fisica a cui si appoggia una DD viene definita come membro. Un server JMS può contenere un solo membro associato ad una DD. I membri di una DD possono appoggiarsi a destination già configurate su un server JMS oppure possono essere generati in automatico nel momento della creazione.

Ecco la sequenza delle operazioni per configurare una DD:

1. Configurare un cluster WLS.

2. Configurare una serie di JMS servers attivandoli sui WLS servers in cluster:

Fig 1


Fig 2

Fig 3

 
Fig 4

3. Configurare delle destination fisiche che saranno usate come membri sui JMS servers (Opzionale): 

Fig 5

Fig 6

4. Configurare una Connection Factory attivandola sul cluster: 


Fig 7

Fig 8

Fig 9

Fig 10

Fig 11

Fig 12

Fig 13

Fig 14

Ecco di seguito un client che si connette alla nostra DD e la utilizza.

import java.util.*;

import javax.naming.*;

import javax.jms.*;

public class Sender

{

    public static void main(String args[])

   {

      final String CONNECTION_FACTORY = "JMSConnectionFactory";

      final String QUEUE = "DistributedQueue";

      QueueConnectionFactory qconFactory = null;

      QueueConnection qcon = null;

      QueueSession qsession = null;

      QueueSender qsender = null;

      Queue queue = null;

      TextMessage msg = null;

      Hashtable env = new Hashtable();

      env.put(Context.INITIAL_CONTEXT_FACTORY, "weblogic.jndi.WLInitialContextFactory");

      env.put(Context.PROVIDER_URL, "t3://localhost:9001,localhost:9002");

      env.put(Context.SECURITY_PRINCIPAL, "system");

      env.put(Context.SECURITY_CREDENTIALS, "weblogic");

      Context ctx = null;

      try

         {

            ctx = new InitialContext(env);

            qconFactory = (QueueConnectionFactory) ctx.lookup(CONNECTION_FACTORY);

            qcon = qconFactory.createQueueConnection();

            qsession = qcon.createQueueSession(false, Session.AUTO_ACKNOWLEDGE);

            queue = (Queue) ctx.lookup(QUEUE);

            qsender = qsession.createSender(queue);

            msg = qsession.createTextMessage();

            msg.setText("TESTO DI PROVA");

            qcon.start();

            qsender.send(msg);

            }catch(Exception e)

            {

                  e.printStackTrace();

                  }finally

                  {

                        try

                           {

                                       if(qcon!=null)qcon.close();

                                       if(ctx!=null)ctx.close();

                          }catch(Exception ee)

                         {

                                 ee.printStackTrace();

                           }

                  }

            }

}

I messaggi verranno distribuiti in maniera omogenea tra gli eventuali membri:

Fig 15

La tecnologia JMS non definisce uno standard per la gestione automatca di un eventuale crash del sistema. Una buona tecnica per gestire il Fail-Over sulle istanze JMS è quella di configurare uno storage fisico per ogni server JMS in cui verranno memorizzati tutti i messaggi non ancora scodati. In caso di fallimento di una istanza JMS, tutti i messaggi persistiti o su un file system o su una base dati non andranno persi ma saranno processati al reboot del servizio. La gestione del file system o delle tabelle viene fatta in automatico da WLS. Per ogni JMS server possiamo configurare un unico Persistent Store che sarà riservato al server in questione.

Ecco la sequenza di operazioni per configurare la persistenza JMS:

1. Configurare un pool di connessioni(Opzionale).

2. Configurare un Persistent Store.

Fig 16

 3. Associare il Persistent Store ad un JMS server.

Fig 17

4. Rendere persistenti i servers, le destinations e la connection factory.

Fig 18

Fig 19

 
Fig 20

5. Effettuare un restart dei server in cluster.

6. Controllare con un client l’avvenuta creazione delle tabelle sul DB: 

Fig 21

La migrazione di un servizio JMS è una tecnica che viene attuata soltanto in casi estremi in cui, dopo un fallimento, non è possibile effettuare un reboot del servizio JMS sulla macchina fisica. La migrazione JMS permette di configurare automaticamente una configurazione JMS su una istanza WLS in cluster.

Per migrare un JMS server è necessario:

1. Stoppare i server managed appartenenti al cluster.

2. Attivare un JMS server su un Migratable target: 

Fig 22

3. Definire una lista di Migratable servers dove saranno creati dei backup della configurazione JMS:  

Fig 23

4. Aspettare un crash del servizio

5. Assicurarsi che il server da migrare sia down e lanciare manualmente dalla console o a riga di comando l’operazione di migrazione: 

Fig 24

Fig 25

Fig 26

Fig 27

Fig 28

A questo punto abbiamo un sistema JMS completamente clusterizzato. Se usate la versione 6.1 di weblogic server troverete informazioni utili all’URL:

WebLogicJMSPerformanceGuide.pdf