Um interessante artigo publicado no IBM-developerworks onde são apresentadas as melhores praticas para o desenvolvimento de aplicações Java EE.
1. Always use MVC.
2. Don’t reinvent the wheel.
3. Apply automated unit tests and test harnesses at every layer.
4. Develop to the specifications, not the application server.
5. Plan for using Java EE security from Day One.
6. Build what you know.
7. Always use session facades whenever you use EJB components.
8. Use stateless session beans instead of stateful session beans.
9. Use container-managed transactions.
10. Prefer JSPs as your first choice of presentation technology.
11. When using HttpSessions, store only as much state as you need for the current business transaction and no more.
12. Take advantage of application server features that do not require your code to be modified.
13. Play nice within existing environments.
14. Embrace the qualities of service provided by the application server environment.
15. Embrace Java EE, don’t fake it.
16. Plan for version updates.
17. At all points of interest in your code, log your program state using a standard logging framework.
18. Always clean up after yourself.
19. Follow rigorous procedures for development and testing.
Maiores informações no link abaixo .:
http://www-128.ibm.com/developerworks/websphere/techjournal/0701_botzum/0701_botzum.html?ca=dgr-jw17Java-EE-Best-Practices#sec10
8. Use stateless session beans instead of stateful session beans.
Como assim? Tem horas que tem que usar Stateful, tem horas que tem que usar Stateless! Se tem que guardar estado, não adianta, é melhor colocar em um Stateful.
Realmente, além de algumas sugestões bem óbvias, outras são, no mínimo, contestáveis para alguns projetos. Exemplo, o controle de transações via container - é bom, eu uso bastante, mas existem transações complexas envolvendo comunicações entre diferentes aplicações, em diferentes containers, que exigem um isolamento maior, i.e., controle por parte do aplicativo. Quem nunca teve problemas assim que atire a primeira pedra…
Na verdade o item 8 diz que vc deve preferir stateless a statefull. Obviamente nem sempre isso é possivel, senao nao existira os dois tipos de sessão. Mas usando stateless o seu sistema fica muito mais facil de gerenciar, testar e as chances de bugs invisiveis diminuem.
As vezes, em vez de usar uma sessão statefull, é melhor persistir o estado nas proprias entidades e recupera-las de novo quando necessario.
Rubem, o problema é que os stateful session beans são tão caros para o servidor de aplicação, que em muitos casos vale a pena guardar o estado em outro lugar (no baco, por exemplo).
Ou ainda, pode-se aumentar a granularidade dos serviços expostos pelos session beans.
Diz a lenda que SFSB escalam mais que banco, session, etc.
Concordo com vocês na questão do SFSB, mas assim alguém poderia argumentar que estamos “ignorando” a sugestão 4, 15… 
Bom, isso vai contra tudo que eu sei de prog. distribuída.
Quanto maior a granularidade e quanto menos recursos segurar, melhor.
Então não vale comparar com http session inchada!
Você lembra de onde vem essa lenda Rubem?
Não acho isso. Não usar muito sfsb não significa não abraçar o Java EE. Assim como não usar Entity Beans (eca), também não significa não abraçar o Java EE.
[quote=Fabio Kung]
Não acho isso. Não usar muito sfsb não significa não abraçar o Java EE. Assim como não usar Entity Beans (eca), também não significa não abraçar o Java EE.[/quote]
Também não acho. O smile no final da minha frase devia enfatizar a ironia.
É uma questão muito relativa, as tais práticas. Claro, alguns argumentos são indiscutíveis, mas eu pessoalmente acredito que existem tantos projetos diferentes, com necessidades tão diferentes, que por fim você acaba, ao long o dos anos, apredendo a flexibilizar as suas políticas de desenvolvimento.
com certeza!
Bem, uma das vezes que eu lembro agora de cabeça é o Gavin King no Rio Java Summit.
Eu estava pesquisando sobre os defeitos\problemas do SFSB depois de vocês me falaram que ele é algo tão odiável assim…
Encontrei: http://www.onjava.com/pub/a/onjava/2001/10/02/ejb.html
http://www.java-tips.org/java-ee-tips/enterprise-java-beans/choosing-between-httpsession-and-stateful-session.html
http://www.theserverside.com/discussions/thread.tss?thread_id=552
e mais um monte…
até onde eu entendi, a regra padrão se aplica no caso usar ou não SFSB USe quando faz sentido e no propósito pelo qual ele foi feito.
Eu já trabalhei em empresa grande de consultoria, então posso dar minha opinião:
Pergunta básica:
“Como eu vou vender um projeto de 500 mil reais mínimo para usar <framework simple X> + hibernate?”
Ao invés de demorar 1 ano (+ extensão de 3 meses) vai demorar 2 ou 3 meses.
Ao invés de ser uma coisa gigantesca, com um build que demora 2 minutos, vai ser aquela coisa pequena, com menos de 500k no jar.
Ao invés de uma equipe de 20 pessoas, haverá uma equipe de 3-4 pessoas.
Como eu vendo um projeto de 500 mil reais com consultores (sim, diretores que não fazem muito mas cobram 200 reais/hora no cliente) se ele não for extramemante complicado e complexo.
E melhor ainda: ele sendo complicado e complexo, após a entrega eu posso colocar mais alguns carinhas no cliente (BPM), para fazer a manutençao disso.
E o mais legal de tudo: PROJETO VENDIDO! O cliente achou maravilhoso e confia no nome da minha consultoria.
Há um typo nesse artigo: troque a palavra melhores por piores.
A não ser que vc seja o vendedor do projeto de 500 mil que irá ganhar uma porcentagem disso. (sim, porque o desenvolvedor não ganha porra nenhuma mas o cara que vendeu e não vai ter que escrever uma linda de código ganha!)
Bem-vindo ao mundo das grandes consultorias e das empresas endinheiradas que pagam qualquer 500 mil para se ver livre de um projeto.
[quote=saoj]Eu já trabalhei em empresa grande de consultoria, então posso dar minha opinião:
Pergunta básica:
“Como eu vou vender um projeto de 500 mil reais mínimo para usar <framework simples X> + hibernate?”
Ao invés de demorar 1 ano (+ extensão de 3 meses) vai demorar 2 ou 3 meses.
Ao invés de ser uma coisa gigantesca, com um build que demora 2 minutos, vai ser aquela coisa pequena, com menos de 500k no jar.
Ao invés de uma equipe de 20 pessoas, haverá uma equipe de 3-4 pessoas.
Como eu vendo um projeto de 500 mil reais com consultores (sim, diretores que não fazem muito mas cobram 200 reais/hora no cliente) se ele não for extramemante complicado e complexo.
E melhor ainda: ele sendo complicado e complexo, após a entrega eu posso colocar mais alguns carinhas no cliente (BPM), para fazer a manutençao disso.
E o mais legal de tudo: PROJETO VENDIDO! O cliente achou maravilhoso e confia no nome da minha consultoria.
Há um typo nesse artigo: troque a palavra melhores por piores.
A não ser que vc seja o vendedor do projeto de 500 mil que irá ganhar uma porcentagem disso. (sim, porque o desenvolvedor não ganha porra nenhuma mas o cara que vendeu e não vai ter que escrever uma linda de código ganha!)
Bem-vindo ao mundo das grandes consultorias e das empresas endinheiradas que pagam qualquer 500 mil para se ver livre de um projeto.
[/quote]
Pausa para o Merchan … Voltando do plin-plin, EJB implementa uma série de outras questões. Acho que o pessoal deveria olhar para o CORBA e começar a estudar de onde saiu a especificação.
[]´s
Acho que eu coloquei um comentário pertinente, mas vc achou que eu estava fazendo Merchant… Tudo bem, retirei o nome do framework e coloquei no lugar <framework simples X>.
Tá feliz agora? Legal, então voltemos a discussão do tópico…
Você tem razão. EJBs agregaram bastante (inclusive até chamando bastante atenção para onde NÃO devem ser utilizados).
Mas pelo que tenho percebido (e o Luca anda pregando bastante isso) sistemas distribuídos não deveriam ser síncronos.
O próprio pessoal do Java EE se mostra preocupado com isso. Message Driven Beans entraram na versão 2.0 dos ejbs. JMS já existe desde o J2EE 1.3.
Apesar disso, o mais intrigante é que session beans continuam sendo a “menina dos olhos” dos sistemas distribuídos. Será que a bola da vez não está com os MDBs?
Vale a pena dar uma lida aqui. As referências no final do artigo também merecem ser lidas!
Bom post Fábio. Vc levantou um ponto importante.
O ambiente de tecnologia mais popular do mundo, podem me corrigir se eu estiver falando besteira, é o ambiente web em cima de HTTP, que é síncrono.
Assíncrono é melhor que síncrono, ou melhor, assíncrono contem síncrono.
No ambiente web as pessoas deram um jeito de fazer coisas assíncrona via AJAX, que me parece utiliza pooling (requisições a cada n segundos) para simular algo assíncrono.
Num sistema corporativo, onde vc realmente precisa de coisas 100% assíncronas? E quando que um pooling semelhante ao que o AJAX faz não resolve?
AJAX só faz polling porque o XmlHttpRequest (e o http) não suportam publish-subscribe e os clientes não podem ser notificados.
Num sistema corporativo você estaria usando algum MOM (Message Oriented Middleware) que suporta publish-subscribe e não precisaria fazer polling…
AJAX só faz pooling porque o XmlHttpRequest (e o http) não suportam publish-subscribe e os clientes não podem ser notificados.
Num sistema corporativo você estaria usando algum MOM (Message Oriented Middleware) que suporta publish-subscribe e não precisaria fazer pooling…[/quote]
Sim, a pergunta não foi se dá para fazer, mas o porque vc precisa fazer, ou seja, o porque de um simples polling não resolver do mesmo jeito que resolve no caso do Ajax.
Deve haver alguma situaçao, só estou querendo entender se essa situaçao está mais para a regra ou para a exceçao.
O problema é que o polling inunda muito mais a rede (escala menos).
Por isso ele só é usado onde não tem como fazer publish-subscribe.