Esse artigo faz parte da revista Java Magazine edição 36. Clique aqui para ler todos os artigos desta edição

ht=34 alt=imagem_pdf.jpg src="/imagens/imagem_pdf.jpg" width=34 border=0>

Tira-Dúvidas

O que é melhor, desktop ou web?

Estamos em um impasse aqui no escritório e gostaríamos muito de ajuda. Decidimos trabalhar com Java para desenvolver nossas aplicações contábeis, mas estamos em dúvida se seria melhor usar Servlets/JSP ou Swing.

Marcos Alexandre Miguel

 

De modo geral (não apenas na plataforma Java) preferem-se as aplicações com interface web, pois elas permitem tratar as estações de trabalho dos usuários como “clientes magros”, sem necessidade de instalar, configurar e atualizar software localmente. Estudos realizados pelo IDC e Gartner Group indicam que o suporte a uma estação de trabalho tradicional consome mais de 3 mil dólares por ano, no tempo gasto com a manutenção do software instalado nesta estação e a recuperação de incidentes como ataques de vírus. Assim sendo, quanto maior o universo de usuários, maior a economia obtida pelo uso de interfaces web em lugar das tradicionais aplicações locais gráficas (GUI) – em vez de dar suporte a centenas de estações de trabalho, basta dar suporte a um único servidor ou poucos servidores em um cluster.

Tecnologias para automatizar a instalação e atualização de software local, como o Java Web Start (JWS) reduzem um pouco este custo, mas ainda não chegam ao mesmo patamar de redução obtido pelas aplicações puramente web. Os downloads e instalações automáticos, se não forem bem planejados, podem acabar irritando o usuário ou prejudicando a performance da rede.

Aplicações web também permitem se obter um nível maior de segurança. Por exemplo, o banco de dados poderia ser configurado para aceitar conexões apenas do servidor web, de modo que não seria possível a um usuário mais “esperto” conectar diretamente ao banco para acessar ou modificar os dados. Em uma aplicação gráfica tradicional, cada estação necessita de acesso direto ao banco de dados, o que deixa aberta a possibilidade de o usuário acessar o banco sem passar pelos controles implementados na aplicação.

Por outro lado, quando há necessidade de se digitar grandes volumes de dados, ou quando há necessidade de realizar consultas interativas com muitas opções de reorganização dos dados e aumento ou diminuição do nível de detalhamento das informações, as interfaces gráficas se mostram superiores às interfaces web.

Embora tecnologias como o AJAX estejam reduzindo as diferenças de capacidade das aplicações web em relação às aplicações gráficas, o tempo de rede necessariamente gasto por uma aplicação web garante que ela nunca terá a mesma agilidade e “tempo de resposta instantâneo” que pode ser obtido por uma aplicação gráfica.

Na prática, são bem raros os casos onde a interface web seja um limitador sério para uma aplicação, e boa parte dos usuários hoje gosta da simplicidade de uma interface web em comparação com interfaces gráficas cada vez mais cheias de “fru-frus” e menos padronizadas.

Também se observa, na prática, que muitas aplicações gráficas não fornecem agilidade para a digitação, porque a cada campo de texto ou combobox é feito um acesso ao banco de dados, para validar ou expandir o valor recém-digitado. Estes acessos envolvem a rede e por isso aumentam o tempo de resposta da aplicação.

Um meio-termo interessante é o uso de interfaces gráficas para acessar objetos de negócios em um servidor de aplicações, por exemplo componentes EJB ou web services. Dessa forma é possível obter-se as vantagens de interfaces gráficas em termos de interatividade e tempo de resposta, e ainda assim manter a maior parte do esforço de manutenção e suporte centralizado em poucos servidores. Por outro lado, a complexidade deste tipo de aplicação faz com que muitos prefiram se limitar às interfaces web.

Fernando Lozano

Classloaders e hot-deploy

Tenho um sistema no qual preciso que, a cada chamada de uma classe, uma nova instância da classe seja carregada pelo classloader, pois preciso mudar a classe e o sistema não pode parar (ou seja, é necessário fazer “hot-deploy”). Percebi que no Eclipse quando estou em modo de depuração, a cada chamada ele recarrega a classe mas quando rodo normalmente isso não acontece. Tentei reescrever o classloader, mas parece que o mesmo mantém a classe em cache após a primeira carga. Como faço pra contornar este problema?

Diego Fincatto

...

Quer ler esse conteúdo completo? Tenha acesso completo