Java Web ou Java Desktop

Fui perguntado no trabalho, para opinar a respeito de criar uma nova aplicação java, mas escolhendo uma dentre as três alternativas abaixo:

1ª) Aplicação WEB utilizando Browser (Internet Explorer, Mozilla, etc) no client;
2ª) Aplicação Desktop utilizando JSE com Web Service;
3ª) Aplicação Desktop utilizando JSE com RMI

Resolvi criar este post com a minha resposta. Aí vai:

Vou dividir minha análise em dois aspectos principais, que de acordo com o que eu entendo, englobam as maiores dúvidas a respeito da escolha a ser feita nesses casos: distribuição do software ao cliente e distribuição da arquitetura de camadas lógicas (ou negócio, que seja). De qualquer forma, é muito difícil de encaixar uma opinião adequada sem saber o contexto na qual o desenvolvimento deste aplicativo está envolvido. Se eu tivesse o contexto bem definido em mente, talvez a resposta pudesse ser mais óbvia.

Em relação à distribuição de software ao usuário, pelas alternativas fornecidas, acredito ser muito clara esta preocupação. Distribuir um software desktop (seja qual for a plataforma) nunca foi, nem nunca será um trabalho fácil por muitas complexidades que eu poderia citar de bate-pronto, como por exemplo: dependências (versão de JVM, autorizações individuais de firewall para protocolos diversos) , requisitos locais (capacidade mínima de processamento do micro do usuário, privilégios impostos pelo administrador de rede) além das atualizações automáticas enviadas pelos administradores de rede, que podem eventualmente danificar um ambiente elaborado para rodar a aplicação.

No que diz respeito a manter o próprio software e a versão do JDK atualizadas ao usuário, felizmente em java existe uma tecnologia extremamente eficaz que é a “Java Web Start (JWS)” (http://java.sun.com/products/javawebstart/) . Esta técnica permite com que os desenvolvedores mantenham uma única cópia do instalador do software em um local designado na rede, deixando a cargo do JWS o cuidado com as dependências de software, como por exemplo versão da JVM, softwares de terceiros, bem como o próprio software desenvolvido. Funciona basicamente assim: um usuário acessa via browser o endereço estipulado pelo desenvolvedor, e o restante (instalação de VM, instalação de software de terceiros e do próprio sistema) é feita de forma automática pelo JWS. Isto elimina um caminhão de trabalho, mas não acaba com os problemas de autorização de firewall nem requisitos mínimos de hardware dos clientes e este é um ponto delicado. Imagine que em uma aplicação web, caso uma sobecarga seja identificada, basta você melhorar o hardware do servidor. Em uma aplicação desktop com a mesma situação, o hardware de todos os usuários precisam ser melhorados para que o software possa rodar com eficiência, elevando sensivelmente o custo de utilização. Ainda a respeito da distribuição, existe o problema de segurança que envolve uma eventual substituição de arquivos do sistema por arquivos maldosos ou maliciosos. Para solucionar este problema, todos os arquivos enviados para uma estação de usuário precisam ser assinados digitalmente, garantindo que o que ele está rodando é exatamente o que deveria estar rodando.

Em termos de desenvolvimento em si, aplicativos desktop em java infelizmente nunca deslancharam, nunca fizeram sucesso, nem nunca atrairam muitos desenvolvedores. Pelo fato de ser realmente multiplataforma, o desenvolvimento de aplicações desktop é trabalhoso, árduo e um pouco mais demorado. Pessoas experientes neste tipo de desenvolvimento precisam estar presentes, não adianta pedir a um desenvolvedor com experiência em web que passe agora a trabalhar com desenvolvimento desktop em java, as coisas são muito, mas muito distintas. Neste ponto talvez, a opinião de alguém mais experiente do que eu seja mais válida, mas acho que a não ploriferação de aplicativos desktop feitos em java são uma prova viva disto. Ao mesmo tempo, é possível afirmar que existem coisas que só são possíveis de serem realizadas através do desenvolvimento desktop, como acessar periféricos locais, por exemplo. Se este for o caso, desktop é a única alternativa.

Em relação ao desenvolvimento web, os problemas a enfrentar são muito menores. O usuário basicamente precisa de um browser que pode ter uma versão definida e mais nada. Os requisitos são muito menores, as permissões de acesso a serem delegadas por parte de administradores de também são mínimas e as atualizações do software são extremamente simples: atualizando o servidor, todos os usuários estarão instantâneamente atualizados. Requisitos de hardware e segurança, passam a ser centralizados, facilitando a vida de todo mundo.

A maturidade do desenvolvimento de aplicações WEB em java é um ponto extremamente positivo. Existem diversas opções de mercado em termos de padrões e frameworks, com a maioria deles gratuitos. A performance da VM em servidor também é um ponto bastante forte, sendo muito maior do que em um desktop por exemplo. Os servidores web existentes também seguem um padrão estipulado, possibilitando com que produtos de diversos fornecedores possam ser adquiridos sem comprometer o correto funcionamento da aplicação (desde que seja desenvolvida seguindo os padrões). Ao que me parece, o desenvolvimento WEB tem muito mais aspectos positivos em relação à uma aplicação desktop do que o contrário.

Em relação à arquitetura das camadas do software que não fazem parte da camada de apresentação, as duas alternativas fornecidas, “RMI” e Web Service, são válidas também para aplicações web, mas não necessariamente precisam ser utilizadas. Novamente, como não sei o contexto nem possuo os requisitos do sistema, fica bastante difícil fazer afirmações, mas o que eu poderia dizer é o seguinte:

Primeiramente, como “Web Service” é um tipo de RMI, irei considerar que RMI foi colocado aqui com a intenção de se utilizar “Componentes remotos” (http://en.wikipedia.org/wiki/Software_componentry). A diferença básica (existem muitas, mas esta é essencial) que vejo entre os dois, é que para que um método de um “Web Service” seja utilizado, seu cliente precisa conhecer apenas o método desejado, mesmo que ele possua muitos outros. Já no caso de um “componente remoto”, para que um cliente possa consumir um de seus métodos, ele é obrigado a conhecer todos os outros, independente de seu uso ou não (Quando digo “conhecer”, quero dizer conhecer a assinatura (forma de invocação) e não detalhes de implementação). Entendidos este conceitos, e de acordo com o contexto (novamente) do sistema ou de parte dele, a escolha entre um e outro pode tornar-se mais clara e fácil.

- Para aplicações desktop distribuir “o negócio”, em um chamado “servidor de aplicações”, é algo que realmente agrega bastante valor ao projeto, independente de ser via web service ou via componente. Todas as regras de negócio ficam centralizadas e são acessadas pelo cliente remotamente permitindo atualizações fáceis (neste ponto, desde que algumas regras de projeto sejam respeitadas), acessos à servidores de banco de dados também passam a ser centralizadas, e etc. Para aplicações WEB esta afirmação não é tão concreta assim, visto que toda a lógica pode ser mantida no próprio servidor web, desenvolvendo a aplicação utilizando-se um dos diversos frameworks existentes para modelar tal tarefa, como o Spring por exemplo (http://www.springframework.org/), eliminando os problemas conhecidos para desktop.

- Caso realmente seja decidido que a distribuição remota é realmente necessária, para analisar a escolha entre “Componente” e “Web Service”, além do que eu já disse, também é necessário considerar aspectos de performance: RMIs dos Web Service não são tão performáticos quanto RMI-IIOP por diversos aspectos. Web Services também não suportam ambientes transacionais com facilidade, como classes desenvolvidas em Spring ou EJB por exemplo. Porém, caso esses pedaços de software precisem ser compartilhados com sistemas desenvolvidos por terceiros, os web services devem ganhar uma atenção maior.

Bom, dizer qual é melhor a escolha sem possuir o contexto do sistema é muito difícil. O melhor, é sempre aquilo que se encaixa melhor nos requisitos, e isto só pode ser respondido com maior firmeza por quem estiver mais próximo do projeto a ser feito… Mas que bom que não existe uma quarta opção, contendo .NET… Mas mesmo que tivesse, independente de contexto, eu já a descartaria de cara!!