Alguem pra ajudar o cereal?
(é um projeto pra fazer CMP usando o prevayler ao invés de mapeamento O-R)
http://www.jroller.com/page/pcalcado/20040308#prevayler_ejb_the_cereal_project
CV, Klauss … comentários sobre a idéia?
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
[quote=“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 ;)[/quote]
Com jgroups não é muito dificil implementar um prevayler distribuido.
[quote=“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.
[/quote]
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.
[quote=“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][/quote]
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.
-
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 !!
-
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 ??!!
-
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 !
-
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 !
-
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
[quote=“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![/quote]
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
[quote=“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.[/quote]
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:
[quote=“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).
[/quote]
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.
[quote=“Daniel Machado”](Vo taca fogo)
… relacional (lembre-se que um objeto é o conjunto Atributos, métodos de acesso e Dados).
[/quote]
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