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.

A ComputerWorld, recentemente publicou um artigo sobre a Tecnologia Java,
mas discordo completamente de tal análise.

Vejo que o mercado se acomodará de acordo com suas necessidades,
por tipo de necessidade de “client” e capacidade de processamento “server”,
mas somente a Tecnologia Java atualmente consegue ser o “martelo certo” para
quase todos os problemas computacionais, desde o “mobile”, passando pelo “server”,
incluindo “integration” e o “desktop”.

Acreditem, temos 13 anos de Java, e acho essa tecnologia e suas plataformas evoluirão
constantemente por mais uns 20 anos em ondas associadas a Web 3.0, Federation,
RFID, Virtualização, GRID Computing, etc.

Não esqueci de SOA, é que SOA é tão antigo quanto a especificação que permitiu
a descoberta e uso do AJAX, pois é um Padrão de Arquitetura associado a ferramentas
e especificações que não são novas: WebServices, Messaging, ETL, etc.

Independente do que a Microsoft faça, e a ComputerWorld diga, a plataforma .NET
ainda é considerada pelas empresas uma solução barata, fácil de desenvolver,
que qualquer programador medíocre é capaz de aprender e fazer “aplicativos”,
mas extremamente amadora do ponto de vista de “confiabilidade” para a construção
de “sistemas” integrados e robustos, principalmente quando falamos em aplicações
com grandes volumes de dados e usuários.

Recentemente até o Banco Itaú, que declaradamente só usava a plataforma .NET
se rendeu ao Java EE, e já está “migrando” seus sistemas do Internet Banking para
Java EE rodando em WebSphere no Mainframe, pois o Itaú estava gastando muito $$$$
para administrar e provisionar recursos para os mais de 170 Servidores IIS rodando .NET.

A IBM do Brasil tem mais 4 grandes casos de sucesso de outros bancos que estão fazendo o mesmo.

Ou seja, temos espaço para todos os tipos de ferramentas para variados tipos de problemas, entretanto, existem soluções “mais adequadas” em prazo-custo-qualidade que outras, e atualmente a plataforma Java EE tem se mostrado a que melhor resolve essa equação.

Bom trabalho a todos.

Muitas aplicações usam o Log4J e seu empacotamento/inicialização
podem se tornar um problema em servidores que tem múltiplos classloaders
para separar componentes do servidor dos módulos e aplicações.

Dessa forma descobri uma maneira muito simples de configurar o Log4J
na inicialização do Glassfish ou do Sun Java System App Server nas versões 7, 8 e 9
que elimina a necessidade de ter um listener para inicializá-lo e configurar as categorias
bem como empacotar o Log4J em cada módulo ou aplicação.

1 - Faça o Download do Log4J

2 - Copie o log4j-x.jar no diretório $APP_SERVER_HOME/domains/domain1/lib/ext

3 - Insira as propriedades abaixo alterando a seção do domain.xml ou via a console
administrativa as propriedades da JVM


<jvm-options>

-Dlog4j.configuration=file:${com.sun.aas.instanceRoot}/config/log4j.xml

</jvm-options>
<jvm-options>

-Dlog4j.configuratorClass=org.apache.log4j.xml.DOMConfigurator

</jvm-options>


4 - Crie um arquivo log4j.xml no diretório $APP_SERVER_HOME/domains/domain1/config
com os appenders e as categorias configuradas baseado no modelo abaixo:

5 - Em cada uma das classes que se deseja ter o uso do Log4J,
defina o Logger assim:


package app.package;
public class MyClass {
private static Logger logger;
static {
try {
logger = Logger.getLogger( MyClass.class );
} catch (Exception e) {
e.printStackTrace( System.err );
}
}
}

Boa sorte!

O tutorial abaixo mostra como implementar um filtro de requisições HTTP na plataforma Java Enteprise Web para forçar o donwload de arquivos que geralmente são abertos diretamente pelos navegadores modernos.

Esta funcionalidade é muito útil quando tem-se aplicativos que geram arquivos dinâmicos muito pesados e tem um tempo de download muito grande, forçando ao usuário ficar aguardando com uma tela em branco enquanto o download não termina.

Pode ser utilizado também para arquivos fixos que estão localizados dentro das aplicações web java ( módulo WAR ) e que não estão colocados como arquivos em servidores Web.

Download do Tutorial

Esta apresentação trás um resumo de como desenvolver aplicativos Java Enterprise

Podemos agendar esta e outras palestras na sua empresa ou grupo de estudo!

Faça o download aqui

Bom trabalho a todos.

Este roteiro trás as informações necessárias de como configurar e usar
o famoso framework Jakarta Struts ( versões 1.X )
na família Sun ONE ( versões 7 até 9 ) / Glassfish

Faça o download aqui

Bom trabalho a todos.

Panomara do mercado de servidores de aplicação Java Enterprise.

Tenho certeza que muitos se perguntam: Qual o melhor servidor de aplicações do mercado?

Esta resposta não é tão simples, pois atualmente temos:

1. Java2 EE 1.4: 17 fornecedores certificados
2. Java EE 5: 9 fornecedores certificados

De fato, não temos como saber qual o melhor servidor,
mas temos como identificar qual o fornecedor e produto que melhor se enquadra para cada organização.

Sugiro um método símples para adoção do servidor de aplicações:

1. Verifique se o servidor é certificado pela Sun/JCP/Padrões ( lista de compatibilidade ).
2. Verifique se o fornecedor tem suporte nível 1, 2 e 3 no país.
3. Verifique se o produto além de estar certificado, oferece ferramentas web de monitoração,
   gerenciamento de configuração e publicação.
4. Verifique as formas de licensiamento e custo, pois geralmente variam por tipo de contrato,
   empresa, número de servidores, etc ( ambientes complexos tem contratos complexos ).
5. Verifique a lista de BUGs documentados do produto, pois muitas vezes esses BUGs podem
   ser eliminados com dicas/configurações fornecidas pelo fabricante.
6. Verifique se o produto usa partes de produtos OpenSource, pois dessa forma
   temos certeza que a empresa aposta na evolução do mesmo.

Se o servidor se enquadra em todos o itens acima e o preço cabe no budget do projeto,
então pode-se criar uma tabela como abaixo pontuando o itens e ter-se a média.

Fórmula NOTA: = ( ( C + S + P + F + B + O ) / 53 ) * 10

Sempre devemos dar preferência por produtos certificados pela SUN,
e aquele que tiver a melhor nota, fica com a preferência de escolha.

Atualmente o mercado de Servidores de Aplicações Java tem grande concorrência
entre Oracle, IBM, SAP e SUN, e o market share maior de instalações “pagas” é da IBM,
devido á sua agressividade comercial. Nos ambiente de desenvolvimento, e instalações “open”
baseadas em produtos Free, o líder é o JBoss AS.

O site TheServerSide.com tem um artigo interessante sobre servidores de aplicação e uma matriz de compatilidade

Bom trabalho a todos.

Seguindo as tendências do mercado para os próximos anos e apresentadas no Java One 2007, criei um modelo para aplicações baseadas em WEB 2.0 usando os conceitos de AJAX, e baseado no framework DWR (Direct Web Remoting) (http://getahead.org/dwr/) associado a EJB3 e JPA da Java EE 5.

Para a Interface com o Usuário, foram escolhidos os Widgets do EXT JS (http://www.extjs.com) que combinados com páginas JSPs permitem a geração dinâmica da UI (Interface do Usuário).

Com o uso extensivo de CSS e de DIVs (TABLELESS), pode-se trocar imagens e mudar o visual facilmente, criando o conceito de temas.

A integração do DWR com os Serviços da Aplicação baseados em Façades e Delegates implementados com SessionBean Stateless funciona muito bem, deixando o controle de transações a cargo do EJB Container

E como o maior problema de qualquer aplicação grande é ligar a camada de serviços com a camada de persistência, adotei a estratégia de usar o padrão de DAO (Data Access Objects) abstraindo as chamadas de NamedQueries do JPA

O resultado foi muito bom, o que levou a batizar este modelo de Fast Dev Framework, que combinado á componentes já consolidados na comunidade Java, fornece mecanismos de filtro, paginação, relatórios, autenticação, autorização em bancos de dados ou LDAP, mecanismos de mensageria, scheduler, sem esquecer de logging e auditoria, permitindo a criação de aplicações complexas com qualidade, aderentes ao padrão Java EE e em tempo recorde!

Este framework está testado e homolgoado para:

Fast Dev Framework

Recentemente avaliei um Engine de GRID composto de uma API simples e extremamente robusto capaz de executar tarefas num ambiente de GRID 100% Java, sem depender de nenhum outro software terceiro

O JPPF (Java Parallel Processing Framework) permite escrever aplicações Java que se beneficiem de mecanismos de provisionamento de dados e execução de tarefas de longa duração em ambientes de GRID, com monitoramento simplificado e com uma diminuição considerável dos tempos de processamento

O ambiente de execução é composto de:

• um DRIVER que é responsável por monitorar os nós do GRID bem como distribuir as classes Java (Remote Class Loading) das tarefas (Task) para os nós
• um ou mais NODES que são responsáveis por executar as tarefas

O DRIVER e cada um dos NODES roda em uma JVM (Java Virtual Machine) exclusiva, que pode estar inclusive em servidores de menor porte ou de grande porte aplicando conceitos de virtualização bem como configurar e gerenciar cada um dos NODES adequadamente.

Topologia:

Caso sua empresa necessite de diminuir os tempos e os custos de processamento de BI, ETL e DW, podemos desenvolver soluções específicas baseado nesta tecnologia

Referências: JPPF.org