Ricardo Bocchi

Salve galera,

Nesse poste vou continuar o assunto JMS, mas agora como configurar uma Bridge no JBoss. No poste http://ricardobocchi.blogspot.com.br/2013/04/jms-bridge.html eu mostrei como configurar uma Bridge JMS no glassfish, com toda sua simplicidade de configuração. Também expliquei alguns conceitos sobre JMS e JMS Bridge, então nesse post, somente escreverei sobre a configuração no JBoss.

A verdade é que tive bastante dificuldade em implementar no JBoss aquela mesma estrutura que fiz no glassfish, pois a versão corrente JBoss As 7.1.1 não tem implementação integrada de Bridge, com isso ela deve ser configurada diretamente no HornetQ, que é o servidor JMS embutido no JBoss. Mas o problema é que a documentação de como integrar tudo, de modo que funcione, na minha opinião, é bem incompleta. Por exemplo, para mim que nunca tinha usado o JBoss ficou meio que inviavel descobrir onde colocar os arquivos do HornetQ de modo que ao subir o JBoss, ele reconhece as configurações de Bridge. Eu queria que a estrutura fosse bem simples, usando o servidor JMS embutido, e não ter que subir um servidor JMS para depois subir um JBoss e fazer a integração. Bom, depois de muito apanhar e não sair do chão com a bendita Bridge, eu descobri do detalhe da não implementação através do JBoss, e descobri que para a nova versão a funcionalidade estaria presente. Com isso, baixei a versão de desenvolvimento do JBoss, compilei e ai sim a configuração de Bridge ficou fácil. Dito isso, vou apenas postar as configurações usadas.

A versão do JBoss usada foi: jboss-as-8.0.0.Alpha1-SNAPSHOT

Abra o arquivo

jboss-as-8.0.0.Alpha1-SNAPSHOT\standalone\configuration\standalone.xml

Primeiramente, para habilitar JMS no JBoss, temos que adicionar a extenção do subsystem dentro da tag <extensions>:

Agora vamos adocionar o sub sistema de mensageria dentro da tag <profile>:

        
        
            
                true
                102400
                2

                
                    
                    
                        
                    
                    
                    
                

                
                    
                    
                        
                        
                    
                    
                

                
                    
                        
                        
                        
                        
                    
                

                
                    
                        jms.queue.DLQ
                        jms.queue.ExpiryQueue
                        0
                        10485760
                        BLOCK
                        10
                    
                

                
                    
                        
                            
                        
                        
                            
                        
                    
                    
                        
                            
                        
                        
                            
                            
                        
                    
                    
                        
                        
                            
                        
                        
                            
                        
                    
                

                
                    
                        
                        
                    
                    
                        
                        
                    
                
            
            
                
                    
                    
                    replicador
                    replicador123*
                    
                        
                        
                        
                        
                        
                    
                
                
                    
                    
                    replicador
                    replicador123*
                
                AT_MOST_ONCE
                500
                1
                500
                500
                true
            
   
                
                    
                    
                    replicador
                    replicador123*
                
                
                    
                    
                    replicador
                    replicador123*
                    
                        
                        
                        
                        
                        
                         
                
                AT_MOST_ONCE
                500
                1
                500
                500
                true

Com essa configuração foram criados dois topicos: Um para enviar mensagens ao outro servidor, e um para receber mensagens do outro servidor. Em source, vocês devem mudar o ip remoto para suas configurações de teste.

Não vou explicar os detalhes da criação das filas, pois basta procurar nos links abaixo, e se você tem noção do que é uma fila, olhando as tags você consegue se achar:

JMS JBoss Documentação

https://docs.jboss.org/author/display/AS71/Java+Message+Service+API+%28JMS%29

Artigo que explica como configurar filas e tópicos de forma detalhada

http://lucianomolinari.wordpress.com/2012/03/01/filas-jms-com-jee6-e-jboss7/

JMS Bridge JBoss

https://docs.jboss.org/author/display/AS72/Messaging+configuration

Um detalhe importânte, é que devemos criar os usuários no JBoss para acessarmos as filas remotamente via Bridge. Na pasta bin do JBoss, temos o utilitário add-user, onde você cria usuários para gerenciamento do appserver e também os usuários que podem ter acesso as aplicações remotamente via lookup. Nessa configuração que fiz, tenho o usuário replicador com senha replicador123, que faz parte do grupo guest.

Ah, também nessa versão do JBoss, temos que configurar um módulo:

Esse módulo, fica em

jboss-as-8.0.0.Alpha1-SNAPSHOT\modules\system\layers\base\br\com\mobilemind\main\module.xml

Pelo que parece, esse módulo precisa ser configurado para que a Bridge funciono. Falo isso, por que a versão ainda está em desenvolvimento, então alguma coisa ainda pode mudar.

Bom, era isso.. depois de apanhar um pouco, venho aqui e compartilho o que conseguie para que talvez alguém possa poupar seu tempo de error idiotas.

Por hora é só, qualquer dúvida é só postar! abrass

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!

http://www.guj.com.br/java/297160-remote-jms

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

Ricardo Bocchi

sexta-feira, 12 de abril de 2013

JMS Bridge JBoss

domingo, 7 de abril de 2013

JMS Bridge

segunda-feira, 1 de abril de 2013

Carona Verde