EJB 3: quando usar?

chun

Acabei de ver a especificação e, de fato, me enganei.

Nós tínhamos algumas entidades que usavam 2 callbacks iguais (dois PrePersist por exemplo) em algumas entidades. O que acontecia (no glassfish) era um comportamento do tipo, dependendo da ordem que declarávamos no @EntityListener, ou somente um era executado ou os dois eram executados. Por exemplo:

@EntityListeners(ListenerOne.class, ListenerTwo.class);

Se mudassemos a ordem para

@EntityListeners(ListenerTwo.class,ListenerOne.class);

O comportamento era mudado, ou seja, um deles não funcionava mais.

Mas não vou bater nessa tecla porque segundo a spec, uma entidade não pode ter mais de um callback para o mesmo método. Então por mais estranho que o código seja e comportamento faça, eu nem deveria tentar fazer isso (já que a spec diz para não fazer). Só um detalhe que, esse código foi testado fazem mais de 2 anos, não sei se isso se repete ainda, nem tenho netbeans + glassfish aqui pra fazer igual, até comecei a baixar mas depois que ví esse lance da spec, nem continuei mais.

Desde essa época, nunca mais lidei com EJB3. Só com Seam, EJB2 e Spring. E hoje, com Rails :stuck_out_tongue:

Bom, agora podemos voltar ao assunto do tópico, esse papo do código do callback foi um engano meu mesmo.

Abraço

Você citou dois app servers que não são Java EE 5 certified, quer que funcione como?[/quote]

Bruno, eles podem nao ser Java EE 5 certified mas implementaram algumas features do JEE5 e sao largamente utilizados. Sendo que muitas vezes o desenvolvedor nao tem a opcao de decidir qual app. server vai utilizar.

Pois da mesma forma que eles nao suportam @EJB em um managed bean, os mesmos suportam um @EJB em um SLSB.

De qualquer forma as versoes atuais desses app. servers que citei ja suportam JEE5, pena que nao posso utiliza-los. :cry:

Em nenhum momento eu critiquei diretamente a Spec. EJB 3. Apenas citei problemas vividos no dia a dia, pois atualemente desenvolvo em EJB3 + JSF.

[quote=chun]Tem muita gente que emite opiniao pensando em EJB pré 3.0…

EJB 2.x , etc…

Rapaziada… quem nunca utilizou o 3.0 , por favor , deem uma lida e depois cheguem a conclusao.[/quote]

Tendo participado de projetos com EJB (inclusive EJB3) e Spring, posso dizer com toda certeza que você realmente não preciso de EJB 3.
Acho EJB legal se você tem outros clientes Java além do cliente web e usar REST ou SOAP/WS-* por algum motivo é uma má idéia ou precisar fazer alguma coisa mais maluca como TPC (não testei TPC com Spring puro e simples… bom, você pode usar o JTA do container… sei la).

O Spring tem diversas coisas legais e roda tudo no seu servlet container preferido. Ou seja, em poucos segundos sua aplicação no ar, livre, leve e solta :slight_smile:
Experimente usar Spring+Maven+jetty:run+JavaRebel para você ver a diferença de produtividade.

E não me venha falar que o glorioso Glassfish (“que é 1230912309123% vezes melhor que o JBoss, que alias demorou 1203821083102 anos para lançar uma versão compatível com Java EE 5”) sobe tão rápido quanto o jetty:run, não tem nem comparação. Numa máquina “rapida”, na configuração default, com uma aplicação simples, ele leva 30 segundos só para começar a subir a aplicação.

IMHO, voce utiliza EJB quando voce tem mais que uma camada de apresentacao que utiliza o mesmo ‘objeto’.

A algum tempo atras trabalhei em um sistema que tinha uma camada de apresentacao WEB e uma em Swing
e ambas utilizavam o mesmo ‘objeto’ para uma funcionalidade X.

Outro caso foi de um projeto realmente grande que envolvia: milhares de requisicoes E filas.

No demais: Hibernate tem transacoes, JNDI voce pendura no tomcat/jetty, Spring tem IoC/DI (e muito mais).
Mas essa é minha opnião, espero que ajude em algo… :thumbup:

[quote=Rubem Azenha][quote=chun]Tem muita gente que emite opiniao pensando em EJB pré 3.0…

EJB 2.x , etc…

Rapaziada… quem nunca utilizou o 3.0 , por favor , deem uma lida e depois cheguem a conclusao.[/quote]

Tendo participado de projetos com EJB (inclusive EJB3) e Spring, posso dizer com toda certeza que você realmente não preciso de EJB 3.
Acho EJB legal se você tem outros clientes Java além do cliente web e usar REST ou SOAP/WS-* por algum motivo é uma má idéia ou precisar fazer alguma coisa mais maluca como TPC (não testei TPC com Spring puro e simples… bom, você pode usar o JTA do container… sei la).

O Spring tem diversas coisas legais e roda tudo no seu servlet container preferido. Ou seja, em poucos segundos sua aplicação no ar, livre, leve e solta :slight_smile:
Experimente usar Spring+Maven+jetty:run+JavaRebel para você ver a diferença de produtividade.

E não me venha falar que o glorioso Glassfish (“que é 1230912309123% vezes melhor que o JBoss, que alias demorou 1203821083102 anos para lançar uma versão compatível com Java EE 5”) sobe tão rápido quanto o jetty:run, não tem nem comparação. Numa máquina “rapida”, na configuração default, com uma aplicação simples, ele leva 30 segundos só para começar a subir a aplicação.[/quote]

Bom, você mesmo já respondeu o porque EJB3 é uma solução viavel… quando vc aprende EJB3… é EJB3… e não " Spring+Maven+jetty:run+JavaRebel"

A curva é bem menor… e o resultado em 90% dos casos é identico… quando você procurar algum profissional para dar manutencao… ele não vai precisar ser um “guru” para mecher no core da sua app.

Quanto a 30 segundos para começar a carregar a sua app… deve ter algo configurado errado em sua maquina… prq minha app começa a iniciar 10 segundos apos eu digitar “asadmin start-domain”…

E o glassfish 3.0 comeca a startar 1,2 segundos depois… então… acho melhor você rever os seus conceitos.

Peraí chun.

Spring+Maven+jetty:run+JavaRebel = 1 Framework, 1 build tool, 1 webserver\goal, 1 standalone tool

O EJB3 é equivalente ao Spring. Usando EJB3 você vai ter que aprender alguma ferramenta de build (nao me venha falar que o NetBeans “abstrai” com aquele ant nojento que ele gera), você vai ter que aprender a usar as tasks\goals ferramenta, você vai ter que aprender a usar um appserver e se quiser usar o javarebel (ele suporta glassfish) vai ter que usar javarebel. Não vejo a necessidade de um guru para mexer no core da aplicação.

Você esta falando de aplicações web ou EJB? Usando EJB3 vou ter que usar um container EJB, logo, vai demorar bem mais que 10 segundos para carregar.

[quote=Rubem Azenha][quote=chun]
Bom, você mesmo já respondeu o porque EJB3 é uma solução viavel… quando vc aprende EJB3… é EJB3… e não " Spring+Maven+jetty:run+JavaRebel"

A curva é bem menor… e o resultado em 90% dos casos é identico… quando você procurar algum profissional para dar manutencao… ele não vai precisar ser um “guru” para mecher no core da sua app.
[/quote]
Peraí chun.

Spring+Maven+jetty:run+JavaRebel = 1 Framework, 1 build tool, 1 webserver\goal, 1 standalone tool

O EJB3 é equivalente ao Spring. Usando EJB3 você vai ter que aprender alguma ferramenta de build (nao me venha falar que o NetBeans “abstrai” com aquele ant nojento que ele gera), você vai ter que aprender a usar as tasks\goals ferramenta, você vai ter que aprender a usar um appserver e se quiser usar o javarebel (ele suporta glassfish) vai ter que usar javarebel. Não vejo a necessidade de um guru para mexer no core da aplicação.
[/quote]

Olha, se nojento ou nao… um “play” e tenho um .ear pronto para deploy… posso personalizar tudo no build.xml ( que é limpo e nao tem nenhuma implementacao, puxa tudo do build-impl.xml), e posso usar este mesmo build system no hudson… que vai gerar numa boa :slight_smile:
O Spring é tão cheio de coisas… que logo vc vai precisar de um cara super treinado para poder conhecer todas artimanhas dele… e já tive muito problemas com isso… e os 512 milhoes de xml ( mechi com versoes antigas do spring)… Enquanto EJB3… é EJB3 :slight_smile: Suporta tanto beans antigos quanto novos… voce evolui quando e como quiser :slight_smile:

Você esta falando de aplicações web ou EJB? Usando EJB3 vou ter que usar um container EJB, logo, vai demorar bem mais que 10 segundos para carregar.[/quote]
[/quote]

Tanto faz… voce esta dizendo que leva 30 segundos para INICIAR o deploy… te digo que em 10 segundos aqui tenho o inicio da minha carga :slight_smile:

Carrego container EJB e tudo mais :slight_smile:

E outra questão é que MUITAS coisas são carregadas “conforme voce vai usando” no caso de servlet containers… um belo exemplo disso é o Hibernate…

No caso do EJB ele carrega tudo de cara…

Todos metem pau na especificação anterior à 3, mas queria que lembrassem como era fazer em CORBA - IDL… Ha EJB complicado, viram nada !!

se não fossem as entidades CMP , o que seria do Hibernate ? Nem existiria :wink:

Mas quem apostou nelas… hoje não precisa jogar tudo fora para utilizar EJB3…

Pensando a longo prazo, EJB sempre foi e continua sendo vantajoso em varios casos.

Hum, não sei exatamente o quanto é possível customizar o build do ant do NetBeans (Se é que é preciso). Então posso estar errado.
Mas ainda bem que eu uso o Maven+Eclipse, que segue uma abordagem contrário, a ferramenta de build gera o projeto do eclipse :). Quanto menos dependente da IDE melhor.

Opa, não compare a nova versão do EJB com a antiga versão do Spring que é covardia.
Alias… o EJB’Standard Java EE’ também é “cheio de coisas” e você precisa de um cara treinado para conhecer todas as artimanhas dele, principalmente as particularidades de cada AS.

OK, vou pegar aplicação que eu tenho e dar uma chance ao Glassfish

[quote=Rubem Azenha][quote=chun]
Olha, se nojento ou nao… um “play” e tenho um .ear pronto para deploy… posso personalizar tudo no build.xml ( que é limpo e nao tem nenhuma implementacao, puxa tudo do build-impl.xml), e posso usar este mesmo build system no hudson… que vai gerar numa boa :)]
[/quote]
Hum, não sei exatamente o quanto é possível customizar o build do ant do NetBeans (Se é que é preciso). Então posso estar errado.
Mas ainda bem que eu uso o Maven+Eclipse, que segue uma abordagem contrário, a ferramenta de build gera o projeto do eclipse :). Quanto menos dependente da IDE melhor.
[/quote]

Já utilizaste o MavenIDE do NetBeans ? É exatamente a mesma coisa :slight_smile: O netbeans obedece a estrutura do Maven… porem voce pode customizar o quanto necessitar do build.xml , lá tem as tarefas pre-compile,pos-compile,pre-ear,pos-ear entre outras… mas quem quer maven , usa maven.

[quote=Rubem Azenha][quote=chun]
O Spring é tão cheio de coisas… que logo vc vai precisar de um cara super treinado para poder conhecer todas artimanhas dele… e já tive muito problemas com isso… e os 512 milhoes de xml ( mechi com ersoes antigas do spring)… Enquanto EJB3… é EJB3 :slight_smile: Suporta tanto beans antigos quanto novos… voce evolui quando e como quiser :slight_smile:
[/quote]
Opa, não compare a nova versão do EJB com a antiga versão do Spring que é covardia.
Alias… o EJB’Standard Java EE’ também é “cheio de coisas” e você precisa de um cara treinado para conhecer todas as artimanhas dele, principalmente as particularidades de cada AS.
[/quote]

Sem duvidas , EJB é gigante… mas para dar manutencao em um sistema “de complexidade media” não é necessario mais que alguns minutos de conversa… fora que EJB é abraçado pelo container… isso quer dizer… voce nao precisa configurar nada nele para iniciar o desenvolvimento… (a versao 3 é claro)… simplesmente funciona… (just works)

[quote=Rubem Azenha][quote=chun]
Tanto faz… voce esta dizendo que leva 30 segundos para INICIAR o deploy… te digo que em 10 segundos aqui tenho o inicio da minha carga :slight_smile:

Carrego container EJB e tudo mais :slight_smile:

E outra questão é que MUITAS coisas são carregadas “conforme voce vai usando” no caso de servlet containers… um belo exemplo disso é o Hibernate…

No caso do EJB ele carrega tudo de cara…
[/quote]
OK, vou pegar aplicação que eu tenho e dar uma chance ao Glassfish[/quote]

Na minha opinião o EJB 3 oferece uma série de serviços de nível enterprise(leia-se robustez, escalabilidade, confiabilidade, etc) de uma maneira padronizada e relativamente simples. Claro que hoje não dá pra comparar, por exemplo, a produtividade de uma aplicação web feita em rails com uma JSF + EJB(apesar de haver quem questione isso) e eu concordo que EJB 3 pode ser improdutivo ou até mesmo desnecessário em aplicações de pequeno ou médio porte. Mas percebam que quanto mais crítica a aplicação, menos se houve falar de rails, spring e adjacências… Eu percebo que os que atacam ferozmente o EJB 3 estão muito presos a facilidade de desenvolvimento e não abrem a cabeça para os requisitos da aplicação em si. Vocês por acaso vão desenvolver aplicações industriais com um php da vida? Não que façam com EJB, mas é só pra levantar a questão de que facilidade de desenvolvimento não é tudo. Quer facilidade? Pega uma dessas IDEs em que você arrasta os componentes e tudo funciona, parecendo até mágica.
E quando a aplicação precisar escalar? E se eu quiser que as regras de negócio não fiquem atreladas a apresentação(web, celular, mainframe, etc)? E se eu precisar de mensagens assíncronas? E se eu quiser um contexto conversacional com o cliente? E se …? Você pode juntar alguns frameworks para resolver esses problemas e outros, mas repito: EJB 3 resolve todos eles de maneira padronizada e relativamente simples. Sem contar que é um investimento que não vai se perder se a uma empresa específica falir… Enfim, confio no EJB 3.

E que venha o Java EE 6 com EJB 3.1

Faz uns 3 anos que saiu o Java EE 5. Ta demorando demais…

Oi Pessoal.

Há cerca alguns meses iniciamos a construção de nosso aplicativo para gerenciamento de Notas Fiscais Eletrônica, hoje o sistema já está bem maduro (funcionalidades). Com 2 meses de desenvolvimento ele já estava no ar, em produção, com as funcionalidades básicas rodando sem problemas.

Para desenvolver esse sistema (que na verdade acabou mudando um pouco seu foco deixando de ser exclusivamente para NFe tornando-se uma base de sistemas mais abrangente, principalmente por causa do SPED), optamos pela plataforma JBoss 5 + EJB3 + JPA (com Hibernate como persistence provider), Apache Axis para comunicação com WebServices da SEFAZ, XMLBeans para gerar as classes de geração dos XMLs, EJBTimers para ativar processos e enviar mensagens JMS, emails… etc.

Neste projeto, a partir do momento que optamos pelo JBoss como App Server, procurei colocar os componentes que fosse suportado pelo mesmo e que fosse indicados para melhor compatibilidade com este servidor. No entanto, optei por não utilizar as apis proprietárias, de forma que… para portar isso para um Glassfish talvez algumas horas de trabalho em testes resolveria caso precisássemos.

Quanto ao portal WEB, começamos com JSP, Struts e Ajax (jQuery), na verdade não foi uma opção nossa… por uma questão de “tempo” e “urgência” tivemos que concluir e aceitar a versão 1.0 dessa forma mesmo, mas hoje já estamos com nossa versão 2.0 caminhando para release em algumas semanas conforme o definido inicialmente, que conta com Seam 2.1 + JSF (é claro) + RichFaces… ainda rodando no JBoss5, tudo acessando os nossos EJBs já existentes e que eram utilizados no portal 1.0.

Felizmente eu sou um dos donos da empresa e como assumi o desenvolvimento em Java sózinho praticamente tive liberdade de escolher o que quisesse como tecnologia. Já fazia mais de 1 ano que eu estava em processo de estudo de tecnologias por interesse pessoal apenas. Antes de tudo isso ocorrer eu ainda trabalhava na Motorola, fiquei lá por 1 ano e 3 meses mas infelizmente lá não tinha liberdade para experimentar essa tecnologia, mas nunca me deixei abater por isso e continuei a estudar o EJB e JBoss. Talvez eu tivesse entrado um pouco mais a fundo no Spring eu tivesse abandonado o EJB3, mas infelizmente ou felizmente eu tive mais clareza com o EJB do que com o Spring, que hoje vejo ser um excelente framework.

De qualquer forma a cada dia que passa estou mais familiarizado com o EJB e vai ser dificil mudar quando já tiver alcançado um know-how avançado do mesmo.

Não adianta vc ser mestre em EJB ou Spring se a empresa para quem vc trabalha não oferece condições de vc colocar em código todo o seu potencial produtivo e criativo em prática, enfim o problema é mais do que técnico.

A melhor tecnologia pode variar a depender de diversos fatores que só um bom gerente de TI consegue captar. É preciso avalidar muito bem a capacidade técnica do pessoal, inclusive seus gostos particulares e principalmente a curva de aprendizado de uma nova tecnologia. Agora no tocante ao Spring e EJB especificamente acho que encontra “mão-de-obra qualificada” para essas duas tencologias não deve ser nenhum grande problema, eliminando assim vantagem de uma sobre a outra neste aspecto.

Se vale a pena um conselho, procuremos sempre observar e reconhecer que nenhuma tecnologia é auto-suficiente. Sempre vai ter aquele momento, ou aquel probleminha chato daquela plataforma, etc… então é aí que o bom profissional tem destaque, ele precisa ser dinâmico e colocar em prática o “dom” da criatividade e da superação que Deus deu para resolver esses problemas, senão passamos a eternidade em busca do mundo perfeito, ou do ambiente perfeito se preferir :slight_smile:

Abraço a todos, parabéns pelos pontos de vista e sejam felizes com suas escolhas, pois a escolha seja ela qual for já é fator positivo de sucesso.

PS: Felizmente pelos posts apresentados não tive arrependimento na minha escolha, o que já é ótimo.

Att.
Edson

Faz uns 3 anos que saiu o Java EE 5. Ta demorando demais…[/quote]

Conta a lenda que Java EE 6 sai na JavaOne deste ano… o Glassfish v3 tá quase pronto…

Quanto a maturidade (3 anos) acho muito bom que não tenhamos muitas atualizações a cada 3 meses…(como eh caso do .Net)…

Alem da tecnologia ficar defasada muito rapidamente , teriamos pouca mao de obra qualificada.
Hoje Javae EE 5 é uma febre em novos projetos… se tivessemos o Java EE 12 possivelmente teriamos problemas de framentação de profissionais…

O que eu achei estranho é que com toda essa discussão, esqueceram de falar pro autor do tópico o que EJB3 faz e onde/quando aplicar. :slight_smile:

Bom, já que a pergunta foi “quando usar”, é de se supor que o autor saiba “como usar”.

Antes de qualquer coisa, vc precisa analisar o projeto e levantar o máximo de informações possíveis, saber o papel técnico que a aplicação vai precisar desempenhar mediante o requisito de negócio dela.

Com base nessas informações, procure avaliar e detectar quais das tecnologias disponíveis de seu conhecimento e/ou da sua equipe estão aptas a resolver técnicamente esses requisitos.

Se possível faça uma matriz comparativa e vc vai chegar a “SUA” melhor opção, pois a minha melhor opção não precisa ser a sua melhor opção.

Se perceber que o EJB é o que tem mais recursos, se ele atenderá (pelo menos na sua maioria) os requisitos técnicos expostos, e se o domínio técnico sobre o EJB é maior do que sobre alguma outra tec., talvez esteja aí o momento de usar.

Agora, alguns dizem que só em grandes projetos, outros nem isso :stuck_out_tongue: , mas na minha opinião particular sempre vou tentar ao máximo usar EJBs principalmente porque é onde eu tenho mais experiência, é padrão corporativo e então a chance de sucesso no projeto é bem grande.

Acho que se for pra partir pra uma abordagem mais técnica aqui no fórum e começar a fazer comparações de “bits”, aí vc corre o risco de ficar “travado” de vez :D. E digo isso não porque não deve ser discutido, e sim pelo fato de que a pergunta é muito abrangente então a resposta não dá pra ser específica, agora… seria diferente se vc tivesse questionado alguma funcionalidade específica do EJB, etc… e é por isso que eu sugeri vc montar a “matriz”, para sua própria análise, porque nós aqui não temos como advinhar o que vc vai precisar e se for por mim vc vai usar sempre que puder, ahauauhaauauahah. :wink:

Att.
Edson.

Bom, respondendo a pergunta do topico…

aqui na empresa eu uso EJB 2 ou 3 para implantar novos serviços para ser usado dentro da plataforma SAP NetWeaver, em outras palavras, para integrar uma aplicação java com uma SAP usando RFC.

Como funcionaria um MVC com a sua regra de negocio no EJB ???
EJB como ficará sua estrutura dentro de src.

E a grande pergunta do forum que poucos responderam …

Quando usar ??

Então é mais adequado usar EJB qndo for distribuir sistemas ???

Qndo o sistema for de medio porte ou acima … ???

Quando for para start 1,2 segundo mais rapido ???

Quando usar ???

[OFF]
EJB traz mais segurança que um padrão MVC design pattern ???

EJB é mais robusto e padrão ???