EJB, quando usar?

basicamente a idéia do EJB é criar componentes de negócio reutilizáveis tendo um amplo suporte de escalabilidade, controle transacional, segurança, web services e o caralho a 4.

pra se ter uma idéia da coisa… suponhamos que você tenha uma empresa que vende produtos tanto por celular, quanto por call center quanto por pedidos online de um site qualquer… então neste caso você tem 3 clients, seja em qualquer plataforma …

quando os pedidos estiverem com validações estáticas (campo nao pode ser null, quantidade nao pode ser menor ou igual a 0, etc…), você chama os componentes de negocio para fazerem as validações dinamicas (cliente está em debito, produto é uma promocao que nao pode vender menos de 10 unidades, blablalba), se bem que não são necessariamente validações dinamicas… mas sim regras de negocio da sua empresa… promoções, descontos, metricas, etc…

se voce tem 3 clients pra uma regra de negócio específica, por que não criá-la em um componente de negócio com EJB de modo que seja padronizada. Então esses clientes chamam o componente de negocio PEDIDOS seja localmente ou remotamente…

mas isso ai é so uma noção mesmo… acabei de acordar e escrevi meio nos sonhos ainda…rs :lol:

bons estudos.

Acho que o propósito do EJB é aplicação distribuída. Pelo que já li, a tecnologia foi concebida com o fim de tornar possível
distribuir componentes por diversas camadas físicas (tiers); cada tier rodando uma JVM.
EJB acabou virando sinônimo de “aplicação corporativa” para muita gente e começou aí a confusão. Não é difícil você ver
aplicações contruídas com EJB rodando na mesma JVM. Daí dirão: “mas então usa a interface local!”. Mas aí eu pergunto: Quando
a tecnologia foi concebida havia a interface local? Surgiu com esse propósito?
Posso estar errado, mas penso dessa forma.

Quem quiser uma referência sobre significados de componentes, tier, etc, pode consultar esse link:
http://blog.fragmental.com.br/2005/08/16/pequeno-dicionario-da-reusabilidade-em-software/

allanmarques:

Acho que o propósito do EJB é aplicação distribuída. Pelo que já li, a tecnologia foi concebida com o fim de tornar possível
distribuir componentes por diversas camadas físicas (tiers); cada tier rodando uma JVM.
EJB acabou virando sinônimo de “aplicação corporativa” para muita gente e começou aí a confusão. Não é difícil você ver
aplicações contruídas com EJB rodando na mesma JVM. Daí dirão: “mas então usa a interface local!”. Mas aí eu pergunto: Quando
a tecnologia foi concebida havia a interface local? Surgiu com esse propósito?
Posso estar errado, mas penso dessa forma.

Quem quiser uma referência sobre significados de componentes, tier, etc, pode consultar esse link:
http://blog.fragmental.com.br/2005/08/16/pequeno-dicionario-da-reusabilidade-em-software/

Então Alan, eu descordo um pouco disso.

Antigamente o custo de desenvolver um sistema usand EJB era muito grande, então seu uso era só aconselhado para aplicações distribuidas. Porém, a partir da versáo 3, isso mudou. Hoje, o custo de desenvolver com EJB eh muito baixo, e vc ganha diversas features importantes de graça dada pelo container, como controle de transação, IoC, pool de conexão, gerenciamento de threads etc etc etc, então, hoje em dia, acredito que vale a pena usar EJB mesmo que vc não for construir uma aplicação distribuida. É claro que usando um Spring da vida, vc ganha tudo isso tbm, mas pq não EJB?

[]'s

lavh,
A versão 3 trouxe muitas melhorias mesmo; a maioria delas desenvolvidas pela comunidade descontente com EJB 2.x.
Eu inverteria a pergunta que você fez: Usando Spring ganhamos tudo isso que você citou, então por que usar EJB?

allanmarques:

lavh,
A versão 3 trouxe muitas melhorias mesmo; a maioria delas desenvolvidas pela comunidade descontente com EJB 2.x.
Eu inverteria a pergunta que você fez: Usando Spring ganhamos tudo isso que você citou, então por que usar EJB?

Então Alan, acho que essa é uma opção pessoal. Eu não queria entrar no mérito de usar Spring ou EJB, na verdade, o que eu quis dizer é que hj eu penso que não é mais desculpa falar que não vai usar EJB pq o sistema não é distribuido. Agora, usar Spring ou EJB acho que é opção de cada um. Ambos são excelentes, eu até mesmo uso os dois juntos e acho que eles se completam.

caso requisito seja atender a manter escalabilidade em larga escala, suporte para ambiente clusterizado ou ambiente distribuído de forma a modularizar aplicações para plataforma de sistema como plataforma java(um exemplo seria comunicação com legados), você tem boas chances de usá-lo.

Não gosto de EJB para serviços distribuídos, se eu realmente precisasse de objetos remotos, pensaria antes em REST, em Terracotta, em XML via sockets, e até em SOAP.

Agora usar EJB3 com interfaces locais, e só locais, é interessante. Pra quem não sabe, os session beans são os seus façades da aplicação, com a diferença que se pode acrescentar serviços como segurança, persistência, injeção de outros EJBs… tudo de maneira declarativa.

falando em terracota, alguém usando, alguma avaliação boa ou má!