CMP ou BMP?

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 :stuck_out_tongue:

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 :slight_smile: 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…

[quote=chun][quote=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.
[/quote]

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 :slight_smile: 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…

[/quote]

Single-Vendor-Lock-In onde? Me mostra… :wink:
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.

:smiley:

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… :wink:

Continuou sem responder a pergunta. :smiley:
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 :slight_smile: esse negocio de dizer que Entity eh trabalhoso soh se vc usar notepad mesmo… prq o xdoclet faz todo o trabalho sujo :slight_smile:

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.
:smiley:

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é?

[quote=jrodrigues]Só acho que você é um EJB Evangelist e acha que EJB vai resolver todos os seus problemas.
:smiley:
[/quote]

Sou mesmo , se vc nao gosta da plataforma que vc opera… paciencia :slight_smile: 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.

[quote=jrodrigues]Anyway, acho que vou gastar o teclado para argumentar com você porque não vai adiantar mesmo.
[/quote]

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 :slight_smile: , 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:

[quote=jrodrigues]Hibernate é um padrão.
[/quote]

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’

[quote=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.
[/quote]

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. :smiley:
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 :slight_smile:

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 :wink:

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 :slight_smile:

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