Eu não te responderia isso sem avaliar o problema, mas um laboratório na NASA acaba de divulgar um videozinho com uma comparação. O vídeo do Sean Kelly é bem engraçado mas traz muito das tendências modernas no desenvolvimento de aplicações, web ou não.
Na atualidade, o laboratório em questão usa Java EE para tudo e avaliou se era a melhor solução para interfaces e aplicações completas web.
O autor começa falando de sua experiência com um sistema em C++ e como qualquer alteração resultava na recompilação de todo o sistema. A solução foi manter partes que são alteradas com mais frequência, no caso interface, em uma linguagem de script, no caso TCL/TK. Este trecho casou muito bem com algo sobre o qual queria escrever faz tempo e que certamente vai guiar minha linha de estudos neste ano.
Aplicações web pequenas geralmente são muito dinâmicas. O layout muda, o esquema muda, tudo muda o tempo todo. Algumas aplicações são temporárias então não vale gastar muito tempo, elas devem se pagar rapidamente. Outras ficam como portais e nossos adoráveis aplicativos online, mas geralmente você também vão precisar de muito dinamismo para enfrentar o mercado atual.
Para estes dois tipos de aplicação eu hoje sugiro fortemente Rails. Eu trabalhei na área de agências web, nestes lugares o trabalho é quase sempre criar um portal e integrar com um backoffice. Antes essa integração era quase sempre feita direto no banco de dados, não que não houvessem opções menos dolorosas, mas era o padrão. Hoje temos o tal do SOA que ninguém sabe direito o que é mas faz com que todas as aplicações acabem com alguma espécie de API para serem utilizadas por outras aplicações.
As aplicações construídas nos tempos mais recentes geralmente têm interfaces REST ou SOAP, as mais antigas e/ou que não tenham estas interfaces podem (e devem, quase sempre) ter um adaptador que permita a outras aplicações utilizá-las sem duplicar o que aquele sistema já faz no novo.
Neste cenário podemos facilmente integrar uma aplicação destinada ao usuário final em, por exemplo, Rails com todo o zoológico de aplicações coorporativas em JEE, .Net, COBOL, C++, Delphi e todas aquelas tecnologias bizarras que parece que só a sua empresa usa no mundo todo. Batsa você colocar a aplicação Rails para conversar com as outras, assim você pode utilizar na sua interface web o que há de melhor enquanto mantêm seus sistemas escritos em Java, C++, .Net ou o que quer que seja.
Mas e quando o que você está construindo são as tais aplicações ‘coorporativas’, as peças que prestam serviços para a interface web?
A maioria dos desenvolvedores quando ouve falar de Ruby on Rails (que eu conheço, anda contra as outras) pensa: “bah! minha aplicação faz muito mais que ser apenas um sitezinho!”
Bom, antes de mais nada:
- Em geral o que é feito hoje nas consultorias são variações de sitezinhos
- Ruby on Rails, por exemplo, traz muito mais produtividade para este tipo de aplicação
- Mesmo que não fossem, Rails serve para muito mais que sitezinhos
Mas vamos partir do ponto que estamos criando uma aplicação que não é apenas um site, não apenas um cadastro que aplica regras de negócio simples em cima de dados.
Eu trabalhei algum tempo em aplicações cuja interface é geralmente um socket aberto falando um protocolo proprietário de um lado e uma interface SOAP no outro. Nada de GUI além de algo muito básico para administração, apenas receber requisições SOAP, processar, mandar mensagens via socket para outro sistema e dar uma resposta SOAP a quem te chamou. O que estes anos me ensinaram é que mesmo neste tipo de sistema existem partes na aplicação que mudam bastante e outras que não mudam quase nunca.
A arquitetura de uma aplicação geralmente não muda. Se você criou seu sistema baseado em EJBs, Servlets e Hibernate, dificilmente isso vai ser alterado no meio do caminho. Mesmo que seja, as pessoas têm alguma noção do custo disso e criam projetos completos para esta migração, ou fazem tudo de forma tão gradativa que viram aqueles famosos projetos eternos que têm data de início mas do fim ninuém sabe.
Já regra de negócio, por exemplo, vive tendo mudanças. Uma promoção que a empresa vai fazer que altera o modo como clientes são cobrados por um mês, uma regulamentação nova ou a reinvenção de algum processo (você sabe, reengenharia de processos está na moda novamente) e lá vamos, como Sean no vídeo, ter que alterar, compilar tudo de novo, empacotar… isso tudo para mostrar ao cliente ver se era realmente o que ele queria. Ah, não é? Repita o ciclo.
Mudanças são parte da vida. O que podemos fazer para evitar que mudanças constantes afetem a produtividade? Que tal adotar uma arquitetura amigável à mudanças?
Java é uma linguagem robusta e segura, muito interessante para construir infra-estrutura, por exemplo, mas não é lá muito dinâmica. Escrever código que está sempre mudando em Java é complicado, envolve mudar arquivos de configuração, recompilação e deployment muitas vezes.
Um grande problema que enfrentei por algum tempo é o modelo monolítico de artefatos em Java EE. Imagine que você gera um grande EAR com toda a sua aplicação. Um EAR geralmente possui uma aplicação web, um conjunto de EJBs ou um JAR de POJOs se você utilizar Spring, por exemplo, e outros recursos.
Imagine que um destes componentes possui um bug (acredite, vão haver bugs) que precise ser corrigido imediatamente. Geralmente nestes casos se implementa um chamado hotfix (ou, em bom português: gambiarra/bacalhau) que vai corrigir de uma forma não-ideal enquanto não se entrega uma versão onde o problema foi realmente sanado.
Ok, você implementa o hotfix e… tem que recompilar, gerar o EAR e mandar pro cliente instalar tudo de novo. Pára servidor de aplicações, instala, sobe tudo de novo…péssimo! Por uma mudança em um componente você teve que parar tudo por talvez algumas horas.
Numa arquitetura C/C++ em UNIX, por exemplo, você possui diversos programas que cooperam através de IPC (comunicação entre processos) para compôr o sistema. Se um destes componentes precisa ser corrigido, o cliente precisa instalar apenas este e não todo o sistema novamente.
A parte do seu sistema que pode mudar é provávelmente a que vai possuir mais bugs no decorrer do tempo, afinal cada mudança pode inserir novos bugs e trazer de volta antigos. Mas e se esta parte da aplicação fosse construída de maneira que qualquer mudança fosse simples e rápida? Este é um tema que pretendo abordar este ano em palestras e artigos.
Como tornar seu sistema mais flexível e mantendo a confiabilidade? Qual o impacto da nova realidade onde Java não é a linguagem única e soberana mas apenas uma ferramenta na caixa do profissional?
Imagine construir uma aplicação com a arquitetura central em Java mas com a Camada Web em Groovy ou quem sabe até Rails num futuro próximo? Que tal escrever suas regras de negócio numa linguagem que seu usuário final entenda e possa ele próprio alterar?
Em breve podem esperar material sobre estes temas com frequência aqui no Fragmental.
–
Voltando á comparação original, os competidores eram variações de Java EE (Servlets, JSP, Hibernate, JBoss em combinações variadas), Ruby on Rails, Django, Zope e TurboGears. As conclusões eu deixo para você ver pessoalmente, eu acho que foram exemplos muito simples para qualquer conclusão maior.
De qualquer modo, faltou um produto interessante: O Seam. Se você quer conhecer este modelo de aplicação que mistura JSF com EJB3, não perca mês que vem a chance de conhecer a paltaforma diretamente da boca de seu inventor, que por um acaso é também inventor do Hibernate(!) e principal colaborador do EJB 3.0 (!!): Gavin King. King vai estar novamente no Rio de Janeiro mês que vem, e não vai estar sozinho! Mais informações em breve.
