Arquivos | Arquiteto RSS for this section

Pattern Store Procedure Facade

imagesFerrContinuando o assunto das regras de negócio dentro do banco de dados, hoje eu gostaria de apresentar uma estrutura arquitetural que se tornou um design pattern muito utilizado dentro das equipes que eu trabalho, no qual eu nomeei de “Store Procedure Facade”. Segue a explicação do que é contexto e um exemplo prático:

Contexto

Dado uma solução, que em uma única requisição HTTP necessita acessar o banco de dados remoto N vezes para pegar informações de tabelas diferentes não relacionadas.

Problema

Dada uma situação de três acessos na requisição, 500 usuários simultâneos fazendo essa operação resultara em 1.500 round trips ao banco de dados, necessitando assim de aumento expressivo da configuração do DataSource, aumento no gasto de memória no parse do framework ORM e a redução exponencial do tempo de resposta da requisição.

Solução

Criar uma store procedure utilizada como se fosse uma Facade para encapsular, agrupar e retornar os N acessos de forma com que com um único round trip ao banco seja possível retornar todas as informações necessárias.

Exemplo

Segue um exemplo em SQL Server 2008:

CREATE PROCEDURE procecure_facade_x

AS

SELECT * INTO #parametro1 FROM tabelaX1

SELECT * INTO #parametro2 FROM tabelaX2

SELECT * INTO #parametro3 FROM tabelaX3

SELECT * FROM #parametro1, #parametro2, #parametro3

GO

Veja que é criada uma Store Procedure Facade que faz acesso em três tabelas diferentes, armazenando cada resultado em tabelas temporárias e depois agrupando e retornando como se fosse a uma mesma consulta.

Resultado

500 usuários simultâneos fazendo essa operação resultara em apenas 500 round trips no banco de dados, um por cada requisição, reduzindo expressivamente a configuração do DataSource, reduzindo os gasto de memória com parse do framework ORM e a aumento expressivo do tempo de resposta da requisição.

“Porque o Filho do Homem veio buscar e salvar o perdido.” Lucas 19:10

Não Faça Regras de Negócio Dentro do SGDB

240px-Stop_hand_nuvola.svgJá se passaram muitos anos desde a década de 90 e ainda assim eu continuo ouvindo e vendo muitas corporações colocando regra de negócio das soluções dentro de um banco de dados. Hoje o cenário de soluções corporativo é outro completamente mais complexo e a arquitetura em duas camadas não oferece características que sustente sua evolução. Resumidamente, soluções construídas em duas camadas não cumprem requisitos como escalabilidade, extensibilidade, manutenibilidade, segurança, perfomance e disponibilidade. Dessa forma, hoje usamos arquitetura n-camadas que é a única que, se bem projetada pode cumprir todos os requisitos não-funcionais característicos das soluções atuais. Segue um resumo básico dos velhos e já batido motivos documentados que justificam o não uso de regras dentro de um banco de dados:

1. Acoplamento

Regra dentro do banco de dados viola o princípio SOC que define que cada pedaço de um sistema precisa estar localizado em um lugar único e exclusivo promovendo isolamento, manutenção, reutilização e futura substituição, sem impacto nas outras partes.

2. Falta de Portabilidade

Regras escritas dentro do banco não oferecem portabilidade entre os diferentes produtos concorrentes da mesma filosofia de banco de dados adotado. Na década de 90 já era um transtorno e só tínhamos os famosos SGDB. Hoje então a coisa piorou com o surgimento com NoSQL e suas varias opções estruturais.

3. Péssima Manutenção e Código Inflexível

Regras no banco de dados são na maioria das vezes escritas usando store procedures  (filosofia procedural da década de 60) que são desprovidos de recursos e as diretrizes da OOP como encapsulamento, agregação, composição, associação, herança e polimorfismo e da mesma forma não conseguem usufruir de nenhum tipo de padrões (Patterns) arquiteturais, projetos e programação.

4. Know-How Especializado

Regras no banco de dados precisam ser manutenidas por profissionais que detenham conhecimento especializado para aquele particular produto e filosofia de banco de dados adotado, sendo difícil e ou caro de se encontrar mercado ou de se formar internamente.

5. Problemas de Performance

Soluções de grande porte, dotadas de um grande e crescente numero de acessos simultâneos e com a execução de regras pesadas vão degradando gradativamente a performance da solução, podendo até (que é o acontece na maioria dos casos) derrubar o serviço, uma vez que os banco de dados são desprovidos de devidos gerenciamentos de recursos encontrados normalmente em MIDDLEWARE relacionados com técnicas de otimizações, tunning, comunicação assíncronas, mensageira (MOM), escalabilidade vertical e horizontal apropriadas aplicadas especificamente na execução das regras de negócios.

6. Ausência de Recursos

Regras de negócio corporativas normalmente englobam o uso de recursos como logica binária, manipulação de arquivos PDF, DOC, XLS, XML, JSON.  Comunicação com sistemas externos como LDAP, SMTP, FTP, Mensageira, SOAP, REST etc. Os SGDB normalmente não possuem API’s disponíveis para estes fins e muitos outros recursos, salvo em casos raros que alguns provedores de SGDB fornece alguma coisa bem limitada e proprietária para tratar um ou outro. A coisa piora por que normalmente não existe abertura para se acrescentar uma API de terceiros para dentro do banco.

Conclusão

Martin Folwer no livro Patterns of Enterprise Application Architecture capitulo 8 escreveu:

“Por todas estas questões, muitas pessoas evitam implementar regras de negócio dentro de um banco de dados. Eu tento me alinhar com esta visão a menos que haja um grande ganho de desempenho a ser obtido, o que, para ser sincero frequentemente ocorre. Nesse caso, pego um método de negócio da camada de domínio e, alegremente  o transformo em um procedure dentro de um banco de dados. Faço isso apenas em áreas com claro problemas de desempenho, tratando-o como um abordagem de otimização e não como um principio arquitetural.”

Joshua Bloch no livro Java Effective capítulo escreveu no item 55 (que eu resumi):

“A historia das décadas passadas nos mostram que otimização prematura na verdade é mais propenso a causar danos do que benefícios. O caminho da otimização precoce pode leva-lo a uma solução que ainda não seja rápida, arquiteturalmente ruim e pior de tudo inflexível de difícil evolução. Portanto, não tente criar programas rápidos! Na verdade, foque em criar bons programas, usando todos os conceitos, princípios e abordagem necessários. Se um programa bem arquiteturado não for rápido suficiente, a boa arquitetura já estabelecida permitira que ele seja facilmente otimizado. Não pense em problemas de desempenho enquanto estiver projetando uma solução. Quando terminar a codificação, avalie seu desempenho. Se ele for suficientemente rápido, tudo estará resolvido. Caso contrário, localize a fonte de gargalo usando uma ferramenta de profile e trabalhe nas partes relevantes. Repita esse processo conforme necessário, avaliando o desempenho após cada alteração até apresentar um tempo satisfatório.”

Acredito que todos estes fatos já fornecem base suficiente para que você tenha condições de fazer a sua tomada de decisão :D . Até a próxima!

“Quão grande és tu, ó Soberano SENHOR! Não há ninguém como tu, nem há outro Deus além de ti, conforme tudo o que sabemos.” 2 Samuel 7:22

Aprenda o Escopo Thread-Local

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

JMS no Tomcat

jmsEu já ouvi falar que quando chega a hora de utilizar uma solução de mensageria tipica JMS é hora de abandonar o Tomcat e adotar outro container JEE. Será que é isso mesmo….? Acho que não…. veja:

Acrescentando com o suporte de facilidades spring vc tem mesmo seviço de um MDB:

Bons estudos para todos!

“Pois o amor de Cristo nos constrange, julgando nós isto: um morreu por todos; logo, todos morreram. E ele morreu por todos, para que os que vivem não vivam mais para si mesmos, mas para aquele que por eles morreu e ressuscitou.” 2 Coríntios 5:14-15

Padrões de Integrações de Sistemas

Muito dificilmente você ainda não ouviu falar do livro Enterprise Integration Patterns, de Gregor Hohpe e Bobby Woolf, com prefácio e contribuição de Martin Fowler. Trata-se de excelente livro sobre integrações, mais especificamente sobre padrões de integrações corporativas, como o próprio título enuncia. O livro aborda padrões de integração amplamente vistos no mercado e explica porque a Mensageria (Messaging) é, dentre eles, o que melhor endereça diversos aspectos que devem ser levados em consideração ao estabelecer integrações confiáveis. Os autores ainda consideram que apesar desta ser uma abordagem amplamente indicada, ela é igualmente pouco conhecido ou aprofundado pelo mercado, e é justamente essa a motivação para que a maior parte do livro discorra sobre os diversos padrões relacionados à mensageria, como por exemplo: Guaranteed Delivery, Message Broker, Message Bus, Publish Subscribe Channel, Request-Reply e diversos outros.

Neste post veremos alguns dos tópicos abordados no livro. Começaremos pela motivação para a existência de integrações, passaremos pelos principais aspectos a considerar em integrações e posteriormente pelas principais abordagens de integração existentes – algumas delas estabelecidas por Martin Fowler. Por fim, veremos um comparativo entre as abordagens descritas. Comecemos então pela questão: Por que integrações são necessárias? A resposta é simples. Integrações são inevitáveis para prover uma experiência unificada e produtiva para funcionários da organização, parceiros e clientes.

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.

E para se prover uma experiência unificada para funcionários, parceiros e clientes, devemos considerar que integrações podem ocorrer entre soluções estruturadas em plataformas distintas, separadas geograficamente dentro e fora do escopo da organização e que usam tecnologias distintas.

Neste contexto, o livro sugere que a escolha por uma abordagem de integração apropriada deva levar em consideração alguns aspectos. Vejamos:

  • Formato de Dado: 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.
  • 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.
  • Exposição de funcionalidades: Muitas abordagens de integrações permitem que aplicações compartilhem não apenas dado, mas também funcionalidades. Tal compartilhamento é interessante, pois gera um nível maior de abstração entre as aplicações envolvidas.
  • 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.
  • 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.
  • 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.
  • Acoplamento entre aplicações: 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.
  • Intrusividade: Integrações devem causar o mínimo de impacto em códigos existentes e devem requerer pouca codificação.
  • Esforço de desenvolvimento (*): 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.
  • 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.

Segundo o livro Enterprise Integration Patterns, nenhuma abordagem de integração endereça todas estas características ao mesmo tempo de forma igualmente bem. Porém, determinadas abordagens de integração podem ser melhores do que outras em determinados cenários. Ainda segundo o livro, existem quatro principais categorias / estilos de integração. Vejamos a seguir:

File Transfer (Martin Fowler): As aplicações produzem arquivos de dados compartilhados para outras aplicações consumirem.

clip_image004

 

 

 

 

Remote Procedure Invocation (Martin Fowler): As aplicações expõem algumas das suas operações de forma que elas possam ser invocadas remotamente. Outras aplicações invocam tais operações para realizar determinadas tarefas ou para compartilhar dados.

clip_image008

 

 

 

 

Shared Database (Martin Fowler): As aplicações gravam dados que se deseja compartilhar em um banco de dados de comum acesso.

clip_image006

 

 

 

 

 

 

Messaging: As aplicações se conectam a um sistema comum de mensageria, de forma a compartilhar dados e a invocar operações através do uso de mensagens.

clip_image010

 

 

 

 

 

 

Cada uma dessas abordagens 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.

clip_image012

Conforme podemos observar na tabela comparativa a seguir, elaborada com base no conteúdo do livro, as abordagens File Transfer e Shared Database são as que apresentam os problemas considerados como os mais graves. Ambas não possibilitam a exposição de funcionalidades, o que permitiria um nível considerável de desacoplamento entre aplicações. A abordagem File Transfer apresenta ainda questões relacionadas ao tempo de atualização de dados, o que pode gerar falta de sincronismo e, por consequência, falta de confiança nos dados apresentados.

Já o Shared Database, porém, ao contrário do File Transfer, é bastante versátil quando se trata de sincronismo de informações, já que as aplicações compartilham um mesmo repositório de dados. Porém, tal abordagem pode não ser viável quando se adquire um pacote de mercado. Fornecedores de tais pacotes, em geral, se reservam o direito de evoluir a estrutura (schema) da sua base de dados em novas versões do seu produto. Outros problemas intrínsecos desta abordagem são o alto acoplamento gerado entre as aplicações que a adotam, uma vez que uma alteração em uma estrutura de dados pode afetar diversas aplicações de uma só vez, e escalabilidade, já que problemas de concorrência podem ocorrer à medida que o número de aplicações que atualizam com frequência uma mesma estrutura cresça. Bloqueios de registros podem fazer com que seleções de dados simples demorem mais do que o esperado. Atualizações massivas ou frequentes podem ainda causar impactos significativos na performance dos demais sistemas.

Apesar da abordagem Remote Procedure Invocation permitir exposição de funcionalidades, o que garante um bom nível de abstração entre as aplicações envolvidas, o acoplamento ainda é considerado como alto neste tipo de abordagem, uma vez que a indisponibilidade da aplicação provedore ou que mudança em formatos de dados impactem diretamente as aplicações consumidoras. A abordagem também é considerada como pouco escalável, de forma semelhante a abordagem Shared Database, considerando que diversos consumidores dependeriam de um único recurso, neste caso a aplicação provedora, e que o aumento no número de consumidores impactaria diretamente tal aplicação provedora.

O livro ainda sugere que dentre as abordagens apresentadas, a Mensageria (Messaging) é a que teria mais vantagens e o que endereçaria melhor os aspectos apresentados anteriormente. E tal sugestão parece ser válida. Note que a abordagem Messaging é a que tem, de fato, mais aspectos positivos nos critérios avaliados.

A abordagem Messaging não requer que aplicações envolvidas sejam modificadas para suportar formatos de dados específicos. Tradutores intermediários podem ser usados para tal (Message Translator). Também permite que funcionalidades sejam executadas quando do recebimento de mensagens (exposição de funcionalidades). Já com relação ao tempo de processamento, padrões de integração near real-time e real-time podem ser usados nesta abordagem. E padrões near real-time logo remetem a processamento assíncrono, que somado a padrões que permitem a garantia de entrega de mensagens (Guaranteed Delivery), vem a garantir maior confiabilidade da integração. Acoplamento e Intrusividade também são itens com mais aspectos positivos nesta abordagem, quando comparado com as demais. Pela fato de empregar um sistema intermediário entre provedor e consumidor de dado, um não é necessariamente diretamente afetado por modificações no outro. A abordagem ainda é considerada pouco intrusiva, já que o código da aplicação não precisa ser afetado pelo código da integração. E uma vez que haja tal separação e que abordagens assíncronas sejam usadas, a abordagem é considerada altamente escalável, já que o processamento de um grande volume de mensagens pode ocorrer no ritmo que a aplicação suporta e não no ritmo que as demais aplicações impõem.

Seus principais problemas não são tão relevantes quando comparados com os das demais abordagens. A seleção de tecnologia, por exemplo, é considerada como negativa para esta abordagem, dada a dependência tecnológica que se adquire com sistemas de mensageria específicos. O esforço de desenvolvimento também é maior quando comparado com as demais abordagens, dada a complexidade intrínseca do desenvolvimento assíncrono e a necessidade de aquisição de conhecimento especializado.

Link Oficial: http://nelsonbassetto.com/blog/2013/02/enterprise-integration-patterns/

“Diz o insensato no seu coração:  Não há Deus.” Salmos 14:1

The Java EE Architect’s Handbook

downloadThis handbook is a concise guide to assuming the role of application architect for Java EE applications. This handbook will guide the application architect through the entire Java EE project including identifying business requirements, performing use-case analysis, object and data modeling, and guiding a development team during construction. This handbook will provide tips and techniques for communicating with project managers and management. This handbook will provide strategies for making your application easier and less costly to support. Whether you are about to architect your first Java EE application or are looking for ways to keep your projects on-time and on-budget, you will refer to this handbook again and again.

What you’ll learn:

You will discover how to:

  • Design Java EE applications so that they are robust, extensible, and easy to maintain.
  • Assume the role of application architect on Java EE projects.
  • Apply commonly used design patterns effectively.
  • Identify and address application architectural issues before they hinder the development team.
  • Document and communicate the application design so that the development team’s work is targeted.
  • Avoid common mistakes that derail project budgets and timelines.
  • Guide the development team through the design and construction process.
  • Setup effective procedures and guidelines that increase stability and decrease defect reports.
  • Avoid common mistakes that make Java EE applications overly complex and hard to support.
  • Effectively estimate needed resources and timelines.

Who this book is for:

  • Senior Java EE developers looking to assume an architect role.
  • Junior Java EE application architects looking to improve their skills.

“Cantai a Deus, salmodiai o seu nome; exaltai o que cavalga sobre as nuvens. SENHOR é o seu nome, exultai diante dele. Pai dos órfãos e juiz das viúvas é Deus em sua santa morada.” Salmos 68:4-5

Java Spring Architect

logo-spring-103x60Mesmo depois dos avançados da especificação do JEE 6, vemos que ela ainda esta muito longe de se igualar as opções oferecidas pela plataforma Spring. Vale a pena lembrar que da mesma forma que as especificações vão melhorando ao longo do tempo, o Spring também vai evoluindo em uma velocidade muito mais rápida, uma vez que não depende de nenhum tipo de votação comunitária.

Eu mesmo ao longo dos meus 14 anos de Java, sempre tive a cautela de preferir produtos JCP ao invés de proprietários, visando o grande ideal da portabilidade e a independência de vendor, mas hoje eu venho publicamente concluir que tenho percebido que ao longo do tempo tenho adotado os produtos Spring mais e mais. Motivo? O mesmo pelo qual o Spring foi criado: ser uma opção muito mais rápida, barata e leve de um lightweight container que ofereça serviços plugáveis de infraestrutura para soluções corporativas com a mesma qualidade.

Hoje a minha dica é sobre os principais livros de Spring atualizados para os interessados em se aprofundar nessa poderosa plataforma:

51nY36Dqo5L._BO2,204,203,200_PIsitb-sticker-arrow-click,TopRight,35,-76_AA300_SH20_OU01_

Spring in Action  é o livro mais básico que te ensina os pilares do uso de serviços no Spring. Nele você também aprendera os serviços e recursos mais básicos que ele proporciona.

415x7PWAe5L._BO2,204,203,200_PIsitb-sticker-arrow-click,TopRight,35,-76_AA300_SH20_OU01_

Just Spring Integration  é o livro que estende o spring oferecendo os serviços de infraestrutura voltados para integração de soluções definidos pelo catalogo de patterns de integração conhecidos pelo EAI.

51RXnaly93L

Spring Data é o livro que estende o spring oferecendo os serviços de infraestrutura voltados para persistência de dados relacionados com banco de dados relacionais e NoSQL.

Existem outros livros mais específicos de outros serviços que você também pode estar estudando como, por exemplo, Spring Bath in Action e Pro Spring Security

Uma vez que você domine todos estes serviços, você praticamente se tornara um “Arquiteto Java Spring”, dominando contextos de soluções mais modernos da atualidade e apto para projetar soluções corporativas de pequeno, médio e grande porte.

“Não retarda o Senhor a sua promessa, como alguns a julgam demorada; pelo contrário, ele é longânimo para convosco, não querendo que nenhum pereça, senão que todos cheguem ao arrependimento.” 2 Pedro 3:9

Seguir

Obtenha todo post novo entregue na sua caixa de entrada.

Junte-se a 676 outros seguidores