Beleza galera?
Conheci o spring e descobri que ele tem todas as vantagens do ejb mas não é dependente de aplication server. Então que vantagens eu teria, em relação ao spring, pra usar ejb?
Desde já agradeço.
[quote] Conheci o spring e descobri que ele tem todas as vantagens do ejb mas não é dependente de aplication server. Então que vantagens eu teria, em relação ao spring, pra usar ejb?
Desde já agradeço.[/quote] Aplicações distribuidas né…
[quote=WilliamSilva][quote] Conheci o spring e descobri que ele tem todas as vantagens do ejb mas não é dependente de aplication server. Então que vantagens eu teria, em relação ao spring, pra usar ejb?
Desde já agradeço.[/quote] Aplicações distribuidas né…[/quote]
AFAIK, o Spring suporta aplicações distribuídas.
Na verdade não há necessariamente exclusão entre as opções. Vc. pode usar Spring e EJBs juntos sem problema algum.
A vantagem de se usar EJBs (com ou sem Spring) é ter um ponto de controle observável e gerenciável em sua aplicação usando mecanismos já disponíveis nos servidores de aplicação. Assim, se vc. começar a ter problemas de ,por exemplo, performance, pode identificar mais facilmente onde está o seu gargalo sem ter que recorrer a mecanismos mais intrusivos, como mensagens de trace.
Apesar de utilizar EJB no trabalho, eu não curto muito… as vezes não precisa de muita coisa, e por padrão temos q utiliza… parece um míssil pra matar um passarinho…
Um ponto vista legal do EJB é que você pode deixar a transação por controle do containner, ao invez de ficar dando commit e rollback na mão… não sei se em spring tem como fazer isso…
psevestre wrote:[quote] AFAIK, o Spring suporta aplicações distribuídas.
[/quote]
[quote] A vantagem de se usar EJBs (com ou sem Spring) é ter um ponto de controle observável e gerenciável em sua aplicação usando mecanismos já disponíveis nos servidores de aplicação[/quote]Certo, acho que foi o vinho.
Sim, é possivel. Existe um módulo do Spring chamado Transaction http://static.springframework.org/spring/docs/2.0.x/reference/transaction.html
Agora sobre o Spring fazer os componentes distribuidos, eu particularmente nunca vi, então não posso opinar 
Pelo q eu tenho lido sobre Spring o controle transacional é muito parecido com o do EJB, mas referente a componentes distribuídos tenho quase certeza que ainda ele não tem esse suporte.
Acho que nçao entendi. O que vocês chama de ‘componente distribuido’? Alias, o que voces chama de componentes?
Boa Phillip, eu entendo que um componente(objeto) distribuido pode ser um objeto que rode em sistemas heterogenios.
O que eu quis dizer na verdade, é sobre objetos rodando dentro de um cluster, onde um EJBContainer faz todo o controle de Load Balance, Fail-over, Controle de Transações, Clustering, Threading, etc etc etc.
Eu não tenho 100% de certeza, mas acredito que o Spring não faz tudo isso, principalmente a parte de Clustering.
Uma vantagem do Spring sobre o EJB é que o Spring permite injeção de componentes mais abrangente do que o EJB 3.0.
Enquanto os servidores EJB só injetam componentes gerenciados pelo container, o container do Spring injeta praticamente qualquer coisa, como POJO’s. Esse pode ser um bom motivo para utilizá-los em conjunto, como dito mais acima.
Lembrando que o Spring foi uma das respostas da comunidade à frustração das especificações EJB anteriores (2.1, 2.0).
Boa Phillip, eu entendo que um componente(objeto) distribuido pode ser um objeto que rode em sistemas heterogenios.
O que eu quis dizer na verdade, é sobre objetos rodando dentro de um cluster, onde um EJBContainer faz todo o controle de Load Balance, Fail-over, Controle de Transações, Clustering, Threading, etc etc etc.
Eu não tenho 100% de certeza, mas acredito que o Spring não faz tudo isso, principalmente a parte de Clustering.[/quote]
Pois é cara, esse assunto tem conceitos que eu preciso fixar na minha cabeça.
Corrijam-me se estiver errado:
Load Balance, Clustering e Fail-over - Isso é específico do EJB ? Já ouvi falar de produtos que gerenciam essa parte tipo o Terracota.
Controle de Transações - Isso eu sei que o spring faz mole, utilizando aspectos.
Threading - Teoricamente isso não ficaria por conta do container (Partindo do princípio queo sistema foi bem projetado) ?
Trabalho hoje com EJB e a única coisa que (em minha humilde interpretação 
) percebi que o faz diferente, é a questão de ser distribuído. O que eu só saberia fazer, como alternativa, utilizando SOA.
Sei lá, pelo menos eu achava que estes conceitos funcionavam desta forma… gostaria que me ajudassem a confirmar.
[]´s
?
Boa Phillip, eu entendo que um componente(objeto) distribuido pode ser um objeto que rode em sistemas heterogenios.
O que eu quis dizer na verdade, é sobre objetos rodando dentro de um cluster, onde um EJBContainer faz todo o controle de Load Balance, Fail-over, Controle de Transações, Clustering, Threading, etc etc etc.
Eu não tenho 100% de certeza, mas acredito que o Spring não faz tudo isso, principalmente a parte de Clustering.[/quote]
Pois é cara, esse assunto tem conceitos que eu preciso fixar na minha cabeça.
Corrijam-me se estiver errado:
Load Balance, Clustering e Fail-over - Isso é específico do EJB ? Já ouvi falar de produtos que gerenciam essa parte tipo o Terracota.
Controle de Transações - Isso eu sei que o spring faz mole, utilizando aspectos.
Threading - Teoricamente isso não ficaria por conta do container (Partindo do princípio queo sistema foi bem projetado) ?
Trabalho hoje com EJB e a única coisa que (em minha humilde interpretação ) percebi que o faz diferente, é a questão de ser distribuído. O que eu só saberia fazer, como alternativa, utilizando SOA.
Sei lá, pelo menos eu achava que estes conceitos funcionavam desta forma… gostaria que me ajudassem a confirmar.
[]´s[/quote]
Vamos lá , tentar auxiliar …
O Spring realmente ganhou muita força com seu conceito IoC por matérias e publicações como o livro do Rod Johnson e Juergen Hoeller - Expert One-on-One J2EE Development without EJB.
Naquela época, muitos projetos usavam EJB para princípios simples, como controle de transações, mapeamento pós-relacional (entity beans) e aqui ele começa a mostrar como projetos, AOP , frameworks como Hibernate podiam ser usados e o EJB não precisaria entrar em pauta para tais necessidades.
Claro que há outras necessidades, que o Spring hoje cobre também, como chamadas RMI, exposição de serviços e etc…
A especificação EJB 3.0, olhou para esse cenário e traduziu os conceitos de simplicidade de configuração e implementação.
Hoje diria que é uma tecnologia que cumpre muito bem o seu papel, sem precisar a recorrer à soluções terceiras, fora da especificação , como Terracotta para gris de pojos.
Um passo bem interessante é o conceito de exposição da camada de negócios em WebServices, com uma simples annotation.
SOA é muito mais que isso, aliás recomendo o livro do Thomas Erl, que estou lendo e aprendendo muitas coisas e revendo conceitos que foram lançados ao mercado de forma errônea.
Voltando à sua duvida, Spring e EJB não são excludentes. Você pode usar ambos no seu projeto, aliás o Spring suporta bem EJB.
Como são muitos módulos, você poderá usar o IoC do Spring, que é realmente mais completo, talvez controle de transações via AOP - proxy entre outros módulos à parte, como MVC e tudo mais.
Outro detalhe, precisa ver se sua aplicação vai ter container WEB !! O Spring precisa desse container para configuração dos seus serviços.
A BEA tem um projeto - http://interface21.com/pitchfork/ para resolver esse problema.
Se for utilizar JBoss, dá um tok em MP , tenho um projeto que fiz usando umas propriedades do application, pra contornar esse tb …
Bão fião é isso…boa sorte
Cara, valeu pela redação, mas esse é o tipo de texto que leio em todos os artigos “Spring x EJB”… sem ofensa.
A minha dúvida não era “o que é spring ?” nem “o que é EJB ?” nem “O que é SOA ?”, já trabalhei com todos eles, e sim “Por que eu usaria EJB, já que dá pra fazer tudo com spring + outros frameworks?”.
Gostaria que alguém me desse uma resposta técnica, tipo: “Eu usaria ejb se fosse um cenário X, pois isso fica ruim fazer com spring.” ou parecida com a resposta do ManchesteR, porque esses textos de alto nível não me dão a resposta que preciso.
Mas obrigado.
[]´s
bom, vamos tentar ajudar um pouco então …
Se tu usar Spring + Terracota não consigo imaginar nenhum cenário em que seja necessário utilizar EJB.
hoje, eu não confiaria no Terracota para cluster e load balancing das aplicações, apenas por ter muito menos tempo de mercado que os servidores de aplicação convencionais e por este ser um assunto bastante complexo.
então, quando eu preciso de remotabilidade transparente, para aumentar a escalabilidade horizontal da aplicação prefiro utilizar EJBs.
outro ponto, é possível, mas não vejo motivo, para utilizar Spring com EJB3.
EJB3 é na minha opinião, até mais fácil de trabalhar do que com Spring (a não ser que tu esteja usando o Spring-Annotation junto com o Spring.
Uma outra vantagem grande do EJB que é possível fazer com o spring, mas vai dar trabalho, é a gerenciabilidade da aplicação. (existe esta palavra?)
mas ainda acho que o maior motivo para se utilizar EJBs em vez de Spring é a remotabilidade transparente que os EJBs sempre tiveram, e com o spring só é possível alcançar utilizando o Terracota.
remotabilidade transparente, para aumentar a escalabilidade horizontal == Performance ?
escalabilidade não é sinônimo de performance, mesmo tendo uma ligação direta entre as duas …
escalabilidade é a capacidade de um software de manter a performance e a confiabilidade com o aumento da carga.
(tudo bem, esta explicação esta praticamente simplista, mas neste caso vai servir)
Imagine que em um mês, o numero de usuários do teu sistema aumente de 100 usuários por minuto para 1.000.000 usuários por minuto.
um sistema escalavel vai conseguir manter a mesma performance com este aumento absurdo de carga.
a escalabilidade vertical = Comprar mais HD, CPU, Memória, …
ou seja, escalabilidade vertical tem limites.
escalabilidade horizontal = Colocar uma ou mais maquinas do lado e configurar um cluster
ou seja, escalabilidade vertical praticamente não tem limites.
EJBs são a forma mais fácil de se ter um sistema com uma alta escalabilidade horizontal, pois a lógica de negócios que normalmente é a parte mais pesada de um sistema …
lógico que devem ser considerados diferentes gargalos para diferentes tipos de sistemas …
se o gargalo for a camada web isto não vai resolver, se o gargalo for o banco de dados também não vai …
por tanto para cada caso uma solução diferente 
humm, agora pesquei a parada.
Valeu pela paciência
[]´s
X