EJB ou Spring

Pessoal, tenho a situação de uma aplicação onde estima-se cerca de 2 milhoes de requisições mês.
Estamos definindo a arquitetura, temos experiencia em SPRING, utilizando somente seus recursos de DI e o Acegi, quanto ao EJB, temos um pequena experiencia, mas por exemplo, nunca fizemos na pratica um pooling de beans.
Enfim, pela alta carga de requisições vejo EJB como a saida mais apropriada, por facilitar uma dita escalabilidade horizontal, visto que este sistema deverá ter alta disponibilidade.
No entanto, vejo que se nao utilizar SPRING eu perco muito pelas vantagens que seus subprojetos nos trazem, o Acegi por exemplo, seu DI que é mais eficiente do que o do EJB, e outros.
Enfim, o que voces acham. Eu devo utilizar EJB ou SPRING, ou ambos é aconselhavel tbem?

Outra coisa pessoal, gostaria de saber voces tem confiança em colocar o SPRING para um projeto assim, tão grande como expliquei

Thread.start() Membro desde: 23/04/2004 13:21:51 Mensagens: 28 Offline

spranta, neste link http://www.parleys.com/display/PARLEYS/Voca,%20a%20Spring%20case-study tem um case do spring gerenciando 100 milhôes de transações em 4 horas todos os dias, logicamente deve ter uma puta arquitetura por trás disso, mas já serve como base.

Eu gosto muito do Spring, mais que do EJB, porém eu não tenho valores estatisticos para comprovar se a sua arquitetura é melhor com EJB ou SPRING. Porém uma coisa legal é usar eles em conjunto. Embora eu nunca tenha feito, olhando na documentação parece algo simples.
http://static.springframework.org/spring/docs/2.5.x/reference/ejb.html

qual a diferença entre a 2.0.7 e a 2.5. mudou muita coisa ?

Herrera

Eu também prefiro Spring a EJB, mas não sei exatamente o que você precisa no projeto para opinar. Sobre a questão da escalabilidade, o que o seu projeto precisa que o Spring não oferece?

E a versão 2.5 traz muitas novidades. Dentre elas a possibilidade de configuração do contêiner com anotações.

Eu voto para EJB, pensando que na versão 5.0 JEE, vc tem DI tb.. e sobre o acegi, vc tem o JAAS, que tem funcionalidades similares e ainda é garantido que funciona em qualquer container(lembrando que tem que seguir a especificação sem utilizar recursos específicos do container).
Eu já trabalhei com sistemas grandes e clusterizados com JEE, agora com spring mexo a pouco tempo, mas já esbarrei em alguns problemas para chamar componentes distribuídos fisicamente. Quem sabe alguém pode dar uma força nisso, pois seria a base para vc fazer cluster horizontal.

ManchesteR wrote:Eu gosto muito do Spring, mais que do EJB, porém eu não tenho valores estatisticos para comprovar se a sua arquitetura é melhor com EJB ou SPRING. Porém uma coisa legal é usar eles em conjunto. Embora eu nunca tenha feito, olhando na documentação parece algo simples.
http://static.springframework.org/spring/docs/2.5.x/reference/ejb.html

Exato! Embora até aonde eu sei não está full a integração do Spring com o EJB3, a versão atual é bastante abrangente!

Olá pessoal, primeiramente agradeço a todos pelo retorno tão imediato.
Primeiramente, estudei um pouco mais o conceito de objeto distribuido, e aos poucos estou concluindo que realmente nao existe necessidade de objetos distribuidos para o meu problema, nao vejo um grande ganho de escalabilidade distribuindo objetos, sei que existe, mas considero que uma clusterização da aplicação é um ganho muito maior de escalabilidade, pois a distribuição de carga que uma clusterização oferece ao meu ver sobrecarrega menos determinados pontos da aplicação, visto que se temos um objeto distribuido com EJB que não seja clusterizado ele pode vir a ser um gargalo mesmo estando distribuido. Aliás, é possivel clusterizar objetos distribuidos do EJB? E o desempenho de chamar remotamente EJB, compensa? Como disse, estou achando que um ambiente clusterizado possui uma escalabilidade maior que objetos distribuidos, o que voces acham?

Cara não entendi muito bem o que vc quis dizer. Mas o fato é, que até onde sei, é muito fácil escalar horizontalmente um sistema baseado em EJB3. agora, gargalo seria se vc fizesse invocações remotas à objetos dentro da mesma VM, isso seria sim um gargalo...

Bom vamos lá, o Spring realmente segura milhões de transações numa boa. Muitos até compararam a performance IoC com o Guice do google e a nova versão, segundo à Interface21 está em torno de 200X mais rápida.

O Acegi é um excelente framework de segurança, com uma série de features adicionais. Recomendo estudar bastante o produto, a fim de desenhar uma solução utilizando até fetaures que talvez vc não conheça e pode reforçar sua aplicação como Run-as replacement, Remember-me e por aí vai ... vc ainda pode delegar o Login para um centro de autorização JAAS.

PS: O esquema de votos do Acegi é bastante interessante e só por isso já vale à pena utilizar a ferramenta.

Quanto EJB ou Spring, lhe digo que não são excludentes. Isso porque você pode sim utilizar DI da nova especificação, entretanto esta não lhe dará suporte à Objetos que não passem por ele.

A nova versão 2.5 está bastante simplificada o acesso aos recursos, como JNDI que anteriormente exigia um XML de configuração mais complexo.

Agora existe configurações JEE , anotações diversas ... o framework está bastante produtivo, acho que deram uma olhada nessa direção e como ele é bastante abrangente, ficou meio complexo.

Com relação à seu projeto, pode ficar tranquilo, utilize os recursos JEE juntamente com spring. Se fores utilizar JPA por exemplo, pode se fazer valer dos templates JPA do Spring, localizar a PU registrada no JNDI facilmente com as novas tags JEE da versão 2.5.

Trabalho a um bom tempo com Spring e o utilizo em diversos projetos, até pessoais e é um dos frameworks melhores documentados que conheço.

PS: Desenvolvi uma ferramenta de migração para milhões de registros concorrentes e ele funciona tranquilamente

Arquitetura Spring + Hibernate praticamente.

O que vc diz "clusterização de aplicação" seria fazer um load balance, onde vc tem toda a aplicação replicada em outra máquina e um apache da vida faz o split ?
Se for isso, realmente vc tem um ganho de escalabilidade e disponibilidade, os únicos pontos que vc tem que verificar são caches, geração de chaves primárias e controle de versão dos objetos de domínio que estão nos dois servidores, se isso não tiver problemas pra vc, então realmente compensa...
O ganho do uso do EJB, é que o mesmo tratamento que vc faria para esses pontos que citei, você aproveita no cluster, pois o container trata isso pra vc. Mas lógico, se vc tiver uma porrada de singleton perdido, aí não tem milagre que resolva

E sobre as invocações remotas, vc tem razão, elas deixam mais lentas as chamadas, e é um ponto a se considerar na clusterização.

Eu acho um erro o que é "pregado" pelo EJB na questão de Cluster.

Soluções como Terracota e até mesmo o GridGain se fazem muito melhores e mais performáticas. Sendo que vc não precisa se preocupar com muita coisa, pois você tem apenas 1 aplicação, quantos nós de máquinas existem pra baixo não é problema da aplicação muito menos da aplicação. É muita configuração e muito overhead para pouca coisa, porém existem sim algumas poucas aplicações para EJB e toda sua parafernalha. =)

Cara, Terracota eu já acho que já é ir para o lado negro da força

, pq existem padrões e especificações para as APIs java, já o bytecode eles não tem muito pudor em mudar a parada...
A coisa em torno de EJB é um pouco da história que envolve sua criação, a galera de hj não viveu trabalhar com sistemas distribuídos no início, pois o EJB 3.0 está muito melhor que 2.1, que por sua vez melhor que 1.0 que era melhor do que usar Corba na mão, mas concordo que ainda pode melhorar

Essa é a questão de todas configurações, mitos e lendas sobre ele.

This message was edited 3 times. Last update was at 27/11/2007 16:04:08

jujo wrote:Eu acho um erro o que é "pregado" pelo EJB na questão de Cluster.

Soluções como Terracota e até mesmo o GridGain se fazem muito melhores e mais performáticas. Sendo que vc não precisa se preocupar com muita coisa, pois você tem apenas 1 aplicação, quantos nós de máquinas existem pra baixo não é problema da aplicação muito menos da aplicação. É muita configuração e muito overhead para pouca coisa, porém existem sim algumas poucas aplicações para EJB e toda sua parafernalha. =)

Concordo em número, gênero e grau.

Antes de pensar em EJB tem que se pensar no POR QUE?

Seu sistema precisa ser realmente distribuído?

Vc vai utilizar mensagens assíncronas ou chamadas remotas?

Precisa de cluster ou load balance com cluster de session resolve?

Mesmo que vc precise de tudo isso, existe diversas outras soluções além de EJB como Spring, Jgroups, xFire, etc.

EJB melhorou muito na versão 3, mas na grande maioria dos casos é uma solução desesperadamente em busca de um problema, para que algumas empresas possam vender projetos caríssimos e applications servers a 10 mil dólares por processador.

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