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:
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.
[quote=“rodolfo_dpk”]
Mas não quero te desanimar, já vi que vc está mesmo convencido então vá a luta e boa sorte !
8)[/quote]
Obrigado, e pode ter certeza que enquanto tiver tempo e não me convencerem do contrário, eu estou tentando.
[quote=“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.
[/quote]
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.
[quote=“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? [/quote]
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.
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.
[quote=“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.
[/quote]
Tá, não quero mais polêmica mas apenas para voltar aos pontos centrais :
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.
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.
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.
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].
[quote=“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 ![/quote]
Gente, eu não tô dizendo que é impossível, ilegal, imoral, etc.mapear nada, eu tô dizendo que:
É uma abordagem que eu não recomendaria
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.
[quote=“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. [/quote]
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…
[quote=“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.[/quote]
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.
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?
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ó 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.
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…
] sobre isso também.