CMP ou BMP?

jah falow tudo
nem BMP nem CMP
use hibernate e seja feliz
:lol:

Opa… esse tipo de reposta nao dah neh ? vc agora jogou no lixo toda a funcao de um container ejb e diz que hibernate eh melhor…

quero saber o PORQUE … quero saber se ele h melhor em analise de casos medios… balanceamento de carga e distribuicao de operacoes… entity beans tira isso de letra… hibernate tem isso ? acho que vc nao me entendeu.

Hehhehehe
Bom eh o seguinte: vc tem q medir a complexidade que vc irá trazer com EJB’s … nao adianta vc pegar um container e colocar out-of-box e rezar pra dar certo, pq nao vai, vc vai ter q ter alguem especializado com isso… fora q seus desenvolvedores tem q realmente saber o q estao fazendo, prestar atenção na navegabilidade dos seus beans para evitar deadlocks na concorrencia dos dados, diminuir escopo transacional ao máximo, etc…
Bom em suma, existem frameworks bem mais leves que EJB q fazem a mesma coisa (dica: Spring + Hibernate)…
É tudo uma questão de pesar os prós e contras… mas por minha experiência com CMP , eu nao uso nunca mais (ou pelo menos ateh sair a 3.0 :-P)

Abraços

EXATAMENTE AE QUE EU QUERIA CHEGAR…

conta essa estoria ae sua com os CMP’s…

e o que vc espera tanto na versao 3.0…

Espero principalmente simplicidade de desenvolvimento, sem depender de otmizações obscuras do container para fazer funcionar…
Minha exp com CMP foi ruim, vários locks qando se colocava A, quando se colocava B a performance ia pro brejo… Muitas coisas…
Abraços

puxa , ae fica dificil , o que me tah parecendo eh falta de introsamento somente isso… de que adianta “simplicidade” se sua escalabilidade vai pro brejo ? da maneira simplista que vc esta me falando tah parecendo mais uma má implementacao do que realmente um problema do CMP , afinal , CMP eh usado em MUITOS lugares grandes… ex: Amazon.com faz mais de 1 milhão de transacoes por hora usando CMP e njao devem ter tuido esses locks…

well… estarei procurando ajuda de alguns professores de universidade… prq realmente se tem uma coisa que preso sao padroes… eles existem para que quando EU sair desta empresa ou quando outro entrar… nao tenha que ficar “imaginando” o que eu use… apenas pense… “usei especificacao j2ee”

Simplicidade nem sempre quer dizer producao… producao nao digo apenas no desenvolvimento inicial… e sim em TODO lifecycle do aplicativo…

Ok boa sorte…
Quando tiver sua própria experiência com CMP poste aqui pra sabermos o que aconteceu ok?

Abraços

Olha, EJB não é tão ruim assim.

Pelo menos minha experiência com BMP e CMP mostrou que os bichinhos funcionam. Mas o ponto principal da discussão é quando usar EJB’s.

O Eduardo disse uma grande verdade: Spring + Hibernate é uma das melhores combinações para demarcação de contexto transacional declarativo e utilização de Dependency Injection, o que diminui em muito o acoplamento de seus objetos, garantindo uma maior coesão do seu sistema.

EJB’s funcionam. Mas o ideal é conhecer muito bem seus life-cycles, entender como funciona a propagação de contexto de segurança, replicação de estado, etc para que possa utilizá-los em um contexto adequado.

Não use EJB’s por modismo cultural. Use quando é realmente necessário.

BMP são extremamente dificieis de serem usandos de forma escalavel, quase sempre se cai no problema do N+1.

CMP custa muito para se desenvolver e a performance não é lá das melhores. Apesar disso, existem containers muito escalaveis.

Outro fator importante é que EJB usado quando não existe uma demanda transacional forte não tem como dar conta do recado e você sempre tem que acabar usando um Fast Lane Reader.

Sem um expert no teu AS pra otimizar os deploy descriptors, a performance pode ser ate 10x pior.

Quanto a usar hibernate + spring, é uma solução muito mais produtiva e ambos produtos são de tão boa qualidade quanto os AS j2ee. Boa documentação e estabilidade de interfaces existem para ambos produtos.

Não vou comentar a questão da produtividade com EJB, que é muito inferior, mas sim da questão de escalibilidade.

O Hibernate tem suporte a caching em duas camadas, uma local a transação e outra global a aplicação, com possibilidade de ser clusterizado.

No final das contas, a única coisa que EJB te da a mais é um cache melhor de entidades, coisa que você teria que fazer um tunning mais manual com hibernate. Porêm para a boa escalabilidade de uma aplicação, essa não pode ser a única forma de caching a ser utilizada.

Se você tá realmente preocupado com estar 100% dentro dos padrões e 100% fora dos prasos. Use EJB.

Justamente , nao eh por modismo… e sim prq realmente estou vendo que EJB tem muitas vantegens e com ele consigo tratar clientes medios como clientes medios e clientes grandes como clientes grandes,…
atuamente minha aplicacao eh a mesma e tenho a mesma “seguranca” e “velocidade” nos dois casos… fora estar preso a linguagem SQL… mais uma coisa q me atraiu em EJB-QL…

detalhe… existe um “SERVIDOR HIBERNATE” ?

tirando os j2ee containers…

pelo jeito q vcs falam… com hibernate o cliente vira um .jar soh com tudo… regra de negocio + visual + banco
eh isso ?

ou estou errado ? e se estiver errado , me explique por favor como eh essa solucao hibernate…

EJB-QL foi uma das coisas q me fez odiar EJB´s… MUITO limitado, nada de order, nada de agrupamentos… Foi o q o Louds disse…
100% dentro dos padrões (putz tem cada uma dentrd desses padrões, uns may esquisitos na spec…) e 100% fora dos prazos…
Kra é muito fácil vc procurar relatos contra EJB´s na web… Olhe os fóruns pra vc ver o tanto de ´Problems with CMP´…

Bom é isso…

Abraços

PS: Hibernate é só o framework de persistência, nao ficaria sua aplicação toda no jar não, e se você souber fazer o negócio direitinho, dá pra abstrair a camada de persistência para seja mais suave a troca caso necessário…

duardor:

EJB-QL foi uma das coisas q me fez odiar EJB´s… MUITO limitado, nada de order, nada de agrupamentos… Foi o q o Louds disse…
100% dentro dos padrões (putz tem cada uma dentrd desses padrões, uns may esquisitos na spec…) e 100% fora dos prazos…
Kra é muito fácil vc procurar relatos contra EJB´s na web… Olhe os fóruns pra vc ver o tanto de ´Problems with CMP´…

Bem , pelo que me pareceu… o EJB-QL nao tem como ideia principal “concorrer com o SQL” , e sim ser uma ferramenta… que vem evoluindo… e ORDER BY jah tem… na versao 2.1, e tem outra… pra q ORDER BY ? a Collections tem sort… onde posso usar N algoritimos para tal operacao… por enquanto o q tah parecendo eh que vc nao gosta da maneira de como funciona e nao que “nao funciona , nao eh produtivo”

Entao Hibernate apenas abtraria minha persistencia… o resto da padrozinacao EJB continuaria existindo ? “session” “messages” ?
o hibernate nesse caso seria apenas um modulo … isso ?

Detalhe sobre o EJB-QL , na PIOR DAS PIORES hipoteses… poria usar JBOSS EJB-QL , que suporta quase tudo de uma linguagem SQL normal… eu estaria sacrificando a portabilidade… mas posso usar em uma ou duas querys… o problema seria ficar preso a um container soh…

Porem… eh uma saida… estaria com uma “semi especificacao” , jah que as Querys na linguagem JBOSS-EJB-QL ficao em um .xml separado…

chun:

duardor:

EJB-QL foi uma das coisas q me fez odiar EJB´s… MUITO limitado, nada de order, nada de agrupamentos… Foi o q o Louds disse…
100% dentro dos padrões (putz tem cada uma dentrd desses padrões, uns may esquisitos na spec…) e 100% fora dos prazos…
Kra é muito fácil vc procurar relatos contra EJB´s na web… Olhe os fóruns pra vc ver o tanto de ´Problems with CMP´…

Bem , pelo que me pareceu… o EJB-QL nao tem como ideia principal “concorrer com o SQL” , e sim ser uma ferramenta… que vem evoluindo… e ORDER BY jah tem… na versao 2.1, e tem outra… pra q ORDER BY ? a Collections tem sort… onde posso usar N algoritimos para tal operacao… por enquanto o q tah parecendo eh que vc nao gosta da maneira de como funciona e nao que “nao funciona , nao eh produtivo”

Entao Hibernate apenas abtraria minha persistencia… o resto da padrozinacao EJB continuaria existindo ? “session” “messages” ?
o hibernate nesse caso seria apenas um modulo … isso ?

Hehehe
Na prática a teoria é diferente…
Bom é o seguinte, vc poderia utilizar session, messages etc com Hibernate tb…
Já que você pode trazer os dados ordenados, pra que perder tempo (processamento, tempo de desenvolvimento, etc) fazendo isso fora do BD?
O que estou argumentando é que o Hibernate pode fazer quase tudo que os containers EJB´s fazem para PERSITÊNCIA… e é N vezes mais fácil de desenvolver utilizando Hibernate… mas se vc se sente confortável com EJB, go ahead… Só não diga que não foi avisado!

Abraços

O google pode ajudar a te convencer

Na verdade ninguem precisa te convencer, o que o duardor e louds estao tentando dizer é que existe vida fora EJB, e é uma vida mais feliz e produtiva :?

sim, o hibernate é só a persistencia … use o Spring pra outras funcoes (seguranca, transação, etc.) e algum framework para distribuicao em cluster de seus componentes (me ocorre o Coherence da Tangosol) …
Nao estar seguindo um padrao da sun nao quer dizer que nao existe um padrao, crie o seu se quiser.

Poderia ? vc fala como se o hibernate fisesse o mesmo papel… nao to entendo qual a solucao de aplicacao distribuida que vc propoem… eh HIBERNATE+O QUE ? prq persistencia nao eh a unica coisa que importa…

Essa desculpa que do “EJB-QL NAO TEM ORDER BY” nao tem como vc usar… EJB-QL 2.1 suporta order by… e como disse no maximo teria que extender em algumas querys usando JBOSS-EJB-QL , continuo vendo “que vc nao gosta da forma que eh feito” e nao que “nao faz” ou “eh ruim” , o conceito de ruim eh muito abstrato… “ruim” pra mim eh fazer um aplicativo em 1/10 do tempo que levaria pra fazer usando os padroes J2EE e ficar 10*10 do tempo pra fazer um alteracao ou para escalonar meu software…

Verdade, existe vida fora do EJB , essa nao eh a questao. EJB eh um contexto muito amplo , o negocio pelo jeito eh “Existe vida sem Entity beans CMP” , prq tanto Hibernate quanto Spring usao enterpise java baens
estou errado ? ( lembre-se em um contexto distribuido )

Tangosol e Coherence nao rodao debaixo de um container EJB ? aonde estaria ganhando ?

Verdade… em partes eh verdade… mas pense comigo… na hora de contratar um profissional… o que eh mais produtivo … contratar alguem que vai sentar na frente e saber o que fazer afinal j2ee eh uma especificacao… ou alguem que vai ter que descobrir suas artimanhas e seguir em frente ?

Yep … vc está errado.

Para o hibernate vc usa POJOs mesmo e para o Spring vc usar definicoes declarativas que no geral sao em cima de POJOs mas as vezes uma ou outra interface é requerida.

Vc pode sim usar EJBs de dentro do seu sistema baseado em Spring mas veja como um cliente qualquer, nenhuma relacao direta.

Nops … assim como para desenha sua solucao com o Spring para usar o Coherence tb nao eh necessario um EJB container.

Hummm … depende.

Se o caboclo que vc contratou nao eh tapado E vc usou algum padrao real (ou seja, definido e seguido) ele aprende e no fim das contas depois do 1o projeto ele provavelmente vai estar produzindo mais do que com EJB.

Só pra esclarecer tb … o EJB 3 será baseado no modelo do hibernate e o hibernate será uma implementação do EJB 3 … entonces se quiser seguir o padrao EJB tudo bem, daqui um tempinho vai estar usando hibernate mesmo assim

Esse POJOs eh um container de objetos distribuidos ? eh o q ? o Spring roda debaixo do q ? ele vai na aplicacao ou tem um “servidor de aplicacao rodando pra ele” ?

ae vc me confundiu… o Spring fornece um Servidor de Objetos distribuidos ? somente ele e mais ninguem ?

E como ficaria a distribuicao dos objetos ? quem faria ? acessaria usando que protocolo ? RMI-IIOP ? CORBA ? como conversar com a aplicacao ?

descordo totalmente… pensando assim eu desenvolveria em clipper , afinal das contas “um dia o cara aprende e produz mais” , mas respeito sua opiniao.

Exato… mas quem seguiu as especificacoes… tanto faz… se tah usando hibernate ou “jozereite” , afinal… estou dentro de uma especificacao e ela eh respeitada entre as versoes de J2EE , quando vier o proximo container… como ele vai trabalhar nao eh meu problema… o que me importa eh que vou jogar minha aplicacao e ela vai rodar, como tenho feito com testes em varios containers desde Sun até oracle… estou fazendo dentro da especificacao… nao mudo uma virgula… o maximo que tenho q fazer eh estanciar os pools para os objetos CMP , mas isso eh facin facin

Falou tudo.
No final, o engine ORM utilizado vai ser Hibernate mesmo. 8)
Bem, de todo o jeito, nowadays, EJB não deve ser a primeira escolha para se desenvolver persistência.
Deve ser a última.

POJO = Plain Old Java Object, ou seja, nenhuma implementação de interface ou herança requerida - faça como quiser.

Nao precisa de um EJB Container, ele roda simplemente em um servlet container qualquer (inclusive no do seu AS preferido) …

O Coherence é que faz a distribuicao (cache e cluster) … detalhes eu desconheco.

Nonon … um cara que manje de clipper, desenvolve a mesma aplicacao (distribuida, com seguranca, etc. etc.) no mesmo tempo que um cara que manje Java? Acho que nao (na verdade nao sei, nunca vi clipper na minha vida) …

Pra nao ficarmos dando voltinhas … continue trabalhando com EJB pq afinal de contas a teoria do spec é legal é valida (de verdade) … e faça um projetinho de brincadeira tentando usar todos os serviços que vc tem com EJB usando frameworks alternativos … e tire suas conclusoes …

Mas ae estamos tendo uma discrepancia … prq imagine o cara que jah vem seguindo as especificacoes… no final… o que ele teve q mudar na ida pra EJB 3.0 ? NADA , imagine q eu escolhesse “hibernate” e simplesmente ele fosse “mais um” , o que aconteceria comigo no final ? Single-Vendor-Lock-In , e isso usando a plataforma java eh inadmicivel no meu ponto de vista…

Quanto a primeira escolha… nao esta sendo Entity Beans para mim , esta sendo a ultima opcao… prq eu poderia muito bem jogar o codigo direto em meus Sessions e sair por ae… problema eh enfrentar o futuro e a manutencao disso…

Puts , mas ae eh reinventar a roda… pra q fazer assim se jah tem algo pronto ?

Ou seja… no final vc tem o mesmo cenario de um container EJB… eh a mesma coisa soh que diferente…

Segundo sua afirmacao anterior… SIM , afinal “ele aprende”

Exatamente , estou fazendo testes e etou tirando minha conclusao deles… e por enquanto Entity Beans CMP nao sao o jeito mais facil , mas sao o jeito mais seguro de garantir um futuro e de capacitar minha equipe dentro de padroes validos e testados… o que nao quer dizer que eu nao possa usar HIBERNATE , afinal em UM pedacionho do codigo pode ser que eu precise… mas o resto das minhas 99% da aplicacao eu rodo dentro de um padrao… e esses 1% eu deixo pra pensar mais tarde como resolver…

chun:

jrodrigues:

Falou tudo.
No final, o engine ORM utilizado vai ser Hibernate mesmo. 8)
Bem, de todo o jeito, nowadays, EJB não deve ser a primeira escolha para se desenvolver persistência.
Deve ser a última.

Mas ae estamos tendo uma discrepancia … prq imagine o cara que jah vem seguindo as especificacoes… no final… o que ele teve q mudar na ida pra EJB 3.0 ? NADA , imagine q eu escolhesse “hibernate” e simplesmente ele fosse “mais um” , o que aconteceria comigo no final ? Single-Vendor-Lock-In , e isso usando a plataforma java eh inadmicivel no meu ponto de vista…

Quanto a primeira escolha… nao esta sendo Entity Beans para mim , esta sendo a ultima opcao… prq eu poderia muito bem jogar o codigo direto em meus Sessions e sair por ae… problema eh enfrentar o futuro e a manutencao disso…

Single-Vendor-Lock-In onde? Me mostra…
Hibernate é um padrão de indústria assim como é EJB, ou OJB, ou até JDO.
Sem falar dos Cayenne da vida.

Cara, você quer distribuição? Então use SessionBeans, BusinessDelegate e ponha o Hibernate ORM na veia. Não esqueça do Spring.

Mas persistência com Entity Beans … CMP’s, aí vc tem o Vendor-Lock-In utilizando features proprietárias dos vendors.

Digo ainda mais, crie uma camada de abstração com AbstractDAOFactory da vida e escolha o modo de persistência como bem entender.

Simples… Hibernate esta na especificacao J2EE ? se nao estiver… nada garante que um container que implemente JE22 venha suportar isso…
logo , fico na mao do meu vendor…

Ueh… mas pelo jeito estao confundindo as coisas… prq ateh… EJB como um todo era ruim… agora vamos usar SessionBeans… leia os comentarios anteriores… onde dizem que EJB LOUCURA… e SessionBeans estao dentro da especificacao e do que se entende por EJB.

Errado, uso TUDO dentro de uma especificacao aberta que eh regida pela JCP , se vc nao acredita nisso , entao nao sei prq vc usa java… nao tem nada de LOCK-IN nisso , a especificacao eh aberta e eh absorvida pelo mercado, e Entity beans CMP nao sao “features proprietarias” eh uma especificacao , como ela eh implementada , pouco me importa , se for da maneira porca… pulo pra outro EJB Contaiener e pronto.

Soh falta vc me dizer que ae estou “facilitando mais as coisas” , um controle do controle ? nah… pra isso q existe Entity Beans para vc ABSTRAIR a persistencia… e nao “inventar moda”.

Single-Vendor-Lock-In onde? Me mostra…

Continuou sem responder a pergunta.
Hibernate é Java puro, e portanto roda em qualquer container.

Hibernate é uma biblioteca, um framework, entende? Pra funcionar out-of-the-box em qualquer container J2EE.

“Implementar a spec ou não” não te garante portabilidade. Veja o caso dos entity beans. CMP 1.1 não funciona. CMP 2.0 não é compatível com CMP 1.1 e a CMP 2.1 introduziu funcionalidades não compatíveis com versões anteriores.
Além do mais, CMP’s são obrigados a usar deployment-descriptors proprietários… O que você me diz disso?

Nao esta dentro da especificacao , nao tem obrigacao de ser suportado , nao tenho de ficar “enjambrando” em outro container… ou na mao do cara que esta “Implementando o hibernate” , prefico ficar na mao da JCP…

Nao quero auto-of-box… se eu quisesse isso , ficava programando em delphi usando DCOM+ , quero algo solido e que esteja dentro de padroes

Bem primeiro que versao 1.1 nao eh discutivel , pois a versao 1.0 do proprio java era uma uma piada ( ou vc adora o awt ?)… estamos falando de algo maduro… da 2.0 , as alteracoes q foram “introduzidas” vc arrumava em uma tarde de trabalho… e nao na codificacao da persistencia TODA da sua aplicacao… detalhe… somente em alguns casos… da maneira que vc fala parece que EJB 2.1 simplemente mudou toda maneira de trabalhar da 2.0 , e isso nao eh verdade e vc sabe disso.

olha , o unica coisa que precisei fazer “proprietaria” eh dizer como ele “persistir os objetos” se eh em um pool , e o nome dele… mais nada… 15 linhas de XML por servidor , xdoclet faz isso pra mim… relax esse negocio de dizer que Entity eh trabalhoso soh se vc usar notepad mesmo… prq o xdoclet faz todo o trabalho sujo

Well , valeu a discussao , muito obrigado pelas opinioes de voces , e levarei tudo em conta na minha escolha… que ainda eh incerta.

E desculpa caso tenha ofendido alguem , mas preciso esmiucar o maximo e em detalhes esse “repudio todo” em cima dos Entitys…

Muito Obrigado mesmo

Só acho que você é um EJB Evangelist e acha que EJB vai resolver todos os seus problemas.

Você viu meu primeiro post?
Não disse que EJB não funciona.

Só disse que tem contexto certo para utilizá-lo.
Já viu a implementação da aplicação Pet Store com EJB? Quase 3000 LOC!
Já viu a implementação com hibernate? 970 LOC!

Não sou eu que estou dizendo isso … é um fato.
Anyway, acho que vou gastar o teclado para argumentar com você porque não vai adiantar mesmo.

:roll:

Hibernate é um padrão. Tanto que é a spec EJB 3.0 é baseada na sua implementação. Se você diz que isso não funciona em todos os containeres … não sei o que te dizer. Funcionou em todos os que usei até hoje e não foram poucos.

Afinal, java puro tem que rodar em qualquer container, né?

jrodrigues:

Só acho que você é um EJB Evangelist e acha que EJB vai resolver todos os seus problemas.

Sou mesmo , se vc nao gosta da plataforma que vc opera… paciencia mas eu acho ela muito solida e competitiva, quanto a todos os problemas , muito pelo contrario , acho que para a minha situacao ela se encaixa como uma luva… Nao estou falando de um sistememinha besta de 30 milhoes de registros… estamos falando de algo bem maior…

Muito bla bla bla e pouca pratica , aqui eh soh ouco falar em bla bla bla , ninguem que realmente fez algo descente pra dar uma opiniao… apenas baseados em “opinioes alheias” , paciencia… depois outro vez me dizer de teoria… Mas farei teste com esses “LOCKS” , acho que eh muito exagero… tah parecendo a MS quando falou que o PetSotre era 10x mais rapido em .net que em java.

jrodrigues:

Anyway, acho que vou gastar o teclado para argumentar com você porque não vai adiantar mesmo.

Adianta sim , soh que nao sou fã do hibernate , quem eh enagelizador dele eh voce… leia seus proprios posts… e o pior… eh evangelizador e nao admite… , mas nao gosto dele , acho q ele foje do atual padrao e ponto final , e tem outra… pensei aqui… vou ter que codificar XML de qualquer jeito… entao nao vejo vantagens… vou desenvolver algo HJ e nao na versao 3.0 , na 3.0 apenas vou migrar… nao posso viver no “se… se… se…” ,

O dia… que a 3.0 ficar implementada descentemente , ou melhor… o dia que ela realmente sair de verdade talvez eu reveja algo…mas se seguir o padrao da passsagem pelas versoes vou rodar em um container 3.0 tranquilamente , dae quem sabe nesse dia eu mude , porem… nao vou seguir algo incerto (JCP eh um processo democratico , tudo pode acontecer ) simplesmente pq todos estao usando…
:roll:

jrodrigues:

Hibernate é um padrão.

Eh… um padrao na sua cabeca… leia a especificacao do EJB 2.1 e veja se diz HIBERNATE lah… se disser blz… 3.0 eh outra estoria… o proprio JBOSS ( que por uma infelicidade enorme sugeriou o hibernate pra 3.0 ) tah cheio de preview… versao definitiva… ‘sabe deus’

jrodrigues:

Se você diz que isso não funciona em todos os containeres … não sei o que te dizer. Funcionou em todos os que usei até hoje e não foram poucos.

Eu disse que enquanto nao virar padrao… na especificacao ATUAL , pouco me importa se roda em N containers… nao eh padrao na plataforma J2EE ainda e ponto final. Nao vou engolir padroes impostos por “pessoas” , senao jah estava usando Prevayler , afinal… todo mundo diz que eh um padrao e roda em tudo… bullshit.

hahaha, vc ainda tah nessa de W.O.R.E. , ok ok , vai lah… padroes de especificacoes existem exatamente para impedir gente como voce de “reinventar a roda, soh que quadrada” com ideias proprias e se levar em consideracao um contexto como todo, realmente a amazon.com deve estar errada , afinal… eles devem ter soh umas 2 milhoes de transacoes por minuto mesmo neh ? soh sao pioneras nesse ramo de livros na internet , prq sera q eles NAO USAO O PADRAO DE MERCADO HIBERNATE ? bom… ae o envangelizador do hibernate deve ter algo a dizer…

Bom , eu jah tinha encerrado a discussao no post anterior , mas se vc quer continuar a bater boca com os “padroes da sua cabeca” e os “achismos” tudo bem… continue… eh isso mesmo que preciso… saber TODOS OS PONTOS NEGATIVOS… vc ainda nao entendeu que eh PROFISSIONAL , tudo bem… eu finjo que eh pessoal soh pra vc ter o que escrever…

É totalmente profissional.
Você que está levando para o lado pessoal.

Expus meu ponto de vista. Aceite-o se você o achar que vale a pena. Senão rejeite-o como você o fez até agora. Acho interessante discussões tecnológicas, por isso sempre exponho minhas opiniões.

Tomara que seja feliz nas suas escolhas.

Só queria te ajudar. Se você acha que eu estou brigando aqui, não estou. Estou pela pura vontade de ajudar.
A decisão é sua.

Be happy, my friend.
Farewell.

Uma das melhores frases que ja li:

Rafael

pra mim a melhor parte eh a confusao entre LOC e LOCK

Chun,

Não esqueça de atualizar este tópico em algun meses. Queremos muito saber se você aidna acredita na especificação EJB…

[]s

Voto nessa também

Só pra discordar voto em

Quem aqui já trabalhou em migração de um sistema de medio porte feito com EJB onde se trocou a versão da especificação ou o container? Quem desses fez isso de forma facil e não teve kilos e kilos de problemas? Quem??

Portabilidade de versão e AS pra EJB é meio que lenda. Principalmente entre as point releases. De EJB 1.0 pro 2.0 você só tinha que reescrever quase TUDO.

Vamos la, bastante cuidado…

Primeiro, nao adianta simplesmente sermos programadores e nao pensar no lado marketing ou financeiro de uma empresa.

Um erro comum dos programadores eh achar que o mais bonito, mais reciclavel, mais elegante, mais etc, eh o melhor para a empresa.

Nem sempre, as vezes ela nao vende o produto sem dizer que tem suporte Microsoft por tras. As vezes nao vende por nao dizer que vai utilizar j2ee. As vezes nao vende pq nao vai dizer que tem struts.

Entao, tem o lado financeiro e marketing para pensar. E isso vem ANTES de contratar o programador. O programador nao influencia nisso pois a existencia dele depende da existencia do projeto, e para a empresa a existencia do projeto eh mais importante.

Fora a teoria a parte,

Tambem acho

Já viu a implementação da aplicação Pet Store com EJB? Quase 3000 LOC!
Já viu a implementação com hibernate? 970 LOC!
A implkementacao do pet store foi feita para mostrar todos os design patterns funcionando em ‘harmonia’… nao devem ser feitas comparacoes
Nunca vi isso, mas ja viu o hibernate trabalhando em diversos micros? Com objetos distribuidos? Eh nativo isso no hibernate ou tem que implementar voce mesmo? Se a resposta eh que eh impossivel, tai um motivo para nao escolher hibernate.

ps: nao se engane, so uso hibernate (coloquei no guj por exemplo), mas tempos que ser imparciais

Hibernate é um padrão. Tanto que é a spec EJB 3.0 é baseada na sua implementação. Se você diz que isso não funciona em todos os containeres … não sei o que te dizer. Funcionou em todos os que usei até hoje e não foram poucos.

perfeito, mas como disse um palestrante da ibm uma vez. se o ejb da pau, voce processa o cara do servidor de aplicacao. se o hibernate da pau voce faz o que? sua empresa abre falencia

como disse antes, a empresa nao pensa so em usar o que da menos linha de codigo, mas tambem em o que nao vai ferrar ela…

ps: nao eh ataque nem nada, so comentario sobre como a empresa e como o programador costuma pensarl. os dois (empresa e programador) estao certos e os dois (idem) estao errados, eh relativo

desculpe se ficou alguma frase meio grossa…

Vc consegue sim rodar o hibernate em um ambiente distribuido ( embora eu nunca tenha colocado sob testes ). Tem alguma coisa em

http://www.hibernate.org/161.html
http://www.hibernate.org/124.html

Rafael

Tudo bem Rafael?

Os textos dos links ainda nao estao bem claros para mim, preciso dar uma digerida melhor… mas parece um codigo BEM feio (ao melhor estilo EJB)

Entao o problema de oibjetos distribuidos eh resolvido pq o hibernate consegue fazer isso, mas mesmo assim ainda fica o ponto do suporte e da empresa precisar de um alibi ou de uma base sustentavel, afinal nao eh todo gerente que gosta de arriscar todo o lucro de um projeto por tal escolha…

Mas ai acho que eh um ambito que ficamos sem muita discussao (ou possibiliadde da mesma) uma vez que nao somos gerentes de projeto e nao entendemos disso… (alguem aqui eh?)

Eu acho que se o problema é a necessidade de padrões e suporte, use JDO, tão bom quanto Hibernate e você pode comprar de um fornecedor que vai ficar muito feliz de te vender suporte platinum 24x7.

:shock: … coisa feia acreditar em markteiro da IBM!

Se o EJB da pau você senta e chora … essa historia de processa o dono do AS é balela, nao conheco nenhum (nenhuzinho) caso onde pode-se processar o fornecedor pq vc usou a plataforma do infeliz pra desenvolver sua solucao e ela nao funcionou.
Nao lembro nem da microsoft ter sido processada porque invadiram qualquer que seja o servidor (sempre eh possivel colocar a culpa em outro) … alias, nessa linha de pensamento ninguem usaria apache pq nao teria quem processar.

Agora, se o hibernate dá pau você senta e conserta

ehehe só pra continuar o papo :lol:

pcalcado:

Chun,

Não esqueça de atualizar este tópico em algun meses. Queremos muito saber se você aidna acredita na especificação EJB…

[]s

Yeap , por enquanto estamos desenvolvendo e CLARO com algumas dificuldades , mas esta valendo a pena , o xdoclet ajuda muito… a coisa toda fica bem portavel…

Sinceramente ,

o Gilherme chegou onde eu estou tentando dizer…

esse negocio de “hibernate deu pau senta e arruma” eh tao lenda quando o “EJB deu pau , processa a empresa” , quero ver vc da noite pro dia debugando o hibernate e arrumando ele… eheheh

e na melhor das hipoteses… que vc consiga… vai ser “a sua versao do hibernate” contra a oficial… que beleza humm ?

Sinceramente , continuo seguindo os padroes… prefiro apostar em EJB+ Container que HIBERNATE…

mais uma vez tem vente coparando EJB 1.0 para 2.0 , meu amigo , soh lamento… quando a versao eh muito nova , é normal terem estes pulos , o proprio java teve disso da 1.1 pra 1.2 , prq sera q chama Java2 neh ? e o AWT ? vai me dizer q java eh uma merda prq vc teve que refazer em swing… essa portabilidade ae que vc reclama ninguem esta imune… nem o hibernate , se vc usar a especificacao 3.0 por ex: os containers vao ser obrigados a suportar a 2.x , vc mesmo especifica no xml qual a versao da especificacao que esta usando… entao… o dia q der na telha eh soh usar a 3.0 … mas o que importa eh que estou dentro de padroes… e que se eu falar com alguem … sobre meu projeto ele vai saber do que estou falando…

Repito , continuo usando e nao tenho tido mais problemas , apenas tenho tido que LER MUITO… pois pra quem veio de DELPHI+MYSQL , EJB eh coisa de outro mundo.

Nao posso participar da discussao porque efetivamente nunca usei EJB - mas o Hibernate eh software livre e voce pode enviar as correcoes ao projeto que, com certeza, elas serao incorporadas na proxima versao.

Marcio Kuchma

Nao posso participar da discussao porque efetivamente nunca usei EJB - mas o Hibernate eh software livre e voce pode enviar as correcoes ao projeto que, com certeza, elas serao incorporadas na proxima versao.

Marcio Kuchma

Quem assina embaixo ? me desculpe mas estou falando de um projeto onde vao ser gastos alguns milhoes de reais… quero saber quem assina em baixo sobre essa sua afirmacao…

smota:

:shock: … coisa feia acreditar em markteiro da IBM!
Se o EJB da pau você senta e chora … essa historia de processa o dono do AS é balela, nao conheco nenhum (nenhuzinho) caso onde pode-se processar o fornecedor pq vc usou a plataforma do infeliz pra desenvolver sua solucao e ela nao funcionou.

Verdade verdade… Mas pelo menos o gerente diz que usou o que foi pedido e nao tentou usar uma coisa muito nova e rola a cabeca dele. Pode ser inacreditavel, mas, mais uma vez, eh o que eu disse, o gerente pensa assim, nos nao. Por isso mesmo que eh dificil entender a posicao dele. Mas que eh valida para ele, isso eh.

Sobre isso servir como argumento para nao usar Apache. Pq voces acham que ainda tem gente que NAO uso apache? Ou tomcat? Ou Jboss? Pq se usarem correm um risco.
A mesma historia de sempre, existem casos e casos. Nao sao todos que nao se arriscam, e sem se arriscar nao ha mudancas. E sem mudancas nao ha melhorias. E sem melhorias o cara vai perder o cargo dele, mas o gerente nao pensa tao longe…

a) Mal do hibernate: A maioria dos programadores e’ medio (infelizmente) e nao vai correr atras de refazer a biblioteca…

b) Mal do ejb: Ejb e’ uma chatice de escrever, (mesmo com ajuda de qq programa)

c) Mal do jdo: hmm… nao posso falar mal, nunca usei

Nao vou falar bem deles pq todo mundo ja falou ne?

Quem assina embaixo de que as correcoes que voce enviar serao incluidas na proxima versao do projeto? Ninguem assina - eh uma questao de logica. Se eu abro meu software eh pra que todos possam ver, aprender com ele e me enviar correcoes. Se alguem me envia uma correcao ou um patch para uma nova funcionalidade que seja adequado, porque eu nao o incluiria no codigo original? Seria uma incoerencia da minha parte.

Como ja falaram, esse negocio de “quem assina embaixo” eh ilusao. Se voce conta com isso para projetos de “milhoes de reais” tomara que nunca se depare com uma situacao em que voce precise dessa “assinatura”.

Marcio Kuchma

chun:

Quem assina embaixo ? me desculpe mas estou falando de um projeto onde vao ser gastos alguns milhoes de reais… quero saber quem assina em baixo sobre essa sua afirmacao…

Existem muitos projetos de muitos milhões de dolares feitos com hibernate, spring-framework e todos os outros geri-geri opensource com nada de EJB.
Você está vendo tudo pelo vies “alice no pais das maravilhas”.
Eu, pessoalmente, acho opensource uma solução muito mais segura que closed-source e te digo por que.

Se você encontrar um bug no projeto XXX, você pode ir lá e corrigir ou verificar se é viavel migrar para uma versão mais nova que corrige o erro. Onde eu trabalhei sempre mantivemos um controle muito rígido das versões dos softwares que usamos (ate agosto desse ano estava em um que usava hibernate 2.0.1). A fica a critério da coordenação do projeto por criar um patch ou tentar atualizar.

Agora se você está falando de software closed source existem 2 opções: atualizar para a versão mais nova e rezar que o bug esteja corrigido ou entrar na fila de correções do produto e torcer para aceitarem ele e lançarem 3 meses depois 1 patch-set que corriga ele. Isso é o cenario mais otimista quando estamos falando de AS j2ee.

A não ser que você esteja trabalhando em um projeto de uma empresa com um contrato mega-milhonario de suporte, e essas existem poucas no mundo.

Acha que estou falando besteira? Bom, eu estou em um projeto dentro de um grande banco, que usa um container j2ee de umas das líderes de mercado, de uma empresa de tamanho quase imensuravel eu diria. Eu trombei esses dias com um bug que fazia o lindo AS dela ir pro vinagre, simplesmente despejava um dump da JVM e desistia de continuar. Qual foi a solução? Google + gambiarra para contornar o bug.

Então é basicamente oque o Guilherme falou, EJB e suporte de empresas AAA é puro marketing, não espere que isso agrege qualquer valor util ao desenvolvedor.

Quanto a facilidade de façar o conhecimento adiante, vale lembrar que EJB mesmo sendo padrão vai continuar sendo beeem mais complexo e dificil de aprender que Hibernate.

[quote=louds]

chun:

Existem muitos projetos de muitos milhões de dolares feitos com hibernate, spring-framework e todos os outros geri-geri opensource com nada de EJB.
Acha que estou falando besteira? Bom, eu estou em um projeto dentro de um grande banco, que usa um container j2ee de umas das líderes de mercado, de uma empresa de tamanho quase imensuravel eu diria. Eu trombei esses dias com um bug que fazia o lindo AS dela ir pro vinagre, simplesmente despejava um dump da JVM e desistia de continuar. Qual foi a solução? Google + gambiarra para contornar o bug.

Então é basicamente oque o Guilherme falou, EJB e suporte de empresas AAA é puro marketing, não espere que isso agrege qualquer valor util ao desenvolvedor.

Quanto a facilidade de façar o conhecimento adiante, vale lembrar que EJB mesmo sendo padrão vai continuar sendo beeem mais complexo e dificil de aprender que Hibernate.

Resumindo tudo

Eu acho, ate hoje, que as empresas SEMPRE erram em tentar economizar. Em nao ver o ponto do programador. Mas eh assim que elas funcionam e desisti de mudar elas, por isso vale mais a pena coordenar ou trabalhar em seus proprios projetos, ou com gente muito boa, cabeca aberta a ponto de permitir decisoes de projeto por opiniao desde o programador ate qq outro…

Estou com o Guilherme , sinceramente ? prefiro ficar com os padroes de mercados, a especificação, e não os padroes “pessoais”

Afinal , o proprio JBoss que sugeriu a mudanca no EJB 3.0 nunca implementou 100% das funcionalidades da especificação e fica dando pitaco…

Aos defensores do JBoss , usem uma vez soh o Oracle AS , ae depois conversamos…

Detalhe , alguem sabe me dizer aonde encontro material sobre objetos distribuidos com HIBERNATE , algo serio… que mostre algo melhor que 1 acessando diretamente , algo estilo EJB…

Preciso ler , conhecer melhor, prq ateh agora soh ouvi “HIBERNATE EH MELHOR” , cases q eh bom… nada…

Detalhe , nao sou a favor do closed-source , trabalho o dia todo com open source , porem estamos conversando sobre uma ESPECIFICACAO e nao sobre um trexo de codigo , vc fala do J2EE como se fosse uma caixa preta , e não é… eh uma especificação aberta…

Agora , se vc teve que fazer gambiarra , eh prq essa empresa ae que vc diz que de tamanho imensuravel , ou nao eh tao grande assim , ou nao sabe do bug,

Esse seu papo de estabilidade tmb eh bla bla bla , prq eu poderia tmb ficar com uma versao estavel e velha de um AS e ponto final, nao me venha com xurumelas , quem vive de passado eh museu , se vc tem um problema , corriga , nao faa gamnbiarra , e se o AS nao corrigir , otimo vc tem em maos uma ESPECIFICACAO e se fez a licao de casa ( tudo dentro dos padroes da especificacao e nao dos padroes do AS ) vc vai portar para outro numa tranquilidade tremenda ( apenas mudando os descritores especificos ) , mas se vc eh mais um que insiste em usar “super-solucoes gambiarras” ( le-se JBOSS-QL por exemplo ) , ae… vc soh tem que chorar mesmo.

Well, especificação versus “padrao pessoal” , sinceramente ? continuo com a especificação. se vc gosta de amarrar as coisas em meia duzia de profissionais , problema eh seu , a empresa eh sua

Nao há nenhum problema com sua posição, que está mais pra se defender de fracassos culpando o fornecedor e a tecnologia do que pra criar solucoes por conta propria (isso é coisa de gerente, vc é gerente?) e sim com sua postura nesta conversa.

ehehehehe Chun, ninguem é obrigado a te convencer de nada … nós estamos falando aqui do que conhecemos, trabalhamos mesmo com isso tudo (hibernate, webwork, spring & cia) e somos mais felizes do que com EJB (a maioria já trabalhou com EJB, nao se engane) …

Como nós estamos apenas preocupados em ter uma boa solucao usamos o que é mais apropriado e isso, acredite, não exclue EJB, só o coloca de lado a maioria das vezes porque existem opções mais viáveis.

Se precisa ler mais do que leu aqui procure no google …

chun, cuidado, eu odeio ejb

so defendo que os gerentes estao certos em nao querer se ferrar. assim como nos nas nossas escolhas.

Guilherme Silveira:

chun, cuidado, eu odeio ejb

so defendo que os gerentes estao certos em nao querer se ferrar. assim como nos nas nossas escolhas.

hehehe… OK terei cuidado :lol:

chun:

Detalhe , nao sou a favor do closed-source , trabalho o dia todo com open source , porem estamos conversando sobre uma ESPECIFICACAO e nao sobre um trexo de codigo , vc fala do J2EE como se fosse uma caixa preta , e não é… eh uma especificação aberta…

Grande ela é, ultima vez que eu olhei esse fornecedor do AS valia mais de 100 bilhões de dolares e o cliente que eu tou algo em torno de 1 bilhão, acho. Eu chamo isso de grande, muito grande. Quanto a não saberem do bug, bom, acho impossivel não saberem dele, já que usamos uma versão antiga do AS e o bug você encontra work-arounds via google.

Quem vive no passado é museu? Acho que você nunca esteve envolvido em um projeto de uma grande corporação. Coisas como plataforma e versões são fixas e normalmente completamente fora do alcance do desenvolvedor ou do gerente mudar. Ou você acha que tamos usando EJB 1.1 por que achamos melhor que o 2.1?

Mas é ai que você se engana. Essas tecnologias de infraestrutura não costumam ser o crux do conhecimento de um projeto, mas sim todo arcabouço criado em volta delas, as muitas camadas de abstração criadas pelos desenvolvedores para completar o projeto. Essas sim são as que dão muito trabalho para um profissional novo aprender.

É muito mais facil aprender Hibernate do zero que aquele confuso fluxo de conversão-transformação-transporte-e-tudo-denovo de um projeto.

Usando EJB, um framework muito mais crú que springframework+hibernate, vão existir muito mais desses artefatos caseiros de infraestrutura. Eu aposto que você vai preferir aprender sobre o BeanFactory do spring que o com.louds.ServiceLocatorFromHell.

Quanto a usar objetos distribuidos, Hibernate não faz isso, ele faz apenas mapeamento objeto-relacional, se você precisa de remotabilidade, use web-services, hesian, burlan, corba ou, preferencialmente, Session Beans.
Não entendi o pq dessa dúvida pra falar a verdade, ninguém usa Entity Beans de forma remota, é uma tremenda burrice fazer isso.

Entenda , seus argumentos não são validos… é chamar nego de burro dizer q um produto q custa 1 bilhao tem bug e nao eh corrigido… presta atencao… fica com o hibernate vai

A questao aqui eh CMP ou BMP , nao Hibernate… ele eh carta fora do baralho… lah BEEEEEEM em cima

Mas obrigado por sua contribuicao

detalhe , nao estou falando de usar entity remoto… concordo , tremenda burrice

detalhe , não tem objetos distribuidos com hibernate ? entao tah mais fora de questao do que eu imagina…

louds:

Quanto a usar objetos distribuidos, Hibernate não faz isso, ele faz apenas mapeamento objeto-relacional, se você precisa de remotabilidade, use web-services, hesian, burlan, corba ou, preferencialmente, Session Beans.
Não entendi o pq dessa dúvida pra falar a verdade, ninguém usa Entity Beans de forma remota, é uma tremenda burrice fazer isso.

Blz Louds?

Me explica melhor pq eh ruim usar o ejb remotamente? Pq eu estava achando que se eu usava um bean (entity/session), eu nao sabia se ele estava na minha maquina ou em uma outra… isso nao define o ‘objeto remoto’?

valeu

guilherme

chun:

Entenda , seus argumentos não são validos… é chamar nego de burro dizer q um produto q custa 1 bilhao tem bug e nao eh corrigido… presta atencao… fica com o hibernate vai

Chun, obrigado por assumir que você não ter mais argumentos. Ou não tem idéia do que tá falando. E eu não falei de produto de 1 bilhão de dolares em lugar algum.

Todo software tem bugs. Ponto. Toda empresa só arruma os bugs que interessam a ela. Ponto. Se você não é capaz de compreender isso, vai ser incapaz de sobreviver nos negocios.

Você nunca deve ter participado de projetos sérios, você deve ser uma piada de um usuario do forum que quer tirar onda com os demais. Você é tão inverossimel nas suas afirmações que ou se trata de uma pessoa completamente alheia a realidade ou se trata de uma piada de mal gosto de alguem.

Guilherme, Entity Beans não devem ser usandos pela interface remota por que costumam possuir uma interface com granulosidade fina e isso é péssimo para objetos distribuidos. O ideal é usar Session Beans de fachada para eles.

Session Beans são ideiais para serem usados como objetos distribuidos já que deveriam possuir interfaces de granulosidade grossa.

Usar SLSB como fachadas pros EB é uma boa prática em j2ee.

Finalizando, chun, use BMP, eles permitem uma melhor flexibilidade no mapeamento entre os objetos e a base de dados.

(imaginem o Rafael com uma faca de cortar peixe na mao, arame-farpado na outra, um balde com alcool, sal, fogo e alguns outros apetrechos a mais a uma distancia de facil alcance. Entao imaginem agora ele aplicando isso tudo a certos “elementos”)

Rafael

louds:

Guilherme, Entity Beans não devem ser usandos pela interface remota por que costumam possuir uma interface com granulosidade fina e isso é péssimo para objetos distribuidos. O ideal é usar Session Beans de fachada para eles.
Session Beans são ideiais para serem usados como objetos distribuidos já que deveriam possuir interfaces de granulosidade grossa.

eheheh essa eu aprendi esses dias … traduzindo pra conversa de gente normal (o que o louds não é ) isso significa que o EntityBean costuma ter as propriedades mapeadas pro infeliz do modelo entao tera chamadas como getName(), getMiddleName() e getFamilyName() e cada uma dessas geraria um punhado de trabalho de serializacao e outras coisitas na chamada remota …
enquanto isso no Session Bean vc simplesmente faz um getAllNamesAtOneTimeAndTogether() e pronto … :shock:
(soh pra constar pra quem usar a busca do forum)

celto louds? :lol:

Exatamente isso que o smota falou.
Um EntityBean alem dos getters, costuma ter operações simples.
E se você precisar chamar um monte delas para completar uma requisição vai ficar bem lento. Por isso usar um SessionBean como fachada, retornando VOs.

Pensa em uma pesquisa que precisa de acesso a 20 EB com 5 atributos cada, acessando eles remotamente, isso vai gerar umas 20x5=100 chamadas remotas, com um tempo de resposta de 10 ms por chamada vamos ter gasto somente com comunicação com a rede 1 segundo. Tempo demais dependendo do que estivermos fazendo.

Usando um SB como fachada vamos ter 1 chamada remota e 100 locais, assim poupando muito a rede de tráfego indesejado.

Tinha esquecido o detalhes do entity remoto como pessima ideia. valeu.

Entao se for usar o session distribuido (com qq patterns ‘escondendo’ isso), faz sentido deixa-los remotos, isso?

Finalizando, chun, use BMP, eles permitem uma melhor flexibilidade no mapeamento entre os objetos e a base de dados.

Guilherme

Desculpem-me mudar um pouco o contexto da conversa, mas pense no seguinte:
ejb é “potencialmente” melhor, mas não para a maioria dos casos dada a realidade da equipe, do prazo e do hardware envolvido.
O melhor dos objetos distribuídos é a distribuição do negócio(Session) pois distribuir os dados, isso o banco de dados já faz a muito tempo e bem.

E mais, não caiam na velha máxima de fazer do AS a melhor forma de acessar localmente uma aplicação distribuída.

[]'s