Arquiteto

Padrões de Transações Java com Spring Framework

Postado em Atualizado em

Uma transação é uma seqüência de ações que são tratadas como uma única unidade de trabalho. Essas ações devem ser completas ou não terem nenhum efeito. O gerenciamento de transações é uma parte importante no desenvolvimento de soluções corporativas, sendo que é que deve garantir a integridade e consistência dos dados  nas operações. Existem 2 tipos de transações:  Locais e Globais.

Transações locais versus globais

As transações locais são específicas para um único recurso transacional, enquanto as transações globais podem abrangem vários recursos transacionais distribuídos.

O gerenciamento local de transações pode ser útil em um ambiente de computação centralizado, onde os componentes e recursos do aplicativo estão localizados em um único lugar, e o gerenciamento de transações envolve apenas um gerenciador de dados local executado em uma única máquina. As transações locais são as mais fáceis de implementar.

O gerenciamento de transações globais é necessário em um ambiente de computação distribuído, onde todos os recursos são distribuídos em vários sistemas. Nesse caso, o gerenciamento de transações precisa ser feito tanto a nível local como global. Uma transação distribuída é executada em vários sistemas, e sua execução requer coordenação entre o sistema global de gerenciamento de transações e todos os gerenciadores de dados locais de todos os sistemas envolvidos.

Spring Framework

Spring Framework fornece toda infraestrutura necessária para se gerenciar transações locais, globais e variações das mesmas. Ou seja, você não precisa perder seu tempo fazendo isso, já esta pronto e disponível através de vários projetos do ecossistema spring. É muito importante que um arquiteto de software Java conheça essas opções e tipos de transações, tendo base para a tomada de decisão diária aí em seus projetos. Segue abaixo um resumo básico das opções em formato de patterns do qual eu venho usando no meu dia dia:

1)Single Transaction RDBMS Pattern

Usado para gerenciar transação local com um único banco de dados, usando um único tipo de serviço e uma simples tecnologia.
Exemplo: solução java persiste dados no MySQL usando uma unica tecnologia JPA.
Spring fornece 3 produtos para resolver tal necessidade:

  1. Spring oferece gerenciador de transação automático para banco de dados relacional: TransactionManager.
  2. Spring oferece gerenciador de transação para as framework e tecnologias de persistência mais usada da plataforma Java: JDBC, IBatis, Hibernate e JPA.
  3. Spring oferece AOP baseado em anotação para gerenciando de demarcação de transação automática e recursiva: @Transaction.

2)Shared Transaction RDBMS Pattern

Usado para gerenciar transação local com um único recurso, usando múltiplos tipos de serviço e tecnologias.
Exemplo: solução java persiste dados no MySQL usando diferentes tecnologias: JDBC e JPA.
Spring fornece 1 produto para resolver tal necessidade:

  • Spring oferece um gerenciador de transação automático que une em um unica transação múltiplos tipos de tecnologias.

Exemplo: Configurar JpaTransactionManager + HibernateJpaDialect compartilhas as conexões e transações da solução usando tecnologia JPA com JDBC simultaneamente.

3)Single Transaction RDBMS + MOM Pattern

Usado para gerenciar transação local com um banco de dados e um MOM, no qual os dados da solução e a persistência das mensagens do MOM fiquem dentro do mesmo banco de dados. Para que isso funcione, o provedor de MOM precisa ter uma arquitetura flexível para fazer a configuração da estratégia de persistência de mensagens dentro do mesmo banco de dados da solução.
Exemplo: solução java persiste dados no MySQL e usa ActiveQQ persistindo as filas/tópicos dentro da mesa base.
Spring fornece 1 produto para resolver tal necessidade:

  • Spring oferece recurso para setar o mesmo gerenciador de transação da camada de persistência da solução sincronizada com persistência das mensagens enviadas para o MOM.

Exemplo: Configurar org.apache.activemq.store.jdbc.JDBCPersistenceAdapter + com.springsource.open.jms.JmsTransactionAwareDataSourceProxy, faz com que as transações da camada da solução fiquem integradas com as persistencia das filas/tópicos do Apache ActiveMQ.

4)Multiples Transations XA/2PC Pattern:

Usado para coordenar um única transação global de múltiplos recursos diferentes como SGBD’s e MOM’s, remotos e distribuídos. Todos independentes e de marcas diferentes. Para que isso funcione, todos os recursos devem aderir ao contrato do proto copo de transação de banco de dados XA/2PC e a especificação java JTA.
Exemplo: solução java persiste dados em um Oracle, em um SQLServer e usa ActiveMQ persistindo as filas/tópicos em banco de dados MySql.
Spring fornece 3 produtos para resolver tal necessidade:

  1. Spring oferece o contrato do gerenciador de transação automático baseado em JTA: JtaTransactionManager, mas não oferece implementação desse serviço.
  2. Alguns provedores de JTA já tem implementações que pode ser usadas no Spring. Exemplos: Atomikos e Bitronix.
  3. Spring oferece um componente integrador com container FULL JEE. O próprio container possui implementação própria de XA/2PC e JTA, fazendo com que o spring use esse implementação para gerenciar as transações de seus beans.

Prós:
– 100% de garantia de confiabilidade de transação ACID.
– Garante 100% rooback e commit, mesmo com falhas de infraestrutura: travamento, crash, falta de energia, falha de HD, queda de rede e etc
– Usa protocolo XA/2PC e chamadas remotas para garantir a transação.

Contras:
– Todos os recursos precisam implementar XA/2PC.
– Todos os recursos precisam estar configurados para rodar com XA/2PC
– Adquirir um provedor de JTA para XA/2PC open ou paga.
– Reduz tempo de resposta com I/O no protocolo 2PC, sendo que a transação é gerenciada de forma distribuída.
– Reduz escalabilidade com I/O no protocolo 2PC, sendo que a transação é gerenciada de forma distribuída

5)Multiples Transations NON XA/2PC Pattern (Best Efforts 1PC):

Usado para coordenar um única transação local múltiplos recursos diferentes como SGBD’s e MOM’s, remotos e distribuídos. Todos independentes e de marcas diferentes. Use essa opção quando por algum motivo, não seja possível utilizar protocolo XA/2PC.
Exemplo: solução java persiste dados em um Oracle, em um SQLServer e por alguma motivo não é possível configurar e usar XA/2PC.

  • Spring fornece uma implementação de um gerenciador de transação chamado de ChainedTransactionManager que implementa esse padrão.

Prós:
– Não usa protocolo XA/2PC.
– É um pattern que “emula” um suposto XA/2PC.
– Melhora no tempo de resposta com menos I/O, uma vez que não existe XA/2PC e nem transação distribuída.
– Melhora na escalabilidade com menos I/O, uma vez que não existe XA/2PC e nem transação distribuída.

Contras:
– Não garante 100% de confiabilidade de transação ACID. Nessa opção, os envolvidos deve ficar ciente desse fato.
– Inconsistências acontecem em casos de falhas de infraestrutura: travamento, crash, falta de energia, falha de HD, queda de rede e etc, dependendo da sequencia do determinado recurso, pode gerar inconsistências, causando comit em 1 recurso e rooback em outro.

Observação:
– As falhas podem ser minimizadas a quase 0%, em caso em que customização adequada na sequencia da configuração da orquestração das transações e investimento melhor de intra que minime falhar infraestruturais nos recursos envolvidos.
– Em certos casos, algumas empresas abrem mão do protocolo XA/2px e aderem a essa estratégia, afirmando que mesmo em casos raros de falhas, o custo da falha seria bem menor que bancar a implementação total do XA/2px.
– Em certos casos, algumas empresas abrem mão do protocolo XA/2px e aderem a essa estratégia, afirmando que é mais barato implementar algum mecanismos dentro da própria solução para identificar e contornar as possíveis inconsistências que bancar a implementação total do XA/2px.

“Este é o dia da vitória de Deus, o SENHOR; que seja para nós um dia de felicidade e alegria!” Salmos 118:24

Características de um Arquiteto de Software

Postado em Atualizado em

Quais são as características básicas que um bom arquiteto de software atualmente deve possuir? Resumidamente, temos 6 itens primordiais:

  • Agir como Líder
  • Ser um desenvolvedor
  • Ter o foco na solução
  • Pensar como um empreendedor
  • Balancear estratégica com pensamento tático
  • Se Comunicar  bem

Agindo como Líder

Os bons arquitetos de software entendem que seu papel como líder não é necessariamente dizer aos desenvolvedores o que fazer. Em vez disso, bons arquitetos agem como um guia, orientando uma equipe de desenvolvedores para a mesma visão técnica baseando-se em habilidades de liderança como contar histórias, influenciar, resolver conflitos, ensinar e construir a confiança com os indivíduos para transformar sua visão arquitetônica em realidade. Um bom líder e, portanto, um bom arquiteto, escutará atentamente as opiniões de cada colaborador, ajustando sua visão com o feedback da equipe. Isso leva bem para o próximo ponto

Ser 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.

Ter 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

Pensando como um empreendedor

Todas as escolhas de tecnologia têm custos e benefícios, e um bom arquiteto vai considerar novas opções de tecnologia de ambas as perspectivas. Os empreendedores bem-sucedidos estão dispostos a assumir riscos, mas buscam maneiras de aprender rapidamente e fracassar rapidamente. Arquitetos podem abordar as escolhas de tecnologia de forma semelhante, buscando informações do mundo real sobre os custos de curto e longo prazo e os prováveis ​​benefícios que eles vão perceber. Um bom exemplo é quando o arquiteto evita comprometer-se com uma nova ferramenta baseada na leitura de um novo artigo, ou ter ouvido falar dele em uma conferência. Em vez disso, eles procuram entender como a ferramenta é relevante em seu ambiente, coletando mais informações. Eles não escolhem uma ferramenta baseada em quão bom a toa, mas que valor oferece, dado o que eles precisam para o seu sistema.

Balanceamento estratégico com pensamento tático

Muitas equipes constroem seu software de forma reativa com desenvolvedores individuais que escolhem ferramentas e tecnologias com as quais se sentem mais confortáveis ou com mais experiência.  O bom arquiteto mantém um olho fora da caixa, alem da zona de conforto para que novas tecnologias, ferramentas ou abordagens que possam ser úteis, mas não necessariamente imediatamente. A adoção da tecnologia requer uma abordagem que considere um horizonte de longo prazo. Os arquitetos procurarão um bom equilíbrio entre a agilidade, permitindo que a equipe se mova rapidamente e o alinhamento, mantendo a consistência suficiente, tanto no nível organizacional como em equipe.

Comunicando bem

Arquitetos sabem que a comunicação eficaz é uma habilidade fundamental para a construção de confiança e influenciar as pessoas fora da equipe. Eles sabem que diferentes grupos de pessoas usam vocabulário diferente e que usar os termos técnicos e descrições com os empresários torna a comunicação mais difícil. Em vez de falar sobre padrões, ferramentas e conceitos de programação, o arquiteto usa palavras com as quais seu público estará familiarizado. Comunicar opções técnicas aos empresários com palavras como risco, retorno, custos e benefícios servirá melhor a um arquiteto do que as palavras que eles usam com sua equipe de desenvolvimento. Um arquiteto também percebe que a comunicação dentro da equipe é tão importante quanto fora e usará diagramas e discussões em grupo para estabelecer e refinar a visão técnica e usar um registro escrito como um registro de decisão arquitetônico ou um wiki para fornecer uma trilha histórica para gerações futuras.

Vamos praticar? Vem comigo!

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

Características de um Arquiteto de Software #7

Postado em Atualizado em

Comunicando bem

Arquitetos sabem que a comunicação eficaz é uma habilidade fundamental para a construção de confiança e influenciar as pessoas fora da equipe. Eles sabem que diferentes grupos de pessoas usam vocabulário diferente e que usar os termos técnicos e descrições com os empresários torna a comunicação mais difícil. Em vez de falar sobre padrões, ferramentas e conceitos de programação, o arquiteto usa palavras com as quais seu público estará familiarizado. Comunicar opções técnicas aos empresários com palavras como risco, retorno, custos e benefícios servirá melhor a um arquiteto do que as palavras que eles usam com sua equipe de desenvolvimento. Um arquiteto também percebe que a comunicação dentro da equipe é tão importante quanto fora e usará diagramas e discussões em grupo para estabelecer e refinar a visão técnica e usar um registro escrito como um registro de decisão arquitetônico ou um wiki para fornecer uma trilha histórica para gerações futuras.

“A fé é a certeza de que vamos receber as coisas que esperamos e a prova de que existem coisas que não podemos ver.” Hebreus 11:1

Características de um Arquiteto de Software #6

Postado em Atualizado em

Balanceamento estratégico com pensamento tático

Muitas equipes constroem seu software de forma reativa com desenvolvedores individuais que escolhem ferramentas e tecnologias com as quais se sentem mais confortáveis ou com mais experiência.  O bom arquiteto mantém um olho fora da caixa, alem da zona de conforto para que novas tecnologias, ferramentas ou abordagens que possam ser úteis, mas não necessariamente imediatamente. A adoção da tecnologia requer uma abordagem que considere um horizonte de longo prazo. Os arquitetos procurarão um bom equilíbrio entre a agilidade, permitindo que a equipe se mova rapidamente e o alinhamento, mantendo a consistência suficiente, tanto no nível organizacional como em equipe. Para qualquer dúvidas, veja o post inicial dessa série.

“De tudo o que foi dito, a conclusão é esta: tema a Deus e obedeça aos seus mandamentos porque foi para isso que fomos criados.” Eclesiastes 12:13

Arquiteto de software? O que estudar?

Postado em Atualizado em

Já recebi muita essa pergunta nos fóruns, emails e cursos, hoje gostaria de separar um tempo e falar sobre. Aperte o cintos e vamos nessa. Objetivo de um arquiteto de software é projetar soluções. O que podemos fazer para aprender isso?  Participar de projetos reais, “colar” no arquiteto responsável da corporação, aprendendo com ele os contextos ai do dia a dia e suas decisões de design. E se eu não tiver acesso a um? Sem problemas, temos livros fantásticos no mercado que registram e documentam experiencias e contextos de projeto reais de software. Mesmo se tivesse acesso a um, seria necessario complementar o seu conhecimento, estudando os mesmos livros, potencializando seu know-how e experiências. Sendo assim, segue abaixo um lista completa e devidamente sequencial de livros que vão te encaminhar para a profissão de arquiteto de software:

1. Patterns of Enterprise Application Architecture – Autor Martin Fowler

Esse livro é o mais fundamental de todos, tratando ai de padrões, contexto e soluções básicas pontuadas na camada de visão, negócio e persistência. Esse seria o livro que todos deveriam começar. Quantas camadas eu devo fazer? Sessão de usuário, você persiste no cliente? No server? Ou no bando de dados? Regra negocio, procedural ou orientado a objetos? Persistência de dados? SQL ou ORM? Estes são alguns de muitos dos exemplos de coisas básicas respondidas nesse livro. Existe uma versão em português.

2. Domain-Driven Design: Tackling Complexity in the Heart of Software , autor Eric Evans

Ele oferece aos leitores uma abordagem sistemática com relação a como desenvolver uma solução completa usando realmente OOP, 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. Existe uma versão em português.

3. Enterprise Integration Patterns: Designing, Building, and Deploying Messaging Solutions – Autores Gregor Hohpe e Bobby Woolf.

Ao projetar uma solução, o arquiteto tem hoje uma outra dificuldade muito básica, integrar a nova solução com outras existentes, ou legadas e ou de parceiros de negócio. Dificilmente projetaremos um novo produto para funcionar sozinho de forma isolada. Nesse livro, teremos os cenários mais clássicos de integração, opções, prós e contras e muitas informações. Para ligar uma solução na outra, uso banco de dados? Arquivo? Web Services? Mensageria? Qual é melhor? Qual é mais cara?  Mais demorara? Nele você encontrara todas essas informações já mastigada e comprovada na prática. Outro motivo para ler esse livro é que ele se aprofunda especificamente no padrões de integração relacionado ao uso de servidores de mensageria. Não temos versão em português. Já fique sabendo que, sem inglês, como arquiteto, não da para chegar tão longe.

4. Service Design Patterns: Fundamental Design Solutions for SOAP/WSDL and RESTful Web Services, Autor Robert Daigneau

O uso de web services hoje tem sido um pilar fundamental para fazer integração de soluções, fazendo com os estilo SOAP e REST tenham seus próprios contextos, padrões, casos e soluções individualizadas. Nesse livro, você encontrará todos esses casos, padrões, e experiências relacionados com o uso efetivo de cada estilo de web services SOAP e REST. Não tem versão em português.

5. Building Microservices, Designing Fine-Grained Systems, Autor Sam Newman

O novo dilema de um arquiteto de software, na hora de projetar um solução é manter o uso de tipo de projeto monolítico ou usar o novo tipo de projeto conhecido com microservices. Nesse livro, você encontrara todas a informações necessárias para aprender oque é microservices, quando e se deve usar no seu projeto. Não tem versão em português.

5. Microservice Patterns, Autor Chris Richardson

Se o arquiteto decidir em usa o estilo de projeto microservices, muitos problemas surgiram na aplicação da filosofia. Como coordenar transação em projetos separados? Devo usa um banco de dados por serviço ou um para todos. Esse livro, que não esta pronto, trata contextos, padrões e experiencia relacionado o uso cotidiano de microservices. Até lá, consulte o site oficial do autor, que contem um boa documentação previa do assunto.

Conclusão

Bom pessoal, vou encerrar por aqui. Acredito que já temos livros ai para um “booooommmm” tempo de estudo, estou nessa jornada há um bom tempo, quase terminado todos eles. Te convido a entrar nessa jornada comigo. Vamos nessa? Precisando de ajuda, estou a disposição. Até a próxima!

“Por isso, não fiquem preocupados com o dia de amanhã, pois o dia de amanhã trará as suas próprias preocupações. Para cada dia bastam as suas próprias dificuldades.” Mateus 6:34

Características de um Arquiteto de Software #5

Postado em Atualizado em

Pensando como um empreendedor

Todas as escolhas de tecnologia têm custos e benefícios, e um bom arquiteto vai considerar novas opções de tecnologia de ambas as perspectivas. Os empreendedores bem-sucedidos estão dispostos a assumir riscos, mas buscam maneiras de aprender rapidamente e fracassar rapidamente. Arquitetos podem abordar as escolhas de tecnologia de forma semelhante, buscando informações do mundo real sobre os custos de curto e longo prazo e os prováveis ​​benefícios que eles vão perceber. Um bom exemplo é quando o arquiteto evita comprometer-se com uma nova ferramenta baseada na leitura de um novo artigo, ou ter ouvido falar dele em uma conferência. Em vez disso, eles procuram entender como a ferramenta é relevante em seu ambiente, coletando mais informações. Eles não escolhem uma ferramenta baseada em quão bom a toa, mas que valor oferece, dado o que eles precisam para o seu sistema. Para qualquer dúvidas, veja o post inicial dessa série.

“Estejam sempre alegres, orem sempre e sejam agradecidos a Deus em todas as ocasiões.”1 Tessalonicenses 5:16

Otimizando Chamadas Rest

Postado em Atualizado em

Hoje eu gostaria de compartilhar uma estratégia de chamadas Rest que tenho aplicado com muito sucesso nos últimos projetos. Imagine que você tenha um projeto que necessite consumir diferentes web services rest, na operação do usuário final. Quero dizer que, por exemplo: no click de 1 botão na interface visual, esse projeto precise consumir 3 operações de web services rest para fazer concluir a operação. Supondo que, cada web services demora ai 10 segundos, resultaria na tempo total de 30 segundos para essa operação. Vejamos o exemplo abaixo que simula o caso:

Emulamos uma suposta interface que defini o contrato do web service rest:

Emulamos 3 chamadas remotas que demorem 10 segundos de tempo cada uma:

Finalmente, temos a chamada dos 3 web services:

Conclusão:

Como estamos usando a estratégia de chamada sequencial, logo, a operação levará exatamente 30 segundos para ser completamente efetuada.

Existe alguma forma de melhorar esse tempo de resposta? É claro que sim, usando a estratégia de chamada paralelas.

Segue abaixo como ficaria o mesmo exemplo, usando a estratégia paralela. Mantemos a emulação da interface que defini o contrato do web service rest:

Mantemos as 3 chamadas remotas que demorem 10 segundos de tempo cada uma:

Agora iremos usar o framework java.util.concurrent do JSE para fazer chamadas em paralelo.

1)Precisaremos empacotar as chamadas rest em um Callable:

2)Precisaremos criar um pool de thread para executar as operações ao mesmo tempo:

3)E finalmente, precisaremos fazer a chamadas remotas usando um Future para disparar as chamadas em paralelo:

Conclusão Final:

Como temos as 3 operações sendo executadas em paralelo, obviamente teremos um tempo de 10 segundos para ser completamente efetuada. Ou seja, vale muito a pena!

Github

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

“As pessoas fazem muitos planos, mas quem decide é Deus, o SENHOR.” Provérbios 19:21