Arquiteto

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

Características de um Arquiteto de Software #3

Postado em

wellroundedarchitect-1024x574-1Ser um Desenvolvedor

Fazer boas escolhas arquiteturais consiste basicamente na responsabilidade de equilibrar um ideal arquitetônico conceitual com o estado real de um sistema de software. Por exemplo, não há sentido em optar por um banco de dados de documentos a um sistema se o domínio do problema é mais adequado para um banco de dados relacional, mesmo que seja chato. Um arquiteto pode se sentir tentado a impor tecnologias ou escolhas arquitetônicas sem considerar o fundamento do problema. A melhor maneira de um arquiteto mitigar isso é gastando tempo com desenvolvedores e tempo no código. Entender como o sistema foi construído, e suas restrições, dará ao arquiteto mais informações sobre as escolhas certas para o ambiente. Para qualquer dúvidas, veja o post inicial dessa série.

“Mas o Senhor Jesus é fiel. Ele lhes dará forças e os livrará do Maligno.”2 Tessalonicenses 3:3

Não fique amarrado com o Spring

Postado em Atualizado em

homem-de-negcios-amarrado-na-corda-2431821Eu praticamente faço tudo com Spring Framework. Ele simplesmente é o camisa 10 de todos os meus projetos nesses últimos 10 anos. Mas eu também não nego o benefício de usar um produto Java baseado em especificação. Quando você inicia sua carreira em java, não da muita bola para as especificações, até ter a experiência de migrar, trocar e/ou alterar uma solução e ver as consequências de usar uma especificação. A ficha caiu para mim quando migrei soluções de décadas usando banco de dados relacionais com JDBC e um outro com JPA. Demorei simplesmente algumas fáceis horas enquanto outras produtos de outras plataformas dentro da  mesma empresa, precisaram de 9 meses para fazer o mesmo. Migrei vários provedores de JSF em soluções web alguns bons anos também com muita facilidade e segurança. Tive outros exemplos legais também, que vou deixar para uma próxima.

O Spring é um produto proprietário e sendo assim você inevitavelmente acaba ficando amarrado com ele, sua versão e seus pacotes. Por exemplo: Se você use o modulo de IoC, vai acabar usando o import da anotação org.springframework.stereotype.Component. Quando essa anotação mudar de pacote, for substituída por uma outra ou você migrar de provedor de IoC, já era seu projeto! Quebra tudo e perde portabilidade.

“Seria possível usar o Spring e não ficar amarrado com ele?”

Sim, existem varias formas diferentes de fazer isso. Hoje quero dar 3 dicas que tenho usado nos últimos anos para reduzir a dependência e amarração para o framework Spring.

1. Não use anotações proprietários de IoC

O modulo de IoC do spring funciona perfeitamente com a especificação CDI. Assim, você pode parar de usar anotações proprietárias @Component, @Controler, @Repository, @Service, @Autowire e etc. Ao invés disso, use especificação CDI @Named, @Inject e @Resource. É claro que iremos perder os tratamentos de exceptions automáticas existente nas anotações spring e outros detalhes, mas você acaba retirando dependência desses pacotes de seu projeto. A maioria dos projetos tem tratamento de erros customizados e não dependente desses serviços. Então, analise e veja o que vale mais a pena. Segue abaixo alguns links sobre o assunto:

  1. https://www.mkyong.com/spring3/spring-3-and-jsr-330-inject-and-named-example/
  2. https://mobiarch.wordpress.com/2013/01/11/spring-di-and-cdi-comparative-study/

2. Não use anotações proprietários de escopo web

Quando você integra um JSF com container IoC do spring, é obrigado a usar as anotações de escopo proprietária para declarar ciclo de vida do seus managed beans. Você também não precisa usar elas. Nas ultimas versões do spring saiu um recurso muito bacana chamado de Meta Anotations Support. Resumidamente, é ato de criar suas próprias anotações customizadas reusando e/ou evitando DRY de anotações spring dentro de seus beans. Usando esse recurso, você poderia criar suas próprias anotações de escopo, evitando espalhar repetidamente o import de pacotes proprietários do spring dentro de seus projetos. Segue abaixo um exemplo meu:

sem-titulo

Assim, nos seus managed beans, você evita o import dos org.springframework.context.annotations.Scope, usando então sua própria anotação. Veja um exemplo de managed bean:

sem-titulo2

3. Não use anotações proprietários de transação

Uma das coisas que eu acredito ser mais utilizadas do modulo de transação do spring é a facilidade e a simplicidade da anotação @Transaction do pacote org.springframework.transaction.annotation. Com ela, o spring aplica AOP recursiva em suas transações de modo fácil e rápido. O que você não parou para pensar é que o seu domain model (DDD) acaba importando esse pacote proprietário em um bilhão de classes, ficando totalmente amarrado com o spring no uso desse serviço, furando o conceito mais básico e clássico DDD de um projeto que é a independência de produto, serviço ou framework. Pare de fazer isso! Aplique o mesmo caso do item 2 acima. Crie sua anotação de transação customizada e reuse no seu DDD. Segue um exemplo:

sem-titulo3

Assim, nos seus beans transacionais, você evita o import dos org.springframework.transaction.annotationusando então sua própria anotação. Veja um exemplo:

sem-titulo4

Com essas três dicas simples, você elimina a maioria dos imports proprietários do spring framework para dentro do seu projeto, deixando seu código independente, mais flexível e limpo. Você continua usando o melhor e maior framework java da história, e consegue manter as camadas do seu projeto independente de serviço e detalhes infraestruturais! Até a próxima pessoal 😉

“Para ser sábio, é preciso primeiro temer a Deus, o SENHOR. Os tolos desprezam a sabedoria e não querem aprender.” Provérbios 1:7

Mensageria 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. Boa leitura para todos 😉 .

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

Arquitetura DDD Desmistificado

Postado em

sem-titulo

Nesse belíssimo artigo sobre DDD, Lorenzo Dee desmistificou vários segredos a respeito de DDD que na maioria das vezes ficam nas “entrelinhas” escondidos nos livros. Você gostaria de aprender a como criar uma arquiteturas dessas? Veja no curso de Arquitetura de Software AQT M1. Bons estudos 😉 !

Tu és grande e poderoso, glorioso, esplêndido e majestoso. Tudo o que existe no céu e na terra pertence a ti;1 Crônicas 29:11