Ejb 2.1,3.0, meo deus!

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

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

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

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

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

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.

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!

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

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

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!

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

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…

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.

HTTP? RMI? WebServices? Corba?

Tuxedo? JTA?

Boa pergunta!

Abraços,
Marco Campêlo

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

Sério mesmo, poderia explicar melhor?

Abraços,
Marco Campêlo

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!

Abraços,
Marco Campêlo

É 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

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

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 ?

pcalcado:

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…

É 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 ;)

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…

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.

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 ?

louds:

chun:

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

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.

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

Médio.

luiz_ross:

Uma pergunta, que tipo de sistema é esse, no qual vc´s querem utilizar EJB´s, é grande, pequeno, médio porte?</blockquote>

1. foi apenas um exemplo de OBJETO COMPLEXO que seria complicado para passar via WebServices… pode ser um objeto complexo de qualquer outra natureza… e sinceramente ? estou exemplificando… nao precisa levar ao PEH DA LETRA… apenas entender o principio …

2. Cara… vc entendeu o q eu quiz diser com RMI , O RMI BASICAO… que todo mundo dah exemplo… fazer um servidor RMI de um lado e um cliente acessando os objetos do outro… EH CLARO QUE RMI eh protocolo… soh foi um exemplo… po… vamo faze uma forcinha pra entender…

3. gostei da sua sugestao… entao pra vc seria:
   CLIENT->SESSION->HIBERNATE->DB ? certo ?

pcalcado:

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

chun:

1) foi apenas um exemplo de OBJETO COMPLEXO que seria complicado para passar via WebServices… pode ser um objeto complexo de qualquer outra natureza… e sinceramente ? estou exemplificando… nao precisa levar ao PEH DA LETRA… apenas entender o principio …

2. Cara… vc entendeu o q eu quiz diser com RMI , O RMI BASICAO… que todo mundo dah exemplo… fazer um servidor RMI de um lado e um cliente acessando os objetos do outro… EH CLARO QUE RMI eh protocolo… soh foi um exemplo… po… vamo faze uma forcinha pra entender…
   

Não levei ao pé da letra, só respondi o que você falou. Minha sugestão final é:

1 - Estude RMI melhor para você entender o “BASICAO” e um pool (pool de que? Skeletons? Stubs? Afinal, esse não é RMI basicão?)

2 - Estude sistemas distribuidos melhor, objetos complexos passados numa rede têm limitações em qualquer tecnologia usada (mesmo EJBs), se não não existiria DTO.

3 - Seja menos arrogante e prepotente, esse não é um bom meio de obter ajuda, pelo menos não de mim

Não. O que falei foi onde você pode entrar com EJBs stateless, no seu esquema falta uma camada de negócios.

chun:

1) foi apenas um exemplo de OBJETO COMPLEXO que seria complicado para passar via WebServices… pode ser um objeto complexo de qualquer outra natureza… e sinceramente ? estou exemplificando… nao precisa levar ao PEH DA LETRA… apenas entender o principio …

2. Cara… vc entendeu o q eu quiz diser com RMI , O RMI BASICAO… que todo mundo dah exemplo… fazer um servidor RMI de um lado e um cliente acessando os objetos do outro… EH CLARO QUE RMI eh protocolo… soh foi um exemplo… po… vamo faze uma forcinha pra entender…

3. gostei da sua sugestao… entao pra vc seria:
   CLIENT->SESSION->HIBERNATE->DB ? certo ?
   

1)SOAP é suficiente para mandar objetos extremamente complexos. Os casos onde ele falha é quando os objetos não deveriam ser enviados via rede. Se o seu exemplo era meramente ilustrativo, sem relação com uso real, de nada ele vale e seu argumento não parece válido.

2)Você teria que implementar pooling manualmente, caso seja necessario. A priore, o rmid vai sofrer o mesmo load que um container EJB, já que não existe como diminuir o número de conexões cliente.

3)Não, o sugerido seria: CLIENT<-> SESSION FACADE <-> DOMAIN MODEL <-> HIBERNATE.

1. até agora vc soh falou e nao respondeu a pergunta… se eu acessar o mesmo metodo de um mesmo objeto num servidor que esteja servindo objetos via RMI ( usando Naming.rebind ) , o q vai acontecer ?

2. voce que esta arrogante ENTENDENDO o q eu quis dizer e querendo falar besteira… querendo aparecer perante aos outros… invez de responder vc quer discutir ateh o minimo detalhe… depois eu que sou arrogante ?

pcalcado:

chun:

1) foi apenas um exemplo de OBJETO COMPLEXO que seria complicado para passar via WebServices… pode ser um objeto complexo de qualquer outra natureza… e sinceramente ? estou exemplificando… nao precisa levar ao PEH DA LETRA… apenas entender o principio …

2. Cara… vc entendeu o q eu quiz diser com RMI , O RMI BASICAO… que todo mundo dah exemplo… fazer um servidor RMI de um lado e um cliente acessando os objetos do outro… EH CLARO QUE RMI eh protocolo… soh foi um exemplo… po… vamo faze uma forcinha pra entender…
   

Não levei ao pé da letra, só respondi o que você falou. Minha sugestão final é:

1 - Estude RMI melhor para você entender o “BASICAO” e um pool (pool de que? Skeletons? Stubs? Afinal, esse não é RMI basicão?)

2 - Estude sistemas distribuidos melhor, objetos complexos passados numa rede têm limitações em qualquer tecnologia usada (mesmo EJBs), se não não existiria DTO.

3 - Seja menos arrogante e prepotente, esse não é um bom meio de obter ajuda, pelo menos não de mim

Não. O que falei foi onde você pode entrar com EJBs stateless, no seu esquema falta uma camada de negócios.

2. me diz uma coisa… prq desperdicar DIAS e até MESES fazendo isso manualmente se jah existe algo pronto ? existiria ganho em implementar tudo na mao ? ( acredite , jah pensei em fazer isso )

louds:

chun:

1) foi apenas um exemplo de OBJETO COMPLEXO que seria complicado para passar via WebServices… pode ser um objeto complexo de qualquer outra natureza… e sinceramente ? estou exemplificando… nao precisa levar ao PEH DA LETRA… apenas entender o principio …

2. Cara… vc entendeu o q eu quiz diser com RMI , O RMI BASICAO… que todo mundo dah exemplo… fazer um servidor RMI de um lado e um cliente acessando os objetos do outro… EH CLARO QUE RMI eh protocolo… soh foi um exemplo… po… vamo faze uma forcinha pra entender…

3. gostei da sua sugestao… entao pra vc seria:
   CLIENT->SESSION->HIBERNATE->DB ? certo ?
   

1)SOAP é suficiente para mandar objetos extremamente complexos. Os casos onde ele falha é quando os objetos não deveriam ser enviados via rede. Se o seu exemplo era meramente ilustrativo, sem relação com uso real, de nada ele vale e seu argumento não parece válido.

2)Você teria que implementar pooling manualmente, caso seja necessario. A priore, o rmid vai sofrer o mesmo load que um container EJB, já que não existe como diminuir o número de conexões cliente.

3)Não, o sugerido seria: CLIENT<-> SESSION FACADE <-> DOMAIN MODEL <-> HIBERNATE.

Pelo seu histórico nesse fórum, pode ficar tranquilo que não vou responder mais a esta thread.

Boa sorte com seu sistema.

Otimo , de pessoas como vc, eu dispenso as opinioes, bem prq nao levao a lugar nenhum… ficar discutindo “prq RMI eh protocolo , e bla bla bla” , por favor…

pcalcado:

chun:

3) voce que esta arrogante ENTENDENDO o q eu quis dizer e querendo falar besteira… querendo aparecer perante aos outros… invez de responder vc quer discutir ateh o minimo detalhe… depois eu que sou arrogante ?

Pelo seu histórico nesse fórum, pode ficar tranquilo que não vou responder mais a esta thread.

Boa sorte com seu sistema.

Qual a sua preocupação? Concorrência ou Escalabilidade?

[]'s
Marco Campêlo

Mais concorrencia…

eh um pepino acessarem o mesmo objeto e o mesmo metodo ao mesmo tempo… pra mim vai ser normal…

Qual a sua preocupação? Concorrência ou Escalabilidade?

[]'s
Marco Campêlo

chun:

2) me diz uma coisa… prq desperdicar DIAS e até MESES fazendo isso manualmente se jah existe algo pronto ? existiria ganho em implementar tudo na mao ? ( acredite , jah pensei em fazer isso )

Bom, pooling de Session Beans é mais uma balela de publicidade que algo de utilidade prática. Um SLSB vai realmente precisar de pooling caso ele tenha inicialização complexa. Os containers fazem pooling porque associam um monte de coisa a eles.

Soluções de pooling existem hoje e implementar um servidor RMI usando apenas o spring framework pode ser mais simples que parece. Ahh, esqueci, nada de open source.

Pode existir algum ganho de performance caso sua aplicação não use todos recursos do container. No seu caso acho melhor ir pela opção mais segura, use session beans.

Outra coisa, eu concordo com o phillip que você deve tentar ser mais acessivel quando ler e responder aos demais. Como você que está apresentando a dúvida, ele não tem como assumir que a parte que você omitiu, a mais importante, tinha ficado clara. Que é a falta de uma camada de negocios em todas as alternativas que você apresentou.

chun:

Mais concorrencia…

eh um pepino acessarem o mesmo objeto e o mesmo metodo ao mesmo tempo… pra mim vai ser normal…

Não entendi muito bem sua preocupação pois entendo que o RMI será utilizado apenas no transporte e questões como concorrência independem de você estar utilizando RMI ou qualquer outra tecnologia de aplicações distribuídas.

Você pode ter problemas de concorrência até em Servlets, se você botar a variável errada no lugar errado!

[]'s
Marco Campêlo

quando digo RMI , quero dizer “Disponibilizar abjetos via Named.rebind() usando o protocolo RMI sob IIOP/JRMP”

mcampelo:

chun:

Mais concorrencia…

eh um pepino acessarem o mesmo objeto e o mesmo metodo ao mesmo tempo… pra mim vai ser normal…

Não entendi muito bem sua preocupação pois entendo que o RMI será utilizado apenas no transporte e questões como concorrência independem de você estar utilizando RMI ou qualquer outra tecnologia de aplicações distribuídas.

Você pode ter problemas de concorrência até em Servlets, se você botar a variável errada no lugar errado!

[]'s
Marco Campêlo

Essa parte eu entendi!

Mas continuo achando que o problema de concorrência não é relacionado a RMI, EJB, Servlets, etc.

Se você tem um Session Façade que chama a regra de negócio da sua aplicação que está escrita em POJOs (ou seja, não estamos mais falando de EJB), dependendo de como você estruturou essas suas classes (de regras de negócio), você pode vir a ter problemas de concorrência. E aí cairíamos num caso onde mesmo tendo EJB no meio do caminho, o problema de concorrência ainda acontece.

[]'s
Marco Campêlo

O grande problema de RMI puro, como você colocou na thread, é que você vai ter que lidar com o ambiente multi-threaded, o que não significa necessariamente perder performance ou funcionalidade; isso depende do resto da sua arquitetura.

Mas, sendo bem prático, se seu problema é não poder usar open-source e somente padrões, recomendo Session Beans + JDO.

EXATO !!!

Session beans + SQL DIRETO VIA JDBC vc consideraria insanidade ?

mister__m:

O grande problema de RMI puro, como você colocou na thread, é que você vai ter que lidar com o ambiente multi-threaded, o que não significa necessariamente perder performance ou funcionalidade; isso depende do resto da sua arquitetura.

Mas, sendo bem prático, se seu problema é não poder usar open-source e somente padrões, recomendo Session Beans + JDO.

Nao, nenhum, pra falar a verdade. A discussao acabou indo pra um lado nao muito produtivo, mas se vc quer se livrar de problemas de escalabilidade e concorrencia, Session Beans sao bacanas…

…mas… (sempre tem um “mas…”)

Se voce nao tomar cuidado e prestar atencao no que esta fazendo, o seu sistema acaba ficando dependente dos Session Beans, e isso acaba arrastando o application server junto, o que te dificulta demais fazer testes unitarios. Dai a qualidade do codigo e a produtividade da sua equipe apontam pro chao e ligam o afterburner. Entao, nao exagere, faca dentro dos Session Beans apenas o estritamente necessario, e boa sorte.

E tente ouvir mais os conselhos de caras como o Shoes, que estao hoje em dia tendo que limpar a merda que arquitetos meia-boca fizeram por nao prestar atencao a esse tipo de discussao.

Shun

Este tipo de colação é uma verdadeira sacanagem hein! Por curiosidade olhei seu histórico, e esta mesma história se repetiu … mas com palavras diferentes.
Tente não levar a mau, mas é um tipo de coisa que deixaria qualquer um aqui com os nervos a flor da pele. Procure minimizar estes tipos de colocões quando você não concordar com uma opinião contrária ou diferente da sua.

Abraços e Boa Sorte!
Thiago

Se não estivermos falando de 3 tabelas e uma dúzia de consultas além do CRUD, sim

cv:

Se voce nao tomar cuidado e prestar atencao no que esta fazendo, o seu sistema acaba ficando dependente dos Session Beans, e isso acaba arrastando o application server junto, o que te dificulta demais fazer testes unitarios. Dai a qualidade do codigo e a produtividade da sua equipe apontam pro chao e ligam o afterburner. Entao, nao exagere, faca dentro dos Session Beans apenas o estritamente necessario, e boa sorte.

Pois é, essencial dizer isso também

Fui “cegado” pela restrição absurda de não usar open-source e não comentei sobre coisas do tipo.

nao fiquei nervoso prq ele contrariou8 mkinha opiniao… e sim prq ele ENTENDEU o que eu disse com RMI e fez questao de botar em jogo que “RMI EH PROTOCOLO” , po… sanagem isso

Thiago Senna:

Shun

Este tipo de colação é uma verdadeira sacanagem hein! Por curiosidade olhei seu histórico, e esta mesma história se repetiu … mas com palavras diferentes.
Tente não levar a mau, mas é um tipo de coisa que deixaria qualquer um aqui com os nervos a flor da pele. Procure minimizar estes tipos de colocões quando você não concordar com uma opinião contrária ou diferente da sua.

Abraços e Boa Sorte!
Thiago

No caso de poder usar open source… qual seria a sua sugestao ?

mister__m:

cv:

Se voce nao tomar cuidado e prestar atencao no que esta fazendo, o seu sistema acaba ficando dependente dos Session Beans, e isso acaba arrastando o application server junto, o que te dificulta demais fazer testes unitarios. Dai a qualidade do codigo e a produtividade da sua equipe apontam pro chao e ligam o afterburner. Entao, nao exagere, faca dentro dos Session Beans apenas o estritamente necessario, e boa sorte.

Pois é, essencial dizer isso também

Fui “cegado” pela restrição absurda de não usar open-source e não comentei sobre coisas do tipo.

Depende. Aí teria que saber mais o front-end da aplicação, as interfaces para o mundo externo etc.

O que não falta é framework no mercado e alguns são mais úteis em alguns cenários do que outros.

O Michael vai sugerir usar o genesis, disso não tenho dúvida.

Se você reler respostas antigas vai ver muitas sugestões do que usar… spring framework, hibernate, RoR…

Se enganou, hein?

Eu não faço propaganda cega do produto, tenho ética :mrgreen:

bem ,vou ser bem sincero… acho que uma discussao destas é muito exclarecedora ao pessoal q é novo , apesar dos pesares…

normalmente o pessoal busca respostas praticas , e nao uma montanha de teoria em cima coisa toda… a falta de objetividade eh que mata…

Muito obrigado a TODOS que contribuiram a este POST , uns mais e outros menos… mas o meu muito obrigado a todos.

Nice guys finish last.

Eu entendo que o objetivo do forum é de gerar discussões, espalhar conhecimento e fazer as pessoas chegarem a suas próprias conclusões.

Se estivéssemos aqui apenas para dar “respostas práticas”, seríamos uma ótima empresa de consultoria e estaríamos cobrando para isso!

Se continuar assim, o pessoal vai postar dúvidas e dar o prazo que a pergunta deve ser respondida!

[]'s
Marco Campêlo

A necessidade dos Session Beans seria quando o cliente não está na mesma máquina do Domain Model? Ou seja, caso estejam na mesma JVM não seria necessário, ou teria outra necessidade para os session bean?

As necessidades numa mesma JVM seriam transações e escalabilidade monstruosa… mas isso tudo você pode ter de outras formas.

Na verdade, na maioria das vezes a necessidade real é a imposição de algum gerente

Vou postar a mesma mensagem que escrevi em outro “inferno” de fórum!!!

"Estou com preguiça de ler as postagens anteriores, mas me interessei pelo assunto.
Gostaria de saber quem já utilizou o padrão EJB Session Façade em um projeto para distribuição de módulos, persistindo os dados com Entity’s Bean na versão 2.1, utilizando JDeveloper, BD Oracle 10g e Oracle 10g AS?!? "

Alguém poderia fazer o favor de responder?!?!

Shaman:

Alguém poderia fazer o favor de responder?!?!

O forum é algo comunitário, e o pessoal que ajuda os
outros faz isso no tempo livre - o que, em muitos casos, é quase
inexistente. Portanto, se ninguém respondeu ainda, é espera até que
alguem o faça.\n’

Por favor, não abra mais de um tópico para a mesma
dúvida.

Por favor, antes de perguntar, leia este topico:
http://www.guj.com.br/posts/list/15477.java’

Por favor, leia as regras do forum:
http://www.guj.com.br/posts/list/21516.java’

Continua a pergunta…
Alguém poderia responder?!?

Shamam:

Estou com preguiça de ler as postagens anteriores, mas me interessei pelo assunto.
Gostaria de saber quem já utilizou o padrão EJB Session Façade em um projeto para distribuição de módulos, persistindo os dados com Entity’s Bean na versão 2.1, utilizando JDeveloper, BD Oracle 10g e Oracle 10g AS?!?

Olá Shamam,

se vc ainda não leu estes tópicos no qual vc colocou o seu post, te aconselho ler eles todinho!

Com certeza vc vai perceber que neles tem informações muito mais importantes do que utilizar Entity Bean 2.1 + BD Oracle 10g e Oracle 10g!

Para mim o que é relevante no meu questionamento é exatamente a utilização dessas tecnologias num ambiente distribuído.
Se alguém trabalha ou já trabalhou num ambiente com essas características, por favor, me informem.

aff…

faz o seguinte…

abaixa o bendito orcle developer, aprende entity beans e session bean e testa!

Bom… acredito que o oracle developer irá ajudar muito! Ele deve ter suporte a criação de entitys beans automático à partir do banco!

Isso é um recurso fenomenal Crie o máximo de entitys que vc puder. Afinal, é muito fácil fazer isso com o Oracle 10g. Vc apenas clica na tabela de banco de dados e o oracle 10g cria um entitu fresquinho fresquinho.

Sempre que sentir a necessidade de utilizar este recurso, não exite. Ele é bastante rápido.

Os entity beans são realmente muito bons. É uma das principais tenologias do J2EE. Não é a toa que chamam o EJB de o coração do J2EE.

Outra informação importante: é bastante rápido e fácil de testar. No projeto que trabalho a galera usa e nunca reclamaram do EJB! :mrgreen:

Abraços!
E Boa Sorte!

A finalidade do meu questionamento não é discutir o meu conhecimento, e sim saber se alguém possui experiência prática num ambiente de desenvolvimento como o que eu abordei anteriormente. Levando-se em consideração a existência de objetos de um BD em número de dezenas de milhares. Pelo que percebi a discussão aqui é sobre a migração entre EJB 2.1 para 3.0. Gostaria que pessoas com experiência em desenvolvimento de sistemas corporativos possam postar mensagens significativas, sobre as expectativas e considerações com relação ao EJB 3.0 que abordassem temas como custo de retrabalho e desenvolvimento.

Mantenho a minha pergunta:

"Gostaria de saber quem já utilizou o padrão EJB Session Façade em um projeto para distribuição de módulos, persistindo os dados com Entity’s Bean na versão 2.1, utilizando JDeveloper, BD Oracle 10g e Oracle 10g AS?!? "

Quanto ao JDeveloper e OAS, eu nunca usei.

Outra pessoa poderá se quiser responder sobre este assunto… mas nada impede de utilizar outras IDE’s ou Application Service…

Para lidar com milhares de transações, talvez EJB seja realmente uma boa. Para saber os prós e os contras de Sessions Beans e Entity Beans de pessoas que já trabalharam com estes cenários, dê uma lida nestes posts abaixo:

http://www.guj.com.br/posts/list/23055.java
http://www.guj.com.br/posts/list/22965.java
http://www.portaljava.com.br/home/modules.php?name=Forums&file=viewtopic&t=14198&sid=4c6967e2e9bfc6e842292f28a4685b62 (este último indicado pelo pelo SAOJ no post http://www.guj.com.br/posts/list/22965.java )

Abraços!
Thiago Senna

OK…
Só pra lembrar, é Application SERVER…

Alguém neste fórum?!?

Ola Shaman,

Por que voce nao abre outro topico em vez de ficar reaproveitando topicos com temas distintos?

Alem do mais, como ja mencionei antes o forum é algo comunitário, e o pessoal que ajuda os
outros faz isso no tempo livre - o que, em muitos casos, é quase
inexistente. Portanto, se ninguém respondeu ainda, é espera até que
alguem o faça.

Isso é uma oferta de emprego, por que você está procurando um perfil de profissional e não tirar uma dúvida?

Isso não é oferta de emprego, muito menos uma discussão com a finalidade de esclarecer dúvidas. O que proponho, como já comentei, é discorrer sobre as expectativas do lançamento da versão 3.0 com pessoas com experências práticas em EJB.

Percebi que estavam falando neste assunto, por isso pressupus que encontraria aqui alguém que trabalhasse num ambiente corporativo ao menos similar ao que descrevi. Se postei a pergunta neste fórum foi pela esperança de encontrar alguém com uma base de experiência mais concreta do que especulações sobre o tema.

Ainda tenho esperança!!

Alguém neste fórum?!?!?