Clique aqui para ler este artigo em pdf
Clique aqui para ler todos os artigos desta edição
Integrando o AJAX
Leitura Obrigatória: Simplificando o AJAX, WebMobile 9.
Num cenário onde grande parte dos projetos open-source ligados ao AJAX se concentravam em desenvolver componentes visuais e bibliotecas JavaScript, o DWR se firmou justamente pelo seu diferencial: a simplificação da forma de comunicação JavaScript<=>Servidor. Sua arquitetura baseada em mecanismo de RMI se tornou um sucesso, pois se encaixa perfeitamente na abordagem de componentização, que é a forma como são construídos os sistemas mais modernos. Como conseqüência, o processo de integração do DWR com outros frameworks no lado servidor se tornou uma tarefa simples e quase automatizada. Isso torna simples não só a criação de sistemas baseados no DWR em conjunto com outros frameworks, mas também facilita bastante a entrada do DWR em sistemas pré-existentes que utilizam frameworks open-source bem conhecidos como:
· Hibernate;
· JSF – Java Server Faces;
· PageFlow / WebLogic;
· Spring;
· Struts.
Neste artigo, usaremos um time de tecnologias cuja escalação constará do DWR, o framework Spring e o mecanismo de persistência Hibernate. Quando estas tecnologias trabalham em equipe, temos uma infra-estrutura extremamente ágil para construir aplicações AJAX com alta capacidade de extensão e de fácil manutenção. Serão usados o Spring versão 1.2.6, Hibernate versão 3.1, DWR versão 1.1.3 e um servidor web Java baseados no padrão Servlet 2.3 (Tomcat versão 4.1). Um banco de dados relacional também é necessário para fazer a persistência do Hibernate funcionar. No exemplo, será usado o PostgreSQL versão 7.0 instalado num Fedora Linux. Como esta implementação usa generics, você precisa da versão 1.5 da máquina virtual Java para fazer o exemplo funcionar. O artigo assume que o usuário saiba como utilizar este tipo de servidor para criação de contextos e manipulação de arquivos de configuração. Como é impraticável descrever os detalhes de todas estas tecnologias num só artigo, recomenda-se que para acompanhar de forma completa este artigo você tenha conhecimento sobre a forma de trabalho não só do DWR, mas também do Spring e do Hibernate.
O papel de cada tecnologia
No time DWR-Spring-Hibernate, a função de cada elemento é bem definida. Como é de se esperar, o DWR cuida apenas da comunicação browser-servidor, transformando as requisições assíncronas em chamadas a métodos remotos. As bibliotecas JavaScript do DWR (DWRUtil) também são extensamente utilizadas para processar os dados recebidos do servidor e exibi-los no browser.
O Hibernate atualmente é considerado o framework padrão de facto quando se fala de mapeamento objeto-relacional. Assim, na nossa equipe tecnologias, ele será responsável por lidar com toda a parte de persistência dos nossos objetos. O principal trabalho gerado por ele será a criação dos arquivos xml que descrevem o mapeamento entre classes do nosso modelo e as tabelas no banco de dados relacional. Detalhes adicionais referentes à configuração que permite o DWR usar objetos gerenciados pelo Hibernate também precisam ser levados em conta.
O Spring é um framework de aplicação completo. Ele oferece pontos de extensão para as mais diferentes funcionalidades de aplicação: de controle de transações ao suporte à programação orientada a aspectos, de um framework web MVC bastante flexível a um poderoso e ao mesmo tempo simples container de inversão de controle (IoC). Além disso, o Spring também oferece mecanismos para sua integração com o Hibernate que aumentam muito a produtividade durante o desenvolvimento do sistema. Assim, no nosso time, o Spring assume a responsabilidade de configurar e fazer a ligação automática dos diferentes beans da aplicação, além de automatizar a conversa com o Hibernate. Se sua aplicação mistura AJAX com requisições HTTP comuns, o módulo WEB-MVC do Spring também é usado para gerar as páginas HTML. No caso de grandes aplicações corporativas, o Spring também pode assumir o controle de transações.
Assim, o desenho do nosso “esquema tático” fica parecido com o da Figura 1.
Figura 1. Exemplo do fluxo de informação do DWR.
Para fazer este time jogar junto, vamos o descrever passo a passo a configuração de cada um destes componentes de forma a criar uma aplicação simples de controle de despesas pessoais.
Hibernate e o ORM
Fazer o mapeamento objeto-relacional (ORM) é o primeiro passo na configuração do sistema. Quem já usou o Hibernate em sistemas que estão começando, sabe que pode usar duas abordagens:
· Definir o modelo de classes e gerar as tabelas relacionais a partir dele;
· Definir o modelo relacional e gerar as classes a partir dele;
Nas duas abordagens, normalmente se usa uma ferramenta capaz de fazer a geração automática de classes, tabelas e dos descritores de mapeamento usados pelo Hibernate (arquivos XML ou anotações nas classes).
Neste exemplo, partiu-se do modelo relacional para se chegar ao modelo de classes. A aplicação vai controlar receitas-despesas de vários usuários. Para isso foi definido um modelo relacional que pode ser implementado no banco PostgreSQL usando o script SQL da Listagem 1.
Listagem 1. Script para implementa o modelo relacional no PostgreSQL.
1. create table USUARIO (
2. ID_USUARIO SERIAL not null,
3. LOGIN VARCHAR(8) not null,
4. SENHA CHAR(32) not null,
5. NOME VARCHAR(255) null,
6. constraint PK_USUARIO primary key (ID_USUARIO)
7. );
8.
9. create table TIPO_LANCAMENTO (
10.ID_TIPO_LANCAMENTO SERIAL not null,
11.DESCRICAO VARCHAR(255) not null,
12.TIPO CHAR(1) not null,
13.constraint PK_TIPO_LANCAMENTO primary key (ID_TIPO_LANCAMENTO)
14.);
15.
16.create table LANCAMENTO (
17.ID_LANCAMENTO SERIAL not null,
18.TIPO_LANCAMENTO INT4 null,
19.ID_USUARIO INT4 null,
20.VALOR DECIMAL not null,
21.MOMENTO TIMESTAMP null,
22.constraint PK_LANCAMENTO primary key (ID_LANCAMENTO),
23.constraint FK_LANCAMEN_REFERENCE_TIPO_LAN foreign key (TIPO_LANCAMENTO)
24.references TIPO_LANCAMENTO (ID_TIPO_LANCAMENTO)
25.on delete restrict on update restrict,
26.constraint FK_LANCAMEN_REFERENCE_USUARIO foreign key (ID_USUARIO)
27.references USUARIO (ID_USUARIO)
28.on delete restrict on update restrict
29.);
Definimos tabelas para guardar informações de usuário e seus lançamentos de despesas ou receitas. As possíveis descrições de despesas/receitas são guardadas na tabela TIPO_LANCAMENTO.
Para fazer a geração de classes e arquivos de mapeamento foi usado um plug-in para a IDE Eclipse (http://www.eclipse.org/) chamado de Hibernate Synchronizer (http://hibernatesynch.sourceforge.net/). O Eclipse e seu módulo de trabalho para sistemas WEB em JAVA (o WTP) é indispensável para organizar as classes, arquivos, e depurar os módulos do sistema. Já o Hibernate Synchronizer permite a você se conectar com o banco de dados, selecionar as tabelas a serem usadas para então ser gerado o modelo de classes e os arquivos de mapeamento. Para cada tabela, são geradas classes “base” que não podem ser editadas pelo programador. Para cada classe “base” é gerada uma classe filha que pode ser editada pelo programador para adição de novos métodos e/ou regras de encapsulamento. O Hibernate Synchronizer também faz o trabalho interessante de converter automaticamente os nomes de tabelas e campos para os padrões Java de nomeação de classes e atributos. Os arquivos de mapeamento gerados podem também ser editados livremente. Cada vez que salvamos o arquivo, o plug-in automaticamente sincroniza as modificações feitas com o código das classes “base”. "
[...] continue lendo...