| Autor |
Mensagem |
|
|
Rodolfo,
Primeiro, deixa eu pedir desculpas publicamente pelo post mal-humorado de ontem [deu pra perceber que não tem nenhuma carinha?  ]. 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...
rodolfo_dpk wrote:
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).
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 wrote:
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.
rodolfo_dpk wrote:
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 ?
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.
rodolfo_dpk wrote:
Ô 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).
No meu FAQ Troncho:
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.
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.
rodolfo_dpk wrote:
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. Não faço mais isto, tá bem ?
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.
rodolfo_dpk wrote:
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.
Eu sei que dá trabalho, por isso pretendo reutilizar J2EE/EJB.
rodolfo_dpk wrote:
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.
rodolfo_dpk wrote:
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.
Ok, isto eu entendi e tal, e estamos debatendo.
rodolfo_dpk wrote:
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.
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?
rodolfo_dpk wrote:
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 ?
Pois é, mais um motivo para me envergonhar...
rodolfo_dpk wrote:
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.
Meu gerente que diga... por que será que ele tá com essa cara feia me olhando... ihhhh...
[]s
|
 |
|
|
Cv,
cv wrote:
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).
Uhum. É aquela questão: funcionar funciona, mas...
cv wrote:
Resumindo ainda mais, nos queremos fazer com que o OR fale com o OO, ao inves de falar com o R.
esta é minha idéia #1
cv wrote:
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.
Kct, cv, muda de metáfora que esse negócio de galinha eu tô fora!
cv wrote:
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.
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.
cv wrote:
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.
É 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.
cv wrote:
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.
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"...
cv wrote:
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!
Vou me manter calado porque vergonhosamente já li sobre AOP e IoC *muito* menos do que deveria.
[]s
|
|
|
|
rodolfo_dpk wrote:
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".
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.
rodolfo_dpk wrote:
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.
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.
rodolfo_dpk wrote:
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.
Vou ficar devendo o comentário pq este pattern eu não conheço.
rodolfo_dpk wrote:
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 !
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á:
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?
rodolfo_dpk wrote:
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...
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 " target="_new" rel="nofollow"> http://www.google.com.br/search?q=%22impedance+mismatch%22
rodolfo_dpk wrote:
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.
Pois é, EJBs são problemáticos, principalmente CMP. Estamos criando algo chamado Cereal para tentar melhorar isso...
rodolfo_dpk wrote:
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...
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 wrote:
Mas não quero te desanimar, já vi que vc está mesmo convencido então vá a luta e boa sorte !
Obrigado, e pode ter certeza que enquanto tiver tempo e não me convencerem do contrário, eu estou tentando.
[]s[/url][/code]
|
|
|
|
mcampelo wrote:
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...
|
|
|
|
Oi, Rodolfo,
rodolfo_dpk wrote:
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
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.
rodolfo_dpk wrote:
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 !!
Acho que está havendo uma confusão: o Cereal não seria o COntainer EJB, ams sim uam camada de persistência.
rodolfo_dpk wrote:
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 ??!!
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!].
rodolfo_dpk wrote:
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 !
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.
rodolfo_dpk wrote:
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 !
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!].
|
|
|
|
|
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...
|
|
|
|
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
|
|
|
|
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]
|
|
|
|
|
|