As melhores praticas para aplicações Java EE

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.

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.

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.

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.

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…

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.

Fabio Kung:

O problema é que o pooling inunda muito mais a rede (escala menos).

Por isso ele só é usado onde não tem como fazer publish-subscribe.

Concordo plenamente.

Assíncrono é melhor do que síncrono.

Assíncrono contem síncrono.

Polling é menos performático que publish-subscribe, principalmente se vc faz muitas requisições por segundo para aumentar o tempo de resposta da sua mensagem assíncrona. (É, eu gostaria que o meu Outlook Express checasse por novas mensagens a cada segundo, mas o mínimo que ele checa é de um minuto em um minuto!)

Acho que se vc está num ambiente EJB, com um MOM como vc falou, etc e tal, então deve-se usar mensagens assíncronas. Por que não?

Mas se vc está num ambiente sem EJB ou sem application server, ou num ambiente sem MOM, etc e tal, vc pode fazer usando polling e conseguir o mesmo resultado, desde que vc não faça muitas requisiçoes por segundo e consiga escalar a coisa horizontalmente.

Sergio, se você tem que escalar um sistema e precisa de tarefas assíncronas, usar pooling só vai fazer você morrer na praia, pq vai precisar de uma enorme tonelada de hardware adicional.

Não é simplesmente mais facil colocar um MOM na infra do sistema e ser feliz? Pooling é gambiarra por definição, construir a arquitetura de um sistema envolta de uma gambiarra é dar tiro nos pés e sair correndo.

Sistemas distribuidos eu considero que são necessários somente quando você tem uma demanda muito grande e não compensa mais fazer scale-in. Ao partir pro scale-out, fazer troca assíncrona de mensagens entre os componentes distribuídos é a melhor forma de operar.

Não estou dizendo para usar apenas trocas assíncronas, principalmente pq a maioria das linguagens main-stream não possuem resursos sufientes para fazer isso ser viavel de programar.

A questão não é “assíncrono é melhor que síncrono”, principalmente por ser muito perigosa e errada. Cada uma possui suas vantagens e desvantagens, o certo é usar cada uma de acordo com suas necessidades.

Eu apenas quiz falar que assíncrono contém síncrono, mas acho que me expressei mal mesmo.

A web não é assíncrona, e as pessoas cagam pra isso.

Se vc tem um sistema que não está mais escalando então pooling é muito ruim, concordo.

O meu ponto é que comunicaçao assíncrona só é necessária em casos muito especiais.

Veja o GMAIL. Ele faz pooling para checar mensagens de tempos em tempo, e escala muito bem. Não acho que foi tiro no pé.

E o chat do messenger deles? Usa Keep-Alive, socket ou faz pooling?

Só gostaria de entender em que situaçoes mensagens assíncronas irão fazer sentido.

Quando a operação é muito demorada?

Quando vc precisa receber eventos de um outro sistema? Nesse caso porque não ser um serviço para esse outro sistema?

Estou apenas devagando e tentando aprender com quem tem mais experiencia nessa área…

Sérgio, dá uma lida no artigo (e nas referências) que eu postei ali em cima, vale a pena!

Valeu, tava escondido o link. Vou ler tudo com calma…

Como sempre comecei pelo fim, no caso a conclusão.

Gostei:

Sérgio, se assíncrono contém síncrono é pura retórica, em ambos os casos você pode expressar um em termos do outro.

Da mesma forma que você pode simular uma chamada síncrona com JMS, você pode fazer o mesmo com HTTP e ter troca assíncrona de mensagens.

Troca de mensagens é muito útil em cenários que você quer desacoplar quem envia de quem recebe. Seria muito ingênuo querer que toda troca de mensagens fosse feita de forma totalmente acomplada.

Um simples pode tranquilamente publicar uma mensagem em uma fila enquanto você tem vários consumidores operando independentemente sobre ela. Isso funciona muito bem, isso escala absurdamente bem. Quem já mexeu com sistemas financeiros sabe o quao importante é não fazer trocas síncronas.

Você diz que a internet é toda síncrona? Bom, se você usar email, vai descobrir que é um mecanísmo assíncrono de troca de mensagens, e quando descobrir um treco chamado mailing-list, vai descobrir a utilidade de ter o consumidor desacoplado do consumidor.

Além disso, o Gmail usa Comet style eventing, ou seja, em vez de pooling, mantem coneções abertas a espera de mensagens. Isso é uma forma de notificação assíncrona, implementada dentro dos limites do protocolo.

Cara, você já vez uma transferência, doc, ted, saque ou pagamento com cartão? Então, sabe aqueles serviços que os bancos oferecem de mandar 1 SMS quando ocorrer uma dessas operações? Você ganha um doce se adivinhar como são implementados.

Você deveria ler o EIP (Enterprise Integration Patterns) do Gregor Hohpe, lá em conta tudo isso que eu falei em grandes detalhes. http://www.enterpriseintegrationpatterns.com/

Olá

Brilhante as intervenções do Louds (como sempre). Ainda há casos em que as comunicações devem ser síncronas.

Além do link para o EIP (meu livro mais bonito), recomendo também a leitura do Java Messaging do Eric Bruno para quem quer aprender JMS e um pouco de arquitetura de mensagens.

Só quero lembrar que no caso de sistemas distribuídos, o uso de uma arquitetura baseada em troca de mensagens via serviço de mensageria, WS, ESB, etc. deve ser sempre condiderada entre as alternativas viáveis. Muitos sistemas por aí NÃO avaliaram esta alternativa e agora dependem de fornecedor de máquina/fornecedor de servidor de aplicação na hora de aumentar a escalabilidade.

[]s
Luca

Vc leu errado:

Mas sua resposta foi boa, obrigado. Mensagens assíncronas escala tão melhor que mensagens síncronsa que sempre que possivel é melhor fazer um sistema que se baseie nelas. (É isso?)

Só continuo achando que tirando sistemas financeiros, e outros por aí, esse caso é meio exceção e não regra.

Ou devemos para qualquer sistema corporativo usar mensagens assíncronas?

Sobre o gmail, onde podemos ler mais sobre essa comunicaçao assíncrona que vc diz que ele faz? Ele usa duas conexões? (uma para postar e outra para receber em keep-alive?)

Não, possivelmente isso seria:
Quando você clica no botão para mandar um e-mail ele não efetivamente manda um e-mail para quem você mandou, antes, ele provavelmente coloca numa fila de tasks e existem n processos consumidores responsáveis por executas essas tasks

Certo?

EDIT: Ou seja, vocês querem dizer "polling" e não "pooling", certo? Ou "pooling" é a versão aportuguesada de "polling"? E se for o caso, como é que se diz "pooling" (por. ex. connection pooling)? :D

Certo?

EDIT: Ou seja, vocês querem dizer “polling” e não “pooling”, certo? Ou “pooling” é a versão aportuguesada de “polling”? E se for o caso, como é que se diz “pooling” (por. ex. connection pooling)?

O GMail usa uma coneção só, que mantem aberta com o servidor esperando por alguma mensagem. Procura por “comet server” ou “comet style ajax” pra saber mais.

Serviços de mensageria devem ser usados somente quando necessário. Para isso o certo é ter alguém que entenda do assunto para estudar cada necessidade caso a caso, principalmente pq 90% dos desenvolvedores são incapazes de entender o conceito.

Louds, não sei se esse seu post foi com o intuito de corrigir meu post…

Eu quiz dizer enviar uma mensagem e não receber.

Olá

Conexão discada via interrurbano é dose! Vai ver que épor isto que eu não consigo entender o foco deste tópico.

Para mim sistemas baseados em mensagens não tem nada a ver com a camada de apresentação. Devo estar velho e burro porque não entendo o que AJAX tem a ver com JMS. De que se pretende tratar aqui? De camada de apresentação ou do back office?

Quem me conhece, como o Fábio, sabe do meu entusiasmo por sistemas baseados me mensagens para qualquer área e não apenas sistemas financeiros. Repito que talvez a maioria dos sistemas que usam EJBs poderiam ter usado JMS para suportar sistemas distribuídos (que raramente são realmente distribuídos). JMS é bem fácil de usar e os servidores de mensagens como JBoss ou ActiveMQ fornecem boas informações sobre o comportamento do sistema.

O Louds disse que os conceitos são difíceis. Para mim o problema é que os programadores estão viciados em RPC e este é o mal. O programador precisa abrir a cabeça e se livrar do conceito RPC.

[]s
Luca

Lendo o post do Sérgio eu realmente comi bola, ele queria saber mais sobre o esquema de Ajax e não do envio de uso de fila :S

Na verdade estamo falando um pouco de cada coisa Luca

Estamos falando de sistemas assíncronos no geral.

Sobre o comet:

Bem interessante. Polling é realmente muito ruim perto disso. Peço desculpa por ter defendido esse ponto.

Um ponto interessante discutido no link acima é os diversos problemas no nível da rede/proxy/webserver para o comet.

Qual é o framework recomendado para usar comet? O GMail provavelmente fez o seu próprio, certo?

Luca,

Seguindo sua defesa de uso de JMS para sistemas distribuídos, em vez de Stateless Session Beans (SLSB).

Imaginando que um processo depende da resposta da execução de um método do negócio para retornar a informação ao usuário na tela.

Com o processo síncrono (SLSB), o fluxo é sequencial. Você recebe a resposta e repassa à camada visual.

Do jeito assíncrono, como devo proceder? Esperar ser notificado do processamento do MDB e então mandar a resposta de volta?

Sérgio, o maior problema de usar Comet é o número absurdo de coneções que ficar paradas no servidor, para resolver isso, só usando um httpd escalavel feito o yaws, ou então usando um feito especialmente para Comet. Se você fez as buscas no Google já sabe qual é.

Daniel, se tua aplicação precisa ser síncrona, não existe motivo para usar JMS. Ou melhor, existe um caso só que justifica, quanto o processamento do servidor é muito demorado, com JMS você trata muito mais facilmente timeouts e espera do cliente.

Procurei (de olho aberto) mas não achei…

O Yaws não suporta servlets (java), só ERLANG, certo?

Sério, aqui apareceu:

http://cometd.com/
www.lightstreamer.com
http://activemq.apache.org/ajax.html (dai vc usa Comet com JMS!)

E sobre o protocolo que todos usam, Bayeux:
http://svn.xantus.org/shortbus/trunk/bayeux/protocol.txt

Dá para fazer o yaws chamar código Java, existe uma bridge erlang-java, mas qual o sentido de usar uma linguagem meia boca quando o ambiente suporta naturalmente algo melhor?

louds:

Dá para fazer o yaws chamar código Java, existe uma bridge erlang-java, mas qual o sentido de usar uma linguagem meia boca quando o ambiente suporta naturalmente algo melhor?

Talvez para poder usar um milhão de coisas que foram feitas com a linguagem Java.

Como faço persistência com ERLANG?

Olá

Na prática a resposta assíncrona é super rápida. O usuário na tela nem percebe que as comunicações entre processos no servidor são assíncronas. Faça alguma experiências interligando 2 aplicações e veja como o JBoss ou o ActiveMQ responde rápido.

Vou fazer um parêntesis para contar uma historinha:

No início de 2002 um cara que trabalhava comigo ouviu de um cara da IBM que seria melhor desenvolver sistemas totalmente baseados em mensagens. Minha resposta na lata foi de que o funcionário da IBM queria vender MQSeries.

Mas em casa pensei melhor no assunto e percebi que ele tinha razão. Na época eu trabalhava com o banco postal que trocava mensagens ISO 8583 com o switcher que se comunicava com Osasco via sockets através de um monte de threads. O sistema poderia ter sido escrito baseado no MQSeries, que já fazia parte do projeto para outros fins. Com certeza a escalabilidade seria melhor e O TEMPO QUE SE PERDEU com o protocolo dos sockets possivelmente teria sido menor.

[]s
Luca

danieldestro:

Com o processo síncrono (SLSB), o fluxo é sequencial. Você recebe a resposta e repassa à camada visual.

Do jeito assíncrono, como devo proceder? Esperar ser notificado do processamento do MDB e então mandar a resposta de volta?

Claro, muitas vezes não vale a pena. Como já dito, não é para ser usado sempre.

ps.: Sami, você estava corretíssimo quanto à palavra polling. Corrigido!

AJAX entrou na discussão, pois também é um exemplo onde alguma “assíncronidade” (?) trouxe grandes benefícios.

louds:

http://cometd.com/
www.lightstreamer.com
http://activemq.apache.org/ajax.html (dai vc usa Comet com JMS!)

E sobre o protocolo que todos usam, Bayeux:
http://svn.xantus.org/shortbus/trunk/bayeux/protocol.txt

Não resolvem justamente esse problema de precisar aguentar diversas conexões abertas por bastante tempo, já que não travam mais uma thread por conexão?

Edit: já achei um exemplo… http://tomcat.apache.org/tomcat-6.0-doc/aio.html

Não sei se entendi isso direito, mas se a coisa exige uma resposta sincrona, como o Daniel falou, então no lado do servidor ele manda uma mensagem assíncrona e trava/espera pela resposta. Recebida a resposta ele responde para o cliente.

Então para o cliente a coisa foi síncrona, mas no back-end foi assincrona.

É isso?

Dei uma lida lá no artigo que o Fábio sugeriu. Realmente muito bom. RMI, RPC e Corba nunca chegaram a lugar nenhum. Em termos de sistemas distribuídos, mensagens assíncronas parece ser a melhor, mais natural e mais performática maneira de fazer a comunicação.

Uma vantagem que eu consigo perceber agora de um sistema baseado em mensagens assíncronas é a facilidade que vc tem de plugar novos serviços/aplicativos ao redor dele. Não tenho idéia de como um servidor de mensagens JMS (é assim que se chama?) é implementado, mas imagino que qualquer cliente possa chegar a qualquer momento e dizer: "Ei, eu tb quero receber essas mensagens aí!"

Um approach interessante e altamente escalável utilizado por NASDAQ e outras bolsas que precisam processar 1 milhão de mensagens por segundo é Multicast UDP (com retransmissão de pacotes perdidos, catchup the stream e ordenação). Nesse ambiente as mensagens são broadcasteadas para quem quiser recebe-las, bastando para tal fazer um join no endereço e na porta. Some-se a isso NIO e um código nativo em C para dar um bind no DatagramChannel (suporte a multicast com nio talvez no Dolphin!) e tem-se um super processador de mensagens capaz de tratar muitas milhões de mensagens por segundo (o limitador passa ser o hardware do seu switch!). Nada simples, mais muitíssimo rápido e escalável, visto que vc pode ter 1000 máquinas independentes recebendo esses pacotes e realizando as mais distintas tarefas…

Para sistemas bossalmente parrudos que precisam processar muitas requisições ou mensagens por segundo, mensagens assíncronas são a única solução escalável. Problema é que esses sistemas são 1% dos projetos. A grande maioria dos projetos fará babysitting de banco de dados, e pra isso <framework simples X&gt + hibernate resolve muito bem.

Olá

saoj:

Luca:

Na prática a resposta assíncrona é super rápida. O usuário na tela nem percebe que as comunicações entre processos no servidor são assíncronas. Faça alguma experiências interligando 2 aplicações e veja como o JBoss ou o ActiveMQ responde rápido.

Não sei se entendi isso direito, mas se a coisa exige uma resposta sincrona, como o Daniel falou, então no lado do servidor ele manda uma mensagem assíncrona e trava/espera pela resposta. Recebida a resposta ele responde para o cliente.

Então para o cliente a coisa foi síncrona, mas no back-end foi assincrona.

É isso?

1. …trava/espera pela resposta…
   Não, processa requisições dos demais clientes pendurados em outras telas

2. …Então para o cliente a coisa foi síncrona, mas no back-end foi assincrona…
   Sim, o que defendo é avaliação da substituição do RPC usado pelos EJBs através de RMI por trocas de mensagens assíncronas.

3. …esses sistemas são 1% dos projetos…
   Infelizmente o povo está acostumado com RPC porque muitos outros projetos poderiam se beneficiar de uma arquitetura de mensagens. Vou mais além: as mensagens podem representar eventos. Eu ainda acho que qualquer sisteminha de ponto de venda pode ficar mais fácil de se integrar se sua arquitetura for baseada em eventos (que na prática são mensagens)

[]s
Luca

O que voce ainda nao se deu conta é que EJB3 == “framework simples”. Falar que usar EJB3 é super complciado, vai levar anos, vai gastar muito dinheiro, etc, é ignorar por completo a nova especificação.

Olá

Eu que sempre fui cético quanto aos EJBs pré 3.0 (a menos quando envolvia transações distribuídas ou Message beans), concordo plenamente. Mas depois que andei estudando o que o Hibernate 3 faz a mais do que EJB3, fiquei na dúvida se não é melhor usar direto o Hibernate 3.

Pergunto: vale a pena usar as facilidades a mais do Hibernate 3 ao invés de se limitar ao que está atualmente no EJB3?

[]s
Luca

Luca:

Eu que sempre fui cético quanto aos EJBs pré 3.0 (a menos quando envolvia transações distribuídas ou Message beans), concordo plenamente. Mas depois que andei estudando o que o Hibernate 3 faz a mais do que EJB3, fiquei na dúvida se não é melhor usar direto o Hibernate 3.

Pergunto: vale a pena usar as facilidades a mais do Hibernate 3 ao invés de se limitar ao que está atualmente no EJB3?

[]s
Luca

Luca,

Tu poderia sitar o que o Hibernate 3 faz a mais? Eu me lembro de duas funcionalidades, que são a API Criteria e a parte de validação. As validações eu nem conto porque da pra rodar elas fora do Hibernate (vide VRaptor).

Fiquei curioso agora.

]['s

Olá

fabgp2001:

Tu poderia sitar o que o Hibernate 3 faz a mais? Eu me lembro de duas funcionalidades, que são a API Criteria e a parte de validação. As validações eu nem conto porque da pra rodar elas fora do Hibernate (vide VRaptor).

Fiquei curioso agora.

]['s

Com a minha conexão discada via interurbano fica difícil listar mas o livro Java persistence with Hibernate do Gavein King mostra algumas facilidades (extensões) que se podem aproveitar usando Hibernate. E ainda chama a atenção de que provavelmente o Hibernate evoluirá mais rapidamente do que a especificação.

Luca,
tentando exercitar o que foi dito aqui, se vc tivesse que desenvolver uma app para uns 3000 usuários(concorrentes, não simultâneos), por exemplo um sistema dentro de uma rede de Telemarketing, vc usaria JMS?
Vou complicar um pouco, digamos que 90% do tempo os usuarios usariam internamente(Intranet), mas outros 10% eles deveriam consultar gráficos de desempenho num servidor Web, considerando um servidor ideal(Parrudo, redundância, link 2X 100MBs Unmettered…), o que você usaria?

Fabio Kung:

louds:

http://cometd.com/
www.lightstreamer.com
http://activemq.apache.org/ajax.html (dai vc usa Comet com JMS!)

E sobre o protocolo que todos usam, Bayeux:
http://svn.xantus.org/shortbus/trunk/bayeux/protocol.txt

Louds, e quanto aos servidores com conectores baseados em io não-bloqueante como o jetty6, o glassfish e até o tomcat6 ?

Não resolvem justamente esse problema de precisar aguentar diversas conexões abertas por bastante tempo, já que não travam mais uma thread por conexão?

Edit: já achei um exemplo… http://tomcat.apache.org/tomcat-6.0-doc/aio.html

É uma opção a se estudar, nunca usei ou falei com pessoas que usam. Minha única resalva é misturar um hub de mensageria, comet é uma forma de, com um servidor http de conteúdo dinâmico. A gambiarra que eles fazem para colocar NIO não-bloqueante funcionando com servlets é tão grande que não sei se realmente vale a pena misturar.

Sérgio, com erlang vc pode usar SQL normalmente, além disso existem um framework escrito pelo Yariv Sadan que implementa algo parecido com ActiveRecord, e, por último, existe o mnesia, que é uma banco de dados distribuido com suporte a operações soft-realtime.

Briga de Cachorro Grande, Mais vou procurar ajuda aqui.

Bom pessoal,

Possuo o seguinte cenário, Preciso capturar uma mensagem de um sistema de terceiro em minha aplicação e enviar para os meus clientes esta mensagem.

Qual é uma das melhores maneiras para atingir esta arquitetura?

Eu pensei no ActiveMQ, alguém conhece algo melhor.

Obrigado

Paulo Silveira:

saoj:

A grande maioria dos projetos fará babysitting de banco de dados, e pra isso <framework simples X&gt + hibernate resolve muito bem.

O que voce ainda nao se deu conta é que EJB3 == “framework simples”. Falar que usar EJB3 é super complciado, vai levar anos, vai gastar muito dinheiro, etc, é ignorar por completo a nova especificação.

Ironlynx:

Luca,
tentando exercitar o que foi dito aqui, se vc tivesse que desenvolver uma app para uns 3000 usuários(concorrentes, não simultâneos), por exemplo um sistema dentro de uma rede de Telemarketing, vc usaria JMS?
Vou complicar um pouco, digamos que 90% do tempo os usuarios usariam internamente(Intranet), mas outros 10% eles deveriam consultar gráficos de desempenho num servidor Web, considerando um servidor ideal(Parrudo, redundância, link 2X 100MBs Unmettered…), o que você usaria?

Já que desenterraram o tópico, vou aproveitar e perguntar:

Qual é a resposta que acharam?