No texto-base do Merlin, tive que deixar de fora o tema do sistema de configuração baseada em histórico, visto que a complexidade é (e sempre foi) muito grande.
Para se ter uma idéia das coisas envolvidas, o glossário do projeto (sempre em construção), aborda temas como Distanciamento Temporal, Espacial e Relativo de classes. São coisas - e até eu concordo - bem malucas :)
Sempre pensei que esse fosse o ponto mais complicado do framework. Embora eu tenha muito bem definido suas premissas, e suas heurísticas sejam muito bem aceitas (quando corretamente explicadas) pelos ouvintes em fóruns, apresentações e/ou conversas de bar, o fato é que implementá-las sempre foi um desafio.
Minha idéia inicial, após muito fritar os neurônios, foi usar um esquema semelhante aos validadores de beans, os que me constam apareceram pela primeira vez no Hibernate Validator.
Entretanto, tive que fazer adaptações, visto que o Merlin deve suportar quaisquer anotações, ou seja, mesmo aquelas que não foram projetadas para ele. Assim, o simples uso do conceito de validadores (como no Hibernate Validator, e agora na JSR 303), não seria aceitável.
Embora a solução atual, chamada de Resolvers, funcione a contento, o fato é que eles deveriam se preocupar ainda como todo o esquema de "entendimento" do histórico de configurações para, então, resolverem (desculpem o trocadilho) as anotações.
JBoss Rules, a centelha
Nesta semana, mais precisamente na tarde da segunda-feira, de alguma forma, o JBoss Rules me veio à cabeça, e decidi dar uma olhada mais a fundo nele. A ficha caiu.
Todo o esquema de regras de tradução dos beans na IU no Merlin pode ser feito com base no JBoss Rules, ou simplesmente, Drools.
Isso ocorre porque, conforme as complexidades das regras de tradução aumentam, a tendência que ocorram conflitos entre elas aumenta exponencialmente. Colocar um caption à esquerda ou acima de um controle pode depender de inúmeras variáveis e condições do contexto de execução. O Drools resolve isso.
O Velho Modelo ECA Simplificado
O modelo ECA (Evento, Condição, Ação) já é bem conhecido, fazendo parte de frameworks gráficos MVC e outros. Para quem programa em Swing, vai o exemplo:
public actionPerformed(Event event) {
if (user.getUserName().equals("joao")) {
System.out.println("O nome é João");
}
Nesse código acima, o evento (E) ocorreu em um controle na tela. Nesse momento, uma condição (C) é testada e, caso ela seja verdadeira, uma ação (A) é executada. Eis o modelo ECA.
O JBoss Rules, usa algo bem parecido, até mais simples: When Then. Veja o exemplo:
rule "João clicou num controle"
when $user.name == "joao"
then System.out.println("o nome é João")
Simples, não?
Vantagens
Nesse pequeno exemplo, já se percebe a clareza da programação, a qual se assemelha muito à Expression Language (EL) ou Groovy. Para exemplos mais avançados, o usuário vai perceber uma analogia muito grande com a Object Constraint Language (OCL) e outras linguagens de mais alto nível.
Mas tudo isso não é nada se comparado às capacidades do kernel de inferência da ferramenta, o qual é baseado nos trabalhos de Charles Forgy lá nos idos de 1974, onde ele definiu as basas do algoritmo RETE.
Em palavras simples, esse algoritmo é responsável por computar a panacéia de regras (muitas conflitantes entre si) em grafos de objetos (que são a base de dados do Drools) e eleger a regra a ser executada. Traduzindo em miúdos, é este kernel de inferência que acha e resolve as heurísitcas que o Merlin tanto defende.
Conclusões
Não entrei em detalhes do Drools, e nem pude ler um artigo completo ainda. Mas vou colocar no Jira um espaço de horas para identificar melhor seus atributos e fazer os testes necessários.
Obviamente temos drawbacks, como deixar de usar Java nativo para criação das regras - uma coisa que eu não queria. Mas imagino que essas regras podem ser definidas e viculadas através de classes adaptadoras e, logo, é provável que isso não represente um excessivo impacto.
O Drools é bem servido de ferramentas e a duplinha JBoss/Red Hat está por trás. Sendo assim, nada mais justo que confiar nos caras e especular mais sobre o assunto. E é o que iremos fazer.
Para se ter uma idéia das coisas envolvidas, o glossário do projeto (sempre em construção), aborda temas como Distanciamento Temporal, Espacial e Relativo de classes. São coisas - e até eu concordo - bem malucas :)
Sempre pensei que esse fosse o ponto mais complicado do framework. Embora eu tenha muito bem definido suas premissas, e suas heurísticas sejam muito bem aceitas (quando corretamente explicadas) pelos ouvintes em fóruns, apresentações e/ou conversas de bar, o fato é que implementá-las sempre foi um desafio.
Minha idéia inicial, após muito fritar os neurônios, foi usar um esquema semelhante aos validadores de beans, os que me constam apareceram pela primeira vez no Hibernate Validator.
Entretanto, tive que fazer adaptações, visto que o Merlin deve suportar quaisquer anotações, ou seja, mesmo aquelas que não foram projetadas para ele. Assim, o simples uso do conceito de validadores (como no Hibernate Validator, e agora na JSR 303), não seria aceitável.
Embora a solução atual, chamada de Resolvers, funcione a contento, o fato é que eles deveriam se preocupar ainda como todo o esquema de "entendimento" do histórico de configurações para, então, resolverem (desculpem o trocadilho) as anotações.
JBoss Rules, a centelha
Nesta semana, mais precisamente na tarde da segunda-feira, de alguma forma, o JBoss Rules me veio à cabeça, e decidi dar uma olhada mais a fundo nele. A ficha caiu.
Todo o esquema de regras de tradução dos beans na IU no Merlin pode ser feito com base no JBoss Rules, ou simplesmente, Drools.
Isso ocorre porque, conforme as complexidades das regras de tradução aumentam, a tendência que ocorram conflitos entre elas aumenta exponencialmente. Colocar um caption à esquerda ou acima de um controle pode depender de inúmeras variáveis e condições do contexto de execução. O Drools resolve isso.
O Velho Modelo ECA Simplificado
O modelo ECA (Evento, Condição, Ação) já é bem conhecido, fazendo parte de frameworks gráficos MVC e outros. Para quem programa em Swing, vai o exemplo:
public actionPerformed(Event event) {
if (user.getUserName().equals("joao")) {
System.out.println("O nome é João");
}
Nesse código acima, o evento (E) ocorreu em um controle na tela. Nesse momento, uma condição (C) é testada e, caso ela seja verdadeira, uma ação (A) é executada. Eis o modelo ECA.
O JBoss Rules, usa algo bem parecido, até mais simples: When Then. Veja o exemplo:
rule "João clicou num controle"
when $user.name == "joao"
then System.out.println("o nome é João")
Simples, não?
Vantagens
Nesse pequeno exemplo, já se percebe a clareza da programação, a qual se assemelha muito à Expression Language (EL) ou Groovy. Para exemplos mais avançados, o usuário vai perceber uma analogia muito grande com a Object Constraint Language (OCL) e outras linguagens de mais alto nível.
Mas tudo isso não é nada se comparado às capacidades do kernel de inferência da ferramenta, o qual é baseado nos trabalhos de Charles Forgy lá nos idos de 1974, onde ele definiu as basas do algoritmo RETE.
Em palavras simples, esse algoritmo é responsável por computar a panacéia de regras (muitas conflitantes entre si) em grafos de objetos (que são a base de dados do Drools) e eleger a regra a ser executada. Traduzindo em miúdos, é este kernel de inferência que acha e resolve as heurísitcas que o Merlin tanto defende.
Conclusões
Não entrei em detalhes do Drools, e nem pude ler um artigo completo ainda. Mas vou colocar no Jira um espaço de horas para identificar melhor seus atributos e fazer os testes necessários.
Obviamente temos drawbacks, como deixar de usar Java nativo para criação das regras - uma coisa que eu não queria. Mas imagino que essas regras podem ser definidas e viculadas através de classes adaptadoras e, logo, é provável que isso não represente um excessivo impacto.
O Drools é bem servido de ferramentas e a duplinha JBoss/Red Hat está por trás. Sendo assim, nada mais justo que confiar nos caras e especular mais sobre o assunto. E é o que iremos fazer.
Nenhum comentário:
Postar um comentário