Motivação para uma nova arquitetura de aplicações corporativas

Realmente, o meu artigo "É hora de balançar a árvore", rendeu muita polêmica. E a ideia era essa mesmo. Porém, alguns comentários que recebi me fizeram refletir muito, e, depois de tanto pensar e pesquisar, vi que eu estou certo, e que, ao adotar esse "emaranhado" de frameworks do ecossistema corporativo Java, estamos criando um passivo técnico gigantesco para o futuro.






Eu recebi um email bem interessante, vindo de um leitor do referido artigo:

"... esse ponto de vista que você mostrou é pessoal e você não pode extrapolar isso para todas as aplicações corporativas. Java Enterprise Edition e todos os outros frameworks Java apresentam muitas vantagens no desenvolvimento de aplicações corporativas e isolam o desenvolvedor das características de cada plataforma e linguagem..."

Bem, o Leitor apresentou duas questões importantes:

1. O meu ponto de vista sobre o "Acoplamento de Plataforma" gerado pelo uso do ecossistema Java, é pessoal, portanto, sem muito embasamento junto à comunidade de desenvolvedores;
2. O ecossistema Java isola o desenvolvedor das características das plataformas e linguagens utilizadas, e isso é uma vantagem.

Opiniões sobre o Java EE e seus associados

Além das estatísticas do HotFrameworks, e do relatório Technology Radar, existem muitas opiniões parecidas no Mercado. Há algum tempo, me deparei com um site bastante interessante: I Hate JSF, que, apesar de tendencioso, traz alguns comentários que nos fazem pensar a respeito, por exemplo: 

"html5? pass-through attributes? Sounds like a ugly joke. OmniFaces? Great another workaround package to get it work. Too slow? Configure your application? How to configure a Lifecycle bug? With another piece of ugly workaround "frameworks"?"

"Long time java programmer. Wasn't happy with spring JSP for being slow and cumbersome. Tried JSF and had the same problems, but with added complexity. Moved my client to AngularJS/html and changed our server API to return JSON and couldn't be happier. If you are trying to find a client side framework find a pure JS/HTML/CSS solution."

"Simple posts render the whole tree again in the server side. Slow! Terrible to be integrated with java script! Component development is so difficult! Terrible to scale! "

"To complicated. To buggy. To silent (in error case). Bad IDE support even when using Netbeans or Eclipse with JBoss Tools 4. But MOST of all: Because the lifecycle is a design BUG! Its not possible to create a scalable high performance web application with the possiblity of using multiple tabs." 

"JSF does not support HTML5 properly. Try to modify how tables are rendered (almost impossible). JSF does not separate the view from the model. Try to have an HTML/CSS web-designer create a mock-up for a JSF project. JSF mandates use of the bean-model with public get/set methods. This violates important software engineering pillars like encapsulation, information-hiding, consistency and immutability. JSF does not have a controller, violating MVC patterns. The most recommended JSF method is to have backing beans return the URL to the next page, the reverse of having a central controller. There are tons of bugs in JSF 2.x STILL after years of evolution. Upgrading to the latest version of whatever component is not an option for commercial organizations (x breaks y, etc)."

Em resumo, as maiores críticas são quanto ao "encapsulamento" do HTML5 e do Javascript (a segunda questão, apontada como "vantagem" pelo email que recebi), além da complexidade e dificuldade de programação. Tem várias outras queixas de performance e bugs.

O site "Zero Turn Around" publicou um "productivity report", de 2011, no qual ele analisa os depoimentos de 1300 desenvolvedores, sobre o que eles utilizavam para trabalhar. Veja que interessante:

O JSP ainda é mais utilizado que o JSF! Por ser mais fácil e parecido com a metáfora LAMP, o JSP ainda tem um público cativo, bem maior que o JSF. Pelo que vimos no HotFrameworks, essa tendência continua até agora.

Mas o problema não é só o JSF

O próprio EJB vem deixando de ser popular. Os Entity beans foram substituídos há muito tempo por soluções O/R mais simples, baseadas em Hibernate e/ou JPA, conforme o mesmo gráfico demonstra. Eu fiz uma pesquisa usando o Google Trends, para ver qual foi o interesse maior em 2013 e veja só:

Interesse por EJB até 2013

Interesse por Java REST json até 2013

Parece que as pessoas passaram a se interessar mais por RESTful Web Services e JSON do que por EJB. Vamos ver em um contexto mais específico, por exemplo, a comparação de Tags do "StackOverflow":

 Este gráfico demonstra que o interesse por JAX-WS, a especificação Java EE para criar Web Services, ultrapassou o interesse por EJB, a partir de 2012.

Os desenvolvedores estão buscando por soluções de menor Complexidade Acidental, e menor acoplamento, duas características nas quais o EJB perde feio para o Web Service.

Sobre as vantagens do "isolamento" que o Java EE oferece

Bom, para começar, vamos relembrar o que o Technology Radar falou sobre isso:

"Nós continuamos a ver as equipes enfrentarem problemas usando JSF - JavaServer Faces - e estamos recomendando evitar esta tecnologia. As equipes parecem escolher JSF, porque é um padrão J2EE, sem realmente avaliar se o modelo de programação lhes convém. Achamos que JSF é falho porque tenta abstrair HTML, CSS e HTTP, exatamente o inverso do que os frameworks web modernos fazem. JSF (assim como os webforms, do ASP.NET) tenta criar manutenção de estado em cima do protocolo HTTP, que é inerentemente "stateless", e acaba causando uma série de problemas envolvendo estado do lado do servidor compartilhado. Estamos conscientes das melhorias no JSF 2.0, mas acho que o modelo é fundamentalmente quebrado. Recomendamos às equipes usarem frameworks simples e abraçarem e compreenderem as tecnologias web, incluindo HTTP, HTML e CSS."

Eu acho que, ao decidir desenvolver uma solução corporativa baseada em Java EE, você acaba se isolando de qualquer outra possível solução, devido ao Acoplamento de Plataforma. Por exemplo, vamos imaginar que você desenvolva um conjunto de Session Facades para processar algumas regras, logo, todos os Clientes que os acessam deverão ser feitos em Java, usando as classes API que você gerou (classes-clientes). Se quisermos integrar um Cliente feito em PHP, por exemplo, teremos que criar uma camada baseada em Web Services, para servir de interface.

É por isso que vemos um interesse cada vez maior por Web Services. Eu mesmo tenho visto a troca de componentes EJB por Web Services, nos projetos mais recentes, pois aumenta a interoperabilidade com outras soluções.

Em parte, isso é culpa exatamente o extremo isolamento causado pelo Java EE, que faz com que as decisões acabem excluindo outras soluções possíveis.

Em resumo

A tendência de usar RESTful Web Services, observada na pesquisa do Google Trends, aponta na direção de uma arquitetura mais "desconectada" (na falta de termo mais adequado), que permita o intercâmbio mais fácil entre componentes de plataformas distintas.

Muitas soluções "híbridas" para sistemas corporativos estão surgindo, por exemplo "Ajax-JSON-REST": Páginas escritas em HTML5 e Javascript, falando diretamente com RESTful Web Services, feitos em JAX-RS, trafegando dados em JSON, sem a interferência de um Web Container Java EE.

APIs baseadas em XML e SOAP estão sendo preteridas em função do REST / JSON, que permite integração mais fácil com outras soluções (como o Node.js).