Ejb 2.1,3.0, meo deus!

Programação Java
#1

Bem , tenho estudado EJB fazem 6 meses para poder chegar nesse nivel de pergunta no forum…

1 - A empresa em que trabalho esta a adotar uma solucao EJB 2.1 ( Session Beans ) + ACESSO DIRETO VIA JDBC , usando pool do proprio container… isso mesmo… SELECT DIRETO NO BANCO… alguem poderia me dizer qual o impacto disso na pratica ? sera um tiro no pé ?

2 - EJB 3.0 , alguem tem testado , esta ficando legal ? serah suicidio comecar a usar ele com o JBOSS ?

3 - Quem aqui tem experiencia em Entitys CMP ( mas experiencia MESMO , nao o pessoal que soh critica e nunca usou direito ) , poderia me dizer aonde o CMP peca em performance ? e quem usa… como resolveu o problema de “PRECISAR DA UM GROUP BY” e a especirficacao nao suportar ?

Obrigado a todos , e QUALQUER OPINIAO EH BEM VINDA !

#2

Olá Chun!

Esse assunto é crítico…
Rolaram vários debates interessantes aqui!

Um dos melhores tópicos é este:
http://www.guj.com.br/posts/list/15/22965.java, criado pelo Luca!

Mas resumindo:
O problema não é exatamente você usar EJB, o problema é se você realmente precisa de EJB!

Caso você realmente precise de EJB e não haja outra alternativa, vocês terão que se conformar com algumas burocracias, e com a dificuldade e muitas outras coisas desagradáveis que acompanham o EJB até a versão 2.0.

Quanto ao EJB 3.0 parece estar melhor, mais em minha opinião, mesmo não conhecendo a tenologia, acho um pouco cedo arriscar.

Se você assumir os riscos, vá em frente!

Abraços!
Thiago Senna

#3

Que outra tecnologia ofereceria a integração entre aplicativos ( ex: tenho um sistema de caixa e preiso de determinada rotina em meu aplicativo de balcao… acesso o session do caixa e pronto… nao precisa me preocupar com a regra de negocio do caixa… tah ali… eh soh usar ) ?

Que outra tecnologia me ofereceria transacao robusta neste sentido ?

Qual outra tecnologia uniria os dois pontos acima ?

O post do meu amigo luca foi bem exclarecedor… porem nao responde as minhas questoes… para nao zonear muito eu abri um novo post :slight_smile:

Outra coisa , o que vc acha dessa solucao Sessions + JDBC direto ?

[quote=Thiago Senna]Olá Chun!

Esse assunto é crítico…
Rolaram vários debates interessantes aqui!

Um dos melhores tópicos é este:
http://www.guj.com.br/posts/list/15/22965.java, criado pelo Luca!

Mas resumindo:
O problema não é exatamente você usar EJB, o problema é se você realmente precisa de EJB!

Caso você realmente precise de EJB e não haja outra alternativa, vocês terão que se conformar com algumas burocracias, e com a dificuldade e muitas outras coisas desagradáveis que acompanham o EJB até a versão 2.0.

Quanto ao EJB 3.0 parece estar melhor, mais em minha opinião, mesmo não conhecendo a tenologia, acho um pouco cedo arriscar.

Se você assumir os riscos, vá em frente!

Abraços!
Thiago Senna[/quote]

#4

cara,
ja trabalhei em um projeto usando entiy cmp com ejb 2.0.

1 - Não use ejbs(sessions) usando jdbc, ja vi uma arquitetura assim e isso é suicidio em questão de tempo.

2 - não cheguei a usar, mas as features novas parecem ter melhorado muita coisa, principalmente em relação ao ejb-ql.

3 - No seu caso, se realmente fosse usar ejb, usaria cmp. As limitações do, ejb-ql, tipo group by, eu solucionava na mão. algumas consultas mais complexas eu crie um DAO que pegava a conexão do datasource e fazia a consulta. é uma gambiarra, mas funciona bem, pois p/ consultas muito pesadas o cmp fica lento. como eu não ia manipular os dados, so mostrar, a opção do DAO funcionou bem.

so uma pergunta: seu sistem realmente precisa de ejb?
se a resposta for não, tente avaliar outras alternativas.
qq coisa manda ae.

[]'s

#5

Integração entre aplicativos internos podem ser feitos com RMI, Hessian/Burlap ou mesmo Corba.

Dependendo das tuas necessidades transacionais, não existe opção boa a EJB. Mas acho dificil precisar mais que o spring framework oferece. Vocês estão usando transações distribuidas, integração com legado via JCA, outras fontes transacionais ou mesmo JMS? Senão a robustes do spring framework é mais que suficiente.

#6

Só uma curiosidade!!!

Quando comecei a estudar EJB, e para deixar bém claro, comecei estudando o Dominando EJB, que pode ser conseguido livremente no site
www.theserverside.com, eu imaginei que EJB fosse o futuro e a solução dos problemas de toma humanidade!

Talvez hoje vocÊ esteja exatamente com esta imaginação. Percebi isso pela forma como você descreveu a integração de sistemas sem se preocupar com a camada de negócio. Isso por que o EJB traz a idéia de componentes, de que é independente de distribuidores como IBM e BEA. Há até quem imaginou que com EJB surgiria novos ramos na área, como por exemplo, administradores de componentes, programadores de componentes, analistas de componentes e até quem ficasse responsável pela segurança, e que no final, um desenvolvedor que fosse desenvolver um sistema procuraria por seviços e componentes prontos e simplesmente solicitá-los. Ou seja, pensaram (eu tanmbém) que os componentes EJB se tornaram peças de Lego. (Aquele brinquedinho que vc brincou quando era criança… rsrsrs…)

Na prática, viche… Sem comentários.
Mas isso de forma nenhuma desqualifica os EJB’s. Continue estudando esta jossa, que ainda vale a pena.

Abraços!

#7

Sobre a parte de JDBC com Session seria um suicidio… prq poderia argumentar melhor ? aonde q eu empacaria ?

[quote=jgbt]cara,
ja trabalhei em um projeto usando entiy cmp com ejb 2.0.

1 - Não use ejbs(sessions) usando jdbc, ja vi uma arquitetura assim e isso é suicidio em questão de tempo.

2 - não cheguei a usar, mas as features novas parecem ter melhorado muita coisa, principalmente em relação ao ejb-ql.

3 - No seu caso, se realmente fosse usar ejb, usaria cmp. As limitações do, ejb-ql, tipo group by, eu solucionava na mão. algumas consultas mais complexas eu crie um DAO que pegava a conexão do datasource e fazia a consulta. é uma gambiarra, mas funciona bem, pois p/ consultas muito pesadas o cmp fica lento. como eu não ia manipular os dados, so mostrar, a opção do DAO funcionou bem.

so uma pergunta: seu sistem realmente precisa de ejb?
se a resposta for não, tente avaliar outras alternativas.
qq coisa manda ae.

[]'s

[/quote]

#8

Há dois pontos a considerar em sua pergunta:

  1. Usar EJB (Session)

  2. Acesso ao banco de dados direto utilizando JDBC

Se você precisa de acesso remoto aos seus componentes e/ou 2PC, não vejo porque não utilizar Session Beans.

Quando ao fato de fazer acesso ao banco de dados sem utilizar uma ferramenta de O/R, não vejo isso como um tiro no pé. Pode ser muito bonito manter o seu modelo OO íntegro durante todo o ciclo de vida da aplicação e isso pode até mesmo te trazer mais facilidades e produtividade. Mas não encaro isso como o único caminho da felicidade! :wink:

Quantos sistemas nós já não desenvolvemos antes de surgir frameworks como Hibernate? Eu pelo menos tenho muitos casos assim em produção e estão funcionando muito bem, obrigado. Com isso, não quero dizer que Hibernate (JDO, whatever) não presta. Apenas que uma solução JDBC tradicional não será o fim dos dias para o seu sistema. Talvez gere apenas um pouco (dependendo do que você pretende fazer, muito) retrabalho, por conta do framework já te dar de graça recursos de cache, por exemplo.

[]'s
Marco Campêlo

#9

A empresa aqui nao gostaria de ficar na mao de um framework que pode de um dia pra outro “SUMIR” , como foi o caso do struts ( gaurdando sua devida proporcao eh claro ) , o pessoal tem MUITA FEH na JCP … e realmente session oferecem muita coisa pronta… RMI seria suicidio… sao VARIAS ESTACOES e o pooling dos Session resolve isso transparente…

[quote=louds]Integração entre aplicativos internos podem ser feitos com RMI, Hessian/Burlap ou mesmo Corba.

Dependendo das tuas necessidades transacionais, não existe opção boa a EJB. Mas acho dificil precisar mais que o spring framework oferece. Vocês estão usando transações distribuidas, integração com legado via JCA, outras fontes transacionais ou mesmo JMS? Senão a robustes do spring framework é mais que suficiente.

[/quote]

#10

HTTP? RMI? WebServices? Corba?

Tuxedo? JTA?

Boa pergunta! :wink:

Abraços,
Marco Campêlo

#11

Interessante a sua colocação. Mas você poderia explicar melhor como acontece o suicidio? :wink:

Sério mesmo, poderia explicar melhor?

Abraços,
Marco Campêlo

#12

WebServices ? o protocolo SOAP eh muito simplezinho… se eu precisar voltar uma estrutura ou ateh mesmo um objeto mais complexo ele se caga todo…

RMI com varias requisicoes ao mesmo objeto eh um problema… ele nao tem pooling como EJB…

Corba ? teria que implementar um AS usando corba… prq nao usar algo pronto ?

Http ? eh muito desacoplado… nao substitui um Session Stateful… vc tem q ficar fazendo xunxo pra conservar a sessao…

HTTP? RMI? WebServices? Corba?

Tuxedo? JTA?

Boa pergunta! :wink:

Abraços,
Marco Campêlo[/quote]

#13

É a primeira vez que vejo alguém dizer que SOAP é simples!

RMI suprota CORBA.

1 - Usar stateful beans é um problema
2 - Não sei o que é xunxo para você, mas se fosse tão complicado nada funcionaria na itnernet hoje em dia (ou você está cosntruíndo a aplicação mais complexa do mundo…)

Uma solução que aprece viável apra você é Session Beans como camada de serviços contatando POJOs de lógica de negócios e fazendo persistência por algum framework como Hibernate. Você pode alegar que o Hibernate 3 é uma container EJB 3 (aliás, a especificação EJB 3.0 não está terminada ainda), mas se o pessoal aí é realmente aidna acredita somente no que dita o JCP, use JDO ou em último caso Entity Beans CMP, que são uma bsota mas são JCP :wink:

#14

Ah, e de onde você tirou que o Struts sumiu do mapa? FUD brabo esse.

#15

  1. como faria via WEBSERVICES se a resposta de um metodo retornasse uma classe estilo CachedRowSetImpl ? como WebServices lidaria com isso.

  2. RMI nao tem pooling , tanto faz se ele suporta CORBA via IIOP , se dois clientes acessarem o mesmo objeto , PHODEU !

  3. funcionar nao eh sinonimo de melhor opcao… JDBC funciona q eh uma maravilha… mas serah q eh a melhor opcao ?

O que vc poderia me responder com sua experiencia seria:
Usar Sessions + JDBC direto… eh uma boa ? ou um tiro no pé ? e prq ?

[quote=pcalcado][quote=chun]
WebServices ? o protocolo SOAP eh muito simplezinho… se eu precisar voltar uma estrutura ou ateh mesmo um objeto mais complexo ele se caga todo…
[/quote]

É a primeira vez que vejo alguém dizer que SOAP é simples!

RMI suprota CORBA.

1 - Usar stateful beans é um problema
2 - Não sei o que é xunxo para você, mas se fosse tão complicado nada funcionaria na itnernet hoje em dia (ou você está cosntruíndo a aplicação mais complexa do mundo…)

Uma solução que aprece viável apra você é Session Beans como camada de serviços contatando POJOs de lógica de negócios e fazendo persistência por algum framework como Hibernate. Você pode alegar que o Hibernate 3 é uma container EJB 3 (aliás, a especificação EJB 3.0 não está terminada ainda), mas se o pessoal aí é realmente aidna acredita somente no que dita o JCP, use JDO ou em último caso Entity Beans CMP, que são uma bsota mas são JCP ;)[/quote]

#16

O engraçado é como o pessoal resolve as limitações de usar CMP.

Para obter performance nas consultas, vai precisar de um fast lane reader, que o pessoal implementa usando JDBC puro ou Hibernate/iBatis.

Ou você espera que invocar um finder, pegar 1 kilo de entity beans, transformar em 1 toneladas de DTOs e mandar pro próximo tier, ufa, fique rápido? Vai levar 1 ano para codificar e outro ano para executar.

Moral da historia, de 99 em 100 projetos que usam entity beans, na fase de tunning toda parte de consulta é trocada por algo escalavel.

Com BMP a situação é pior ainda, porque é bem comum ter problema de N+1.

Quanto aos gerentes terem medo de um produto open source sumir de um dia para outro, bom, eles são completamente cegos a realidade. Software open source com grande base de usuarios sobrevive MUITO mais que proprietarios.

Quer um exemplo? UNIX. Durante as duas últimas décadas surgiram e desapareceram muitos vendedores de unix e hoje a grande maioria dos sobreviventes está decretanto EOL nos seus produtos. Quem poderia imaginar que o DEC-UNIX iria pro saco em 88? Ou que Irix, Tru64, HP-UX e tantos outros virariam sombras de um sucessor open source.

Linux não existia na década de 80, mas existia o BSD. que ate hoje é um sistema sólido usado em muitos servidores de missão crítica que mantem a internet funcionando.

Eu acho um absurdo pensar que se explodir uma bomba no HQ do jboss e matar todos core commiters do Hibernate o projeto morra. Pode ser que o desenvolvimento desacelere muito, mas o fonte é aberto, é seu.

Mas se usar qualquer coisa que esteja fora do JCP é proibido ai, sugiro usar JDO…

#17

Qual a relação de pooling com acesso concorrente ao mesmo objeto? Uma coisa não tem o menor relacionamento com a outra. Vale lembrar que EJB usa RMI.

#18

O que acontece se com RMI puro se dois clientes tentarem acessar o MESMO objeto e a mesmo metodo ?

No caso do EJB ele cria outro session e executa os 2 ao mesmo tempo… e em RMI ?

[quote=louds][quote=chun]
2) RMI nao tem pooling , tanto faz se ele suporta CORBA via IIOP , se dois clientes acessarem o mesmo objeto , PHODEU !
[/quote]

Qual a relação de pooling com acesso concorrente ao mesmo objeto? Uma coisa não tem o menor relacionamento com a outra. Vale lembrar que EJB usa RMI.[/quote]

#19 
Uma pergunta, que tipo de sistema é esse, no qual vc´s querem utilizar EJB´s, é grande, pequeno, médio porte?
#20

Se você retornar resultset para os clientes da sua aplicação, você não rpecisa de um servidor, faça todo mundo se conectar ao banco de dados.

O que ele qis dizer: camadas, camadas, camadas, camadas.

Claro que RMI não tem pooling, ele é um protocolo, não um container, por isso EJB (e outros) implementam pools em cima de RMI. Se você vai fazer algo MUUUUUUUIIITO simples, pode tentar implementar um pool de serviços, mas se for assim é melhor usar stateless beans.

Pois é, esse é o caso com EJBs também, na maioria das vezes.

Eu não posso dizer sua melhor opção, só posso te mostrar alternativas, quem conhece o problema é você. A questão é: o que você disse sobre HTTP e sessões não procede, em minha opinião. HTTP tem milhares d eproblemas, mas não esses.

Não improta se voc~e está usando Session Beans ou não, se você tem uma aplicação complexa e msitura código de dados com lógica de negócios, vai ter problemas.

A impressão que tenho é que seus EJBs vão 9nesse caso) ter a lógica e o acesso ao banco. Vou repetir:

  • Coloque sua lógica num Domain Model de POJOs
  • Separe o acesso á banco de dados em uma camada própria.

Estrutura razoável:

Cliente <-> Session Beans <-> POJOs do Domain Model<-> Camada de Dados