Microservices

O que são microservices?

O Microservices, também conhecido como arquitetura de microserviços -é um estilo arquitetônico que estrutura uma solução como uma coleção de serviços ligeiramente acoplados, que implementam capacidades empresariais. A arquitetura microservice permite a entrega e a implantação contínua de aplicativos grandes e complexos. Ele também permite que uma organização evolua sua pilha de tecnologia.

Microservices não são bala de prata

A arquitetura microservice não é uma bala de prata. Tem várias desvantagens, complexidades e problemas. Além disso, ao usar essa arquitetura, emergem inúmeros problemas que você deve resolver. Aplicar microservices no lugar errado, gera mais problemas que melhorias. Além disso, é necessário uma mudança de paradigmas para definir e criar microservices, sendo que não é simplesmente quebrar uma grande soluções em pedaços menores.

Onde começar?

Um bom ponto de partida é o padrão de arquitetura monolítica, que é o estilo arquitetônico tradicional que ainda é uma boa escolha para muitas aplicações. No entanto, tem inúmeras limitações e problemas e, portanto, uma escolha melhor para aplicações grandes / complexas é o padrão de arquitetura do Microservice.

“Deem graças ao SENHOR porque ele é bom, e o seu amor dura para sempre.”1 Crônicas 16:34

Anúncios

Aprendendo a usar o escopo Thread-Local Java

Dentro da programação de uma solução usando a tecnologia Java, os desenvolvedores tem a responsabilidade diária de escolher corretamente em qual escopo de ciclo de vida seus objetos existiram. Em minhas consultorias em geral venho percebendo que a maioria dos profissionais Java desconhecem completamente um dos escopos mais interessantes e muito eficiente chamado de Thread-Local. A falta de uso desse escopo em uma solução pode gerar complicadores agravantes na arquitetura, levando a implementação na maioria das vezes para o caminho da complexidade e inflexibilidade. Diante esse cenário, hoje eu gostaria de apresentar o conceito e prática desse escopo, fazendo com que programadores e projetistas Java possam se equipar com mais esse poderoso recurso do JSE.

O que é Thread-Local?

Thread-local é considerado como mais um “escopo de acesso” como outros muitos existentes dentro do Java utilizado para definir o ciclo de vida dos objetos existentes durante a execução de um programa orientado a objetos. O grande diferencial desse escopo seja talvez pelo fato dele ser completamente baseado em conceitos de programação concorrente, fazendo com ele fique um pouco mais complicado de se entender e usar.

Como funciona?

O escopo Thread-Local possui dois tipos de comportamento distintos que lhe diferencia drasticamente dos outros. Poderíamos chamá-los de global e local.

  • Global – todos os objetos armazenados em uma Thread-Local são globais para a thread corrente de execução. Isso que dizer que os métodos de quaisquer objetos sendo executados dentro de uma mesma thread terão visibilidade para este escopo.
  • Local – todos os objetos armazenados em uma Thread-Local estarão restritos somente para objetos sendo executado dentro da determinada thread. Isso que dizer que os métodos de quaisquer objetos sendo executados em outras threads não terão visibilidade para este escopo.

O ponto de referencia para se assimilar a brincadeira é se conscientizar que quem executa um método de um objeto dentro de um programa Java é justamente algum objeto Thread, sendo ele criando manualmente ou não. Dentro de cada thread existe então um lugar especial que pode ser usado para armazenar objetos pertencentes especificamente a thread. Todos as chamadas de objetos que forem empilhados naquela thread terão visibilidade transparente para esse escopo, podendo então usa-lo para os mais diferentes propósitos.

Para tentar clarear mais as idéias, eu poderia dizer que o escopo Thread-Local funciona basicamente da mesma forma que o famoso e velho de guerra escopo estático. Todos os objetos colocados como estáticos no Java são criados apenas uma vez e ficam na memória até o termino da JVM. A única diferença é que os objetos colocados na Thread-Local ficam na memória até o termino da execução da determinada thread corrente. O escopo acaba, quando a Thread terminar de ser executada.

A figura abaixo apresenta um gráfico que ilustra a escopo estático:

Temos na figura acima dois objetos do tipo thread invocando concorrentemente métodos de alguns objetos compartilhados e outros objetos não compartilhados. Tudo que é colocado como estático é globalmente compartilhado para todas as threads e todos os objetos sendo executados dentro de cada thread.

Já na próxima figura temos a representação que ilustra o escopo Thread-Local:

Temos na ultima figura dois objetos do tipo thread invocando concorrentemente os mesmo objetos da primeira figura. Nesse caso em especifico, o escopo Thread-Local age como um compartimento opcional colocado dentro da cada thread, no qual todos os métodos invocados dentro daquela determinada thread tem acesso transparente, podendo usá-lo para qualquer fim necessário.

Quando usar Thread-Local

Use em qualquer lugar que necessite compartilhar objetos em nível de execução de Thread. Alguns possíveis exemplos seriam – parâmetros de sistema, parâmetros de usuários, parâmetros de autenticação e autorização e até parâmetros de processos. Um caso clássico de Thread-Local é a propagação de objetos de transação JDBC com chamadas recursivas. Objetos do padrão DAO poderiam usar este escopo para compartilhar a transação corrente, adicionando varias instruções SQL de diferentes objetos DAO. Frameworks que oferecem serviços transacionais para camadas de persistência como Spring utilizam-se dessa abordagem, podendo também ser facilmente implementada sem nenhum framework de terceiro.

A escopo Thread-Local é disponibilizado no Java usando a classe java.lang.ThreadLocal. Para todas as informações dessa classe, veja o JavaDoc.

Prática

Segue abaixo a implementação de um exemplo bem simples de Thread-Local.

A primeira classe chamada de ClasseThreadLocal foi utilizada para implementar a escopo Thread-Local. A segunda classe chamada de Regra foi utilizado para implementar o objeto que será executando concorrentemente dentro de varias threads. Veja que o método gravar() apenas acessa o valor dentro do escopo Thread-Local. Já a classe ProcessoThread  foi utilizado para implementar as threads que serão executadas em paralelo. Veja que o método run() armazena um objeto do tipo String dentro do escopo Thread-Local que será posteriormente acessível dentro do objeto implementado pela classe Regra. Por fim vemos a classe Exemplo implementando a método main() que faz toda a brincadeira acontecer. Veja que ele cria apenas um objeto Regra e quatro objeto ProcessoThread. Resumidamente, cada objeto thread executa concorrentemente o mesmo objeto Regra que transparentemente e separadamente acessa cada um valor diferente pertencente a sua própria thread de execução.

Observação

Existe uma certa situação em usar Thread-Local dentro de containers JEE, uma vez que a maioria deles otimizam gatos com a criação de objetos threads usando abordagem de pool. Por isso, os objetos colocados dentro do escopo Thread-Local em execuções dentro de containers JEE podem ficar não elegíveis para o GC após a execução, uma vez a thread volta para o pool e fica disponível para a próxima invocação. A forma correta de tratar isso é limpar o escopo Thread-Local no final de cada execução, chamando o método ThreadLocal.remove(). Eu fico por aqui e espero que o artigo te ajude a usar esse incrível escopo. Aquele abraço 😉 .

“Porque, se perdoardes aos homens as suas ofensas, também vosso Pai celestial vos perdoará a vós”. Mateus 6:14

Desenvolvimento Hype Driven

Você já trabalhou  com equipes que usam aquela metodologia de desenvolvimento infalível, o Desenvolvimento Orientado a Modinha? Você mesmo já usou (e/ou está usando) a mais nova tecnologia de software que aquela grande empresa lançou mês passado? Precisamos conversar sobre Hype Driven Development.

Equipes de desenvolvimento de software muitas vezes tomam decisões sobre arquitetura de software ou pilhas tecnológica com base em opiniões imprecisas, mídias sociais e, em geral, sobre o que é considerado “quente” (hype), em vez de sólida pesquisa e qualquer consideração séria do impacto esperado em seus projetos. Essa tendência pode ser chamada de Desenvolvimento Orientado a Modinha ou DOM —  originalmente, Hype Driven Development. Obviamente, existe uma abordagem mais profissional, chamada por alguns de Engenharia de Software Sólido (Solid Software Engineering). Saiba mais sobre como ele funciona e descubra o que você pode fazer em vez disso.

Nova tecnologia, nova esperança

Qual seu hype favorito?  🙂

Soa familiar? Uma equipe escolhendo tecnologia mais recente, mais “quente” para aplicar no projeto e alguém lê uma postagem em um blog, vê que é tendência no Twitter e todos acabaram de voltar de uma conferência onde houve uma grande conversa sobre isso. Logo a equipe começa a usar esta nova tecnologia brilhante — ou paradigma de arquitetura de software –, mas em vez de ir mais rápido (como prometido) e construir um produto melhor,  começa a se deparar com sérios problemas.

A velocidade de desenvolvimento diminui, todos ficam desmotivados, têm problemas para entregar a próxima versão do projeto para a produção. Algumas equipes ainda mantêm a correção de bugs em vez de fornecer novos recursos. São necessários “apenas mais alguns dias” para resolver tudo…

Desenvolvimento Orientado a Modinha ou Hype Driven Development

Desenvolvimento Orientado a Modinha (ou Hype Driven Development) vem em muitos sabores e toca seu projeto de muitas maneiras diferentes:

  • Desenvolvimento Orientado a Reddit. Quando uma equipe ou indivíduo decide sobre a tecnologia/arquitetura/design com base no blogueiro popular que escreveu o que está quente no Reddit, Hacker News, blog do Twitter, Facebook, GitHub ou outras mídias sociais.
  • Desenvolvimento Orientado a Conferência. Observe cuidadosamente o que acontece depois que pessoas (e programadores) retornam de uma conferência: elas ficam inspiradas. E isso é uma espada de dois gumes: começar a usar o mais novo paradigma/biblioteca/framework/arquitetura sem pesquisa suficiente pode ser uma estrada para o inferno.
  • Desenvolvimento Orientado ao Cara que Fala Mais. As decisões mais influentes são as do que está falando o tempo todo sobre esse novo framework/biblioteca/tecnologia que ele não tem experiência, mas fala sobre isso o tempo todo e finalmente a equipe decide adotar a coisa.
  • Desenvolvimento Orientado a Gem/lib/plugin. Um viés especialmente forte na comunidade Ruby On Rails, em que é possível ver um Gemfile por tanto tempo que a única coisa que leva mais tempo é para carregar o aplicativo. Vem da idéia de que cada problema em Rails deve ser resolvido através de um gem — sendo que, às vezes, apenas uma ou duas linhas de código dariam conta do recado ao invés de resolver o problema acrescentando mais problemas com libs, plugins, gems e/ou frameworks.
  • Desenvolvimento Orientado a Stack Overflow. Certamente uma das mais comuns de acontecer, dá-se quando programadores copiam e colam soluções do Stack Overflow (ou encontradas na web, em geral) sem realmente entendê-las.

A raiz de todo o mal?

O problema com hypes é que eles facilmente levam a más decisões. Tanto a decisões arquitetônicas ruins, quanto a decisões tecnológicas sobre stacks costumam assombrar uma equipe meses ou mesmo anos mais tarde. No pior caso, elas podem levar a outra situação muito problemática em engenharia de software: A Grande Reescrita (The Big Rewrite).

A raiz de todo o mal parece estar nas mídias sociais, nas quais novas idéias se espalham muito mais rápido do que são testadas; muito mais rápido do que as pessoas são capazes de compreender os seus prós e contras.

A anatomia de um hype

A maioria dos hypes têm uma estrutura similar a esta:

Ciclo do Hype

“Ciclo do Hype” (clique para ampliar)

Passo 1: Problema real e solução

Eles começam em alguma empresa com um problema. Uma equipe dentro de alguma empresa decide que a solução para o problema está além da pilha tecnológica atual, processo ou arquitetura. A empresa cria uma nova estrutura, biblioteca ou paradigma e logo o problema é resolvido.

Passo 2: Buzz & Keywords

A equipe está animada para mostrar seu trabalho para o resto do mundo e logo eles escrevem posts e fazem palestras e conferências. O problema muitas vezes não é trivial, então eles se orgulham de apresentar os resultados impressionantes de uma solução “da casa”. As pessoas ficam entusiasmadas com a nova tecnologia. O maior problema é que nem todos que ficam animados são capazes de compreender exatamente qual era o problema inicial e todos os detalhes da solução — afinal, tratava-se de um problema não-trivial com uma solução não-trivial.

Leva mais do que um tweet, bate-papo ou post no blog para explicar. Com ferramentas de comunicação como mídias sociais, artigos de blogs e conferências-relâmpago, ocorre muito ruído na comunicação e a mensagem fica “borrada” ao longo do caminho.

Passo 3: Obsessão

Toda força do hype leva desenvolvedores a lerem artigos e a participarem de conferências sobre a tecnologia. Logo as equipes de todo o mundo começam a usar a usá-la. Devido à mensagem “borrada”, algumas delas tomam decisões precipitadas de uso da tecnologia — mesmo que ela não resolva qualquer um de seus problemas reais. No entanto, a equipe tem expectativa de que esta nova tecnologia vai ajudar.

Meme dos desenvolvedores orientados a modinha

Passo 4: Desapontamento

Conforme os sprints passam, a tecnologia não melhora a vida da equipe tanto quanto as pessoas esperavam, mas traz muito trabalho extra. Há muita reescrita de código e aprendizagem extra para a equipe. As equipes diminuem a velocidade, a administração fica chateada. Todos se sentem enganados.

Passo 5: Realização

Finalmente, a equipe faz uma retrospecção e percebe quais são os prós e contras da nova tecnologia e para que finalidade ela seria mais relevante. Todos ficam mais sábios… Até o próximo hype aparecer.

Exemplos reais de hypes

É só pensarmos um pouquinho para lembrar de alguns exemplos reais do “Ciclo do Hype”, em ocasiões que trouxeram muitos infortúnios para muitas equipes de desenvolvimento pelo mundo.

React.js

  1. Problema real e solução. SPAs, como o próprio Facebook, têm tantos eventos de mudança de estado que é difícil manter o controle do que está acontecendo e manter o estado do aplicativo consistente.
  2. Buzz & Keywords. “Funcional”, “DOM Virtual”, “Componentes”.
  3. Obsessão. “Facebook criou a estrutura front-end do futuro! Vamos escrever tudo em React de agora em diante!”
  4. Desapontamento. Há muito trabalho, mas nenhum retorno rápido sobre o investimento.
  5. Realização. React é ótimo para SPAs avançados com muitas notificações em tempo real, mas não necessariamente vale a pena para aplicativos mais simples.

“TDD está morto”

  1. Problema real e solução. David Heinemeier Hansson (criador do framework Ruby on Rails) percebe que é difícil fazer TDD com Rails — já que ele não tem uma boa arquitetura, que comporta OOP — e faz uma escolha pragmática: não escrever mais testes antecipadamente; não trabalhar mais com TDD.
  2. Buzz & Keywords. O hype começa com um post no blog de DHH e uma conferência. Termo-chave do hype: “TDD está morto”.
  3. Obsessão. “Vamos pular os testes! Nosso Guru diz isso. Nós não escrevemos eles de qualquer maneira. Agora, pelo menos, não estamos fingindo. Finalmente somos honestos.”
  4. Desapontamento. Há muito trabalho, mas nenhum retorno rápido sobre o investimento.
  5. Realização. “TDD não está morto ou vivo. TDD está sujeito a tradeoffs, incluindo o risco de mudanças de API, habilidades dos participantes e design existente.” — Kent Beck.

Microservices

  1. Problema real e solução. Grandes aplicações monolítica têm escalonamento difícil. Há um ponto em que é possível dividí-las em serviços. Será mais fácil de escalar em termos de req/sec e mais fácil de escalar entre várias equipes.
  2. Buzz & Keywords. Palavras-chave do hype: “Escalabilidade”, “Baixo Acoplamento”, “Monolítico”.
  3. Obsessão. “Temos um ‘código de espaguete’ porque temos uma arquitetura monolítica! Precisamos reescrever tudo para microservices!”
  4. Desapontamento. Agora é mais lento desenvolver o aplicativo. E difícil de implantar e se passa muito tempo rastreando bugs em vários sistemas.
  5. Realização. Microservices exigem habilidadess “devops” na equipe. Antes de se chegar a graves questões de escalonamento, são um um investimento excessivo. Microservices são extraídos, não escritos.

NoSQL

  1. Problema real e solução. Bancos de Dados SQL têm problemas com cargas elevadas e dados não estruturados. Equipes de todo o mundo começam a desenvolver uma nova geração de BDs.
  2. Buzz & Keywords. Palavras-chave do hype: “Escalabilidade”, “BigData”, “Alta Performance”.
  3. Obsessão. “Nosso banco de dados é muito lento e não é grande o suficiente! Precisamos do NoSQL!”
  4. Desapontamento. “Precisamos usar JOIN nas tabelas? Isso é problemático”. Operações SQL simples se tornam cada vez mais desafiadoras. O desenvolvimento fica lento e os principais problemas não são resolvidos.
  5. Realização. NoSQL são ferramentas para resolver problemas muito específicos — tanto volumes extremamente elevados de dados, dados não estruturados ou cargas muito altas. SQL é realmente uma ótima ferramenta, capaz de lidar com alta carga e volumes de dados enormes se for bem usada.

Elixir e Phoenix (ou sua dobradinha favorita de linguagem/framework)

  1. Problema real e solução. Frameworks web como o Ruby On Rails não lidam bem com aplicativos de alto desempenho, aplicativos distribuídos e websockets.
  2. Buzz & Keywords. Palavras-chave do hype: “Escalabilidade”, “Alta Performance”, “Distribuído”, “Tolerante a Falhas”.
  3. Obsessão. “Nosso aplicativo é lento e nosso bate-papo não é escalável!”
  4. Desapontamento. “Aprender programação funcional e abordagem distribuída não é tão fácil. Agora estamos muito lentos.”
  5. Realização. Elixir e Phoenix formam um excelente framework, mas demanda um esforço significativo para aprender. Haverá retorno a um longo prazo se você precisa especificamente de um app de alto desempenho.

E a lista continua…

O espaço lotado da Engenharia da Computação apresenta muitas áreas em que hypes são comuns. No mundo do JavaScript, por exemplo, novos frameworks  são criados todos os dias. Node.js, Programação Reativa, Meteor.js, Front-end MVC, React.js. Na engenharia de software nascem novas arquiteturas: Domain Driven Development, Hexagon, DCI…

Qual é o seu hype favorito?  🙂

Boas práticas para evitar o DOM

Aprenda sobre uma tecnologia não somente de blogs, mas com a experiência.

Então, se não podemos confiar no que a internet diz e opiniões de outras pessoas, como tomar decisões inteligentes em relação ao Desenvolvimento Orientado a Modinha? Eis algumas dicas e boas práticas.

Teste e pesquise antes de decidir

Aprenda sobre uma tecnologia não somente de blogs, mas com a experiência. A caráter de testes, invista 1 ou 2 dias para construir um protótipo de alguma funcionalidade na nova tecnologia antes de tomar uma decisão. Deixe a equipe analisar os prós e contras. É possível usar algumas tecnologias competitivas e permitir que diferentes partes da equipe construam protótipos com tecnologias diferentes.

Participar de hackathons é uma ótima maneira de construir a consciência de uma equipe através da análise de tradeoffs de diferentes tecnologias. Tome 1 ou 2 dias para toda a equipe testar todas as tecnologias que estão em ascensão. Isso permitirá que a equipe tome decisões inteligentes por si mesma, com base em sua própria experiência.

Quando arriscar?

A princípio, quando o retorno do investimento é enorme. A maioria das tecnologias são criadas para resolver um problema específico. Você tem esse problema? É um problema grande? Será que vai economizar muito tempo? Será que o uso da tecnologia paga o custo da curva de entrada e reescrita? E se inicialmente retardarmos o desenvolvimento pelo fator de dois? Ou quatro? Ainda vale a pena?

Algumas equipes são mais rápidas do que outras em entregar valor, chegando ao ponto de ficarem entediadas ao realizarem entregas de maneira mais fácil. Essas equipes podem introduzir novas tecnologias com mais freqüência — por outro lado, se a equipe tem problemas com entregas, este um forte indício para proceder com cautela.

Trabalhe com as pessoas certas

Ter uma formação técnica sólida é essencial: pessoas que conhecem diferentes paradigmas, compreendem a teoria da programação (por exemplo, algoritmos, concorrência etc) e têm boa cultura de engenharia tendem a ser menos suscetíveis a hypes.

Experiência também conta muito. Hypes impressionam mais desenvolvedores jovens. Com o passar dos anos, as pessoas que viram muitas tecnologias e estiveram em problemas muitas vezes tendem a ter uma visão mais equilibrada da tecnologia e sabem escolher melhor.

Conclusão sobre Desenvolvimento Orientado a Modinha

Desenvolvimento Orientado a Modinha (ou Hype Driven Development) não é novidade. Acontece de de um hype realmente se consolidar no mercado e se tornar “a nova melhor prática”, mas a quantidade de hypes é tão grande que, estatisticamente, poucos são os que alcançam o status de “paradigma” e se mantêm lá.

As dicas de testar e pesquisar, saber quando arriscar e trabalhar com as pessoas certas — com ênfase aos não tão jovens e/ou aventureiros — realmente surtem resultados. Seguí-las pode determinar o sucesso ou fracasso de seus negócios no mundo dos softwares.

bom senso sempre foi um dos melhores aliados de todos nós. Parece que é hora de começar a dar mais atenção a este velho amigo.

FONTE – Este artigo é baseado em Hype Driven Development, do DaftCode Blog.

Consultoria Arquitetural

Sua corporação esta planejando projetar uma solução usando a plataforma Java? Qual estilo arquitetura utilizar? Quais frameworks adotar? Proprietários ou especificações ? Como fazer a integração com outras soluções legadas? Qual servidor de aplicação escolher? Como levantar requisitos não funcionais? Como resolvê-los? Estas são apenas algumas das muitas questões e problemas a ser resolvidas pelo profissional responsável por projetar uma solução Java. Nós da FOR-J oferecemos uma consultoria especial com o objetivo de suprir esse “know-how”, direcionando o seu projeto para as escolhas mais adequadas que realmente resolva a arquitetura de forma profissional e sem “fanboysmo” de produtos ou frameworks. Como funciona essa consultoria?

Levantamento dos Requisitos Não Funcionais

No primeiro contato, a empresa contratante passa por uma entrevista e um questionário com o objetivo de fazer o levantamento de requisitos básicos não funcionais do produto a ser elaborado. A empresa contratante deve obrigatoriamente chegar com os requisitos funcionais previamente esclarecidos e identificados.

Proposta Arquitetural

É elaborado pela FOR-J uma proposta de projeto com a definição de um estilo arquitetural, front-end, back-end, componentização, patterns, mecanismos de segurança, adoção de frameworks, integrações, entre varias outras coisas. Em um segundo contato é feito uma sessão no formato de palestra no qual é apresentada ao contratante uma proposta de arquitetura e as justificativas de como ela resolve o cenário da solução proposta, utilizando documentação arquitetural. Em caso de clientes remotos, essa consultoria pode ser feita através de emails, Skype ou áudio conferencia.

Escopo

Esta fora do escopo da consultoria providenciar a implementação da arquitetura proposta, download dos frameworks, configuração, integração dos mesmos, montagem da arquitetura e do ambiente de desenvolvimento, ficando isso de exclusiva responsabilidade da empresa contratante.

Pagamento

O pagamento deve ser obrigatoriamente feito até o primeiro encontro de levantamento de requisitos via deposito ou boleto bancário.  Estamos à disposição para quaisquer outras informações – fernandofranzini[arroba]gmail.com, (43)98407-4007 ou Whatsapp.

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

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

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

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