Sempre que debato com o Rubem Azenha sobre EJB temos conversas bem produtivas sobre as reais vantagens e/ou desvantagens de adotar essa tecnologia.
Então deixo a pergunta para um debate sadio:
O que EJB te oferece que vc não pode fazer sem EJB de uma maneira muito mais leve, simples e pura?
Até outro dia eu achava que era cluster, mas depois de conhecer o JGroups, vi que nem pra isso ele está valendo a pena hoje em dia. Mas posso estar enganado…
[quote=saoj]Sempre que debato com o Rubem Azenha sobre EJB temos conversas bem produtivas sobre as reais vantagens e/ou desvantagens de adotar essa tecnologia.
Então deixo a pergunta para um debate sadio:
O que EJB te oferece que vc não pode fazer sem EJB de uma maneira muito mais leve, simples e pura?
Até outro dia eu achava que era cluster, mas depois de conhecer o JGroups, vi que nem pra isso ele está valendo a pena hoje em dia. Mas posso estar enganado…
[/quote]
Este Terracotta também prove clusterização de aplicações Java sem utilização de EJB.
[quote=saoj]Sempre que debato com o Rubem Azenha sobre EJB temos conversas bem produtivas sobre as reais vantagens e/ou desvantagens de adotar essa tecnologia.
Então deixo a pergunta para um debate sadio:
O que EJB te oferece que vc não pode fazer sem EJB de uma maneira muito mais leve, simples e pura?
Até outro dia eu achava que era cluster, mas depois de conhecer o JGroups, vi que nem pra isso ele está valendo a pena hoje em dia. Mas posso estar enganado…
[/quote]
Acredito que as vantagens de EJB ( em sua versao 3 é claro ) são a integração entre os servicos e o appserver… com ejb voce tem já um controle de transacoes (JTA) , servico de mensagens (JMS) de forma integrada e totalmente transparente… com Java EE 5 ficou muito produtivo… pois até o contexto de persistencia é inserido via IoC.
Acredito que outras alternativas sejam capazes de fazer a mesma coisa… a pergunta seria… a que preço ? EJB oferece uma estrutura padrão e implementada por dezenas de fornecedores… até a parte de persistencia pode ser escolhida agora (JPA)
Clusterização é apenas UMA das vantagens… a separação do codigo fica muito evidente em Java EE 5 , isso torna as coisas mais simples de serem programadas… JAAS ficou muito mais simples e sumiram os milhares de XML (Spring) … acredito que valha a pena hoje…
Com JBoss Seam voce tem uma integracao perfeita entre os EJB’s e o JSF… ( que vai ser padrozinada pela JSR dos WebBeans )…
Quando se fala em desenvolvimento em grupo e curva de aprendizado não tão ingrime… Java EE 5 é a melhor opcao. Antigamente tinha que se saber dezenas de coisas… hoje não.
é claro que tudo isso pode ser oferecido por outros frameworks em conjunto… a pergunta continua… mas a que preço ?
e por que não usar ?
Olá
Quando estudei EJBs 1.x há muitos anos atrás, fiquei com a certeza de que era apenas complicação desnecessária em 99% dos casos. O desenvolvedor Java que não poluiu a cabeça aprendendo EJBs 1.x fez muito mais pelo seu patrão do que muitos que recomendaram seu uso. Há por aí um grande legado de aplicações usando EJBs antigos rodando em servidores caríssimos obsoletos como é o caso da CEF por exemplo.
Mas agora estou estudando EJB 3.0 e acho que já dá para pensar em usar sem levar o custo do projeto para as rodas de piadas na hora do almoço nos outros departamentos. Só que pensar em usar não significa adotar indiscriminadamente como algun$ consultore$ andaram recomendando nos últimos anos (por ignorância ou sabotagem). Há ainda muitos projetos em que EBJs oferecem poucas vantagens.
[]s
Luca
Rapaz, quando pensarmos em solução de escalabilidade, como iremos fazer se não pudermos colocar nossos componentes distribuidos, e como outros colegas falaram, e para resolver, transação de negócio sem ter que extender frameworks para provêr tais funcionalidades.
As realidades fazem com que vc defina o que usar para resolver tais cituações, mais EJB é uma plataforma e padrão de mercado e em situações corporativas não abro mão dos Session para me provêr o que acima citei.
[s]
baiano
Olá
O problema é que isto não é um requisito comum ou padrão. Fazer isto só por fazer é o que ridicularizou o uso de EJBs.
Um dia almocei com vários diretores de empresas da área financeira. Os caras morriam de dar risada metendo o pau no Java. Eles citaram vários exemplos, inclusive o de uma grande instituição que gastou mais de R$ 20 milhões e depois de um ano ainda não tinha NADA funcionando. O dia em que você passar pela experiência que eu passei vai perceber o mal que alguns consultores podem fazer a uma empresa. Com EJBs pré 3.0 a maioria dos casos foi dinheiro jogado fora.
[]s
Luca
Uma dúvida, para usar JMS é preciso usar EJB ou apenas fica mais fácil usando EJB?
Olá
JMS é uma das melhores coisas do Java. É bem fácil usar sem EJBs mas neste caso sou favorável a usar as message beans. Não só porque facilita mas também porque servidores como o JBoss podem ajudar na monitoração.
[]s
Luca
Sim… mas vamos nos reservar a falar da tecnologia no atual estagio de amadurecimento… senao… vamos extender por meses esta “conversa”… que EJB 1.x e 2.x são terriveis já sabemos…
bola pra frente minha gente !
Olá Luca, obrigado pela resposta, pois então, pelo que andei vendo JMS poderia resolver alguns probleminhas meus, mas não estava querendo ter de ver EJB o sistema é pqno, baixo volume de acesso, etc… Fico feliz q um não dependa do outro.
Estava querendo abordar outras tecnologias, já que EJB será mais difícil de eu usar nos meus projetos. (a não ser q tudo mude, rs, mas não dá para prever tudo, rs)
Uma grande dúvida acerca de EJB é q justamente recomendam ele para sistemas maiores, justamente em cluster, e outars situações mais extremas, contudo o que vejo é ele sendo usando de forma geral, mesmo em sistemas pqnos, isso não seria o equivalente a matar uma mosca com um canhão.
E outro problema o que é um sistema grande, com um grande volume de acessos, etc? Claro q temos aqui pessoas que trabalham em bancos, telefonicas, etc, mas volte e meia aparece alguem falando de um sistema q tem muito acesso e tal, mas na verdade não tem, e um upgrade de hardware resolveria melhor q usar EJB, no meu ver de leigo.
Ou seja não existe uma super valorização dessa tecnologia?
Java EE 5 torna o uso de EJB’s uma coisa normal e sadia… se seu sistema é tão grande como fala… EJB pode ajudar voce a expandir o poder de fogo sem muita alteração na estrutura…
Coisa que com qualquer outra “arquitetura” voce precisaria estar se preparando desde agora… com tecnicas mirabolantes… para que lá na frente… nao precise reescrever tudo…
[quote=chun]Java EE 5 torna o uso de EJB’s uma coisa normal e sadia… se seu sistema é tão grande como fala… EJB pode ajudar voce a expandir o poder de fogo sem muita alteração na estrutura…
Coisa que com qualquer outra “arquitetura” voce precisaria estar se preparando desde agora… com tecnicas mirabolantes… para que lá na frente… nao precise reescrever tudo…
[/quote]
Sim chun isso eu entendi, no caso de um sistema grande é uma realidade, mas estava me referindo a sistemas pqnos ( e q pode falta de informações, experiencia ou parametros de comparação) os desenvolvedores acham q é grande e metem o EJB no meio, sendo q poderia ser resolvido com outras tecnologias.
Veja nunca mexi com EJB posso estar falando bobagem.
Agora se desenvolver com EJB é simples e fácil o “problema” residiria apenas no fato de usar um canhão para matar a mosca, mas o resultado final (q muitas vezes é só o q importa) é atingido (a mosca tá morta), risos.
A proposta de JBoss Seam é justamente esta… usar para qualquer tamanho de projetos Java EE 5
Acredito que com a versão 5 da especificação Java EE , a adoção de EJB em projetos tenha sido invertida… em 90% das vezes voce pode colocar eles… para ajudar a separar as coisas… e deixar uma brecha para uma possivel clusterização futura ou até mesmo uma separacao explicita (ex: um servidor fazendo a regra de negocio e outros 15 atendendo requisicao http )
Com Java EE 5 … o que abunda não prejudica 
Para segurança, nada te impede de usar qualquer outra esquema de autenticação e autorização.
Para escalabilidade, nada te impede de usar um load balance qualquer.
Para cluster (load balance + failover), nada te impede de usar JGroups ou esse outro que falaram aí.
Para controle de transações, nada te impede de fazer isso na mão sem qualquer problema. 99% dos casos de transações são simples e não precisam de two-phase commit ou essas coisas complexas e muitas vezes sem qualquer benefício.
EJB é uma solução desesperadamente procurando um problema!
Eu trabalhei na Accenture na época que EJB surgia. Vi projetos gigantescos que foram jogados no lixo, porque foi feito um sistema gigante, cheio de bugs e uma carroça.
EJB 1.0 e EJB 2.0 era a receita certa para o desastre e prejuízo (para o cliente é claro!).
EJB 3 melhor. Claro, depois de tentar por 3 vezes fazer a coisa direito, já estava mais do que na hora de fazer uma coisa descente.
Mas EJB continua sendo totalmente desncessário, na minha opinião.
O que vc consegue fazer com EBJ que vc não consegue fazer sem ele? Difícil !
[quote=saoj]
Mas EJB continua sendo totalmente desnecessário, na minha opinião.
O que vc consegue fazer com EBJ que vc não consegue fazer sem ele? Difícil ![/quote]
Sergio acho que o ponto é q EJB oferece todas estas funcionalidades já de fábrica e integradas, mas (chutando) vc consegue fazer tudo sem ele (eu acho, rs).
Onde encontro um bom exemplo, tutorial, etc, de como integrar escalabilidade, transação, cluster, etc sem EJB? Quem já fez uma vez e tem isso bem estruturado, ótimo, mas quem não tem o buraco é mais embaixo e acaba ficando com EJB …
[quote=saoj]
Para segurança, nada te impede de usar qualquer outra esquema de autenticação e autorização.
Para escalabilidade, nada te impede de usar um load balance qualquer.
Para cluster (load balance + failover), nada te impede de usar JGroups ou esse outro que falaram aí.
Para controle de transações, nada te impede de fazer isso na mão sem qualquer problema. 99% dos casos de transações são simples e não precisam de two-phase commit ou essas coisas complexas e muitas vezes sem qualquer benefício.
EJB é uma solução desesperadamente procurando um problema![/quote]
Como eu disse… esse preço eu não pagaria… 313 frameworks para fazer algo que um faz ? pra que ? pra provar que dá para fazer diferente ? Java EE 5 simplificou ao ponto desses argumentos serem considerados invalidos… não tem motivo… pra que complicar ? pra que complicar a vida da equipe inteira ? aprender 3123123 frameworks ? no way.
Ejb esta simples e facil… ao ponto de ser usado em 90% das aplicacoes.
A única coisa que é complexa é CLUSTER.
O resto não vejo dificuldade para qualquer programdor mediano.
Além do cluster, o que exigiria trabalho ou outros framewoks?
Curva de aprendizado… dezenas de configuracoes diferentes , maneiras de trabalho diferentes… coisas do genero…
por mais q seja “simples” a curva de aprendizado com certeza será bem mais íngrime.
Me dá um exemplo, tirando cluster, de algo que exija uma curva de aprendizado grande ?