Arquiteto

Solução de mensageira não é um bicho de 7 cabeças # 1

Postado em Atualizado em

activemq-5-x-box-reflectionVocê já ouviu falar de MOM?

Message oriented middleware (MOM) é servidor de aplicação (infra-estrutura de software + hardware) idealizado exclusivamente para suportar o envio e recebimento de mensagens entre sistemas distribuídos. É um serviço utilizado para intermediar a troca de mensagens entre sistemas, com o objetivo de fazer integração de serviços.

Para que serve um MOM?

Serve para dar solução robusta e confiável na integração entre duas ou mais diferentes soluções. Integrar sistemas hoje é um desafio imenso, diferentes plataformas, diferentes tecnologias, diferentes protocolos, diferentes mecanismos de persistências, assim, se faz necessario garantir serviços dentro da solução de integração como por exemplo: desacoplamento, entrega de mensagem, persistência de mensagem, politicas de retry, processamento assíncrono, escalabilidade, confiabilidade, transação, interrupções, segurança, clusterização e muito etc. Um MOM já faz tudo isso e muito mais.

MOM é para ser utilizado em soluções de grande porte?

Essa é justamente meu ponto: você lendo tal definição, tem a falsa impressão que só usaria um MOM para fazer coisas gigantescas e exorbitantes!!! Mas depois de conhecer Apache ActiveMQ e Spring JMS, você vera que é muito fácil e pode usar para fazer coisas pequenas também. Como diria um amigo meu, “só na manteguinha….. 🙂 “.

Você já ouviu falar de ActiveMQ?

ActiveMQ é uma implementação de um middleware completo (MOM), open source e grátis. Ele possui todas as grandes features necessários para dar solução em coisas de “grande porte”, mas o que o pessoal desconhece é que ele tem um arquitetura tão flexível e é tão bem feito que oferece diversas opções de uso e configurações flexíveis. Umas delas é usar o serviço de MOM de forma “embarcada”, dentro da sua própria instancia da JVM e da solução, não precisando criar um servidor remoto exclusivo para isso. Juntamente com isso, você desabilita as chamadas remotas e questões de persistência, e assim, acaba ficando com um mini-serviço de MOM simples, local com suporte a filas(Queue) e tópicos (Topics) que é justamente a “cereja de bolo” desse tipo de serviço.

Você já ouviu falar de Spring JMS?

Spring JMS é kit de desenvolvimento arquitetural que faz parte do framework spring criado exclusivamente para se trabalhar com integração de sistemas usando MOM. Esse produto abstrai toda a infra-estrutura de código utilizada para programar esse tipo de solução, criando uma facade de serviços rápida, produtiva e fácil de usar, retirando a necessidade de fazer código sujo e infraestrutural (boilepart) necessário para se configurar, enviar e consumir mensagens de um MOM.

Vamos fazer um exemplo prático?

Segue abaixo um exemplo real dessa simples e robusta solução:

Ferramentas:

  • Maven
  • Eclipse Java EE IDE for Web Developers – Versão Neon.1
  • Groovy-Eclipse plugin

Projeto:

Segue os passos resumido do projeto:

Crie um projeto java maven: New project -> Maven Project. Adicione groovy no projeto: botão direto no projeto -> configure -> Convert to groovy project. Configure o pom para baixar as dependências básicas: groovy, spring, cdi e activemq:

1

Configurar o spring.xml, subindo o activemq local, sem persistência, sem jmx, sem chamada remota. Configurar uma fila simples e um listener de fila. Configuramos também um jmsTemplate que é a facade de serviços spring que esconde a código sujo de MOM e JMS.

2

Criar um bean que envia a mensagem da fila:

2

Criar um bean que consome as mensagens da fila:

3

Fazer uma classe simples com main para testar o envio e o consumo da mensagem:

3

Execute a solução e teremos a saída:

3

E assim, com  menos de 5 minutos, e poucas linhas de código você consegue embarcar e reusar um MOM completo fazendo filas, tópicos, sem persistência, sem chamada remota, sem gastar muita memoria, rápido, fácil e sem perder tempo fazendo na unha qualquer coisa do tipo. Sem contar que você pode evoluir mais esse produto, habilitando serviço por serviço, tudo de acordo com sua necessidade.

Aonde eu uso isso?

Precisou integrar sua solução java com e-mail?, web services soap? web services rest?, banco de dados legados? ou quer gerar um relatório pesado assíncrono? Esta ai seu ponto de partido. ActiveMQ + Spring JMS = Solução simples e rápida com todos os sabores de processamento assíncrono usando filas e tópicos 100% MOM.

Como eu aprendo mais sobre esse assunto?

Tudo isso e muito mais pode ser encontrado no livro ActiveMQ in Action. Excelente livro sobre conceitos de mensageria, JMS e integrações em geral.

Github

Se te interessar, baixe esse projeto no meu git. Até a próxima 😉 !

“Mas tu, ó SENHOR, me proteges como um escudo. Tu me dás a vitória e renovas a minha coragem.” Salmos 3:3

Características de um Arquiteto de Software #4

Postado em Atualizado em

wellroundedarchitect-1024x574-1Ter um foco na solução

Os desenvolvedores experientes sabem que o código é apenas um aspecto do software real. Para tornar o código executável, um desenvolvedor experiente entende que existem outros atributos de qualidade importantes necessários para que o código funcione bem no ambiente de produção. Eles consideram aspectos como desempenho, segurança, escalabilidade, localidade, disponibilidade, confiabilidade, processos de implantação e testes automatizados. Os desenvolvedores simplesmente focam no código, mas o arquiteto no entanto, se concentrará na compreensão não apenas do código, mas também dos atributos de qualidade necessários para atender às muitas necessidades de diferentes partes interessadas. O bom arquiteto se concentra em encontrar soluções que possam satisfazer tantas dessas diferentes necessidades das partes interessadas, em vez de escolher uma ferramenta ou abordagem otimizada para as preferências ou o estilo de um único contribuinte. Para qualquer dúvidas, veja o post inicial dessa série.

“Procure descobrir, por você mesmo, como o SENHOR Deus é bom. Feliz aquele que encontra segurança nele!” Salmos 34:8

Para quem não sabe para onde vai, qualquer caminho serve

Postado em Atualizado em

574eeb8b9af513-13393298alice-no-pais-das-maravilhas-dublado-1080pHá uma cena que quero comentar na obra “Alice no país das maravilhas” o encontro de Alice com o gato. Na cena, Alice está perdida, e de repente, vê no alto da árvore o gato. Ela olha para ele lá em cima e diz assim:

Alice: “Você pode me ajudar?”
Gato: “Sim, pois não.”
Alice: “Para onde vai essa estrada?”
Gato: “Para onde você quer ir?”
Alice: “Eu não sei, estou perdida.”
Gato: “Para quem não sabe para onde vai, qualquer caminho serve.”

Muitas vezes vejo essa cena se repetir com o pessoal de desenvolvimento perguntando nos fóruns, e-mails e listas algo como:

“Qual melhor framework jA ou jB? Qual a melhor plataforma A , B, C? Qual melhor arquitetura em fazer C, D ou F? Qual framework web usar jWeb1, jWeb2 ou jWeb3?”

Como alguém poderia decidir por exemplo em usar JSF ou VRaptor ou ExtJ se não sabe os detalhes relacionados aos requisitos, contexto, ambiente e restrições da solução? A resposta seria igual ao do gato:

“Para quem não sabe para onde vai, qualquer caminho serve”.

Ou até pior, os céticos poderiam detonar uma opção e exaltar a outra ou pode aparecer aqueles “amantes emocionais” de tecnologia dizendo “usa aquela opção que é legal, eu gosto muito”.

O responsável por essa decisão, normalmente um arquiteto, deveria fazer suas escolhas arquiteturais e tecnológicas baseadas em justificativas coerentes no próprio cenário de requisitos existente a ser alcançado, características, restrições e outros limitadores corporativos externos como: custo, investimento, capacitação, curva de aprendizado, produtividade, gestão de equipe, cronograma e etc, e não em gosto, preferência, opiniões sem contexto ou qualquer outra coisa sem fundamentos lógicos e coerente.

As características da solução irão inevitavelmente se contradizer, alguma decisão deverá ser tomada, não será possível endereçar solução a todas as situações, mas algum caminho precisará ser traçado. Um exemplo comparativo simples, seria algo assim:

Exemplo 1

Contexto: Preciso viajar de Curitiba para São Paulo
Soluções: moto? carro? caminhão? avião?
Decisão: carro.
Justificativa: moto demora, não tenho carteira para caminhão e não tenho dinheiro para passagem de avião.

Exemplo 2

Contexto: Preciso viajar de Curitiba para São Paulo e levar uma geladeira
Soluções: moto? carro? caminhão? avião?
Decisão: caminhão.
Justificativa: moto não resolve, carro não resolve, e não tenho dinheiro para passagem de avião.

Exemplo 3

Contexto: Preciso viajar de Curitiba para São Paulo, levar uma geladeira e participar de uma reunião de negocio daqui 2 horas.
Soluções: moto? carro? caminhão? avião?
Decisão: sou obrigado a gastar com avião.
Justificativa: moto não resolve, carro não resolve, caminhão não resolve.

Como pode ser percebido, se existir um requisito tal de produtividade, talvez o framework A pode ser a melhor que o B, mas caso exista outro requisitos relacionado com segurança que pese mais que outras características, o framework B pode mais adequado que o A.

Não existe framework Java melhor ou pior, tudo esta relacionado em abrir um ponto de visão baseado em conhecer as opções, suas vantagens, desvantagens, virtudes, fraquezas e contrastar com os pesos das caraterísticas dos requisitos! Java é fantástico possuindo vários opções de framework para fazer diferente a mesma coisa. Então querido, seja livre, seja Java! Não se limite! Seja maduro e não tenha sentimentos para frameworks, use o que precisar, quando precisar! Toda produto/framework tem seu valor!

Com este ponto de vista, dizemos que a arquitetura emerge destas informações. Uma vez que o projeto começa a andar e pequenas fatias de releases começam a ser entregues, a solução pode passar mudanças de requisitos, características, ambientes e restrições precisando então ser melhorada e evoluída para um próximo nível, necessitando ou não a troca das opções de frameworks feitas anteriormente. Outra arquitetura emerge então destas novas informações respondendo, rapidamente a necessidades e cenários emergentes.

“O céu e a terra desaparecerão, mas as minhas palavras ficarão para sempre.” Mateus 24:35

Combo Domain Driven Design

Postado em

71lfru1pyalNo dia 22/02 foi liberado a terceira edição do livro Domain Driven Design – Atacando as complexidades No Coração do Software. A comunidade de desenvolvimento de softwares reconhece que a modelagem de domínios é fundamental para o design de softwares. Através de modelos de domínios, os desenvolvedores de software conseguem expressar valiosas funcionalidades e traduzi-las em uma implementação de software que realmente atenda às necessidades de seus usuários. Mas, apesar de sua óbvia importância, existem poucos recursos práticos que explicam como incorporar uma modelagem de domínios eficiente no processo de desenvolvimento de softwares. O Domain-Driven Design atende essa necessidade. Este não é um livro sobre tecnologias específicas. Ele oferece aos leitores uma abordagem sistemática com relação ao domain-driven design, ou DDD, apresentando um conjunto abrangente de práticas ideais de design, técnicas baseadas em experiências e princípios fundamentais que facilitam o desenvolvimento de projetos de software que enfrentam domínios complexos. Reunindo práticas de design e implementação, este livro incorpora vários exemplos baseados em projetos que ilustram a aplicação do design dirigido por domínios no desenvolvimento de softwares na vida real. Com este livro em mãos, desenvolvedores orientados a objetos, analistas de sistema e designers terão a orientação de que precisam para organizar e concentrar seu trabalho, criar modelos de domínio valiosos e úteis, e transformar esses modelos em implementações de software duradouras e de alta qualidade.

51cx1lbp-ll-_sx336_bo1204203200_Para completar o estudo sobre o assunto, existe tambem o livro chamado Implementando Domain-Driven Design que te ensina a implementar o DDD. Implementando Domain-Driven Design apresenta uma abordagem completa para o entendimento de domaindriven design (DDD), a fim de conectar fluentemente padrões estratégicos às ferramentas táticas fundamentais de programação. Vaughn Vernon une abordagens guiadas para implementação com arquiteturas modernas, destacando a importância e o valor de focar no domínio de negócios e, ao mesmo tempo, equilibrar com considerações técnicas. Baseado no livro do seminário de Eric Evans, o autor apresenta técnicas práticas de DDD por meio de exemplos a partir de domínios familiares. Cada princípio é fundamentado com exemplos realistas de Java — todos aplicáveis aos desenvolvedores de C# — e todo o conteúdo é complementado por um único estudo de caso: a entrega de um sistema SaaS baseado em Scrum de larga escala para um ambiente multitenant. O autor o leva a uma viagem além da abordagem “DDD-lite”, que engloba o DDD somente como ferramenta técnica, e mostra como alavancar os “padrões de projeto estratégicos” usando o Contexto Delimitado, Mapa do Contexto e a Linguagem Ubíqua. Ao usar essas técnicas e exemplos, você pode reduzir o tempo de mercado e melhorar a qualidade, já que constrói um software mais flexível, escalável e precisamente alinhado com suas metas comerciais.

Bons estudos para todos!!

“O que você diz pode salvar ou destruir uma vida; portanto, use bem as suas palavras e você será recompensado.” Provérbios 18:21

Dicas de Arquitetura de Software com Java

Postado em Atualizado em

org-320%2fschool-320%2f7d9bfc5e9dc56593d4a38668fdf743e1%2farquiteto2No curso AQT  M1 – Arquitetura de Software com Java, nós ajudamos os desenvolvedores Java a subir um pouco mais o nível de seus conhecimentos, deixando de ser meros programadores e passando a ter uma visão de arquiteto de software, compreendendo questões e princípios básicos de arquitetura. No final do curso, nós implementamos uma solução completa em java, desde de interfaces gráficas desktop , web, regras de negócio, até a persistência em banco de dados relacionais, provando então todos esses conceitos na prática.

Dezenas de alunos e profissionais tem feito o curso e além do feedback 100% positivo, eles tem me perguntando “como” poderiam evoluir a proposta arquitetural ministrado no curso, para um nível mais sofisticado e mais profissional. Hoje eu gostaria abrir essa conversa e dar cinco dicas sobre isso, a como adicionar mais produtos e melhorar a arquitetura proposta:

1.Validação de Negócio

No curso, a validação de negócio ficou dentro da classe domínio Cliente [domain model pattern], implementada de forma manual. Uma sofisticação dessa opção seria substituir a validação manual pela especificação java bean validation, evitando assim DRY e tendo uma melhor produtividade na validação. Sugiro provedor hibernate validation.

2.Fabricas

No curso, a criação do objeto responsável pela implementação da persistência seguindo o contrato da camada repositório [domain model repository pattern] ClienteJdbcImp, foi a classe FabricaPersistencia [Factory method pattern] implementada de forma manual. Uma sofisticação dessa opção seria substituir a fabrica manual pela injeção de dependência de uma especificação de um container IoC, evitando DRY e uma melhor produtividade. Sugiro provedor Spring IoC.

3.Persistência JDBC

No curso, o framework adotando como tecnologia de persistência da camada repositório foi o JDBC. Uma sofisticação dessa opção seria substituir o JDBC pelo JPA, evitando implementação improdutiva e burocrática das API de baixo nível, seus DRY e uma melhor produtividade. Sugiro provedor hibernate JPA.

4.Comandos SQL

No curso, os comandos SQL’s foram colocados dentro de atributos estáticos finais no formato string na classe ClienteJdbcImp. Uma sofisticação dessa opção seria não fazer SQL, deixando JPA gerar todos essas instruções dinamicamente via estratégia de ORM, evitando DRY e uma melhor produtividade. Sugiro provedor hibernate JPA.

5.Transação JDBC

No curso, os controle transacional ficou a a cargo JDBC usado de forma automática via connection=autocommit na classe ClienteJdbcImp. Uma sofisticação dessa opção seria usar controle de transações declarativas por AOP, evitando DRY, uma melhor produtividade e consistência. Sugiro Spring transactions.

Conclusão

Como pode ser visto, seria impossível e impraticável ensinar cada um desses produtos/tecnologias nesse mesmo curso, ficando ai de sugestão para você, aluno do nosso curso estudar e avançar gradualmente em cada um desses tópicos, a medida que você se despertar para eles. Eu me coloco a total disposição para ajudar sobre o assunto. Até a próxima 🙂 !

“Portanto, não percam a coragem, pois ela traz uma grande recompensa. Vocês precisam ter paciência para poder fazer a vontade de Deus e receber o que ele promete.” Hebreus 10:35-36

As dificuldades da Integração Entre Soluções

Postado em Atualizado em

integracaoUma solução não vive sozinha

As aplicações de hoje raramente vivem isoladas. Os usuários esperam acesso instantâneo a todas as funcionalidades, que podem ser fornecidas por aplicativos e serviços diferentes, dentro ou fora da corporação. Sendo assim, a integração de soluções nas corporações hoje é um requisito obrigatório para qualquer negocio. Em um mundo ideal, pode se imaginar uma organização que tenha um sistema único e coeso, projetado desde o inicio para funcionar de forma unificada e coerente. Porém, a realidade que vemos é completamente diferente. Em uma empresa, mesmo que pequena, muito dificilmente existe apenas uma aplicação. E mesmo que se opte por desenvolver tal aplicação única, diversos seriam os desafios que acabariam por inviabilizar a estratégia.

Integrar é dificil

E para cumprir esse requisito, projetistas e arquitetos de software precisam considerar que integrações são complexas e cheios de desafios, uma vez que podem ocorrer entre soluções estruturadas, de diferentes provedores, de diferentes épocas, com plataformas distintas, com tecnologias distintas, usando protocolos distintos, repleta de restrições, limitações, problemas, separadas geograficamente dentro e fora do escopo da organização.

Reuso de Conhecimento

A grande questão desse tópico é que faz algum tempo que não precisamos mais nos “aventurar a desvendar ou inventar” os segredos da integração! No livro Enterprise Integration Patterns, temos uma documentação extensa e completa de um catálogo de padrões que nos fornece um arsenal de informações a respeito de várias estratégias já usadas e aprovados em ambientes de produção nas ultimas décadas. O proposito desse artigo hoje é resumir os principais pontos desse livro. Acomode-se na sua cadeira e vamos que vamos 🙂 .

Caraterísticas de Integração

Segundo o livro, antes de qualquer ação, é necessário que o responsável pela integração pondere pelo menos 10 características fundamentais na decisão que repercutiram futuramente na qualidade, evolução e sustentabilidade, podendo impactar positivamente ou negativamente no serviço final. Segue eles abaixo:

  1. Acoplamento: Aplicações integradas devem minimizar as dependências entre si, de forma que cada uma possa evoluir sem causar problemas para as demais. Integrações devem ser específicas o suficiente para cumprir seu papel, porém, genéricas o suficiente para garantir que mudanças não façam com que as aplicações dependentes parem.
  2. Formato: Para se integrarem, aplicações devem concordar em um formato de dado. Considerando que alterar todas as aplicações da organização para considerar um formato de dado único pode ser inviável, tradutores intermediários podem ser empregados. Outro assunto relacionado é como a evolução do formato do dado ao longo do tempo pode impactar as aplicações dependentes.
  3. Seleção de Tecnologia: Diferentes abordagens de integração requerem diferentes quantidades de licenças de software e hardware. Tais ferramentas podem ser caras, podem levar a dependência da organização com fornecedores específicos e ao aumento da curva de aprendizado dos desenvolvedores.
  4. Exposição de Funcionalidades: Muitas abordagens de integrações permitem que aplicações compartilhem não apenas dados, mas também funcionalidades. Tal compartilhamento é interessante, pois gera um nível maior de abstração entre as aplicações envolvidas.
  5. Tempo para atualização: Integrações devem ser estruturadas pensando na minimização do tempo de defasagem de dado. Idealmente, aplicações consumidoras de dado deveriam ser informadas assim que o dado estivesse pronto para consumo. Quanto mais tempo se leva para o compartilhamento do dado, maior a probabilidade de falta de sincronismo de dados.
  6. Processamento Assíncrono: A chamada de funcionalidades remotas de forma síncrona pode ser algo custoso para a aplicação consumidora. A capacidade de realizar tarefas assíncronas traz diversas vantagens como, por exemplo, escalabilidade. Porém, tal solução tem design, desenvolvimento e depuração mais complexos.
  7. Confiabilidade: Conexões remotas não são apenas lentas, mas também são muito menos confiáveis do que a execução de procedimentos locais. Aplicações remotas podem não estar disponíveis ou a rede pode estar temporariamente indisponível. Comunicações assíncronas e confiáveis permitem que a aplicação origem realize outras tarefas, de forma confiante que a aplicação destino receberá a informação.
  8. Intrusividade: Integrações devem causar o mínimo de impacto em códigos existentes e devem requerer pouca codificação.
  9. Esforço: Algumas soluções de integração podem endereçar bem os diversos fatores apresentados, porém, podem ser difíceis de se desenvolver, depurar e manter. Profissionais específicos podem ser necessários para monitorá-las e para gerenciar erros.
  10. Escalabilidade: Integrações devem causar o mínimo de impacto na performance dos sistemas envolvidos. Também devem ser projetadas para suportar aumento no volume de dados trafegados e ainda pensando-se nos impactos decorrentes de acréscimo no número de sistemas consumidores de uma determinada informação. (Não constam no livro. Adicionados por mim por considera-los igualmente importantes com relação aos demais.)

Estilos de Integração

Segundo o livro, a evolução de anos de integração nos mostram que existem 4 principais estilos de integração. Esses quatros estilos, se endereçam automaticamente assumindo as caraterísticas acima citadas. Vejamos a seguir:

1) Transferência de Arquivo

Um sistema escreve um arquivo texto ou binário para que outro sistema leia.

1

2) Banco de Dados Compartilhado

Múltiplos sistemas utilizam o mesmo banco de dados físicos para consultar e manipular dados.

2

3) Invocação Remota

Um sistema expõe dados e funcionalidades para que sejam acessadas remotamente por outro sistema através de uso de tecnologias e protocolos proprietário ou públicos.

3

4) Mensageria

As aplicações se conectam a um sistema comum e intermediário de mensageria conhecido como MOM, de forma a compartilhar dados e a invocar operações através do uso de mensagens. O livro defini 65 diferentes micros padrões dentro desse estilo que pode ser combinado para dar soluções nos mais diversos cenários.

4

Prós e Contras de Cada Estilo

Cada um dos estilos possuem vantagens e desvantagens. A ideia não é usar sempre a mesma, mas ao invés, aquela que melhor se adeque a um cenário em particular. O livro é tão bom que já nos poupa tempo, classificando sistematicamente os prós e contras de cada caraterísticas versus o estilos, nos ajudando a ter uma visão global na tomada de decisão. Segue abaixo:

clip_image012

Qual é melhor ou Pior? Qual é o bala de Prata?

Segundo o livro, nenhum estilo ou abordagem de integração existente endereça todas as características acima ao mesmo tempo de forma igualmente bem. O estilo Mensageira é que mais se destaca entre todos por apresentar 80% de pontos fortes e 20% pontos fracos, e devem ser sempre o primeiro a ser considerado, porém, determinadas abordagens de integração podem ser melhores do que outras em determinados cenários. Em alguns casos, se faz necessário ate misturar dois ou mais estilos juntos para se chegar em um modelo mais adequado.

Sendo assim, é extremamente importante que o responsável por essa decisão se posicione embasado de fatos analíticos, lógicos e empíricos e não por preferência pessoais, por limitação técnicas ou qualquer outra coisa, sem fundamento sistemático.

Conclusão

Graças a esse livro, arquitetos e projetistas ganham e reusam conhecimento de décadas, sem precisar se preocupar em perder tempo, dinheiro e investimento para “desvendar mistérios” relacionado a criação de arquitetura na integração de soluções. Alem do livro, existe o site oficial com bons resumos e informações extras sobre esses os estilos e padrões. Até a próxima pessoal 😉 .

“Quando estamos na presença de Deus, temos coragem por causa do seguinte: se pedimos alguma coisa de acordo com a sua vontade, temos a certeza de que ele nos ouve.”1 João 5:14

Mensageria não é um bicho de 7 cabeças # 2

Postado em Atualizado em

activemq-5-x-box-reflectionNo último post Mensageria não é um bicho de 7 cabeças # 1, eu te ensinei a como integrar um serviço completo de MOM de forma simples e rápida para qualquer solução java standalone. Hoje eu vou dar continuidade no assunto, te ensinando a ativar os 4 serviços mais básicos indispensáveis que vão deixar sua solução com aquela cara de “produto de integração profissional” MOM de grande porte. Aperte os cintos e venha comigo:

1.Pooling de Fila

É  muito comum em integrações usando MOM que as filas tenham um pooling de objetos mínimos e máximo, com o objetivo de dar uma boa vazão no consumo das mensagens simultâneas, em caso de acumulo e alta demanda. Para ativar esse serviço em nossa solução, use a propriedade concurrency na configuração do consumidor da fila. Segue abaixo um exemplo:

1

No exemplo acima estamos configurando um listener de fila que conterá um pooling de mínimo 3 e máximo 8 objetos que serão responsáveis por consumir simultaneamente a demanda dessa fila. Isso você deve ajustar conforme a demanda prevista da suposta fila. O próprio spring controlara o pooling em caso de ociosidade e ou aumento de demanda. Fácil de mais, que chega a ser sem graça 😉 !

2.Persistência de Mensagens

Uma solução MOM profissional que se preze deve persistir as mensagens em banco de dados para que em caso de downtime, exista 100% de segurança e garantia de entrega de mensagens na volta do serviço. Como estamos trabalhando com soluções java standalone, a opção é persistir a fila no mesmo banco de dados da própria solução. Graças a integração plena entre Spring e o ActiveMQ, temos  como configurar o MOM para gravar as mensagens no mesmo DataSource no qual a solução Spring esta pendurada. Para ativar esse serviço, é necessario setar propriedade persistent como true na definição do broker local, configurar um bean adaptador de persistência que liga o MOM no DataSource do Spring. Segue abaixo um exemplo:

1

Acima temos o primeiro bean spring de DataSource básico utilizada na solução. Logo após temos o segundo bean de adapter que a faz a ligação da persistência do ActiveMQ  para um banco de dados definido pelo DataSource. Esse é o segredo ai da integração do MOM com o Spring. E por fim, temos o ultimo bean do broker que se integra ao adptador de banco de dados. Interessante pontuar a propriedade createTablesOnStartup que fara o adaptador gerar os scripts de banco de dado do MOM de forma automático na start do contexto do spring. Quando os produtos trabalham em conjunto, tudo fica mais fácil!

3.Fila Transacional

As mensagens agora sendo gravadas dentro de um banco de dados, muda totalmente de figura a questão de consistência. A solução precisa então integrar seu contexto transacional com o MOM, de forma a garantir que em caso de “commit” ou “rooback” de processos, as mensagens e o consumo da fila sejam também “comitadas” ou “descartadas” seguindo o fluxo global. Para ativar esse serviço, o spring oferece o já conhecido JmsTransactionManager que gerencia a integração de transações para MOM. Segue o exemplo abaixo:

1

Acima temos o primeiro bean que ativa o broker já passado no primeiro post do artigo, tendo o segundo bean o foco da questão que é o que ativa a transação para o serviço de JMS. Importante pontuar: como a persistência do MOM já esta sendo configurada para o usar o DataSource da solução, assim sendo, o bean spring que controla a transação dessa solução, também estará automaticamente configurado para controlar a transação das operações do MOM no banco de dados configurado pelo DataSource. Este bean gerenciador da transação eu deixei de fora, podendo ser qualquer um dos vários tipos existente no spring.

4.Politica de Retry

E para fechar com chave de ouro, devemos também configurar qual sera a politica de retry em caso de falhas de consumo de fila. Ou seja, caso ocorra exceptions na processamento da fila, o que seu MOM deve fazer? Basicamente é criar uma politica de retentivas e ou até descarte da mensagem. Para ativar esse serviço configure um bean RedeliveryPolicy que declara qual sera o comportamento para a tal fila. Segue o exemplo abaixo:

1

Acima temos o bean definindo a seguinte politica: caso ocorrer erro de processamento da fila, aguarde 10 segundos e tente novamente. Em caso de erros, continue tentado de 1 em 1 minutos. O maximumRedeliveries -1 indica que é para fazer retry de forma infinita até processar com sucesso. Você poderia usar numero 3, indicando que se deseja tentar no máximo 3 x e depois deletar a mensagem. Veja na imagem do item 3, a configuração da connectionFactory que recebe a politica da fila.

Conclusão Final

E assim, com mais 5 minutos, e mais algumas poucas linhas de configuração spring, você consegue ativar os serviços de pooling, persistência, transação e politicas de retry, deixando sua solução Java + ActiveMQ + Spring JMS 100% profissional para suportar contextos de integrações de alta qualidade, performance e segurança.

Aonde eu uso isso?

Precisou integrar sua solução java com e-mail?, web services soap? web services rest?, banco de dados legados? ou quer gerar um relatório pesado assíncrono? Esta ai seu ponto de partido. ActiveMQ + Spring JMS = Solução simples e rápida com todos os sabores de processamento assíncrono usando filas e tópicos 100% MOM.

Como eu aprendo mais sobre esse assunto?

Tudo isso e muito mais pode ser encontrado no livro ActiveMQ in Action. Excelente livro sobre conceitos de mensageria, JMS e integrações em geral. Boa leitura para todos 😉 .

“Meus queridos amigos, todas essas promessas são para nós. Por isso purifiquemos a nós mesmos de tudo o que torna impuro o nosso corpo e a nossa alma. E, temendo a Deus, vivamos uma vida completamente dedicada a ele.” 2 Coríntios 7:1