Prevayler e EJB

Hmm, eu nao tenho aqueeeeeele conhecimento maravilhoso sobre a spec do CMP, mas cara, ta muuuuuito obvio que ela foi feita para mapeamento O-R, e tentar usar Prevayler (ou qualquer outra coisa que nao seja O-R ali vai ficar complicado. Primeiro, pq vc nao ganha vantagem nenhuma em usar Prevayler aqui - seus objetos de negocio vao continuar sendo amarrados com a API de EJBs, e vc nao vai poder ter um rich domain model, como geralmente se faz em sistemas prevalentes.

O Phillip tá tentando botar um ovo quadrado, IMHO, mas se ele conseguir, acho que muita gente vai gostar de usar

Na verdade, a idéia do projeto se deu lendo o livro do JBoss e o de JMX escritos pelo Fleury. Nos dois, existem exemplos de como é fácil substituir o CMP do JBoss [que hoje use Hibernate, mas na época era JAWS] por praticamente qualquer persistência, até serialização.

Bom, está tão óbvio que CMP foi feito para JDBC e SGBDs quanto toda a especificação J2EE ou 99.99% dos sistemas que temos hoje, seja em Java ou COBOL, foram feitos pra SGBDs. Com um paradigma novo, precisamos de ferramentas novas. Como dito: prevalência é um conceito, rpecisamos da ferramenta para que vejamos se é viável ou não. Eu, pessoalmetne, acredito muito enste conceito.

Eu particularmente não concordo que o Prevayler por si só consiga substituir EJBs em uma aplicação real J2EE, daquelas que usam quase tudo que é oferecido no framework, com sucesso, mas acho que a idéia é fantástica.

A idéia de colocar como CMP ao invés de um novo container [estão/estavam tentando fazer isso com o Objectopia - http://www.objectopia.org] é reaproveitar o que já existe e oferecer algo mais fácil em termos de migração. O Cereal ainda é muito “early stage” para afirmar qualquer coisa, apenas uma idéia, mas acho que o caminho pode não ser tão ruim.

[]s[/url]

Uma duvida, Phillip, como vc pretende resolver o problema de distribuicao de objetos usando o Prevayler debaixo de uma camada CMP? A maioria das imoplementacoes de CMP confia em um RDBMS centralizado para realizar boa parte da distribuicao e controle de concorrencia, mas o Prevayler (ainda) nao tem isso. Alguma ideia?

PS: legal vc ter aparecido por aqui, bem-vindo à casa

Carlos,

Bom, é pra essas cosias que juntamos as cabeças

Este é um dos pontos que acho que o prevayler precisa de um gás. Nas primeiras versões, pretendia colcoar tudo em uma JVM só, enquanto o time do Prevayler, o do Cereal e outros vão pensando neste assunto para chegarmos a um modelo viável e robusto. Andei lendo algo que o Campelo postou na RioJug sobre replicação de repositórios, e realmente ainda não pensei em nada concreto, mas podemos dar uma XPzada e fazer o que precisamos hoje: algo local para primeiro nos concentrarmos em:

• Integração com AS
• Busca com EJBQL e outros tipos
• Tolerância a falhas
• Ferramentas adminsitrativas

Não acho que vai demorar muito para alguém envolvido colcoar o ovo de colombo em pé… esse não vai ser quadrado…

Na verdade, não costumo participar de fóruns web pq tenho repguiça de preencher formulários , prefiro lsitas de discussão. Mas já que o tópico é esse…

[]s

Ah, Samuel, coloquei o FAQ no site, já que não tô entendendo xongas do java.net qeu não publica o projeto [devo estar fazendo uma besteira muito grande e óbvia!!]. O SourceFOrge parece bem melhor… mas, de qualquer jeito, vamos ver…

Alias, soh agora eu entendi o nome… cerealizacao

Muito bem sacado

“cv”:

Uma duvida, Phillip, como vc pretende resolver o problema de distribuicao de objetos usando o Prevayler debaixo de uma camada CMP? A maioria das imoplementacoes de CMP confia em um RDBMS centralizado para realizar boa parte da distribuicao e controle de concorrencia, mas o Prevayler (ainda) nao tem isso. Alguma ideia?

PS: legal vc ter aparecido por aqui, bem-vindo à casa ;)

Com jgroups não é muito dificil implementar um prevayler distribuido.

“pcalcado”:

Na verdade, a idéia do projeto se deu lendo o livro do JBoss e o de JMX escritos pelo Fleury. Nos dois, existem exemplos de como é fácil substituir o CMP do JBoss [que hoje use Hibernate, mas na época era JAWS] por praticamente qualquer persistência, até serialização.

Phillip,

qual seria a grande vantagem dessa arquitetura CMP + Prevayler?

Utilizar uma API já conhecida (CMP) com a velocidade do Prevayler? Algo como, tornar o Prevayler popular, já que os programadores não precisariam aprender nada de novo?

Andei lendo por aí (aliás, talvez tenha sido aqui mesmo no JUG) que o CMP é o que há de pior na API do EJB e que deveria ser jogado fora para que construissem algo descente.

Opa, já que falaram no meu nome, vou contribuir com meus 0,02 cents …

Existe um projeto chamado Space4J (http://www.smartjava.com.br) que é baseado no Prevayler e implementa Load Balance de uma maneira bem simples.

Parece que a solução ficou muito boa e o Klaus convidou o Sérgio (do Space4J) para escrever/reescrever o módulo de Load Balance do Prevayler.

“pcalcado”:

Bom, está tão óbvio que CMP foi feito para JDBC e SGBDs quanto toda a especificação J2EE ou 99.99% dos sistemas que temos hoje, seja em Java ou COBOL, foram feitos pra SGBDs.
[]s[/url]

Bem, na verdade os caras da Sun “viajaram” generalizando demais, tentando suportar qualquer fonte de dados e por isso não focaram SGBDs, porque senão a EJB Query language não seria tão estúpida quanto era na J2EE 1.2 (não tinha nem “group by”…) e ainda stá muiito atrás de qualquer implementação SQL.

Outros problemas que você têm com Prevayler EJB.

1. Qualquer componente EJB deve suportar sua participação em um contexto de transação. Vocês estão pensando em implementar um adapter JCA pro Prevayler que suporte transações 2PC (two phase commit) ?!! Porque senão não têm o menor sentido em pensar em EJB e um projeto deste porte daria um trabalho do caraça !!

2. Só o que o CV mencionou sobre as classes do domínio ficarem acopladas a API EJB já seria o motivo suficiente pra esquecer esta idéia. Cruz credo ! Os containers IOC (ou Dependency Injection, como queira) como Spring e PicoContainer estão abafando por aí e têm gente querendo integrar Prevayler com EJB ??!!

3. Eu acho o Prevayler, em especial o Space4J muito interessantes. Com eles você pode facilmente persistir seus beans (ou POJOS) de forma transacional. Isto é ótimo para aplicações OLTP (On Line Transaction Processing), que também é foco dos EJBs. Se você não necessita de transações em múltiplas fontes de dados do servico de transações do J2EE, poderia usar tranquilamente estas soluções e no caso do Space4J, ainda por cima em ambiente clusterizado !

4. Se conselho fosse válido, se vendia mas pessoal, ESQUECAM EJB´s com CMP. Nem tentem aprender ! Este conselho é sério. Eu acho que a Sun vai acabar “deprecando” CMP ou este vai cair no esquecimento mesmo porque traz muito mais problemas do que soluções !

5. Eu expûs uma idéia ao Sérgio Oliveira, criador do Space4J. Seria uma extensão que replicaria os beans para um banco de dados relacional, além do próprio Space4J. Ele foi muito legal e me encorajou a tocar a pesquisa. Em princípio seria um framework AOP que interceptaria o final da execução dos Commands que persistem os beans e, usando talvez um mapa OR do Hibernate e o próprio runtime do Hibernate. Mas agora estou mais modesto e pensando em começar prototipando talvez com tags XDoclet do Hibernate nos beans que também seria persistidos para o Space4J. A única coisa que falta é identificar como sincronizar os estados nos dois repositórios. O papel de fonte “master” seria do Space4J.

As vantagens :

Como eu já mencionei, com Space4J e/ou Prevayler você teria um ambiente OLTP decente e ainda teria um controle sobre ele afinal todo mundo aqui é um arquitetos Java

Mas e quanto às aplicações que dão suporte a a decisões como relatórios (Crystal, JasperReports), data-warehouse e OLAP. Sim, se você não topou com este termo ainda, um dia vai topar, meu amigo !

Infelizmente não dá pra contar com JXPath ou sei lá o quê para fazer queries que atendam aplicações reais de negócios. As soluções que o pessoal do Prevayler apresentam para queries são até interessantes, mas eu me pergunto : se o poder da ferramenta é OLTP, por quê ficar malhando o SQL ? SQL é bom, pessoal ! Isto sim vale a pena aprender!

Enfim, já escrevi demais e minha mulher tá me intimando.

Quem tiver críticas ou sugestões, será um prazer !

Rodolfo

“rodolfo_dpk”:

Mas e quanto às aplicações que dão suporte a a decisões como relatórios (Crystal, JasperReports), data-warehouse e OLAP. Sim, se você não topou com este termo ainda, um dia vai topar, meu amigo !

Infelizmente não dá pra contar com JXPath ou sei lá o quê para fazer queries que atendam aplicações reais de negócios. As soluções que o pessoal do Prevayler apresentam para queries são até interessantes, mas eu me pergunto : se o poder da ferramenta é OLTP, por quê ficar malhando o SQL ? SQL é bom, pessoal ! Isto sim vale a pena aprender!

Fiquei curioso, Rodolfo… o que te faz achar que as linguagens de queries para objetos existentes hoje em dia (SODAQuery, JXPath, OGNL) nao sejam suficientes, ou nao sirvam como substitutos para SQL em um sistema orientado a objetos? É perfeitamente possível gerar relatórios através delas, sem muita dor de cabeça.

Ô, CV !

É possível sim, mas “sem muita dor de cabeça” eu não sei não… Montar um datawarehouse e fazer consultas via ONGL, por exemplo não faz o menor sentido, IMO. JXPath então…

SQL foi criado com sólida base matemática. Aquele papo de conjuntos e suas operações, união, intersecção, etc. Isto é matéria do ginásio. O que me parece é que os mais jovens mal começam com Java e já descartam SQL porquê é “relacional”. Pô, em uma expressão de 4 linhas de SQL é possível extrair, filtrar, agrupar e fazer joins diversas (inner, left, etc) e ainda as obter algumas primary keys de qualquer bean desejado, assim vc poderia instancia-lo.

Fazer isto com outra linguagem qualquer me parece “forçar a barra”. Cada tecnologia tem que ser usada no seu melhor. Pra falar a verdade, eu acho que exatamente pelo problema das queries é que os banco de dados orientados a objetos nunca “pegaram” e até hoje ainda usamos banco de dados relacionais.

Só mais um ponto : Aproveitar ferramentas existentes (Crystal Reports, Excel ou mesmo JasperReports) é uma necessidade das empresas, mesmo as pequenas. Produzir relatórios é uma tarefa até simples então mudar até a linguagem de consulta ao banco de dados parece reinventar a roda e ainda sem vantagem nenhuma. :roll:

(Vo taca fogo)

"SQL foi criado com sólida base matemática…"
Então, a idéia é o contrário.
A tendencia (no meu mundinho java pelomenos) é tudo ser objeto.
Mudança de paradigma é sempre complicado.
O modelo relacional é um modelo excelente para um paradigma relacional, a partir do momento que você pensa em objetos, devem-se existir maneiras melhores de se armazenar dados do que a maneira relacional (lembre-se que um objeto é o conjunto Atributos, métodos de acesso e Dados).

"Fazer isto com outra linguagem qualquer me parece “forçar a barra”. "
Volto a falar, mudança de paradigma.
Quando foi criado o conceito de OO (década de 70 se não me engano), este paradigma era absurdo e impossivel de ser implementado. Hoje ele é real. Até pouco tempo atrás (10 anos) não era, era mais uma ‘coisa’ para nós falarmos mal.

O que quero dizer é isso.
Cada um tem a sua beleza e eficiencia pra um contexto.
Eu acho o banco de dados relacional muito bom, mas acho o OO de uma beleza incomparavel (como diria um cantor, é lindu, tudo é lindo). Não só de uma beleza, de uma proximidade da realidade ótima.
A partir de momento em que tudo que está ao nosso redor é um objeto, nada melhor que jogar em um objeto as coisas que vc quer guardar.

Oi, Rodolfo,

Bom, eu estou mais ao lado do Prevayler Team em achar que SQL é uma amarração, não uma ferramenta. EJBQL pra mim é um método de trazer o legado dos SGBDs ao
futuro. Tantos anos aprendendo estruturas de dados e algorítimos para ficar restrito eternamente a esse troço tão limitado?

É como um engenheiro de software aprender física. Para quê? Um engenheiro “normal” trabalha com física, nós trabalhamos puramente com lófgica. Um modelo concebido sobre base matemática, o Modelo Relacional e sua álgebra, não pode ser aplicado eficientemente num contexto de Objetos.

Acho que está havendo uma confusão: o Cereal não seria o COntainer EJB, ams sim uam camada de persistência.

Eu pessoalmente acredito no modelo EJB e acredito que ele vai ficar por um bom tempo, no nosso mundinho J2EE. Assim como SGBDs não são eternos [e não necessariamente serão substituídos por prevalência, é isso que estamos tentando descobrir], EJB, J2EE… também não. O ponto é: algo para usarmos aprovetiando o legado de EJB e que desde já msotre as pessoas que SGBD não é a mãe delas [nota: nunca fale isso perto de um DBA certificado Oracle… ou pelo menos se rpepare para correr!].

Concordo quando você diz algo do tipo: “Se não precisa de JMS, JCA, etc., considere uma solução mais simples”, de repente até o Prevayler puro. Transações estão no escopo do Prevayler.

A idéia de CMP é bem legal, mas a implementação é extremamente mal feita, e credito isso ao SGBD e mapeamentos.

Novamente: é uma camada de Persistência, uma otimização do Prevayler para EJB CMP. J2EE e seus serviços continuarão a ser providos normalmente, até o ponto em que toca a CMP. O primeiro objetivo é construir um plug-in para os AS open-source no mercado, e fazer benchmarks.

Ontem a noite, fiquei criando o primeiro exemplo, utilizando como guideline o tal artigo mencionado do Fleury. Terminei de implementar um plug-in de persistência para o JBoss, e assim que testá-lo vou disponibilizar para download no blog [enquanto a resposta do java.net não chega… ô trocinho demorado!].[/quote]

Olá,

Sinceramente acho que essa discução leva a lugar algum, mas sobre o que os dois colegas falaram na minha humilde opinião.

Se vc usa banco de dados relacional, não invente use SQL.
Agora se vc não quer SQL e quer tudo objeto…esqueca o banco de dados e armazene em outro modelo de dados. Misturar não é legal.
Agora não curto essa idéia de que se estamos programando em Java e tudo tem que ser objeto iremos mudar de acesso aos dados (no caso dos bancos de dados relacionais ) que ja funcionam a mais de 20 anos e que muita gente conhece.

Para isso que existe o prevayler pra não user SQL e banco de dados

[]'s

“mcampelo”:

Phillip,

qual seria a grande vantagem dessa arquitetura CMP + Prevayler?

Utilizar uma API já conhecida (CMP) com a velocidade do Prevayler? Algo como, tornar o Prevayler popular, já que os programadores não precisariam aprender nada de novo?

Andei lendo por aí (aliás, talvez tenha sido aqui mesmo no JUG) que o CMP é o que há de pior na API do EJB e que deveria ser jogado fora para que construissem algo descente.

CMP é um modelo de transparência, onde o programador da aplicação não repcisaria se improtar em onde seus objetos são persistidos, se concentrando em regras de negócio e blábláblá…

O que eu acredito, até agora, é que uma boa idéia como está foi amarrada pelo SGBD de uma forma que realmente é impossível usar CMP seriamente sem recorrer à truques específicos de um Container qualquer.

O Prevayler, no caso, oferece o fim da conversão relacionas-objeto e, além disso, uma velocidade asustadora.

[]s

A propósito: este fórum é compatível apenas com IE? Tá compricau utilizar os botões do editos no firefox…

Estranho, eu (e muita gente aqui) uso o Firefox direto pra navegar no fórum, sem problemas… :shock:

“Daniel Machado”:

(Vo taca fogo)
A tendencia (no meu mundinho java pelomenos) é tudo ser objeto.
Mudança de paradigma é sempre complicado.
O modelo relacional é um modelo excelente para um paradigma relacional, a partir do momento que você pensa em objetos, devem-se existir maneiras melhores de se armazenar dados do que a maneira relacional (lembre-se que um objeto é o conjunto Atributos, métodos de acesso e Dados).

Daniel,

Uma coisa é uma coisa e outra coisa… Vamos lá : Utilizar um banco de dados relacional para persistência não impacta em nada o seu modelo OO e vice e versa. O Hibernate, por exemplo, implementou vários patterns inspirados no trabalho do Scott Ambler (um velho guru OO) para resolver a impedância. O Martin Fowler, outro velho guru OO também mostrou alguns patterns pra isso em um livro recente. Até o Fleury do JBoss Team, com aquele papo de “I love EJBs” acabou contratando o Gavin King, criador do Hibernate porque não é bobo e percebeu que não adianta ficar inventando a roda para persistência dos beans.

“Daniel Machado”:

(Vo taca fogo)
… relacional (lembre-se que um objeto é o conjunto Atributos, métodos de acesso e Dados).

Opa ! Isto não é uma boa definição para objeto :roll: O CV já postou aqui no GUJ uma vez um exemplo simples, de forma divertida, uma “novelinha” em que se modela uma classe, com seus atributos e comportamento (responsabilidades) e após isso usa-se o XDoclet com Hibernate para persistir os beans criados. Pronto !

Então uma coisa é a modelagem OO, que deve ser feita antes de qualquer coisa. Depois, aproveite o trabalho de décadas dos melhores gurus OO para mapear seu modelo para um repositório relacional… Simples !

De qualquer forma, isso não deixa de ser uma grande “gambiarra” para tornar (mais ou menos) transparente a persistência de objetos sobre bancos relacionais, ou seja, o uso de design patterns famosos só prestaram ao seu único papel que é o de facilitar na implementação de tarefas algumas vezes complicadas. Mas isso não tornou o sistema “mais OO”; na verdade, tornou o sistema um pouco “menos relacional”.

Ahh tinha algumas outras coisas a comentar, mas agora, depois da aula, não consigo me lembrar.

Agora voltando à discussão do projeto do Phillip. A idéia é boa sim. Mas, talvez, a idéia pudesse ser melhor implementada usando Connectors do que CMPs, uma vez que estes são muito atrelados ao uso com banco de dados relacionais (embora admita-se o uso de fontes de dados alternativas).

p.s.: sobre querylanguages, talvez fosse interessante dar uma olhadinha nesta especificação: http://www.prevayler.org/wiki.jsp?topic=Poquer

Oi,

Tá bom, como quiser. Mas como eu já disse, as implementações atuais EJBQL são ridículas comparadas até a um bd relacional grátis como o MySQL e a especificação não me parece ter tanto futuro assim mas só o tempo dirá, não ? Na verdade, elas estão muito atrás no tempo, vide o exemplo que citei antes sobre a clausula “group by”.

Eu não disse que quero usar SQL em um contexto de Objetos. O que estou dizendo é que é perfeitamente possível usar SQL para suas consultas a um bd relacional (claro!) e instanciar seus beans com base nos dados recebidos.

Tem um pattern no catálogo J2EE da Sun chamado “Fast Lane Pattern”, ou algo parecido. Basicamente ele sugere utilizar SQL para suas consultas, por ex. recuperar alguns valores chaves e com base nestes valores instanciar seus EJB´s. O motivo : não invente a roda, SQL é poderoso e muito mais rápido que via OQL. É só procurar o site J2EE patterns da Sun. Aliás, o BC4J, um framework de persistência da Oracle (antes de comprar o TopLink) implementa isto de forma muito eficiente.

Explicando : quando você disponibiliza um recurso qualquer (uma fonte de dados persistente) em um contexto transacional EJB, você necessita no garantir que seu recurso pode participar em contextos de transações múltiplas. Por exemplo : vc têm uma fonte Oracle e a outra é um ERP como o SAP. Voce têm que gravar um registro no Oracle mas sua lógica de negócio exige que após gravar no Oracle você também deve avisar o SAP. Ambas as fontes têm que garantir que podem participar em um contexto único de transação, ou seja, ou grava nas 2, ou não grava em nenhuma. Isto não é coisa simples de se fazer. Mas pensando bem, acho que o JBoss ainda não tem suporte a 2PC então divirta-se !

Sou certificado em Java, e ainda gabaritei as questões sobre orientação a objetos. Mas quer saber ? Também sou certificado DB2 e não vejo nenhum conflito nisto…E quanto a EJB´s, leia alguns artigos de um cara chamado Rod Johnson, criador do framework Spring. Nem seria necessário você ler, bastaria vc se comprometer com TDD (Test Driven Development) que já teria vários motivos pra concluir sozinho que EJB pode ser muuuito improdutivo, pra dizer o mínimo.

Eu não falei nada sobre JMS e JCA !! Mas também gosto de ver as coisas simples. E é exatamente por isso que considero uma inutilidade acoplar seus beans de negócio a uma API EJB. É perfeitamente possível prover vários serviços que um container EJB oferece como segurança e delimitação de transações de forma declarativa para classes java puras (os POJOS), e ainda sem estar acoplado a nenhuma API EJB…

Mas não quero te desanimar, já vi que vc está mesmo convencido então vá a luta e boa sorte !
8)

Por mim tanto faz, não quero depender de SQL, EJBQL, whateverQL. Queria dar esta opção à pessoa, a questão do suportar EJBQL e SQL está vinculada ao legado. A opção em seguir ao máximo a especificação é exatamente para isso.

O complicado, como estava falando com o cv ontem, é: ou você tem uma linguagem como Poquer, SQL, EJBQL, etc., ou tem um modelo de objetos com estruturação livre.

Ok,

Agora coloca isso em um SGBD. Ok, vc vai poder persistir seus campos e utilizar SQL, mas fica com todos os o]problemas da mudança de paradigma, principalmente que você, provavelmente, vai ter que voltar com a tupla para um objeto.

Se você quer usar SQL em um banco de dados que deveria guardar objetos “desmontados” em forma de tabelas, então você está usando SQL em um contexto de objetos.

Vou ficar devendo o comentário pq este pattern eu não conheço.

Aham. Quem te falou que o Prevayler não tem transação? Ainda que não tivesse, nada difícil de implementar, considerando a estrutura [poderia impactar na performance, um pouco…]. Ok, vamos lá:

public void iniciaTransacaoGeral(){
 MySAP.inicaTransacao();
 Persistencia.iniciaTransacao();
 seiLahOQue.iniciaTransacao();
 }

 public void rollbackGeral(){
 MySAP.rollback();
 Persistencia.rollback();
 seiLahOQue.rollback();
 }

Eu entendi errado ou a coisa é simples assim? Se cada parte individual prover transações, qual o problema? Não é assim que o JCA suporta transações?

Uhm e…? Não entendi o que as letrinhas no seu curriculum têm a ver com isso, mas… Se você não vê problemas, talves isto te ajude:

http://www.google.com.br/search?q=%22impedance+mismatch%22

Pois é, EJBs são problemáticos, principalmente CMP. Estamos criando algo chamado Cereal para tentar melhorar isso…

JMS e JCA são o tipo da coisa que meio que te obrigam a utilizar um AS.

Você não quer acoplar à EJB… e vai acabar acoplando a outra. Ou vai criar todo o framework de distribuição sozinho e exclusivo do sistema? Acoplamento fraco é algo procurado desde Page-Jones e seu livrinho preto de Projeto Estruturado, mas frameworks não necessariamente estão ligados ao acoplamento, a menos que sua implementação seja ruim. Lógica é lógica, e deveria ser transferível facilmente.

A questão não é EJB é bom ou EJB é mau. EJB existe, amanhã quando acordar vou estar olhando alguns, muitos deles nem sequer criados por mim ou minha equipe, mas eles estão lá e tenho que usá-los. Não tenho absolutamente nada contra outros frameworks, muito pelo contrário, mas 90% dos problemas que alguém pdoe citar em EJBs [pelo menos os que já vi] estão relacionados direta ou indiretamente com mapeamento objeto-relacional e cache de objetos.

“rodolfo_dpk”:

Mas não quero te desanimar, já vi que vc está mesmo convencido então vá a luta e boa sorte !
8)

Obrigado, e pode ter certeza que enquanto tiver tempo e não me convencerem do contrário, eu estou tentando.

[]s[/url][/code]

Phillip,

“pcalcado”:

O complicado, como estava falando com o cv ontem, é: ou você tem uma linguagem como Poquer, SQL, EJBQL, etc., ou tem um modelo de objetos com estruturação livre.

Como venho dizendo, são problemas distintos : as instâncias dos beans
orientados a objetos dentro de um container qualquer, desde uma JVM simples até um Websphere EJB ou mesmo um Avalon é completamente distinta da persistência deles, ou seja, a persistência é um outro problema : armazenamento e queries (puro IO).

Tente pensar em 2 contextos : um é a instância do objeto na JVM, que deve ser apenas sua estrutura fundamental : atributos e comportamentos. Hooks para EJB já poluem inutilmente este modelo essencial. No segundo contexto você persiste estes atributos dos seus beans em várias tabelas relacionais usando patterns (não gambiarras como o Daniel falou) projetados por adivinha quem ? O Scott Ambler, o cara da primeira url que aparece nesse link do Google que vc deu ! Se vc ler o item “5. Strategies for Overcoming the Object-Relational Impedance Mismatch” você verá que ele apresentou os problemas da impedância mas propôs soluções pra eles !. Você só enxergou os problemas !

No primeiro contexto você têm uma paradigma OO e no segundo contexto você têm um paradigma relacional. Qual o problema em usar os dois se já existem tantas ferramentas ótimas pra isso ?

Ô meu ! Eu não sei quem falou não ! O problema é que os provedores de recursos que suportam os contextos de transação em containeres EJB (o que você está fazendo) devem escrever drivers que conversam com o serviço JTS via a api JTA (são tantas letrinhas que posso até estar errado ) da especificação J2EE e isto é muito diferente do tipo de suporte transacional que o Prevayler oferece, que é muito mais simples, direto e sem frescuras (mas eficiente).

Você mencionou algo sobre correr de um DBA Oracle. Tudo bem, foi brincadeira mas isto demonstra um preconceito bobo (calma, apenas minha opinião, na boa, brow !) e apenas por isso mencionei alguns dos meus suados certificados. :oops: Não faço mais isto, tá bem ?

Tudo bem, essa é a intenção.

“pcalcado”:

Você não quer acoplar à EJB… e vai acabar acoplando a outra. Ou vai criar todo o framework de distribuição sozinho e exclusivo do sistema?

Sim, dá pra montar frameworks que podem prover segurança, transações e até distribuição em cluster mas dá um trabalho do cão e seriam proprietários, de valor apenas para quem quer e pode usar, mas desde que contemplem toda uma arquitetura.

Mas as coisas começaram a ficar mais simples agora com a chegada dos containers IOC e os frameworks AOP. Você têm o menor nível de acoplamento possível com conteiners IOC e com AOP vc pode interceptar suas requests e manipula-las da forma que quiser.

[]s

Rodolfo

Caramba, eh tanta coisa pra discutir aqui que eu nao sei nem por onde eu comeco. Bom, vou comecar ignorando grande parte dessa discussao que eu vou considerar irrelevante por enquanto, mas se alguem quiser continuar comentando, eu entro tambem.

Vou partir do pressuposto aqui de que todo mundo nessa discussao (Daniel, Phillip, Rodolfo, em especial, mas estao todos bem-vindos) ja conhece bem os problemas que a J2EE tem, e quais as possiveis solucoes, e que tambem ja conhece bem os problemas que o mapeamento objeto-relacional tem, e conhece as possiveis solucoes (como ja foi citado, existem inumeros patterns e ferramentas que ajudam a lidar com isso). Isso eh importante, ja que muito do que eu vou dizer aqui pode ser interpretado incorretamente caso essas duas ultimas afirmacoes nao sejam verdadeiras.

Sim, objetos e tabelas não sao exatamente amigos. Mas tambem nao sao inimigos, e eu não sei onde é que está a novidade aqui. Parem de “discordar concordando” e prestem atencao no que eh importante nessa discussao: estamos tentando fazer com que um modelo de persistencia adulto (CMP), que serve como fachada para um modelo de persistencia idoso (RDBMS) em cima de objetos, possa ser adaptado para trabalhar com um modelo de persistencia jovem (prevalência).

Resumindo ainda mais, nos queremos fazer com que o OR fale com o OO, ao inves de falar com o R. Nao concordo que seja realmente o passo certo a ser dado - pra mim, isso ainda soa como botar um ovo quadrado, mas é um passo, de qualquer maneira, e o Phillip ja deu inumeras razoes para que ele ache este passo importante.

No geral, concordo com ele, mas é obvio e ululante dizer que o futuro (bom ou ruim) do Prevayler em si nao depende diretamente e desesperadamente do sucesso ou falha do que o Phillip esta fazendo agora. Nao que isso seja ruim, muito pelo contrario, eh otimo ter esse tipo de independencia, e eh otimo saber que, tudo dando certo, o Cereal vai impulsionar mais gente a usar o Prevayler. O meu grande problema com um approach como o do Ceral eh que o coitado do Prevayler vai estar tao enterrado em um monte de APIs que o tornam invisiveis, que as boas features do Prevayler que só se consegue tendo liberdade para usar OO do jeito que der na cabeca na sua aplicação também vao ser perdidas.

E, enquanto eu tou falando de “OO do jeito que der na cabeca”, a gente sabe que IoC (que não é nada novo, só foi descoberto agora) e AOP (que é realmente novo, tão novo que ninguém sabe direito pra que serve) se tornaram as salvacoes de qualquer lavoura. Nao sabe como fazer persistencia ou controle transacional? AOP neles. Nao sabe definir um modelo de componentes? IoC neles. E vamo lá! É só enfiar mais esse frameworkzinho, ou jogar mais um pouquinho da tecnologia X em cima que a coisa anda!

Eu sou um defensor ferrenho de IoC e AOP, como muitos aqui já puderam notar, e posso ate delirar um dia desses e achar que eu sei bastante sobre o assunto (o que vai provavelmente mas se a discussão descamba pra esse lado, é melhor parar por aqui, já que não é esse o intuito. Se nós estamos falando de implementar um modelo prevalente dentro de um CMP Engine, então vamos falar do que pode ser feito para implementar um modelo prevalente dentro de um CMP Engine, por favor.

Eu falei, falei, e nao disse porra nenhuma ate agora. Incrivel.

“cv”:

Caramba, eh tanta coisa pra discutir aqui que eu nao sei nem por onde eu comeco. Bom, vou comecar ignorando grande parte dessa discussao que eu vou considerar irrelevante por enquanto, mas se alguem quiser continuar comentando, eu entro tambem.

Tá, não quero mais polêmica mas apenas para voltar aos pontos centrais :

1. O Phillip tá bolando uma camada de persistência (via Prevayler) pra EJB no JBoss. Eu acho ótimo e tenho todo o respeito pelo esforço dele mas quero deixar claro por que não concordo que valha a pena e expûs os motivos técnicos.

2. Eu acabei caindo de gaiato na discussão e decidi apresentar a idéia de se replicar os beans de forma assíncrona para um bd relacional pra obter a opinião do pessoal por aqui. A maioria, entretanto, se manteve enxergando “mudança de paradigma” quando se fala em bd relacionais. Eu expliquei várias vezes porque isto é um engano e que um paradigma pode facilmente conviver com outro em uma aplicação. Usei até bons exemplos do CV sobre isto. Citei vários gurus OO e patterns como referência.

Então, discussão é pra isso mesmo, troca de idéias e experiências, não importa se vc concorde ou não. É fácil concluir que todos aqui têm talento e se eu puder ajudar a focar esse pessoal em idéias mais úteis (não necessáriamente o que eu sugiro), eu estou colaborando com minha experiência, não ?

Fui. Caraça, este lance de ficar escrevendo come muito tempo. Não dá pra fazer isto não ! Vou sumir por um tempo pessoal. Abraços a todos.

Rodolfo

Cv,

Uhum. É aquela questão: funcionar funciona, mas…

esta é minha idéia #1

Kct, cv, muda de metáfora que esse negócio de galinha eu tô fora!

Com certeza, aliás o uso do Prevayler se deve [como tá naquele FAQ troncho que fiz] ao fato dele proporcionar as características desejadas [OO puro, desempenho, etc.] e já estar pronto e funcional.

É uma das idéias tb. Vcs que são bem mais xpers que eu sabem da questão do “embrance change”, “supere o medo” e derivados. É uma boa para quem não acredita em prevalência por preconceitos bobos ver que funcionaria bem.

Pois é, a questão das query langauges e a maldita compatibilidade com legado. Bom, podemos prover extensibilidade suficiente para a pessoa utilizar estruturas de dados mais “Prevaylers” que “EJBs”…

Vou me manter calado porque vergonhosamente já li sobre AOP e IoC muito menos do que deveria.

[]s

Rodolfo,

Primeiro, deixa eu pedir desculpas publicamente pelo post mal-humorado de ontem [deu pra perceber que não tem nenhuma carinha? :oops: ]. Cheguei tarde em casa e não resisti a tentação, ams o sono me deixou ríspido e arrogante, perdão novamente e obrigado por não ter me levado a mal,

vamo que vamo…

Na verdade, eu acho que se aplica aqui uma máxima do Klaus: “Eu posso implementar SQL no PRevayler, ams você não pode melhorar o Oracle”, ou algo na linha [substitua oracle por SGBD em geral].

“rodolfo_dpk”:

Tente pensar em 2 contextos : um é a instância do objeto na JVM, que deve ser apenas sua estrutura fundamental : atributos e comportamentos. Hooks para EJB já poluem inutilmente este modelo essencial. No segundo contexto você persiste estes atributos dos seus beans em várias tabelas relacionais usando patterns (não gambiarras como o Daniel falou) projetados por adivinha quem ? O Scott Ambler, o cara da primeira url que aparece nesse link do Google que vc deu ! Se vc ler o item “5. Strategies for Overcoming the Object-Relational Impedance Mismatch” você verá que ele apresentou os problemas da impedância mas propôs soluções pra eles !. Você só enxergou os problemas !

Gente, eu não tô dizendo que é impossível, ilegal, imoral, etc.mapear nada, eu tô dizendo que:

1. É uma abordagem que eu não recomendaria
2. Se houvessem alternativas, eu seria o primeiro a experimentar

Mas como o quê que eu trabalho hoje? Cereal é uma coisa em fase de definição de objetivos, ainda.

Tenho que concordar com o Daniel. ELas são ótimas, sim, ams em quebrar galho. Uma teoria louca que pensei agora: O nível de “quebrar-galho” de algo é diretamente proporcional à quantidade de XML [e derivados] que você precisa configurar para o troço funcionar.

No meu FAQ Troncho:
[i]
What is it?
Cereal PSC is an free software project to develop a way to improve J2EE performance using Prevalent storage devices as part of the Containers’ structure, specifically: replacing CMP’s and BMP’s need of a database with a Prevalent storage.

The target is to create all thing needed with all the features we have today in a J2EE environment, including an EJBQL implementation. We don’t want to create neither an AS, nor a EJB Container, there are several good others. We want to improve the model used now, not to create a new one. J2EE specs and Prevalence concepts shall be followed the most strictly possible.[/i]

O mais rigidamente possível [se meu inglês tb troncho me deixou expressar bem] não significa 100%. Na verdade, não posso nem dizer se não há uma solução [ou se, efetivamente, há um problema!] sem antes reler a especificação.

Na verdade, aquilo foi uma brincadeira, mas tenho que confessar que tenho péssimas experiências com pessoas certificadas, mas também não tenho o direito de generalizar.

Eu sei que dá trabalho, por isso pretendo reutilizar J2EE/EJB.

“rodolfo_dpk”:

Mas as coisas começaram a ficar mais simples agora com a chegada dos containers IOC e os frameworks AOP. Você têm o menor nível de acoplamento possível com conteiners IOC e com AOP vc pode interceptar suas requests e manipula-las da forma que quiser.

Assim que tomar vergonha na cara e ler mais sobre isso terei uma resposta a altura do comentário, mas por agora pretendo apenas reafirmar que estou adaptando o que temos hoje.

Ok, isto eu entendi e tal, e estamos debatendo.

Bom, eu acho que isto ficou meio fora de tópico, mas ninguém disse que é uma idéia ruim, muito pelo contrário.

Bom, “mudança de paradigma” vc pdoe ate’discordar, ams que a fronteira é atravessada a cada opereação, e que isto é caro, você concorda?

Pois é, mais um motivo para me envergonhar… :oops:

Meu gerente que diga… por que será que ele tá com essa cara feia me olhando… ihhhh…

[]s

“pcalcado”:

Tenho que concordar com o Daniel. ELas são ótimas, sim, ams em quebrar galho. Uma teoria louca que pensei agora: O nível de “quebrar-galho” de algo é diretamente proporcional à quantidade de XML [e derivados] que você precisa configurar para o troço funcionar.

Poxa meu, eu to lendo esse topico aqui desde o inicio, achei muito interessante, mas como não tenho tanto conhecimento preferi só olhar, mas depois dessa a mão coçou (não sei se é assim que se escreve) e não resisti. Trabalho com Oracle a 3 anos (to mais que acostumado com SQL ) e trabalho com Java a 1 ano.

Tu tocou num ponto que eu acho um pé no s*** ficar configurando XML pra fazer mapeamento OO/OR.
Mesmo que eu goste de SQL, essa abordagem foi muito util, pois isso é uma gambi mesmo e não adiante dizer que tem como fazer bonitinho que não tem…sempre tem os “malditos” XML de mapeamento.

Bom ja falei demais…

[]'s

Ontem à noite, antes de ir dormir, eu fiquei pensando um pouco naquilo que o Phillip falou a respeito do problema de “impedance mismatch”, que é a porcaria resultante de se misturar tecnologias que obedecem a paradigmas diferentes (como é o caso de Java com banco de dados relacional). E como o Rodolfo ressaltou depois, muito foi feito para tentar superar este problema. No entanto, com o surgimento da AOP, como superar mais este “probleminha” que é o de integrar um sistema altamente dinâmico (AOP) a um modelo absurdamente estático, como é o modelo relacional?

Desvio de assunto detected

Nao sei bem de onde saiu AOP da conversa, mas, no fundo no fundo, acho que nao tem tanta diferenca entre AOP vs RDBMS quanto OOP vs RDBMS. Se voce pensar bem, aspectos e objetos tem muitos problemas em comum quando vc tenta enfia-los em um banco de dados (heranca, encapsulamento, comportamento dinamico…), alem dos novos problemas… se bem que, no fundo no fundo, nao consigo pensar em nenhum exemplo onde voce va precisar ter seus aspectos persistidos (voce pode manter o estado dos seus aspectos em objetos, e o problema volta a ser OO vs. RDBMS)…

Eu acho que a grande limitação dos DBs vem da tentativa (bem sucedida, talvez) de fazê-los rápidos.

Não vou desviar o assunto pra falar sobre tipagem. Mas o melhor formato possível pra um objeto é o que conseguimos com a seriação dele. Dá até pra gravar o objeto de um jeito legal, enfiar índices, e tal, tem até projetos open source sobre isso.

Mas pra gravar um aspecto num banco, vc tem que lembrar que absolutamente tudo é um punhado de bits. Ainda tem muito pouco disso em alto nível, mas acho que é o caminho.

Se sua variável pode ser um inteiro, um objeto, um método, uma classe, um programa (variavel que é um programa?), e vc tem um esquema pra gravar isso, vc ultrapassa qualquer impedância.

Se eu achei meu texto sem pé nem cabeça, imagina vocês, né?? Outra hora que eu esteja com menos sono eu melhoro ele.

[]s!

Oi, pessoal,

Só pra avisar que o Cereal acabou de ser aprovado. Algumas coisas mduaran na minah cabeça, mas o propósito de aplicar prevalência em algo neste estilo continua.

A HP do projeto [inalterada desde que submeti, logo esperem mduanças em breve ] fica aqui. No meu blog tem um post [em inglês, ou pelo menos naquele idioma em que eu escrevo lá ] sobre isso também.

[]s