Arquivos | Arquiteto RSS for this section

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

Como se tornar um arquiteto de software?

arquitetoVeja nessa palestra de 15 minutos de Kleber Xavier falando a respeito de como nasce, o que faz e como se tornar um arquiteto de software. A palestra confirma 100% o que nos da FOR-J temos ministrados na nossa grade de treinamentos para arquitetos:

Arquiteto de Software

AQT M1  Arquiteto Java – Planejamento Estratégico: Objetivo deste curso é introduzir o participante ao cenário atual das complexidades tecnológicas encontradas na produção de soluções corporativas, abordando de forma conceitual as atividades básicas desempenhadas por um arquiteto de software. O curso aborda as mudanças arquiteturais ocorridas nas ultimas décadas, cruzando com as tecnologias oferecidas pela plataforma Java, atividades básicas de um arquiteto de soluções e diversas estratégias de resolução de requisitos não funcionais.… + informações 

AQT M2  Arquiteto Java – Projeto e Design: Objetivo desse curso é oferecer aos participantes conhecimentos práticos relacionados à criação e design arquitetural da verdadeira essência orientada a objetos utilizando a plataforma Java. O curso aborda desenvolvimento guiado por testes conhecido por Test-Driven Design TDD e o desenvolvimento orientado a domínio conhecido por Domain Driven Design – DDD. O curso é finalizado com um estudo de caso completo.… + informações

“Amai-vos cordialmente uns aos outros com amor fraternal, preferindo-vos em honra uns aos outros.” Romanos 12:10

Programação – Item 55

Online_video_marketing_optimize_conversion_rates_tips_id35618561Otimize Criteriosamente

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 gerador de perfil 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.

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

“Tudo quanto, pois, quereis que os homens vos façam, assim fazei-o vós também a eles; porque esta é a Lei e os Profetas.” Mateus 7:12

Arquiteto de Software X Humildade

4_WorkHardA humildade não é uma característica muito comum nos profissionais arquitetos de software. Depois de ter trabalhado com alguns arquitetos terríveis e, recentemente, com um muito agradável,  Johannes Brodwall compilou algumas de suas experiências e compartilhou neste post Humble Architects.  Leitura obrigatória para os arquitetos de plantão.

“Diz ao SENHOR: Meu refúgio e meu baluarte, Deus meu, em quem confio.” Salmos 91:2

Seguir

Obtenha todo post novo entregue na sua caixa de entrada.

Junte-se a 659 outros seguidores