Ejb e jpa

Oi Fernando,

você poderia especificar melhor a sua pergunta? EJB 3.0 != Hibernate.

Claro,

Gostaria de saber quais são os argumentos que me leve, ao desenvolver uma aplicação web, a utilizar EJB, e não apenas JPA/Hibernate. Um dos motivos, é a parte de clusterização…Mas existem outros argumentos?? Eu sinceramente acho o uso de EJB uma complexidade a mais…

Não sei se vc conseguiu entender a questão…

Entendi. Bem, o EJB é o carro chefe da plataforma JavaEE da Sun e a sua arquitetura fornece um conjunto de serviços para aplicações coorporativas, como segurança, transações, cluster, agendamento e outros recursos. JPA está na especificação EJB 3.0 mas a Sun pretende torná-la uma especificação a parte, sem falar que você pode utilizar JPA para outros tipos de aplicações, como Desktop.

JPA se baseou no Hibernate e por ser uma especificação, algumas empresas a utilizam por esse motivo. O Hibernate ainda continua sendo muito mais robusto do que a JPA, fornecendo uma API muito mais abrangente. JPA e Hibernate são frameworks ORM, ou seja, para persistência. Persistência é um dos recursos que a arquitetura EJB abrange.

Como alternativa, existem frameworks no mercado que fazem o trabalho semelhante, e até as vezes melhor. Portanto, a escolha deverá ser minunciosamente decidida, a fim de que os recursos atendam aos requisitos do seu sistema.

Mas aí é que está a questão: Que requisitos são esses que me obrigariam a tomar a decisão pelo uso do EJB e não pelo uso do JPA/Hibernate??

Fernando Generoso da Rosa:

Mas aí é que está a questão: Que requisitos são esses que me obrigariam a tomar a decisão pelo uso do EJB e não pelo uso do JPA/Hibernate??

Como eu falei anteriormente, EJB é diferente de JPA/Hibernate ou qualquer outro framework ORM. EJB são componentes de negócios que rodam em servidores de aplicações.

Você pode utilizar EJB sem JPA/Hibernate ou até mesmo sem JDBC, mudando o formato de persistência do seu sistema, como por exemplo em arquivos.

Então, para substituir o EJB, utilizaria o Spring??? Substituiria totalmente??

Perfeito.

Perfeito.

A meu ver Spring está LONGE de substituir EJBs. Eles podem trabalhar em conjunto sem problemas, mas dizer que Spring substitui EJB é um absurdo.

Spring é um framework de IoC(dentre outras coisas mais que foram acrescentadas com o tempo), EJB tem como objetivo prover funcionalidades convenientes a um ambiente JEE (facilitade para clusterização, Controle de Transacional, componentização).

[]'s

GraveDigger:

A meu ver Spring está LONGE de substituir EJBs. Eles podem trabalhar em conjunto sem problemas, mas dizer que Spring substitui EJB é um absurdo.

Mencionei que o Spring poderia substituir o EJB pelo exemplo citado pelo autor do post.

Leia a próxima MundoJava que você verá que o Spring é muito mais além do que um simples framework IoC.

Se você já está usando um servidor JEE, como Glassfish ou JBoss, eu não vejo nenhum motivo para preferir Spring a EJB, a não ser talvez se toda a equipe já estiver familiarizada com Spring. Se o padrão já provê tudo o que você quer, pra que ficar adicionando dependência?

Pessoalmente, eu acho que EJB 3 reduz a curva de aprendizado, porque passa para o container responsabilidades como controle de transação e injeção de dependências. Você pode preferir deixar essa parte no seu framework, mas eu acho que EJB está bem intuitivo.

rubinelli:

Se você já está usando um servidor JEE, como Glassfish ou JBoss, eu não vejo nenhum motivo para preferir Spring a EJB, a não ser talvez se toda a equipe já estiver familiarizada com Spring. Se o padrão já provê tudo o que você quer, pra que ficar adicionando dependência?

Pessoalmente, eu acho que EJB 3 reduz a curva de aprendizado, porque passa para o container responsabilidades como controle de transação e injeção de dependências. Você pode preferir deixar essa parte no seu framework, mas eu acho que EJB está bem intuitivo.

Sim, em nenhum momento eu disse que X é melhor do que Y. A minha resposta foi apenas para sanar a dúvida do Fernando. Tanto EJB como Spring são uma mão na roda para desenvolver aplicações enterprise.

rcarneiro:

GraveDigger:

A meu ver Spring está LONGE de substituir EJBs. Eles podem trabalhar em conjunto sem problemas, mas dizer que Spring substitui EJB é um absurdo.

Mencionei que o Spring poderia substituir o EJB pelo exemplo citado pelo autor do post.

O “exemplo” de EJB que ele falou foi JPA, não EJB em sua totalidade, ele desconhecia EJB, até ai sem problemas, mas afirmando o que vc afirmou, dá a entender que de fato EJB limita-se ao que ele pensava, o que está incorreto.

Valeu a dica, talvez o Spring tenha mudado absurdamente nesse tempo que eu não estou utilizando-o.

Mas ainda discordo dele como alternativa ao EJB,hehe.

[]'s

GraveDigger:

Mencionei que o Spring poderia substituir o EJB pelo exemplo citado pelo autor do post.

Bem, o Rod Johnson criou o Spring justamente para atacar as falhas que ele encontrou nas versões antigas do JavaEE. O Spring tem suporte transação, segurança, AOP, Web services, agendamento, messageria, injeção de dependência e outros tipos de recursos.

O EJB também não tem todos esses recursos?

rcarneiro:

GraveDigger:

Mencionei que o Spring poderia substituir o EJB pelo exemplo citado pelo autor do post.

Bem, o Rod Johnson criou o Spring justamente para atacar as falhas que ele encontrou nas versões antigas do JavaEE. O Spring tem suporte transação, segurança, AOP, Web services, agendamento, messageria, injeção de dependência e outros tipos de recursos.

O EJB também não tem todos esses recursos?

Não todos esses, o Spring provê até alguns que o EJB não provê.

Mas qual a alternativa do Spring para um modelo de programação Stateful ?

[]'s

Prototype.