Fragmental

8/10/2005

Pilhas Proprietárias, Pilhas Livres e Pilhas Padronizadas

Qual é o clima atual no mundinho JEE (ou J2EE se você ainda não está nos novos tempos) ?

Há Muito Tempo Atrás, Numa Galáxia Muito Distante...
No início, havia o caos. A única pseudo-padronização no mundo das aplicações cooporativas de massa era o MTS com COM. Quem podia, contava com Tuxedo e UNIX, mas isso não era muito comum fora dos bancos e operadoras de telecomunicações (que tem dinheiro de sobra).

Se você queria contruir uma aplicação transacional, distribuída (CORBA ou DCOM, únicas opções levadas a sério), escalável, cheirosinha, você tinha que escolher um fornecedor. Ao contrário de JEE, os fornecedores não lhe davam uma implementação, eles lhe davam toda a tecnologia, você ficava preso a ela.

JEE Ao Resgate (ou Desgaste)
Então, alguém pensou em usar aquela linguagem de applets para produzir aplicaçõs de verdade e foram surgindo as especificações que culminaram no JEE, com o poderoso EJB como seu Rei e Deus.

A pilha JEE é comsota por tantas especificaçõe sque abrangeriam quase tudo necessário para uma aplicação de grande porte.

O grande problema, como quase sempre, foi a dose excessiva de hype. Toda documentação sobre JEE pré-2003 vai te falar em objetos distribuídos, componentes distribuídos, aplicações distribuídas, transações distribuídas, interfaces distribuídos... e surgiu a Primeira Lei da Distribuição de Objetos, de Fowler:
Não Distribua Seus Objetos
Distribuir objetos num sistema é de uma forma bem geral desnecessário e complexo, mas JEE faz pensar que se você não distribui (ou não consegue distribuir) objetos, você é um marsupial, já que tem toooodas aquelas maravilhas tecnológicas para suportar isso. Para ter uma noção, basta saber que a especificação de EJB 1.0 não previa acesso local, apenas remoto, aos componentes.

Apesar dos problemas, JEE surgiu e se manteve como a plataforma de facto para aplicações enterprise (seja lá o que isso signifique de verdade).

Mas.. com o passar do tempo a coisa foi pegando fogo. Pessoas desenvolveram alternativas bem viáveis aos recursos de JEE criticados (EJBs, quase sempre), e surgiram ferramentas fantásticas como o Spring Framework e o Hibernate, mas que são proprietárias (são software livre, mas não são um padrão).

O Hibernate, depois de ganhar gás ao ser incluído no JBoss, virou modelo para o EJB 3.0. O Spring, apesar de uma plataforma comprovadamente (pelo menos por mim) excepcional, não teve a mesma sorte, e agora que a nova especificação de EJB traz recursos de IoC, começou uma guerrinha entre projetos. A projeto Hibernate vem tratando com hostilidade o povo do Spring, já que eles "não são o padrão".

Piratas, Padrões e Picaretas
Se você for começar um projeto hoje, que tecnologias vai utilizar?

Se você for uma ameba ou trabalhar para amebas, vai usar EJB sem nem ler requisitos. Se você for um cara que sabe avaliar a melhor ferramenta para o serviço, come vegetais e exercita o cérebro, vai acabar numa senhora dúvida.

A pilha JEE oferece muitos serviços e muita complexidade, mas pelo menos é padrão.

O Spring oferece serviços de uma forma leve e bonitinha, mas não é padrão (seus objetos de negócio não estão presos ao Spring, não é tão difícil migrar os serviços para alternativas caso queira),e é apenas um entre muitos.

Claro que se você prefere que os outros façam a escolha por você, algumas empresas estão criando suas próprias pilhas, empacotando projetos Open Source e formando suas próprias visões do Java para aplicações de grande e médio porte (Pequeno porte? Por favor, esqueça JEE, se não Java. Conhece o Rails?). Temos uma brasileira, inclusive.

Então, temos um problema.
Temos mesmo?

Liberdade de Escolha
A confusão tem seu lado bom. Se fosse nos antigos tempos negros do Java Enterprise Edition, você não teria escolhas, tinha que usar EJB e pagar milhões num Servidor de Aplicações. Hoje você pdoe resolver o mesmo problema de milhões de maneiras diferentes e com um Tomcat (ou Jetty se você for um cara esperto).

Leia a seçaõ acima de novo, mas com outros olhos. Você pode escolher. Isso é muito importante.

Infelizmente, escolher bem é difícil. No mínimo você deveria conhecer um pouco sobre o cenário atual, o cenário futuro e muito sobre tecnologia. Existem pessoas que simplesmente precisam que alguém lhes diga o que fazer, o que usar, e para estes um cenário mais fechado é o ideal.

Seja lá o que você escolher, considere alguns pontos:
  • Empresas podem acabar, cuidado ao se prender a uma
  • Projetos de Open Source Software podem acabar, mas o código esta lá (você acha que se o Struts for definitivamente e indubitavelmente depreciado ninguém vai mantê-lo?)
  • Não use uma tecnologia onde mais de 20% do código construído por seus programadores (ou ferramentas) é pumbling (configuração, adaptadores, gambiarras) e não regra de negócio
  • Não ache que uma ferramenta (Editor, IDE, plugin, Ant Task) vai reduzir complexidade gerando código (código gerado conta nos 20% da regra anterior, bytecode gerado não conta)
  • Não se prenda a uma plataforma que não permita integração com o padrão JEE (mes mo EJB)
Por esses pontos, hoje, eu escolheria o Spring em boa parte dos meus projetos. Qual a sua escolha?

(Este post foi motivado pelo do Floyd Marinescu)


 
f