Mentawai ou Spring

O uso de um não exclui o outro. Inclusive existe uma integração entre os dois: http://www.mentaframework.org/spring.jsp
Assim você pode usar o Mentawai como framework web e Spring como framework IoC\transaction management\etc.

Prefira utilizar o Spring para IoC\etc caso o seu sistema tenha que ter em algum momento transações que não sejam “required” (mais de uma transação por request), se você for utilizar outros recursos do Spring ou se você for ter centenas de classes gerenciadas pelo IoC do Spring.

Prefira o Mentawai para IoC se você não precisar de um sistema complexo de transações (uma transação por request) que o mentawai fornece.

A questão principal é usar a ferramenta certa para o problema certo. E isso é o principal problema da maioria dos projetos. Muitas vezes usa-se uma bazooka para matar uma mosca, resultado em um mar de complexidade desnecessário.

Pra que vc precisa do Spring?

Pra que vc precisa do Mentawai?

Veja o que os caras da Sun que trabalham com o OpenSolaris (devem gostar de complexidade!!!) falaram sobre Spring + WW2:

Sobre Spring achei isso no site do WW:

Vc vai usar AOP ??? Vai usar demarcação de transação ??? Existe várias outras soluções para IoC e Auto-wiring: Guice, Pico, Miocc, etc. O Mentawai já fornece um ótimo suporte a IoC (http://www.mentaframework.org/ioc.jsp) e Auto-wiring (http://www.mentaframework.org/depinj.jsp). Veja também as receitas rápidas para IoC (http://recipes.mentaframework.org/posts/list/8.page) e Auto-wiring (http://recipes.mentaframework.org/posts/list/14.page).

É importante notar tb que o Mentawai não é apenas um framework MVC, não é apenas mais um controlador MVC. O Mentawai é uma solução FULL-STACK, que vai desde do pool de conexões, passando por IoC, autenticação, tags, ajax (server-side e client-side), etc. Vc até pode criar sua salada de frameworks (e colaborar para a não tão boa reputação do Java em desenvolvimento web), mas o Mentawai não o encoraja a fazer isso, pois ele oferece soluções ou abstrações para todos os problemas repetitivos de toda aplicação web. Até cluster e fail-over o Mentawai provê para aplicações web em load balance (cache distribuído => http://recipes.mentaframework.org/posts/list/19.page). Só ficaria faltando chamadas remotas e mensagens assincronas, mas aí realmente não faria qualquer sentido, pois estamos falando de aplicações web e não aplicações distribuídas.

SaoJ, muito boas suas considerações, mas deixa eu explicar melhor o que quero fazer e gostaria de sua opinião, se mesmo assim devo utilizar o Mentawai.

Minha aplicação será modular, parte adminstrativa, financeira, biblioteca, etc …
As filiais, 2 no caso, irão acessar o servidor da matriz (isso sem problemas)
Haverá uns 40 usuários internos, como professores e funcionários e os alunos 400 ± que acessaram coisas basicas como notas e tal

Entendo que esteja bastante superficial as minhas especificações, mas o que você acha o Mentawai daria conta?
Em quais casos você acha que o Spring seria melhor?

Não é o Mentawai que vai dar conta disso, é o seu código, se você fizer código porco, não é usando Spring que você vai resolver o seu problema.

Gaste um tempinho vendo o que o Spring pode fazer por vo cê, aprendendo Java de verdade e entendendo como aplicações web funcionam, depois você vai atrás de escrever uma aplicação dessas.

A primeira pergunta que vc precisa responder é: terei um sistema distribuído ou não?

Demorei alguns anos para entender o que realmente é um “sistema distribuído” e quando ele é realmente necessário. Se minha explicação não estiver 100% correta, peço a alguém que colabore.

Um sistema distribuído não é um sistema que vc distribui em CD-ROM, nem uma aplicação em load balance. É algo mais profundo e importante do que isso. Um sistema distribuído é quando vc tem vários sistemas diferentes e independentes rodando em várias máquinas diferentes. E esses sistemas precisam se comunicar entre si.

A comunicação entre sistemas distribuídos pode se dar via mensagens síncronas (chamadas remotas via RPC, RMI, web services, etc.) ou via mensagens assíncronas (JMS, JbossMessagins, WebSphereMQ ou qualquer outra implementação de JMS ou qualquer outro processador de mensagens central como o JGroups).

Quando vc fala que sua aplicação será modularizada com um módulo biblioteca, outro módulo administrativo, etc. imagino que vc terá diversos módulos ou packages rodando na mesma aplicação, rodando na mesma JVM rodando no mesmo servidor web, ou seja, sua aplicação será modularizada mas esses módulos não serão distribuídos. Mas porque imagino que vc não queira distribuí-los? Porque seu cliente é uma escola e não um banco, porque vc não quer sistemas independentes rodando em paralelo, com bancos de dados em paralelo, com máquinas independentes em paralelo, etc. Por que vc não tem necessidade de deixar o sistema financeiro rodando 24 por 7 mesmo que vc esteja dando um restart na aplicação da biblioteca para atualizar algum código por lá, e por aí vai. Se vc desejasse tudo isso, vc teria que pagar um preço de infra-estrutura e complexidade e poderia partir para uma solução baseado em mensagens síncronas. E se vc quisesse tudo isso e ainda quisesse uma escalabilidade bossal, ou seja, se vc amanhã fosse ter 30 outros novos módulos em 60 novas máquinas dentro do seu mega sistema, então com certeza vc precisa de um sistema distribuído baseado em mensagens assíncronas. Escalabilidade bossal (= gigantescamente grande), fail-over bossal, desacoplamento bossal = mensagens assíncronas. De novo, isso é muito bonito, mas é bastante complexo e custoso do ponto de vista de infra-estrutura, software e mão-de-obra. Sua escola não precisa disso. Os benefícios de uma solução dessas não pagam os custos para a sua escola. Para um banco, uma bolsa de valores ou uma corretora de ações, com certeza o benefício paga o custo. O problema é que quanto mais complexa for a solução, mas as consultorias ganham dinheiro. Então se vc chamar uma consultoria para fazer um projeto para sua escola, muito provavelmente ela vai sugerir um sistema distribuído em mensagens assincronas. É assim que o mundo capitalista funciona. Coisas simples para uma consultoria ou consultores que ganham bastante por hora não se justificam.

Então vamos manter as coisas simples e eficientes. Vc precisa de um aplicação web. Se desejar pode ter dois servidores web em load balance, para se uma máquina bootar o teu sistema não sair do ar. Seus modulos estarão todos dentro da mesma aplicação, ou melhor, serão pacotes dentro da mesma aplicação e não aplicações independentes e distribuídas.

Quando vc pergunta se o Mentawai daria conta, vc diz em relação ao que vc precisa fazer ou ao que o sistema precisa suportar de carga? Posso te garantir, pelo feedback que temos e pelos sistemas que estão hoje rodando com o Mentawai que ele da conta dessas duas coisas. Veja lá no site os depoimentos das pessoas que utilizam o Mentawai. Alguns fizeram até testes de carga e tiveram excelentes resultados.

Agora como o Mauricio falou, vc é o responsável pelo seu código. Se esqueça de dar um close() num FileInputStream e a coisa vai ficar preta para o seu lado, usando Mentawai ou JBoss.

Spring MVC achei horrível. O Menta nunca usei então não posso dar opiniões. Gostei muito do VRaptor.

Dá para fazer um cluster de session através desse cache com JGroups aí? Não conhecia o JGroups. Que coisa louca! Funciona mesmo?

Acho que o Tomcat já tem um session cluster, mas não sei o que ele usa por baixo. Sei que o JBoss usa JGroups para o seu cluster.

Para fazer um cluster de session com o Mentawai, tudo que vc precisaria fazer é usar um cache distribuído para guardar os objetos “User” dos usuários logados. Daí vc faria um filtro que checaria se o User está nesse cache. Se ele estiver, vc pode assumir que ele estava logado numa outra máquina que saiu de cena (caiu/morreu) e ele foi direcionado para essa nova máquina pelo load balancer.

Vc só não pode esquecer de remover o User do cache quando o usuário dar um logout ou a session dele espirar. Acho que o jeito mais fácil de fazer isso é usar o org.mentawai.cache.TimeoutCache, que automaticamente remove um objeto do cache se ele não for acessado depois de N minutos.

Ele é muito flexível e poderoso, tanto que o Grails é baseado no mesmo e sua abstração é fantástica.

Obrigado pelos comentário, irei implementar alguns exemplos para eu me familizar melhor como framework e ver se gosto do estilo do mesmo.
Fiz teste com o VRaptor, achei bastante interessante, mas ele parece pouco flexível quanto a estrutura dos diretórios, me corrijam se estiver equivocado.

Ele é muito flexível e poderoso, tanto que o Grails é baseado no mesmo e sua abstração é fantástica.

Rapaz, testei estes dias o Grails e fiquei fascinado. Deve ser o framework java web mais simples que já vi.

Mas Grails é Groovy e não Java…

saoj:

djemacao:

Rapaz, testei estes dias o Grails e fiquei fascinado. Deve ser o framework java web mais simples que já vi.

Mas Grails é Groovy e não Java…

Nada impede que você use classes Java em Groovy e vice versa.

+1 voto pro V-Raptor!