Archive for the greenbox Category

Pense aqueles momentos que você tem um grande sistema em produção e várias regras de negócios são mudadas devido a movimentos de mercados, ou simplesmente "eventos" internos do seu ERP, como baixa em estoque, ou aumento de vendas, atraso de entregas e etc... Imagine os  tipos de aplicações que sofrem mudanças e compilações diárias devido a suas regras de negócio, vida bastante complicada nao é?

Há um projeto na empresa que deveremos usar alguns agentes inteligentes para evitar recompilação em cenários das regras de negócios devemos usar o JBoss Rules (Drools), para isto, bolei alguns facilitadores para abstrair seu uso, caso num futuro alguém queria usar o Jess, a mudança será natural. O mais interessante, é que já há uma JSR que trata também estas questões de engine de regras (rules) , que é a JSR 094.

Vou aproveitar este post, para dar algumas idéias de arquitetura e design de um mecanismo de execução de regras e alguns exemplos simples. Primeiramente uma interface que encapsula o processamento de regras:

JAVA:
  1. import javax.rules.RuleException;
  2.  
  3. public interface RuleProcessor<r> {
  4.  
  5. public void execute(Object o) throws RuleException;
  6.  
  7. }

Uma classe Abstrata que trata algumas peculiaridades do Drools:

JAVA:
  1. import org.drools.RuleBase;
  2. import org.drools.RuleBaseFactory;
  3. import org.drools.compiler.PackageBuilder;
  4. import org.drools.rule.Package;
  5.  
  6. public class AbstractDroolsRulesExecutor {
  7.  
  8. protected  static RuleBase readRuleBase(String sourceDRL) throws Exception {
  9. //read in the source
  10. Reader source = new InputStreamReader(AbstractDroolsRulesExecutor.class.getResourceAsStream(sourceDRL));
  11. PackageBuilder builder = new PackageBuilder();
  12. builder.addPackageFromDrl( source );
  13. Package pkg = builder.getPackage();
  14. RuleBase ruleBase = RuleBaseFactory.newRuleBase();
  15. ruleBase.addPackage( pkg );
  16. return ruleBase;
  17.  
  18. }

Um executador padrão para regras via Drools.

JAVA:
  1. import javax.rules.RuleException;
  2. import org.drools.WorkingMemory;
  3.  
  4. public class DroolsExecutor extends AbstractDroolsRulesExecutor implements RuleProcessor<object> {
  5.  
  6. public void execute(Object o) throws RuleException {
  7. WorkingMemory wM ;
  8. try {
  9. wM = readRuleBase("/"+o.getClass().getSimpleName()+".drl").newWorkingMemory();
  10. wM.assertObject(o);
  11. wM.fireAllRules();
  12. } catch (Exception e) {
  13. e.printStackTrace();
  14. new RuleException("Falha ao buscar a Regra : " + e.getMessage());
  15. }
  16. }
  17. }

Sendo assim, com base no nome da classe do objeto passado para ser validado, carregamos um arquivo de regras, e ai disparamos todas as regras associadas. Veja a seguir o exemplo do arquivo de regras:

JAVA:
  1. #created on: 15/Fev/2007
  2. package com.cardif.erp.produtos
  3.  
  4. import com.cardif.erp.produtos.Produto;
  5.  
  6. #list any import classes here.
  7.  
  8. #declare any global variables here
  9. rule "Estoque"
  10.  
  11. when
  12. p : Produto( estoque ==0)
  13. then
  14. System.out.print("Estoque Zerado, por favor reveja!");
  15. p.dispatch();
  16.  
  17. end
  18.  
  19. rule "NomeProduto"
  20.  
  21. when
  22. p : Produto( nome  =="Seguro")
  23. then
  24. System.out.print("Para seguros nao posso fazer isso...");
  25. p.dispatch();
  26.  
  27. end

Este arquivo usa uma DSL específica, simples e fácil para codificação, porém podemos criar dicionários baseados na linguagem humana, do tipo:

"envie um email para o {destinatario} quando o estoque for de {risco}"

Imagine que desta forma até seus usuários podem validar suas regras de negócio. Usando as classes que mostrei nesste post, você pode testar as regras de forma extremamente fáceis, veja este exemplo:

JAVA:
  1. Produto pro = new Produto();
  2. pro.setNome("Seguro");
  3. pro.setEstoque(0);
  4.  
  5. DroolsExecutor d = new DroolsExecutor();
  6. d.execute(pro);
  7.  
  8. System.out.println("Executado");

Consegui arrumar um tempo para voltar a me dedicar ao Greenbox, agora de forma mais organizada, pelo menos tudo que estou fazendo já está no CVS ( https://greenbox.dev.java.net/source/browse/greenbox/greenbox4/#dirlist ) .

As atividades de hoje foram simples:

  • Recompilar o Greenbox para NetBeans 5.5
  • Removi a dependência do Commons-Logging, visto que o NetBeans agora possui isto por default, há muito tempo sofria com um erro de Classloader, e resolvi com essa mudança.
  • Otimização de Geração
    • Já que o Plugin e o Framework são módulos bastante distintos, agora estou abusando do uso do poder o NB Platform, para criar os Arquivos agora uso a seguinte estrutura:
    JAVA:
    1. NbUtils.createFile(project,
    2. new String
    3. (getClasse().getPackageName(). replace
    4. ('.','/')),
    5. classe.getClassName()+
    6. ".hbm.xml",hbm);

    • E agora esta é a nova forma de criar um Arquivo:
    JAVA:
    1. public static void createFile(Project project, String path,
    2. String name,String content) throws IOException
    3. {
    4.  
    5. SourceGroup[] sourceGroups =
    6. ProjectUtils.getSources(project).getSourceGroups
    7. (JavaProjectConstants.SOURCES_TYPE_JAVA);
    8. FileObject targetFolder =
    9. sourceGroups[0].getRootFolder();
    10. targetFolder = FileUtil.createFolder
    11. (targetFolder,"/teste");
    12. FileObject target = FileUtil.createData
    13. (targetFolder, name);
    14. FileLock lock = target.lock();
    15.  
    16. try {
    17.  
    18. (target.getOutputStream(lock), "UTF-8"));
    19. bw.write(content); bw.close();
    20.  
    21. }
    22. finally {
    23.  
    24. lock.releaseLock();
    25.  
    26. }
    27.  
    28. }

    Quanto as novas Features:

    Uso de JPA como Annotações

    Usaremos todas as anotações do JPA+Algumas do Greenbox para montar os Casos de Uso Suporte a EJB 3 Usaremos EJB 3 com SessionBeans e Interceptors

    Suporte a Ajax

    Estamos estudando a mais apropriada solução para o Greenbox e seus usuários

    A medida que for melhorando mais coisas estarei reportando aqui! []'s

    A Comunidade JavaTools, criou um desafio, convidou alguns usuários de Eclipse e NetBeans, que aceitaram usar a ferramenta "contrária" por um mês. Tive o prazer de ser um destes usuários, minhas respostas foram super diretas e resumidas, mas mostram quais minhas impressões de 1 mes de uso do Eclipse, leia mais aqui : https://javatools.dev.java.net/newsletter/20061101.html

    Leiam a dica de como fazer isto aqui [inglês]

    Há 2 dias comecei um projeto que o code-nome ainda é GBrails (Greenbox On Rails).

    A inspiração/metáfora vem do RubyOnRails, que é uma ferramente bem produtiva, apesar de alguns problemas de deployment.

    Vários, eu disse váaaaarios usuários questionam, as razões pelas quais o Greenbox roda tao "plugado" no Netbeans, há vários motivos, mas este questionamento comecou aqui mesmo na empresa, onde há pessoas que usam o InteliJ IDEA e o Eclipse.

    Havia um projeto de um desenvolvedor do Greenbox de tornár o que há para o NetBeans, real para o Eclipse, infelizmente o foco dele teve que ser um pouco diferente.

    Bom, resolvi então criar algumas coisas para o mundo Eclipse, pelo menos montar uma forma simples de usar o Greenbox, dentro desta IDE.

    Greenbox OnRails - Requisitos

    1 - Usuário faz o Download de zip ou tar.gz

    2 - Decompacata numa pasta por exemplo /opt/java/gbrails

    3 - A estrutura desta pasta deve ser:
    -build.xml
    -build.properties
    -web [arquivos app web ]
    -src [arquivos fonte ]
    -lib [bibliotecas (*.jar)]
    -gb.sh ou gb.bat [utiliário shellscript e cmd(win)]
    -structure [ pasta contendo a estrutura do projeto com arquitetura JSF+Spring+hibernate]
    -projects [pasta com o projeto com build.xml, libs, src, xmls e etc de base para projetos novos, use a como workspace no eclipse]

    4 - Criando um projeto:

    ./gb.sh create-project locadora =>Resultado: Deve criar uma pasta com nome locadora na pasta projects

    5 - Na pasta project/locadora/src/app/ crie uma classe chamada TipoPagamento.java, e copie o seguinte código:

    CODE:
    1. QEdyZWVuYm94KHRhYmxlTmFtZT0idGlwb19jb250YSIpDQpwdWJsaWMgY2xhc3MgVGlwb0NvbnRhIHs=

    CODE:
    1. DQpAR3JlZW5ib3hGaWVsZChwcmltYXJ5S2V5PSJ5ZXMiLGNvbHVtbk5hbWU9ImNvZGlnbyIsbGFiZWw9IkNvZGlnbyIpDQpwdWJsaWMgSW50ZWdlciBjb2RpZ29Db250YTs=

    CODE:
    1. QEdyZWVuYm94RmllbGQoY29sdW1uTmFtZT0ibm9tZSIsbGFiZWw9Ik5vbWUgZGEgQ29udGEiKSBwdWJsaWMgU3RyaW5nIG5vbWVDb250YTs=

    6 - Agora execute ant gb-generate no seu projeto Eclipse

    7 - Verifique Sources Gerados.

    Basicamente, estes sao os passos do GBRails.

    Basicamente o que fiz foi criar uma nova Task Ant que descente de Javac, e processar as anotacoes dentro desta task, executando os parsers dos templates velocity. O resultado está satisfatório. Uma feature que devo implementar, é um controle de comparacao, para have restrições para evitar geração duplicadas, como NAO acontece na task Javac, devido a um método especial da mesma[1].

    Registrando mais uma vez, que quem quiser receber o beta para realizar testes, basta enviar um e-mail para edgar (em) summa-tech.com , que disponibilizarei um endereco para baixar esse EARLY-ACCESS, cheio de bugs para que vocês ajudem e colaborem com um projeto que pode BENEFICIAR bastante voces.

    []'s

    Edgar

    CODE:
    1. DQpbMV0gIHByb3RlY3RlZCB2b2lkIHNjYW5EaXIoRmlsZSBzcmNEaXIsIEZpbGUgZGVzdERpciwgU3RyaW5nW10gZmlsZXMpIA==

    No último JavaOne (2006), várias pessoas me perguntavam:

    É verdade que quase tudo no Brasil é Gratuito e OpenSource ?

    A resposta quase sempre era: "Sim e as empresas estão convergindo para essa realidade, tanto que venda de produtos hoje no Brasil é uma tarefa ardua e difícil".

    Os jargões ManagedOpenSource ou OpenSource 2.0, servem para muitas empresas justificarem o empacotamento destas soluções e ganharem com serviços. Isso é errado? No meu ponto de vista Não.

    Ora Edgar, então o que é errado então na sua visão?

    Não vejo nada como muito errado, mas uma coisa que é super estranha é capturar vários projetos OpenSource, juntar num NOVO produto, e esse produto ser completamente fechado, vendido e pior: Super Caro! :)

    Pegando um caso como a Summa Technologies, ela possui um framework de produtividade focado em cenários corporativos chamado: Genesis, o qual usa uma séria de frameworks OpenSource, entre eles:

    • AspectWerkz
    • Jakarta Commons
    • XDoclet
    • Ant
    • Thinlet
    • BCEL
    • CODEC e vários outros

    Sendo assim, nada mais justo que o Genesis seja também OPEN SOURCE.

    Caso tão ruim quanto vender, são os FORKS, isso acontece quando você pega um projeto, altera, melhora em seu benefício, e nem ao menos pergunta para os commtters se alguma de suas melhorias podem ser devolvidas a árvore principal. Também a quebra de compatibilidade é uma forma de Fork, ou seja, alterando classes base, impedindo que co-exista com a versão "original" do projeto.

    Atuando como desenvolvedor do Greenbox, eu já passei por situações super complicadas umas 3 vezes no Brasil, com FORKS absurdos, e pior, alguns deles EFETIVAMENTE, muito bons, porém muito longe do CVS do projeto, não prejudicando, mas também não ajudando uma porção de pessoas e empresas na comunidade.

    Tenho que terminar urgentemente o módulo que suporta relacionamentos no Greenbox, pois isso vai pertmitir novas arquiteturas, entre elas:

    • JBoss Seam
    • Wicket + Spring + Hibernate
    • Genesis + JSF

    A mensagem final é: Ganhe o máximo de $$$ que puderes com OpenSource, mas não esqueça dos princípios básicos, que não é ser comunista, mas tentar ajudar, tentar contribuir de alguma forma, seja com testes, documentações, samples, qualquer forma de ajudar é sempre válida! É sempre mais bonito, cortez poder jogar limpo com os desenvolvedores, comunidade e mercado em geral! Pense nisto!

    Olá amigos,

    Agora o GreenboxNB, tem uma feature que permite gerar as os casos de uso sem mecher no web.xml, faces-config ou o spring-context.

    Agora o Greenbox tem um Aquivo de Configuração que é um XML bem simples, e para ler nao usamos nada mais que java.util.Properties, mas em formato XML. Este arquivo vai guardar as referencias de tudo que você gerou no Greenbox, e quem sabe no futuro alguém queira adicionar informações como versões de geração, para documentação ou histórico do projeto(Nota: para quem usa Maven2 tem um goal pra isso ;) ).

    O Arquivo XML é simples e é assim:

    < ?xml version="1.0" encoding="UTF-8"?>
    < !DOCTYPE properties SYSTEM "http://java.sun.com/dtd/properties.dtd">
    
    Use cases generated by Greenbox
    br.com.XXXX.exportacao.produto
    br.com.XXXX.exportacao.marcas
    br.com.XXXX.exportacao.departamentos
    br.com.XXXX.exportacao.subcategoria
    br.com.XXXX.exportacao.categoria
    
    

    Este arquivo ficará dentro da pasta WEB-INF/greenbox/ com o nome usecases.xml , e o Netbeans vai sempre ler esse arquivo para gerar os arquivos isolados para Faces-Config e Spring-Context.

    Sendo assim, agora há um "shared" Spring Context, que contém a definição de DataSource e TransactionManager, além da SessionFactory e todas as referências pros HBM's do Hibernate. Além de um micro-spring-context para o Business Delegate e DAO dos casos de usos, todos separados e independentes.

    Estamos trabalhando forte agora na questão de relacionamento, esses dias vou ver como estão as alterações que o Rodrigo Urubatan , está commitando no CVS para promover isto também no Plugin, de fato fica simples no hibernate, e nosso desejo é tornar tao simples quanto eram os:

    DBLookupComboBox do bom, velho e saudoso Delphi :D

    []'s e boa semana!

    ps-Quem for pro sul esses dias... Lá está frio pra valer... Haja coberta, roupa e uma boa companhia .

    Esse link é super útil, ainda mais para pessoas "nao" apaixonadas por Hibernate como eu:

    http://www.xylax.net/hibernate/index.html

    Ele mostra as questoes de relacionamentos.

    Útil para eu fazer isto uma e somente uma vez no greenbox e nuca mais me preocupar.

    []'s
    Ed

    O Greenbox ganhou um grande desenvolvedor para o Kernel e que está fazendo além de melhorias no Framework.
    Leia este texto super interessante aqui:Leia Aqui

    No Greenbox, quando você for melhorar ou recriar um caso de uso baseado nas anotações, quando você clicar no botão "Generate Sources" ele vai analisar os arquivos a serem gerados com os que já estão nos disco, e vai lhe perguntar se você quer aproveitar suas mudanças, ignorar, ou seja, o famoso módulo de diff, veja abaixo um screenshot disto rodando:

    Diff

    Isto estará disponível no BETA 4, lembrando que este BETA poderá ser rodando no NetBeans 5.0, 5.5 e 6.0

    Para quem quiser realizar o download do BETA 3:

    Clique aqui