Últimas notícias do evento

Feedback Ead – AQT M1 Arquitetura de Software com Java

Postado em Atualizado em

“Já estava dando uma olhada nos cursos da FOR-J Treinamentos há algum tempo. E felizmente fui contemplado eu um sorteio para o curso AQT M1 – Introdução a Arquitetura de Software. E posso garantir sem sombra de dúvidas: Vale muito a pena. Material muito bem organizado, sequência das aulas muito bem planejada e as aulas são muito bem ministradas. Estão de parabéns. E mais uma vez, muito obrigado. Com certeza irá contribuir e muito para o meu desenvolvimento profissional.”

Silvair Leite Soares

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

Nunca desista de seus sonhos…

Postado em Atualizado em

Nesse final de semana tive o privilégio de conhecer e assistir a palestra de Marcos Pontes, cara genial e referência aí para qualquer um de nós brasileiros. Foi um sábado incrível! “Nunca desista de seus sonhos, independente de quem você é e de onde você se encontra”!

“Entreguem todas as suas preocupações a Deus, pois ele cuida de vocês.”1 Pedro 5:7

Série de Padrões de Integração

Postado em Atualizado em

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

65 Padrões de Mensageria

A partir de hoje estarei postando um resumo de cada padrão de mensageria para ser utilizado como material de referencia e estudo. Até lá!

“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

Catálogo de Refatoração: Simplificando Expressões Condicionais #2

Postado em Atualizado em

Consolidar Fragmentos Condicionais Duplicados – use quando encontrar um fragmento de código que é executado em todas as ramificações de uma expressão condicional if-then-else. Mova-a para fora da expressão guardas tornando a intenção do código muito mais clara.

Remover Flag de Controle – use quando encontrar uma variável que esta atuando como uma flag de controle para uma série de expressões booleanas. Substitua todas as flags de controle por break ou return guardas tornando a intenção do código muito mais clara.

Substituir Condições Aninha Por Cláusula Guarda – use quando encontrar um método tem uma lógica condicional que não deixa claro o fluxo normal da execução. Substitua estes casos por clausulas guardas tornando a intenção do código muito mais clara.

Para todas as informações, veja o post inicial.

“A pessoa que me ama obedecerá à minha mensagem, e o meu Pai a amará. E o meu Pai e eu viremos viver com ela.” João 14:23

Desabafo Total V2

Postado em Atualizado em

professor burroEu não costumo postar textos negativos e nem falar mal de “coisas ou pessoas”, mas hoje eu vou sair da minha ética profissional e vou “chutar o pau da barraca”. Tenho passado por situações que eu realmente não entendo, e fico abismado de ter que passar por isso. Segue os casos:

Usar SOAP para retornar uma String contendo um XML…

Como pode??? SOAP é um protocolo pesadíssimo com o objetivo de determinar e garantir um “contrato” de envio e recebimento de objetos no formato XML no qual faz parte do contrato o esquema e a validação do próprio envelope do objeto. Declarar um WSDL com retorno de String e colocar um XML la dentro só pode ser coisa de manézãooooo mesmo!! Não faz nenhum sentido isso!! Meu Deus do céu!!! Peguei + de 3 empresas grandes fazendo isso e ainda tiver que ler e transformar o xml via String!!

Usar MongoDB como se fosse relacional….

Tem gente copiando modelo relacional para dentro do MongoDB, usando referencia de ID’s em diferentes collections, criando processos compostos “transacionais” manuais, implementando roolback manuais e um trilhão de porcaria de código para suprimir as buscas com JOIN. Meu Deuuusss do céuuu!! Volta para o banco de dados relacional cabeçudooooo! MongoDB não foi feito para isso….La no mongo você desnormaliza os dados, cria uma única collection por transação e persiste somente 1 objeto único atômico com todos os seus agregados por transação de sistema. Você esta querendo economizar espaço? Pra que? Não ta usando um NoSQL para escalar horizontalmente? kkkkkkk…….É verdade que o mongo tem recursos para fazer joins entre collection, mas é para ser usada na exceção e não como regra.

Usar microservices para meia duzia de serviços…

Microservice não é uma coisa boa! Microservice é uma coisa ruim! Microservice é como se fosse uma última atitude arquitetural desesperada para tentar arrumar e organizar uma solução monolítica que chegou ao caos por ser muito grande e complexa de gerenciar. A introdução dessa arquitetura em si já gera muitos problemas e contornos que se forem aplicadas para soluções sem perfil acabam só estragando ao invés de melhorar. Para de abelhuuudarrrrr !! Fazer soluções pequenas usando microservices vai mais gerar problemas que o próprio contexto de negócio da solução!  Arquitetura monolítica sempre sera para 90% dos casos….

Falar mal de um produto grátis, mas crackear um pago

Eu uso eclipse, é grátis, é da comunidade e vive com bugszinhos normais. Mas já vi pessoas falando muito mal do eclipse exatamente por isso, mas quando fui ver as maquinas dos “bunitões”, tudo usando Jetbreais IntelliJ “CRACKEADO” ! Sem comentáriosssss !

Tem livro por ai que consegue piorar o aprendizado

Estou nesse mês estudando um nova linguagem de programação bem dificil. O autor “bunitão, gostosão” do livro, esta ensinando GET e SET de objetos usando uma classe de 30 linhas que abstrai coordenadas cartesianas polares de um único conjunto de dados. Meu deussssss do céu!!!! Não tinha como deixar o exemplo pior??? É pra acabaaaaa…..Ruim d+!

Ufa…agora estou mais leve! E desde já, me perdoem pelo desabafo….

“Deus sabe por onde você anda e vê tudo o que você faz.” Provérbios 5:21

16 anos do meu primeiro livro de java

Postado em Atualizado em

Hoje, me dei conta que fez 16 anos que comprei meu primeiro livro de Java. E ele ainda esta aqui, detonado mas firme e forte. Como o tempo passou….

“O amigo ama sempre e na desgraça ele se torna um irmão.” Provérbios 17:17