Existe futuro para o Java EE?

Existe futuro para o Java EE? Ainda há esperança para esse famoso stack de desenvolvimento de aplicações corporativas? Ou tudo se resumirá ao Node.js e às tecnologias mais modernas? (imagem feita por j4p4n, obtida do OpenClipart).




Dois grandes amigos meus, cujos nomes não solicitei autorização para citar, comentaram em meus posts recentemente:

"...Mas acho Java é a linguagem ideal do bom programador. Não é a errática e desconjuntada como o Javascript. É uma linguagem elegante, feita para tempos mais civilizados. =-P
Brincadeiras e tal, acho JS uma linguagem bacanuda - ótima para prototipagem e para experimentar. E Node.js torna a brincadeira ainda melhor. Mas tenho medo dessa quantidade de frameworks surgindo do nada. Isso me lembra um certo ecossistrema "robusto e modular..."

"...Não vou comentar sobre JEE, mas gostaria de contribuir dizendo que apesar dos problemas dos frameworks "estruturantes" temos o desafio de nivelar a equipe de desenvolvimento, tornando desenvolvedores com menos experiência produtivos. É como uma fábrica onde é preciso seguir determinadas especificações para obter produtos previsíveis e com qualidade..."

São considerações muito válidas, vindas de pessoas que considero sérias e profissionais, logo, cabe uma reflexão sobre o uso atual e futuro do Java EE.

Javascript é caótico

Sem dúvida alguma! Para começar, é uma linguagem fracamente tipada, o que pode nos levar a erros de lógica terríveis, causando perda de produtividade. Igualmente, não reforça a orientação a objetos, logo, nada o impedirá de criar um código totalmente procedural usando Javascript.

Essas duas características levam a código fonte de baixa qualidade. Existem poucas ferramentas de análise que conseguem criar uma AST (Abstract Syntax Tree) a partir do código Javascript, e analisar métricas de qualidade. Existe a Mozilla Javascript AST, implementada por ferramentas como o SiderMonkey (o engine Javascript do Firefox), que tem uma API para geração de AST e parse de código Javascript.

Porém, as ferramentas de análise de código Javascript ainda são desconhecidas do grande público. Estamos trabalhando no assunto e vamos criar uma versão do jQana exclusiva para uso com Node.js.

Os frameworks são amadores

Comparados com os frameworks do ecossistema Java EE, tudo o que existe para Javascript e para Node.js ainda é muito "amador". APIs mudam da noite para o dia, causando "bugs" em nossos sistemas. Frameworks são criados e abandonados rapidamente, e a moda está em constante evolução.

Parece que as grandes empresas ainda não se interessaram seriamente pelo Javascript, talvez, devido ao seu grande envolvimento com o próprio Java.

Ainda há dúvidas quanto à Robustez e Segurança

Com certeza absoluta! O próprio Node.js foi criado em 2009! É lógico que ainda não temos experiências suficientes para analisar a robustez e segurança das aplicações feitas com ele. Uma breve pesquisa por "node.js security issues" no Google, revela muita preocupação com o assunto.

E, quando à robustez, existem muitas preocupações quanto a tão divulgada "performance" das aplicações Node.js, sob tráfego pesado ou computações complexas. Eu mesmo postei um artigo sobre o assunto aqui mesmo.

Arquitetura diluída não significa usar apenas Node.js

Eu tenho defendido aqui um conceito que, por falta de nome melhor, chamei de "arquitetura diluída", na qual diluímos as responsabilidades por vários componentes, ao invés de concentrar tudo em um stack de frameworks dentro do Container Java EE.

Isso não significa que devemos abandonar o Java EE (e o Java) partindo para usar somente Node.js. O que eu acredito é que, ao basearmos nossas decisões de negócio exclusivamente no ecossistema Java, usando coisas como JSF e JPA, estamos criando um "acoplamento de plataforma", criando código legado a cada novo sistema entregue.

Logo, precisamos utilizar uma arquitetura diluída e desacoplada, que permita substituir as várias camadas por qualquer coisa. Para isso, podemos usar:

• JSON como mecanismo de serialização de objetos, ao invés do XML e do mapeamento O/R JPA;
• REST como API de interoperabilidade, ao invés do SOAP;
• HTML 5 / REST como camada de apresentação, ao invés de JSF ou JSP;
• NoSQL como mecanismo de persistência, ao invés de SGBDs relacionais;

E podemos usar isso tudo APESAR de mantermos o Java e o Java EE!

Leia esses artigos que escrevi, mostrando a primeira abordagem que usei para "balançar a árvore":

1. Uma arquitetura diluída: Camada de apresentação;
2. Uma arquitetura diluída: Lógica de negócios;
3. Uma arquitetura diluída: Persistência.

Eu pego uma aplicação (microblog), feita em ambiente Java EE tradicional (JSF/Facelets, JPA/Hibernate) e crio uma versão mais diluída. 

Na camada de apresentação

Eu uso HTML 5 com uma interface REST para conversar com um RESTful Webservice, feito em Java, usando JSON como mecanismo de serialização. Eis o Gist da página HTML:

Não há uma página JSF no Container, não há uma estrutura de componentes JSF sendo passada para o Navegador, e a página é escrita apenas em HTML 5 com jQuery. O controle do estado é feito através de uma "chave de sessão", recebida pela página e repassada nos outros requests.

O controle do estado em si é feito no Banco de dados.

Na camada de lógica de negócios

Eu uso um Webservice RESTful, criado usando o JAX-RS, e que roda dentro de um Container Jetty, embutido. Eis o Gist e o código:



O Webservice não é diferente de qualquer webservice feito em Java EE. Eu uso os métodos HTTP GET e POST, passando e recebendo objetos JSON ou parâmetros via "extra path".

No final do código, há um método estático "main", que configura e sobe o Container Jetty. Como ele é "stateless", posso subir quantas instâncias eu desejar.

Na camada de persistência

Eu uso um DAO MongoDB, que recebe objetos JSON e os persiste no banco NoSQL. Eis o Gist e o código:



É bem simples.

Sobre o exemplo

Embora eu não tenha implementado tudo, ele funciona muito bem, é escalável e é baseado em Java EE. Só que é um "café carioca", ou seja, diluído com um pouco de água. É uma arquitetura diluída e desacoplada, pois posso substituir as camadas sem ter que re-escrever o código fonte.

E foi o que eu fiz. No artigo seguinte (Arquitetura diluída: "limando" o Java EE !), eu substitui a camada de lógica por um serviço REST feito em Node.js, mas mantive as camadas de apresentação e de persistência, pois continuei consumindo o DAO MongoDB feito em Java, e usando a mesma página HTML 5.

Eu provei que é possível continuarmos a usar Java e Java EE, mas de forma diluída, diminuindo a concentração no stack de frameworks que compõem o Java EE, criando uma aplicação mais simples e flexível.

Conclusão

Eu acredito que os próprios desenvolvedores do Java EE já vinham pensando nisso, quando criaram o Java EE 6 incluindo OSGI e profiles. Não tenho dúvidas que o Java EE 7 e as futuras versões serão ainda mais desacopladas e interoperáveis.

De qualquer forma, acredito que o destino das aplicações "monstro" baseadas no ecossistema Java, compostas por: JSF, JPA, SOAP/XML e EJB, já está selado. Elas vão desaparecer!