GWT - Spring [Security] - JEE: Do not try this at home

Apesar de ter tido recentemente funções mais comerciais e administrativas, ainda escrevo código. 

Acontece que as interfaces de usuário em Java têm me deixado bastante insatisfeito. JSF, e sobretudo os frameworks baseados nessa tecnologia não me convenceram.  Alternativas também não me seduziram. Adobe Flex tem seus usos mas é - na minha experiência - uma tecnologia delicada. JavaFX... alguém já usou ?

Aproveitei um novo projeto para testar algumas tecnologias que achei interessantes mas que não tinha usado em projetos reais. Principalmente GWT (Google Web Toolkit), Java EE 6 e Spring Security. Apesar de não serem tecnologias novas, Spring e GWT evoluem constantemente.

Technology stack

• Google Web Toolkit para a interface de usuário. Tecnologia interessante, com um showcase mais do que convincente, as proprias aplicações da Google. Para o marshalling entre o Javascript e a parte Java, me limitei a usar o próprio GWT (RemoteServiceServlet).
• Java EE para a lógica de negócios, disponibilizada em serviços (session beans). Um teste interessante seria expor esses serviços com REST,XML/JSON. Mas isso é outra história.
• Spring Security para a segurança da camada de apresentação, por ser mais rico do que a segurança padrão.

Primeiras conclusões

Globalmente, as primeiras conclusões da experiência são as seguintes. Nada muito novo afinal. Apenas uma opinião, claro. Em matéria de arquitetura de sistemas, tudo se discute.

• RIA é bom... mas não vem de graça. Interações mais ricas com o usuário devem ser previstas e... programadas: o código tem tendência a aumentar tanto em quantidade quanto em complexidade. Mesmo com frameworks poderosos.
  
• RIA é bom... mas tem riscos. Como todas as tecnologias RIA que conheci, GWT é uma ferramenta poderosa mas não sem riscos em termos de complexidade do código escrito. Em comparação com um bom velho MVC como Struts, GWT é menos "dirigista" no desenho do codigo. Tem um grande risco de deixar a entropia natural levar o codigo... para o buraco. Mas esse risco não é próprio do GWT. Encontrei o mesmo com Adobe Flex. Se for mal desenhada (tecnicamente falando) desde o inicio,a interface usuários pode se tornar um inferno para debug e manutenção.
• Usar essas tecnologias todas em uma só aplicação não é claramente uma boa escolha (do not try this at home). Em particular, não vejo valor agregadao em misturar Spring e Java EE (EJB). Muito pelo contrário, a integração de dois containers IoC concorrentes (Spring IoC e CDI) já é em si um problema. Mas vale ressaltar que um dos objetivos do projeto era justamente testar a integração do stack completo.
• Devo dizer que discordo bastante do discurso comercial em volta de Spring. Só um exemplo: Spring security foi escolhido por ser funcionalmente mais rico do que a plataforma JavaEE. Infelizmente, apesar de declarar que "Spring Security é um produto separado de Spring"...  o "method security" só funciona para beans gerenciados pelo Spring (ou precisa integrar AspectJ). Ilustra muito bem o fato que Spring é um produto comercial concorrente da plataforma JavaEE.
• A principal dificuldade que encontrei foi a segurança. GWT, usando RPC através de servlets, não se da muito bem com a segurança clássica Java EE (só basta imaginar em caso de timeout de sessão).
• E como sempre para quem se aventura em "terra incognita", a documentação faz toda a diferença. Infelizmente, mesmo com milhares de artigos comparando Spring e EE, ainda falta uma boa documentação

Provavelmente terei a oportunidade de colocar mais posts no assunto, sobre detalhes de how-to's e lições aprendidas.