ob os princípios da arquitetura cliente-servidor, sendo uma única versão para a aplicação servidora e duas versões para a aplicação cliente. Diante disso, realizou-se um comparativo quanto ao desempenho das duas versões cliente, uma com persistência local temporária e outra sem esta característica.
Para que serve:
A persistência local temporária junto às aplicações clientes instaladas em dispositivos móveis oferece maior agilidade e flexibilidade. Isto porque os modelos em que as aplicações clientes acessam diretamente uma aplicação servidora resultam em um maior número de acessos e necessitam do estabelecimento de conexões permanentes. Já com a persistência local temporária se evita o estabelecimento deste tipo de conexões quando os dados já estão armazenados no dispositivo.
Em que situação o tema útil:
Além do contexto apresentado neste artigo, abordagens que utilizam persistência local em dispositivos móveis são úteis em quaisquer situações em que os usuários precisem de agilidade e flexibilidade. Além disso, deve-se considerar também a economia de recursos (tempo e dinheiro, por exemplo) propiciada, pois não haverá gastos com tráfego de dados ou, pelo menos, estes gastos serão reduzidos.
Os dispositivos móveis são cada vez mais utilizados, tanto por pessoas quanto por empresas, e propiciam mobilidade e praticidade na execução de tarefas do dia-a-dia. Com isso, o número de aplicações para tais dispositivos tem crescido, fazendo com que haja transmissão de dados mesmo sem um meio físico de comunicação (sem fio – Wireless) [2][4]. Neste processo, a aplicação cliente (dispositivo móvel) executa requisições à aplicação servidora, onde se encontra o banco de dados, mas pode ter um baixo desempenho, perda de velocidade e serem custosas ao se considerar o tráfego de informações [2][4][5][6].
Diante destas circunstâncias, torna-se (no mínimo) interessante trabalhar com um nível de persistência local temporária nestes dispositivos móveis como solução para as desvantagens citadas. Assim, somente haveria requisições entre as aplicações cliente e servidora quando a primeira não possuísse os dados necessários em seu repositório local ou quando fosse necessário persistir novos dados gerados. Diante desta nova perspectiva, reduz-se o tráfego de informações e melhoram-se os resultados com relação a tempo, desempenho e custos, dentre outras vantagens quanto a realizar constantes buscas junto ao banco de dados (aplicação servidora). Para avaliar a influência da persistência local em dispositivos móveis utilizou-se a plataforma Java Micro Edition (Java ME).
Apresentação da Aplicação e seu Funcionamento
Para o desenvolvimento do presente artigo foram criadas três aplicações: uma servidora (utilizando Java EE); e duas cliente (utilizando Java ME), com as ferramentas NetBeans e NetBeans Mobility Pack (ambas na versão 5.5.1), Sun Java Wireless Toolkit (Java ME Wireless Toolkit) e Mobile Service Architecture (MSA, JSR 248), além do Java Development Kit (JDK, na versão 5.0).
Uma das aplicações cliente sempre realiza requisições de dados à aplicação servidora, enquanto outra aplicação, quando precisa acessar os dados, primeiro verifica se estes estão salvos temporariamente no próprio dispositivo e, caso não estejam localmente, requisita-os à aplicação servidora e os armazena no dispositivo. Independente de qual aplicação cliente for utilizada, a arquitetura caracteriza-se como cliente/servidor padrão (Figura 1), com clientes que interagem com os usuários e com um servidor que recebe e responde às requisições. Esta comunicação entre as aplicações cliente e servidora ocorre por meio do protocolo HTTP (HyperText Transfer Protocol) com o propósito de realizar pedidos de Produtos para Clientes (consumidores ou compradores), recuperando e salvando dados junto à aplicação servidora.
Figura 1. Arquitetura da Aplicação.
Na Figura 1, quando a aplicação cliente-1 precisa se comunicar com a aplicação servidora, esta envia um pedido pela Internet. Este pedido é interpretado pela aplicação servidora e uma resposta é gerada e enviada de volta. A comunicação entre as aplicações cliente-2 e servidora ocorre da mesma forma, mas, antes de cliente-2 enviar um pedido, esta verifica se já não possui localmente os dados necessários. Caso esses dados sejam encontrados, são recuperados do próprio dispositivo, sem qualquer comunicação entre as aplicações.
Descrição e Considerações quanto à Aplicação Servidora
Esta é uma aplicação web com um servlet que recebe e responde a requisições das aplicações cliente. Estas requisições podem ser pedidos de dados que precisam ser recuperados do BD localizado junto à aplicação servidora ou podem ser novos dados gerados nas aplicações cliente para serem persistidos.
Para desenvolver essa aplicação criou-se um projeto Java Web com a estrutura apresentada na Figura 2 e cujas relações são identificadas na Figura 3. No pacote tcc.beans estão as classes Cliente, ItemPedido, Pedido e Produto, que representam os dados a serem persistidos no banco. Para isso, estas classes possuem a anotação @Entity e algumas outras que permitem que o Hibernate as reconheça como classes de objetos que devem ser persistidos e/ou recuperados.
Figura 2. Estrutura de Pacotes e Classes da Aplicação Servidora.
Figura 3. Relacionamento entre as Classes e Pacotes da Aplicação Servidora.
No pacote tcc.dao estão as classes HibernateUtil e Dao. A primeira carrega as configurações do hibernate.cfg.xml (arquivo de configuração da conexão com o BD e classes mapeadas) e implementa os métodos de controle das conexões e transações com o banco. Já a segunda classe (Dao) persiste e recupera os dados.
No pacote tcc.servlet está a classe TCCServlet, um servlet que possui a implementação de métodos que fazem chamadas aos métodos de carregamento e persistência de dados da classe Dao, além da conversão de objetos para stream (seqüência de caracteres). Já no pacote tcc.webtomobile está a classe WebToMobileServlet, o servlet criado pelo NetBeans Mobility Pack e que usa o método POST do protocolo HTTP para transferir dados entre as aplicações cliente e servidora. A criação deste servlet pelo NetBeans Mobility Pack propicia uma grande facilidade, pois automatiza a criação da conexão fim-a-fim entre a aplicação Java ME e a servidora, já que ele é o real responsável pelo recebimento das requisições das aplicações cliente. Por fim, em tcc.webtomobile.webtomobilesupport foram criadas algumas classes utilizadas por WebToMobileServlet e ainda outras classes utilizadas na leitura e escrita dos objetos enviados para atender as requisições recebidas.
Funcionamento do Servlet
O servlet é a classe responsável por receber e responder a requisições das aplicações cliente. Neste projeto, a classe TCCServlet implementa métodos que utilizam as classes do pacote java.tcc.beans, java.tcc.beans.util e java.tcc.dao para gerenciar os dados recuperados da base de dados e persistir aqueles enviados pelas aplicações cliente. Para isso, a classe TCCServlet implementa os métodos getListaTodosProdutos() para recuperar a lista dos Produtos salvos e o método getListaTodosClientes() para recuperar a lista dos clientes (consumidores ou compradores) cadastrados. Neste contexto, os objetos são convertidos em streams pelos métodos toStream (Listagem 1) das classes do pacote tcc.beans.util para serem transmitidos. As classes do pacote tcc.beans.util, por sua vez, herdam as propriedades das classes do pacote tcc.beans e utilizam a classe Tokenizer do pacote tcc.util para a conversão.
Listagem 1. Método toStream da classe ClienteConverter.
01 public String toStream() {
02 if (endereco == null || endereco.length() == 0)
03 endereco = SEPARADOR_VAZIO;
04
05 if (telefone == null || telefone.length() == 0)
06 telefone = SEPARADOR_VAZIO;
07
08 StringBuffer sb = new StringBuffer();
09
10 sb.append(String.valueOf(id)).append(SEPARADOR_CAMPO)
11 .append(nome).append(SEPARADOR_CAMPO)
12 .append(endereco).append(SEPARADOR_CAMPO)
13 .append(telephone).append(SEPARADOR_REGISTRO);
14
15 return sb.toString();
16 } // public String toStream
Quando a requisição da aplicação cliente consiste na persistência de novos dados, é necessário recompor o objeto da classe Cliente (consumidores ou compradores) e o Vector de ItensPedido (Listagem 2 – linhas 68 e 75, respectivamente). Para isso, implementou-se o método salvaPedido(String clienteStream, Vector itens) na classe TCCServlet que, depois da recomposição cria e persiste um objeto do tipo Pedido junto à aplicação servidora (Listagem 2 – linha 84).
Listagem 2. Método SalvaPedido da classe TCCServlet.
63 public boolean salvaPedido(String clienteStream, Vector itens){
64 try{
65 Vector
66 HibernateUtil.openSession().beginTransaction();
67 ClienteConverter cc = new ClienteConverter();
68 cc.fromStream(clienteStream);
69 Cliente c = (Cliente) Dao.Load(Cliente.class, new Long(cc.getId()));
70 Pedido pedido = new Pedido();
71 pedido.setCliente(c); pedido.setData(new Date());
72 List
...
