Vocês usam ou não EJBs?

Programação Java
#1

Olá

Sou um duro crítico dos EJBs desde que estudei EJBs 1.1 e achei ultra super mega complexo além de ultra super giga problemático em termos de desempenho e administração. Mas agora depois da versão 2.0, não penso que nunca devemos usar EJBs. Acredito que em pelo menos alguns casos dos muitos que estão por aí, eles são a solução única ou a menos ruim.

Hoje o Thiago Senna colocou a seguinte observação em um ótimo post (a meu ver com este final impróprio)

Na minha opinião, não é que não se deva usar EJBs de jeito algum e muito menos esperar pelo EJB 3.0. Acho que há alguns casos em um pequeno número de grandes empresas que a melhor ou quase única alternativa é usar EJBs em toda a sua plenitude com todos os seus problemas. Há muitos outros casos onde basta usar EJBs parcialmente com apenas Container Managed Transactions Stateless Session Beans e se pode viver muito feliz. E sei que cada vez mais se constroem arquiteturas baseadas em mensagens onde cabem muito bem os Message Driven Beans.

Apesar de pensar assim e conhecer teoricamente um pouco de EJBs, nunca participei de um projeto em que diretamente codificasse EJBs. No único caso apenas fiz o deployment no JBoss de coisas prontas que nem vi direito o código. Aí me ocorreu perguntar:

:arrow: Quem já trabalhou com EJBs e qual observação positiva ou negativa pode escrever para a gente.

Quem nunca trabalhou mas souber de casos também está convidado a dar um pitaco.

[]s
Luca

#2

Eai Luca, Olá Guj’s!

Só deixe-me fazer uma pequena observação quanto ao comentário, antes q a galera meta o pitaco em mim!

A minha colocação infeliz foi no contexto de que não seria uma boa idéia aprender EJB nesta altura do campeonato, já que a pessoa que tinha dúvidas é um iniciante!

Desculpem-me por ter me expressado tão mal!

Luca, valeu por criar este post e por referir a minha péssima colocação!
Espero ter me retratado corretamente. Mas ainda sim quero dar um pitaco nos EJB’s!

Abraços!

#3

Oi Luca,

já trabalhei em alguns projetos onde EJBs faziam parte da solução. E pelo pouco que pude ver, fiquei com a seguinte impressão:

  • MDBs são muito bons para trabalhar com JMS. Achei bem simples de codificar e se você usa uma boa IDE então, fica mais fácil ainda. Tive uma experiência de precisar trabalhar com JMS sem MDBs e foi um caos por não ter a transação gerenciada automaticamente pelo container. Não consegui enxergar pontos ruins no MDBs e pelo que leio por ai, acho que apesar do pessoal cruxificar o EJB 2.x, até livram a cara dos MDBs! :slight_smile:

  • Acho que Session Beans são muito interessantes quando você precisa fazer aplicação distribuída. Codificá-los é um pé no saco, mas com uma boa IDE ou XDoclet, o problema se resolve facilmente. Codificar clientes para Session Beans é bem simples e você ganha de graça as transações, autenticação, etc.

Abraços,
Marco Campêlo

#4

Ja trabalhei bastante com EJBs, o suficiente pra querer fugir deles como o diabo foge da cruz, por inumeras razoes, testabilidade e depurabilidade sendo as maiores delas, e ainda bem, parece que isso esta melhorando no EJB3, mesmo ainda nao terem resolvido o problema de se ficar amarrado a um fornecedor para as coisas que nao estao na spec.

De certa forma eu concordo com o Thiago - eh burrice usar EJBs hoje em dia, e pessoas bem-informadas o suficiente sabem quando se deparam com as raras excecoes que tem por aih. Entao, se vc adicionar um "Geralmente, " no comeco da frase dele, faz perfeito sentido.

#5

Olá!

Quantos aos EJB’s a minha opinião é a seguinte. Utilize EJB quando não houver opção melhor. Essa minha afirmação só valerá até a versão 2.0.
Quando ao EJB 3.0 eu não sei. Vamos esperar para ver!

O problema principal dos EJB’s talvez nem seja os EJB’s propriamente dito, e sim como os desenvolvedores empregam mau o conceito de EJB em seus projetos. Eles simplesmente optam por esta tecnologia por ser uma tecnologia poderosa e que traz um certo status de certa forma. Também tem aqueles (eu por exemplo) que visa esta tecnologia para aprender e tirar suas curiosidades em projetos que não tem este perfil. O projeto é sério e o cara deixa de pesquisar uma boa solução e aplica EJB logo de cara, só para ver no que vai dar e preencher o currículo com conhecimentos e experiência em EJB!

Hoje o ciclo de vida no meu desenvolvimento de um sistema onde está aplicado EJB é assim:

  • faço uma alteração para concertar um determinado erro;
  • 35 minutos para compilar a aplicação;
  • 2 minutos depois a máquina desliga sozinho,
  • ligo a máquina;
  • 5 minutos (em média) para iniciar o servidor e a aplicação.
  • faço o bendito teste e encontre outro erro.

Minha máquina tem 512 de RAM, e utilizo produtos Borland que faz com que exiga mais ram ainda.
Já foi solicitado máquinas melhores, mas… isso já virou conto de fadas…

Se analisado com calma, este projeto não precisaria de EJB’s. Outras tecnologias seriam suficientes para resolver o problema, mas até aqui, tudo bém.

Conclusão: Independente se usamos EJB ou qualquer outra solução é necessário se ter um planejamento da arquitetura do projeto e quais são as tenologias que devem ser empregadas para resolver o problema, e não sair usando uma solução poderosa só pelo seu nome e pela força de empresas que lhe dão suporte!

Espero ter contribuído!
Abraços!
Thiago Senna

#6

[quote=cv]Ja trabalhei bastante com EJBs, o suficiente pra querer fugir deles como o diabo foge da cruz, por inumeras razoes, testabilidade e depurabilidade sendo as maiores delas, e ainda bem, parece que isso esta melhorando no EJB3, mesmo ainda nao terem resolvido o problema de se ficar amarrado a um fornecedor para as coisas que nao estao na spec.
[/quote]

E foge para onde:

  • Quando você precisa trabalhar com JMS?
  • Quando você precisa fazer chamadas remotas ao seu código? WebServices? HTTP? RMI?

Abraços,
Marco Campêlo

#7

Mas isso é válido para qualquer tecnologia, não apenas para EJBs! :slight_smile:

Além das 50 mil interfaces e dos 500 mil XMLs, o que mais vocês enxergam de tão ruim nos EJBs?

[]'s
Marco Campêlo

#8

Opa…

Você esta falando de Spring?

Eu também já ouvi falar bém dos MDB’s. Mas hoje já temos o spring que oferece suporte para o JMS.

Daí pergunto: Para quê um EJB container para gerenciar Mensagens se você pode fazer isso usando POJO’s.

Não conheço este recurso em detalhes, mas os EJB’s neste caso não são mais a única solução.

Abraços!
Thiago

#9

Ok, vamos lá.

Session Beans são úteis, mesmo. mas quando temos clientes distribuído sou rpecisamos de transações gerenciadas pelo Container ( nãoq ue seja obrigatório, mas é útil). Até hoje eu só trabalhei em um sistema que precisasse de fato de uns EJBs, o sistema é um grande two-phase commit, e algumas coisas acabam sendo muito complexas sem a ajuda do container.

Entity Beans acho que todos concordam a merda que são, sem meias palavras.

MDB eu sou usuário, nunca fiz nada que fosse rpeciso codificar um só uso os que estão prontos, mas parece bem legal.

O grande lance quando se utiliza EJB é separar os objetos de negócio do componente. A Sun com suas especificações, blueprint e documentação toda (bem como os fornecedores de AS) induzem as pessoas a pensar que os EJBs devem implementar seus objetos de negócio. Eles dão um ótimo Service Layer nos casos citados acima, não mais que isso.

Eu, sinceramente, acredito que de tudo que já li no GUJ, 99% das pessoas que postam dúvidas aqui não tem real necessidade de usar EJBs. De tudo que trabalhei até hoje, eu só vi um sistema que seria legal seu uso!

#10

Spring? :slight_smile:

Depende. Quem sao os clientes? Onde estao os clientes? O que os clientes vao fazer? A sua pergunta ja da uma ideia das possibilidades, mas existem muitas outras, e algumas se encaixam em certos casos bem melhor que EJBs, mas EJBs continuam sendo uma boa ideia pra transacoes distribuidas se, e somente se, voce realmente precisa de transacoes distribuidas. :wink:

#11

Tirem para mim uma dúvida, por favor!

Você poderiam citar um exemplo que quando realmente se precisa de EJB, e que não há opções para substituí-lo!

Pergunte isso para que se um dia eu pensar em EJB, vou lembrar da resposta desta pergunta!

Abraços!
Thiago

#12

Rolou uma discussão semelhante em:

http://www.portaljava.com.br/home/modules.php?name=Forums&file=viewtopic&t=14198&sid=4c6967e2e9bfc6e842292f28a4685b62

A pergunta que eu coloquei lá foi:

[color=red]O que temos em EJB que não conseguimos ter sem ele ???[/color]

Na minha cabeça é a APENAS clusterização/distribuição dos beans. Isso é legal e útil para um sistema que não pode parar de maneira nenhuma e não é muito fácil de se obter por fora de EJB.

O dia que eu tiver que fazer um projeto com EJB vou me matricular numa faculdade de direito e começar a considerar uma mudança de ramo.

#13

ja trabalhei em um sistema que usava ejb’s(2.0).
tinhamos entitys cmp na persistencia e session como facades na camada de negocio.
minha impressão:
so use ejb se sua app realmente precisar ser distribuida.
acho session beans validos na camada de negocio, mas mesmo com ant/xdoclet p/ ajudar na geração de interfaces/xml’s ainda assim é bem trabalhoso.
entitys, prefira cmp. gosto do controle de transacões dele e, a persistencia é bem tranquila, mas como os sessions, da muito trabalho de manter. e os recursos do ejb-ql ainda deixam muito a desejar, qq consulta mais complexa se torns impossivel, e vc acaba tendo que fazer muitas coisas na mão.
consultas muito pesadas tmb eram um problema, pois a app acaba ficando muito pesada.

[]'s

#14

MDBs são legais de usar. Eu vejo session beans sendo uteis em alguns cenarios.

:arrow: Aplicação clusterizada, os containers J2EE fazem bem.
:arrow: Requisitos transacionais muito complexos, o Spring da conta do setup, mas caso envolva múltiplas fontes, legado ou 2PC, ainda sou mais usar EJB junto.
:arrow: JCA/Connectors/Legado, ainda é a melhor opção. Todas soluções que eu vi além de JCA+EJB são desastrosas.

#15

Eu, atualmente, faço parte de um projeto que utiliza EJB´s( Entity Beans e SessionBeans), e sinceramente,
não tenho muito o que criticar em relação aos “mesmos”.
Vamos por partes:

Entity Beans: seja CMP ou BMP - é a pior merda que inventaram dentro dos EJB´s. IMHO nas versões menores que 2.1, nem deveriam existir. Sem comentários.Uso essa bosta e faço o Arquiteto que quis usar isso se arrepender até o ultimo fio de cabelo dela, por essa escolha mal feita. É um saco ter que ficar analizando as querys extremamente peeeeeeeeeeesadas que o maldito gera no IronTrack.

SessionBeans: relativamente faceis de se trabalhar, proveem muitos serviços uteis(Segurança, Transação, …), e que não são aquele absurdo de complicados de configurar.Com relação aos xml´s de configuração - são extremamente nojentos, asquerosos, ou qualquer adjetivo do genero…mas nunca tive que modificar uma virgula em um ejb-jar.xml, jboss.xml ou qualquer outro, já que o XDoclet(a ferramenta mais util que inventaram até hoje) :mrgreen: gera tudo que é necessário pra que a coisa funcione, então acho que ninguem tem muito que reclamar disso, a não ser que o cara goste de dar tiros no próprio pé e cria tudo na OOONHA, interfaces, xml´s.

MDB´s - nunca usei, mas já vi o quão uteis são e simples de se trabalhar.

Resumindo: IMHO EJB´s(Session Beans e Message Driven Beans) são bastante uteis SIM, [color=red]mas quando usados com sabedoria[/color], na hora, local e projeto que realmente requerem todos os serviçoes que eles disponibilizam.

Isso serve pra qualquer tipo de tecnologia. Provavelmente se neguinho teve problemas com EJB´s, é porque ele foi adotado em um projeto onde
provavelmente não deveria ser adotado, e o cara nunca tinha visto isso na vida e foi obrigado a usar e tinha que fazer pra ontem e não teve tempo de estudar.

Conselho: Estudem primeiro a tecnologia, depois use-a, e ai sim, tirem conclusões…é muito fácil botar a tecnologia(EJB) no tronco e lascar o chicote na coitada.

:stuck_out_tongue:

#16

Luis,
vc tem razão, e quando falo que ejb’s so devem ser usados quando realmente necessarios, falo em relação a arquitetura e principalmente tecnicamente, pois é uma tecnologia complexa.
Em um outro post, ja tinha colocado que se a escolha for usar ejb, uma pessoa experiente na equipe vai poupar muita dor de cabeça.

[]'s

#17

Ótimo ponto, Shoes.

Nunca estudei EJB a fundo ou li recomendações da Sun ou qualquer outro fornecedor para saber o que eles pensam do assunto, mas nos casos onde usei EJB não vi nenhum bom motivo para botar alguma (ou toda) regra de negócio em um Session ou MDB.

Um dos casos onde utilizamos EJB e eu acho que funcionava muito bem (precisávamos fazer a aplicação distribuída + cluster + load balance), o Session servia apenas como um layer para fornecer a interface remota. Toda regra de negócio estava distribuída em classes Java normais. Inclusive, facilitava muito em relação a testes, pois não era necessário testar o Session para verificar se uma funcionalidade estava OK ou não, podíamos rodar os testes direto nas classes de negócio.

Abraços,
Marco Campêlo

#18

[quote=cv]

Depende. Quem sao os clientes? Onde estao os clientes? O que os clientes vao fazer? A sua pergunta ja da uma ideia das possibilidades, mas existem muitas outras, e algumas se encaixam em certos casos bem melhor que EJBs, mas EJBs continuam sendo uma boa ideia pra transacoes distribuidas se, e somente se, voce realmente precisa de transacoes distribuidas. ;)[/quote]

Que existem outras possibilidades, eu entendo e concordo.

Mas nesse caso em especial (chamadas remotas), qual vantagem vocês enxergam em utilizar qualquer uma das opções mencionadas (WebServices, RMI, HTTP) ao invés de EJB? Queria vantagens reais (dizer que configurar XML e implementar interface é chato, não vale, porque isso as IDEs já resolvem) …

Abraços,
Marco Campêlo

#19

Aqui utilizei MDB e Session Bean no último projeto que desenvolví e me foram bastante úteis.

O meu cenário era o seguinte: uma aplicação que precisava executar processos assíncronos, como atualizações e geração de arquivos. Esses processos deveriam ser requisitados por sistemas diversos.

O que fiz foi criar um sistema que gerenciava esses processos. E MDB com JMS foi como uma luva de veludo no frio de Vladvostok.

Os sistemas “clientes” apenas fazem uma chamada HTTP ou via uma interface Java / JNDI que criei (única dependência nos clientes). E o gerenciador dos processos assíncronos executam os EJB Session Bean que cada sistema disponibiliza.

Nesse caso foi uma ótima solução usar EJB. Nunca mais usei eles.

#20

Não levem a mau! É brincadeira!! Só para descontrair!! :wink: