Tecnologia da Informação

Pensando no artigo anterior "Faça funcionar, então, melhore!", e levando em conta as necessidades das empresas de desenvolvimento, dos desenvolvedores, arquitetos e analistas de sistemas, projetei e testei a eficiência de uma arquitetura relativamente símples para suportar aplicações corporativas e aderente á onda da Web 2.0 sem esquecer da necessidade de agilidade no desenvolvimento.

Modelo Web 2.0 e Java EE(tm) de aplicações:

Dessa forma, para um universo de 90% das aplicações Web 2.0, a arquitetura projetada abaixo garante índices consideravelmente altos das qualidades sistêmicas de:

• escalabidade: garantida pelo uso do modelo AJAX DWR, pois a comunicação do navegador do cliente com o servidor é feita baseada em Marshlling de objetos do padrão JSON, muito menos sobrecarregado que WebServices ou outro modelo baseado em XML.
• confiabilidade: garantidada pelo modelo transacional da plataforma Java EE 5 e da peristência baseada em JPA;
• eficiência: devido ao tráfego reduzido entre o cliente e o servidor, e do uso do cache do JPA, esse modelo tem índices excelentes de taxa de transferência X quantidade de acessos;
• segurança: garantia pela associação do modelo de segurança básico da Java EE 5  com o DWR, pois a Java EE 5 provê a autenticação e autorização e o DWR identifica as requisições dos clientes, impedindo que um cliente não identificado envie mensagens ao servidor;
• evolutividade: garantida pelo modelo das classes idealizadas para separar as responsabilidades de geração de páginas, de persistência, de serviços dos EJBs, de serviços do DWR e de scripts JS do cliente.

Arquitetura Java EE 5(tm) usando DWR:

• Componentes amarelos: criados pelo desenvolvedor;
• Componentes azuis: gerados dinâmicamente;
• Componentes roseados: fornecidos pelo servidor ou terceiros;

E sem complicar o processo de deploy, tal modelo permite que a publicação da aplicação seja feita num ambiente símples ou complexo como os modelos abaixo:

Sem Cluster:

Com Cluster:

Atualmente estamos desenvolvendo 5 projetos usando tal arquitetura, e ela tem se mostrado extremanente sólida, confiável e produtiva.

Referências:

• DWR 2.0 - http://getahead.org/dwr
• EJB3 - http://java.sun.com/products/ejb/
• JPA - http://java.sun.com/developer/technicalArticles/J2EE/jpa/
• Glassfish - http://glassfish.java.net/

Usem os comentários para discussão de críticas, melhorias e sugestões.

Conversando hoje pela manhã com o experientíssimo Arquiteto de Sistemas Sênior, o Sr. Claudio Teixeira, sobre requisitos funcionais e não-funcionais de um sistema distribuído que estamos projetando e desenvolvendo, nos deparamos com alguns pontos “extraordinários” de problemas que podem acontecer quando desenvolve-se produtos de software para corporações que não são do ramo de TI, por exemplo:

• Armazenamento e versionamento de documentos;
• Criptografia de dados e arquivos;
• Ambiente redundante de servidores;
• etc;

Descobrimos que estávamos indo um pouco além dos requisitos não-funcionais realmente necessários para que esse produto possa ser utilizado pelos seus usuários, saindo do escopo do aplicativo e entrando em escopo de software básico e infra, assim, relembramos velhos termos uvidos no passado como:

• “Cuidado para o ótimo não virar inimigo do bom”;
• “Keep It Simple, Stupid!” - KISS Theory;
• “Make it work, then, make it better”;
• etc;

Devemos nos lembrar sempre que todo software e hardware ( sistema ) tem suas qualidades e restrições, e que é impossível desenvolver um projeto que faça tudo o que o usuário deseja de uma única vez pois as funcionalidades e restrições estão ligados diretamente ao custo, prazo e qualidade do sistema, portanto devemos ter sempre em mentes as seguintes linhas gerais:

• Não aumentar a complexidade do que já é complexo;
• Criar componentes e utilizar “frameworks” de mercado para facilitar a manutenção;
• Trabalhar com ciclo de vida de produto;

Sendo assim, toda vez que formos participar de um projeto de software, principalmente na etapa de venda e projeto, devemos estar cientes e principalmente deixar o cliente confortável com o que vai ser feito, quando vai ser entregue e que melhorias podem ser implementadas ao curto e médio prazo num sistema de informação.

Bom trabalho a todos.