EJB 3 ou SpringFramework?

JavaChild Membro desde: 07/01/2008 10:13:47 Mensagens: 107 Offline

Olá Senhores,

Atualmente tenho trabalhado somente com EJB 2.1 e recentemente montei algo de médio porte com SpringFramework, gostei muito!!

Só que agora faço uma pergunta aos que conhecem a fundo a nova especificação,

Em que situações devo utilizar EJB's e em quais não devo utilizar o SpringFramework?

Abraços!

\o/

Para aplicações distribuídas, com a facilidade que o EJB3 trouxe e junto alguns bons mecanismos(DI, por exemplo), eu optaria por ele.

GUJ Master Membro desde: 23/01/2008 11:14:35 Mensagens: 1905 Offline

Rafael Nunes wrote:Para aplicações distribuídas, com a facilidade que o EJB3 trouxe e junto alguns bons mecanismos(DI, por exemplo), eu optaria por ele.

Spring FrameWork você não vai precisar de Application Service (Containers EJB), todavia a arquitetura vai lhe obrigar a compatibilizar o tende ser mais vantageoso em termos de manutenabilidade.
Uma decisão a se pensar, ao design da arquitetura a ser projetada em vista de todo um processo.

JavaChild Membro desde: 07/01/2008 10:13:47 Mensagens: 107 Offline

Para aplicações distribuídas, com a facilidade que o EJB3 trouxe e junto alguns bons mecanismos(DI, por exemplo), eu optaria por ele.

Com SpringRemoting, um RMI não resolveria? e também não sei como é no EJB3, mas no 2.1 tenho que implementar n interfaces para ser remoto!
com Spring apenas denoto e em execução se torna Remote.

Só não sei como ficaria a transação com SpringRemoting.

This message was edited 1 time. Last update was at 26/02/2008 10:21:06

Marcio Duran wrote:
Spring FrameWork você não vai precisar de Application Service (Containers EJB),

E qual o problema em se ter um?

Marcio Duran wrote:
todavia a arquitetura vai lhe obrigar a compatibilizar o tente ser mais vantageoso em termos de manutenabilidade.

E o que isso quer dizer?

Ps: Por que você precisa colocar uma(ou várias) imagem gigantesca em toda mensagem sua?

rpffoz wrote:
Com SpringRemoting, um RMI não resolveria? e também não sei como é no EJB3, mas no 2.1 tenho que implementar n interfaces para ser remoto!
com Spring apenas denoto e em execução se torna Remote.

Sim, resolveria, mas como disse, a facilidade que tenho com EJB3 não sei se compensaria(nunca utilizei o Spring pra fazer comunicação remota). E ao contrário do EJB2, o EJB3 você só precisa de uma interface comum(que será sua interface remota) e uma classe(que será seu EJB) com duas anotações.

rpffoz wrote:
Só não sei como ficaria a transação com SpringRemoting.

Com EJB eu deixo isso a cargo do container. E como nunca tive que fazer nada muito complexo em relação a transações, tem me atendido perfeitamente.

Exemplo EJB3:

voilá..

GUJ Master Membro desde: 23/01/2008 11:14:35 Mensagens: 1905 Offline

Rafael Nunes wrote:
Spring FrameWork você não vai precisar de Application Service (Containers EJB),

E qual o problema em se ter um?

- O que o domínio pede ? O que vai me tornar mais escalável ou não.

"todavia a arquitetura vai lhe obrigar a compatibilizar o tente ser mais vantageoso em termos de manutenabilidade."

E o que isso quer dizer?

Ps: Por que você precisa colocar uma(ou várias) imagem gigantesca em toda mensagem sua?

Gosto de imagem, mas coloquei uma menor

JavaTeenager Membro desde: 29/03/2005 14:53:51 Mensagens: 165 Offline

Rafael Nunes wrote:
Exemplo EJB3:
interface MinhaInterface{ void metodo_mais_remoto_do_mundo(); } @Stateless(name="MeuBean") @Remote(MinhaInterface.class) class MeuBean{ void metodo_mais_remoto_do_mundo(){} }

voilá..

exemplo com spring:

Se sua aplicação vai ser realment distribuida, eu fico com EJB3.
Eu tinha em trauma com EJB por causa de um projeto em 2004 suando a versão 2.1, e nem podia ouvir falr nessa palavra.
Mas a um tempo atras resolvi dar uma estudada e usei em um projetinho p/ ver como era. Muito facil de usar.

Pontos que destaco nessa versao:
1 - Não depende mais explicitamente da API de RMI, vc usa classes e interfaces java normais.
2 - Suporte a DI direto pelo container.
3 - Controle de transações transparente.
4 - Facil de escalar se for necessario.
5 - "Independencia" de container.

IMHO, hoje se eu precisasse desenvolver um sistema distribuido eu escolheria EJB3.

[]´s

JavaChild Membro desde: 07/01/2008 10:13:47 Mensagens: 107 Offline

Se sua aplicação vai ser realment distribuida, eu fico com EJB3.
Eu tinha em trauma com EJB por causa de um projeto em 2004 suando a versão 2.1, e nem podia ouvir falr nessa palavra.
Mas a um tempo atras resolvi dar uma estudada e usei em um projetinho p/ ver como era. Muito facil de usar.

Pontos que destaco nessa versao:
1 - Não depende mais explicitamente da API de RMI, vc usa classes e interfaces java normais.
2 - Suporte a DI direto pelo container.
3 - Controle de transações transparente.
4 - Facil de escalar se for necessario.
5 - "Independencia" de container.

IMHO, hoje se eu precisasse desenvolver um sistema distribuido eu escolheria EJB3.

Hun... realmente hoje não vou distribuir meus objetos, logo o Spring me atende muito bem.
Mas taí, se houver a necessidade de distribuir objetos em outra aplicação, eu darei uma pesquisada.

Quanto as vantagens, acredito que fica pau a pau com o Spring atualmente, só me encucou um detalhe, o que você quis dizer com:

5 - "Independencia" de container.

!?!?

edpipole wrote:

Rafael Nunes wrote:
Exemplo EJB3:
interface MinhaInterface{ void metodo_mais_remoto_do_mundo(); } @Stateless(name="MeuBean") @Remote(MinhaInterface.class) class MeuBean{ void metodo_mais_remoto_do_mundo(){} }

voilá..

exemplo com spring:

@Service public class TesteServiceBean implements ITesteServiceBean { @Autowired private IComponentBean componentBean; public void setComponentBean(IComponentBean componentBean) { this.componentBean = componentBean; } }

Não conheço o Srping remote, mas nesse seu exemplo eu preciso de 4 arquivos para disponibilizar algo remotamente?
Duas classe e duas interfaces?

[]´s

rpffoz wrote:

Hun... realmente hoje não vou distribuir meus objetos, logo o Spring me atende muito bem.
Mas taí, se houver a necessidade de distribuir objetos em outra aplicação, eu darei uma pesquisada.

Quanto as vantagens, acredito que fica pau a pau com o Spring atualmente, só me encucou um detalhe, o que você quis dizer com:

5 - "Independencia" de container.

!?!?

Teoricamente, se vc pegar sua aplicação usando EJB3, gerar um EAR dela, vc pode fazer deploy em qualquer container EJB que implemente a especificação.
Coloquei entre aspas pq ainda não testei isso, e nos sabemos que entre a teoria e a pratica tem um grande distancia... hehe

[]´s

JavaTeenager Membro desde: 29/03/2005 14:53:51 Mensagens: 165 Offline

jgbt wrote:

Não conheço o Srping remote, mas nesse seu exemplo eu preciso de 4 arquivos para disponibilizar algo remotamente?
Duas classe e duas interfaces?

[]´s

na verdade você precisa apenas de uma interface para distribuir... esse e a implementação do lado servidor... apenas a interface ITesteServiceBean precisa ser de fato distribuida...

mais para distribuir eu tbm vou de EJB... a não ser que vc use spring na sua aplicação delegando as transações para o container EJB e usar EJB de fachada...

What is classpath? Membro desde: 05/02/2004 13:43:20 Mensagens: 6 Offline

Acredito que isso vai depender do contexto (conhecimento do arquiteto, tempo, atributos de qualidade, requisitos do sistema) da tua arquitetura.

Agora as vantagens e desvantagens de cada um em contextos conhecidos:

- Gerenciamento de transação:

Acho muito interessante porder definir um TransactionManager utilizando aspectos, e de "esquecer" um pouco disso e ainda ter flexibilidade sem alterar código depois.

EJB3 tem os interceptors, mas acho mais flexível os tipos de definições disponíveis no Spring (regExp, pointcut, annotation) além de ser menos intrusivos e você ainda pode definir o escopo dos objetos, etc.

- Distribuição:

Existem várias estratégias de distribuição e o motivo de porque você implementá-las. Se for por performance, temos que ver onde está o gargalho, pois temos várias soluções desde de optimização de selects lentos, load balance, até virtualização, e em último caso alteração de código. A maioria dos problemas que já vi em relação a sistemas bem desenvolvidos foi por causa de I/O ou lock em algum objeto/dado, que são problemas de sobrecarga e concorrência, ou seja, arquitetura.

Como EJB3 é uma API, os comparativos vão depender de qual servidor de aplicação está sendo usado e qual tipo de sistema temos. O mesmo acontece com o Spring, pois essas estratégias são plugáveis dentro do contexto do Spring, que vão desde de barramento de serviços de dados, clusterização (Terracotta), SpringRemote, etc. (Não esqueçam do SCA que deve estabilizar em breve, plugável também no Spring)

- Acesso a dados:

JPA é uma padronização já esperada, mas que ainda falta alguns itens como Criteria e StoredProcedure mais robusta, infelizmente ainda vou continuar com os meus DAOs, ainda não dá para injetar um EntityManager e usar ele para tudo.

- Extensibilidade

Agora com o Spring 2.5, podemos definir schemas e usá-los dentro do contexto do Spring. As especificações e as novas funcionalidades da plataforma Java tente a ser mais demoras e nem por isso, como vimos, vão ser melhores que as da comunidade.

- Padrão de mercado

Acredito que a grande maioria dos projetos começam com a célebre frase, "o sistema é somente alguns processos e uns cadastros simples". Com o Spring consigo crescer sem muitos problemas de refactore de forma simples, e com o EJB já tenho que está dentro de certos padrões, isso não ruim, mas para fazer um pequeno sistema é chato. JBoss Seam está melhorando essa integração da plataforma Java, mas ele ainda não faz parte de nenhuma JSR, ah faz sim, WebBeans, ou seja, vai demorar, é promessa.

- Deployment

Para EJB3 isso é bem legal, criar um EAR e fazer um deploy "no sangue". Isso depende muito de como foi projetado o sistema, ja tive problemas com sistemas que tinham singletons, mas isso deve se amenizado em breve com os frameworks a nível de bytecode (asm, cglib).

Aqui a plataforma entrou na frente, porque só existe Spring Dynamic Modules, mas ainda tá verde.

- Teste

Ah, isso não dá para comparar, pois a plataforma por ela mesmo, não tem facilidades ou API para testes. O Spring, é igual a chiclete que gruda em tudo, JUnit e uma API já estão disponíveis.

E ainda existe uma outra possibilidade, Spring com EJB3, já pensou nisso ? Ter o melhor dos dois em um projeto. Segundo o Spring Reference, dá sem problemas!

Vejo a plataforma JEE como um corredor em segundo lugar sempre atrás do primeiro, pegando o vácuo e vendo os buracos que não deve pisar. Isso é muito bom.

- A comunidade cria, testa e vira API.
- A gente começa a usar e vê oportunidades de soluções, implementa, virá padrão de mercado;
- Torna-se API.!

Ciclo de aprimoramento da plataforma Java. Não sei se DotNet tem isso, mas vou descobrir, até me cadastrei no The Journal Architecture. (Calma, eu não sou "traíra", só quero ver o tem do outro lado do rio.)

Veja que mais e mais o trabalho de um arquiteto, que tem conhecimento dessas vantagens e desvantagens, está sendo valorizado porque essas respostas dependem de muitas variáveis a analisar.

JavaChild Membro desde: 07/01/2008 10:13:47 Mensagens: 107 Offline

Vlw rafaeluchoa pela linda explanação!

Me clareou algumas coisas e me mostrou algumas, não conhecho SCA, mas nada como uma Googlada não resolva.

Quanto ao seu ponto de vista, realmente um arquiteto tem que estar o máximo preparado com tais tecnologias,
como disse, minha formação é EJB 2.1, mas nas horas vagas estou me atualizando! +)

Mais uma vez muito obrigado.

Abraços
\o/

Thread.start() Membro desde: 24/03/2008 08:16:26 Mensagens: 27 Offline

- Teste

Ah, isso não dá para comparar, pois a plataforma por ela mesmo, não tem facilidades ou API para testes. O Spring, é igual a chiclete que gruda em tudo, JUnit e uma API já estão disponíveis.

Excelente post, mas não entendi a parte que foi falada sobre os testes.

No home do site oficial do JBOSS Seam, encontramos a seguite mensagem:

Seam components, being POJOs, are by nature unit testable. But for complex applications, unit testing alone is insufficient. Therefore, Seam provides for easy testability of Seam applications as a core feature of the framework. You can write JUnit or TestNG tests that reproduce a whole interaction with a user, exercising all components of the system, and run them inside your IDE.

Alguem poderia comentar alguma coisa sobre esses testes unitários no Seam? Esses componentes são realmente testáveis, visto que o Seam utiliza EJB3?

Notícias, artigos e o maior fórum brasileiro sobre Java