Arquivo Discussoes de Programacao e Tecnologia 
Estava lendo um material e encontrei duas categorias para aplicações Web:
J2EE : recursos de escalabilidade, distribuição, facilidade de integração, etc …
POJO : aplicações mais simples, que não precisam de recursos de um Application Server, desta forma, podem ser implementadas apenas por páginas JSP e Servlets.
Oq a galera do GUJ anda desenvolvendo?
Essas duas categorias nao existem 
Uma aplicacao Web pode ser feita com ou sem EJBs, mas a existencia ou nao de componentes EJB no desenho da aplicacao nao deveria mudar a forma como ela eh desenhada. A implementacao muda, claro, mas se a arquitetura for boa, nao vai fazer diferenca 
Dito isto, estou usando trio WebWork2 + PicoContainer + Velocity, e tem funcionado muito bem ate agora (e isso aqui nao eh nenhum sitezinho da Tia Cleide, eh um internet banking ;))
PS: pra quem ficou boiando, POJO = Plain Old Java Object, ou, traduzindo, “objeto java qualquer” 
PS: Desculpa se alguem aih tem uma tia chamada Cleide - a intencao nao foi ofender
Cv, caramba!
Que show de diplomacia, hein?? Até a Tia Cleide vc garantiu!!
[]s!
[set flamewar mode off]
Usar POJO é uma solução muito mais flexível em comparação ao uso de EJBs para qualquer tipo de aplicação, uma vez que seus objetos precisam “assinar” uma quantidade muito menor de contratos (afinal, seu objeto não precisa ser um javax.ejb.SessionBean, ter uma javax.ejb.HomeInterface/EJBObject, etc etc), além de você não precisar carregar um mastodonte do tamanho de um Weblogic/Websphere/JBoss/Sun One/<coloque aqui seu appserver> para apenas fazer o deploy da sua aplicação. 8) Mas concordo que há nichos em que EJBs podem ser úteis, só não me ocorre um exemplo neste instante. :twisted:
[set flamewar mode off]
Usar POJO é uma solução muito mais flexível em comparação ao uso de EJBs para qualquer tipo de aplicação, uma vez que seus objetos precisam “assinar” uma quantidade muito menor de contratos (
daniel, assinar mais contratos nao faz de voce menos flexivel… pode fazer de voce mais complicado, mais pesadinho, mais chato de ler, com mais coisas inuteis, mas nao menos flexivel.
O lance eh que a gente nao vê sempre projetos com vários application servers e transações distribuídas…
… mas que tem, tem!!
[set flamewar mode off]
Usar POJO é uma solução muito mais flexível em comparação ao uso de EJBs para qualquer tipo de aplicação, uma vez que seus objetos precisam “assinar” uma quantidade muito menor de contratos (daniel, assinar mais contratos nao faz de voce menos flexivel… pode fazer de voce mais complicado, mais pesadinho, mais chato de ler, com mais coisas inuteis, mas nao menos flexivel.
Hmmm, entendi o que você quis dizer, Paulo, e de fato eu acho que me expressei mal. :oops:
PS: pra quem ficou boiando, POJO = Plain Old Java Object, ou, traduzindo, “objeto java qualquer”
Acho a tradução de POJO para “Bom e Velho Objeto Java” mais interessante!
Um cara que defende POJO é o Martin Fowler :http://www.martinfowler.com/isa/domainModel.html