domingo, 7 de abril de 2013

JMS Bridge


Salve galera,


Hoje vou escrever sobre um assunto que não domino, mas estou pretendendo usar essa tecnologia em alguns projetos, então uma boa maneira de aprender sobre um assunto é escrever sobre ele, e ver se tudo o que aprendi até agora ficou claro. Vou falar sobre JMS.

JMS

O assunto JMS a muito tempo está na minha "lista" de coisas para aprender antes de morrer (sim, coisa de programador! hahahaha), mas por preguiça e falta de motivação, até agora só havia lido superficialmente sobre o assunto. Nesse post vou explicar o que é JMS e para o que ele serve.

JMS, ou Java Messages Service, segundo a Wikipédia, é uma API da linguagem Java para middleware orientado à mensagens. Através da API JMS duas ou mais aplicações podem se comunicar por mensagens (http://pt.wikipedia.org/wiki/JMS ). JMS é uma maneira simples a padronizada de trocar informações entre sistemas distribuídos, ou entre sistemas remotos. Um bom exemplo seria a replicação de dados entre sistemas, onde sistemas dependem de informações de outros sistemas para tomar alguma decisão.

Motivação

Existem diversas estruturas de sistemas onde a comunicação não pode ser em tempo real, ou não podemos ter um servidor central, seja por falta de internet confiável, alta disponibilidade e outras coisas mais. Nesses casos, cada ponto, ou nó tem sua unidade própria de funcionamento, mas precisa trocar e compartilhar informações com outras unidades.


Sobre JMS

Precisamos saber que uma estrutura JMS tem dois componentes principais. Uma fabrica de conexões com uma fila e uma fila.
As filas podem ser de dois tipos:

Consumidores X Produtores

Quando falamos sobre JMS temos dois papeis principais. Os produtores e os consumidores, que não precisam de muita explicação, pois os nomes produtor e consumidor já são bem sugestivos. Mas para não passar em branco:

O produtor é o cara que solicita uma conexão a fabrica de conexão e envia uma mensagem.
O consumidor é o cara que solicita uma conexão a fabrica de conexões e recebe as mensagens enviadas.

Tipos de Fila

Queue: Esse tipo de fila tem uma relação de 1 x 1 com seu consumidor, isso quer dizer que quando uma aplicação lê o dado da Queue, esse dado é marcado como lido e não é mais entregue para ninguém.

Topic: Esse tipo de fila tem uma relação de 1 x n consumidores, isso quer dizer que podemos ter vários consumidores recebendo a mesmo informação.

Persistente

As filas podem ser persistentes (Persistent) ou não. Uma fila com propriedade de persistência é mais segura que uma não persistente por motivos óbvios. Enquanto uma tem suas mensagens armazenada em um local seguro, como um banco de dados ou arquivo, a outra fica apenas em memória. Então, se os dados da fila não podem ser perdidos com uma queda de luz, ou alguma reinicialização do container, você deve usar uma fila persistente. Por padrão, se nada for configurado, os dados são persistentes para ambas as filas.

Time to Live

Ao escrever uma mensagem na fila, podemos definir um tempo de vida para ela (Time to Live), que define o tempo de vida até que ela expire e saia da fila. Isso também vai depender da importância da mensagem. Por padrão, elas têm tempo de vida infinita.

Durabilidade

O termo durabilidade só se aplica as filas do tipo Topic. Para acessar uma fila desse tipo temos que fazer uma inscrição de conteúdo no servidor JMS, claro que isso é apenas "formalidade" pois para uma Queue fazemos o mesmo processo, mas o que define um Topic são seus possíveis múltiplos leitores. Com isso, nós podemos informar qual a importância do conteúdo na perspectiva do assinante ou leitor. Quando dizemos que a assinatura é durável (Durable) estamos dizendo ao servidor JMS que todo conteúdo gerado deve ser entregue, independente de eu estar on-line ou não. Com isso, todo conteúdo gerado é "guardado" para que eu possa receber agora ou mais tarde, garantindo uma entrega segura e sem perdas. Já uma assinatura não durável (NonDurable) diz que quando eu estiver off-line o conteúdo gerado não precisa ser guardado, logo quando eu ficar on-line vou receber apenas o conteúdo gerado a partir desse momento.

JMS Bridge

Uma ponte JMS é um canal direto de comunicação criado entre duas filas JMS que é gerenciada pelo servidor JMS. Isso quer dizer que se tivermos uma fila A1 no servidor G1 e uma fila B1 no servidor G2 fazendo uma ponte, todas as mensagens escritas em A1 são recebidas em B1 automaticamente. Com isso podemos sempre tratar as filas como sendo locais e não precisamos fazer conexões externas em nossa aplicação, pois o servidor JMS é quem cuida da replicação.

Apesar de outros detalhes, acho que essas são as coisas mais importantes que devemos saber antes de iniciar a parte divertida, ou seja, a programação.

Objetivo

Comunicação entre duas aplicações Java rodando em AppServers distintos (Glassfish). Cada aplicação deve ter uma fila de leitura, onde recebe mensagens de uma aplicação remota, e também deve ter uma fila de escrita, na qual ela vai escrever mensagens para que uma aplicação remota receba.

Problema

Antes de conhecer as pontes do JMS, (JMS Bridge) eu pensava que cada aplicação deveria conectar-se no outro AppServer remoto para poder consumir e produzir os dados na suas respectivas filas. Depois um certo tempo batendo a cabeça tentando fazer essa solução sem obter sucesso, eu abri uma pergunta no GUJI, então apareceu essa solução rápida, limpa e certeira!


Solução

A solução foi usar o próprio servidor JMS embutido no Glassfish para fazer essa ponte, de modo que da perspectiva da aplicação, só existam filas locais. Com isso, a responsabilidade de replicação das filas fica com o AppServer, diminuindo consideravelmente a complexidade do problema.

Desenvolvendo a solução

Primeiramente devemos ter um ambiente de testes, com maquinas virtuais, maquinas real ou duas instâncias de um glassfish rodando na mesma maquina.

Ambiente de teste para esse post
- Duas maquinas. Uma com Windows 7 64 bits e um MAC OS 10.8.2
- Java7
- Glassfish 3.1.2.2 (build 5)

Vamos dar nomes aos bois. Vamos chamar um servidor de  Master e o outro de Slave. No servidor Master, vamos rodar uma aplicação chamada JMSMaster e no servidor Slave vamos rodar uma aplicação chamada JMSSlave.

Vamos acessar o console do servidor Master, http://localhost:4848. Vá em Resources > JMS Resources > Connection Factories. Vá em novo, e coloque os dados abaixo:

Pool Name: jms/ReplicationFactory
Resource Type: javax.jms.TopicConnectionFactory
Descriprion: Replication Factory
Status: enabled

Agora vá em Destination Resouce. Vá em novo e crie duas filas com os dados abaixo:

JNDI Name: jms/ReplicationProducer
Physical Destination Name: ReplicationProducer
Resource Type: javax.jms.Topic
Description: Replication Producer
Status: enabled

JNDI Name: jms/ReplicationConsumer
Physical Destination Name: ReplicationConsumer
Resource Type: javax.jms.Topic
Description: Replication Consumer
Status: enabled

Certo, o que precisamos saber aqui é que:
Pool Name e JNDI Name é o nome do recurso usado para acessa-lo dentro da nossa aplicação. 
Physical Destination Name é o nome usado para configurar a ponte JMS

Agora vamos acessar o console do servidor Slave. Faça o mesmo processo com os dados abaixo:

Connection Factory
Pool Name: jms/ReplicationFactory
Resource Type: javax.jms.TopicConnectionFactory
Descriprion: Replication Factory
Status: enabled

Topic

JNDI Name: jms/ReplicationProducer
Physical Destination Name: ReplicationConsumer
Resource Type: javax.jms.Topic
Description: Replication Producer
Status: enabled

JNDI Name: jms/ReplicationConsumer
Physical Destination Name: ReplicationProducer
Resource Type: javax.jms.Topic
Description: Replication Consumer
Status: enabled

Note que tudo é igual, exceto de que o  Physical Destination Name foi invertido:

Quando escrevermos em ReplicationProducer no Slave, a mensagem vai ser replicada para ReplicationConsumer  no Master.

Quando o Master escrever no ReplicationProducer a mensagem será replicada para ReplicationConsumer no Slave.

Parece meio complexo lendo agora, mas é bem simples.

Nesse momento já temos nossos dois servidor configurados para fazer um JMS Bridge, com isso é hora de programar!

JMSMaster 

Vamos criar um EJB com as seguintes classes:



@Stateless
public class JMSProducerBean implements Serializable {

    @Resource(name = "jms/ReplicationFactory")
    private ConnectionFactory cmf;
    @Resource(name = "jms/ReplicationProducer")
    private Destination destination;
    private DateFormat dateFormat = new SimpleDateFormat("dd/MM/yyyy HH:mm:ss");

    public String send() throws JMSException {
        TopicConnection connection = null;
        String date = dateFormat.format(new Date());
        Logger.getGlobal().log(Level.SEVERE, "#> {0} send new replication..", date);
        try {
            connection = ((TopicConnection) cmf.createConnection());
            TopicSession topicSession =
                    connection.createTopicSession(false, Session.AUTO_ACKNOWLEDGE);
            TopicPublisher topicPublisher = topicSession.createPublisher((Topic) destination);
            TextMessage message = topicSession.createTextMessage("Master Node: " + date + " - new replication");
            topicPublisher.publish(message);
        } finally {
            if (connection != null) {
                connection.close();
            }
        }

        return null;
    }
}

@MessageDriven(mappedName = "jms/ReplicationConsumer")
public class JMSConsumer implements MessageListener {

    @Override
    public void onMessage(Message message) {

        try {
            TextMessage textMessage = (TextMessage) message;
            Logger.getGlobal().log(Level.SEVERE, "#> receive: {0}", textMessage.getText());
        } catch (Exception e) {
            Logger.getGlobal().log(Level.SEVERE, "#error process receiver.. {0}", e.getMessage());
        }
    }
}

@Stateless
public class TimerSessionBean {

    @EJB
    private JMSProducerBean productorBean;

    @Schedule(persistent = false, second = "*/10", hour = "*", minute = "*", dayOfMonth = "*", year = "*")
    public void myTimer() {

        try {
            productorBean.send();
        } catch (Exception e) {
            Logger.getGlobal().log(Level.SEVERE, "### error send message: {0}", e.getMessage());
        }
    }
}

JMSSlave

@Stateless
public class JMSProducerBean implements Serializable {

    @Resource(name = "jms/ReplicationFactory")
    private ConnectionFactory cmf;
    @Resource(name = "jms/ReplicationProducer")
    private Destination destination;
    private DateFormat dateFormat = new SimpleDateFormat("dd/MM/yyyy HH:mm:ss");

    public String send() throws JMSException {
        TopicConnection connection = null;
        String date = dateFormat.format(new Date());
        Logger.getGlobal().log(Level.SEVERE, "#> {0} send new replication..", date);
        try {
            connection = ((TopicConnection) cmf.createConnection());
            TopicSession topicSession =
                    connection.createTopicSession(false, Session.AUTO_ACKNOWLEDGE);
            TopicPublisher topicPublisher = topicSession.createPublisher((Topic) destination);
            TextMessage message = topicSession.createTextMessage("Slave Node: " + date + " - new replication");
            topicPublisher.publish(message);
        } finally {
            if (connection != null) {
                connection.close();
            }
        }

        return null;
    }
}

@MessageDriven(mappedName = "jms/ReplicationConsumer")
public class JMSConsumer implements MessageListener {

    @Override
    public void onMessage(Message message) {

        try {
            TextMessage textMessage = (TextMessage) message;
            Logger.getGlobal().log(Level.SEVERE, "#> receive: {0}", textMessage.getText());
        } catch (Exception e) {
            Logger.getGlobal().log(Level.SEVERE, "#error process receiver.. {0}", e.getMessage());
        }
    }
}

@Stateless
public class TimerSessionBean {

    @EJB
    private JMSProducerBean productorBean;

    @Schedule(persistent = false, second = "*/10", hour = "*", minute = "*", dayOfMonth = "*", year = "*")
    public void myTimer() {

        try {
            productorBean.send();
        } catch (Exception e) {
            Logger.getGlobal().log(Level.SEVERE, "### error send message: {0}", e.getMessage());
        }
    }
}

Se você analisar os códigos, vai ver que a única mudança do JMSMaster para o JMSSlave, são as mensagens enviadas. Agora você pode fazer e deploy da aplicação nos seus respectivos servidores e ver a magica acontecer nos logs de cada um. Faças os testes com mensagens duráveis e não duráveis deixando um ou os dois servidores off-line de vez em quando, reiniciando, sem rede, esse tipo de coisa.

Mais uma vez volto a dizer que sou novo nessa tecnologia, e ainda não coloquei essa lógica em produção, pois preciso ainda ver a questão de persistência segura, desempenho e tudo mais. Então, se em algum momento escrevi alguma besteira, fiquem a vontade para me corrigir.

Espero que esse post possa ajudar alguém que esteja procurando uma solução parecida. 

Até a próxima! abrasss


Nenhum comentário:

Postar um comentário