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
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.
[quote=ManchesteR]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[/quote]
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.
[quote=jujo]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. =)
[/quote]
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.
[quote=reinaldob]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.[/quote]
Eu acho que não.
Simplesmente eu acho que o fato de os ASs gerenciarem o cluster la no topo da pilha, bem pior do que um gerenciamento na base, onde pra cima vc não precisa de nada, fica tudo transparente.
Mas, quase nunca se precisa algo assim tbm =) a maior parte dos problemas um simples load balancing já resolve.
[quote=saoj][quote=jujo]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. =)
[/quote]
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.
[/quote]
Isso já foi discutido uma série de vezes, sobre corba , evolução e tudo mais …
Particularmente a especificação tem coisas legais, como MDB´s , logo não dá pra sair generalizando.
Vale estudar com cuidado e se o problema é performance, olhar para soluções como as citadas, ainda incluiria uma à lista - Gigaspaces, que na versão 6 possui excelente integração com Spring
[quote=reinaldob]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 ?
[/quote]
É isso mesmo.
E pelo visto EJB não é seria mesmo minha melhor solução para dar melhor escalabilidade a aplicação.
Agora uma duvida que ainda nao entendi, quando distribuir objetos com EJB é realmente interessante? Alguem conhece um exemplo prático que possa nos apresentar, para que possamos cada qual em seu projeto responder a velha pergunta: Meu projeto precisa ou não ter objetos distribuidos?
Até porque pelo que tenho sentido, o proprio uso de WebService pode substituir um objeto distribuido do EJB, ou seja, prover um serviço remoto em uma máquina isolada fisicamente. Ou seja, se eu acho que minha aplicação toda em uma única maquina está sendo sobrecarregada, eu poderia isolar suas regras de negocio com EJB em um objeto distribuido, ou seja, fora daquela maquina né, mas eu tbem poderia fazer isso via WebService, não? E com WS eu ainda teria o ganho de maior interoperabilidade. Será que eu confundi muito as coisas? Com relação a performance, alguem sabe qual solução seria melhor?
E por fim só mais uma duvida: Verifiquei que EJB pode ser um ponto de controle observavel e melhor controlável pelo SErvidor de Aplicação, desta forma, na possibilidade de um possivel problema, como desempenho por exemplo, este recurso me daria maiores possibilidades de identificar o gargalo. Como eu poderia ter pontos de controle observaveis pelo meu servidor de aplicação desta forma sem usar EJB, alguem sabe?
By Kenobi:[quote] 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. [/quote]
Só complementando:
http://www.acegisecurity.org/
http://www.javaworld.com/javaworld/jw-10-2007/jw-10-acegi2.html
http://code.google.com/p/google-guice/wiki/SpringComparison
http://google-guice.googlecode.com/svn/trunk/javadoc/com/google/inject/Binder.html
http://www.christianschenk.org/blog/comparison-between-guice-picocontainer-and-spring/
sds.
Um detalhe é que 2 milhões de requisições/mês diz pouco sobre tua necessidade. Não fica claro como ficam distribuídas essas requisições. Falar de picos é mais útil.