Respostas:
Quais são os prós e os contras de adotar os mecanismos de regras Java JESS e Drools?
Use um mecanismo de regras se precisar separar as regras de negócios da lógica do aplicativo. O artigo Seu projeto precisa de um mecanismo de regras tem um bom exemplo:
Por exemplo, um sistema típico de vitrine pode envolver um código para calcular um desconto:
if (product.quantity > 100 && product.quantity < 500) { product.discount = 2; } else if (product.quantity >= 500 && product.quantity < 2000) { product.discount = 5; } else if (product.quantity >= 2000) { product.discount = 10; }Um mecanismo de regras substitui o código acima por um código semelhante a este:
ruleEngine.applyRules(product);
Cabe a você decidir se colocar um console de administração de regras nas mãos de pessoas não técnicas é uma coisa boa ou não :)
Mais detalhes em Devo usar um mecanismo de regras? , Por que usar um mecanismo de regras? , Algumas diretrizes para decidir se deve usar um mecanismo de regras e no Google .
Existem outros jogadores?
Outros jogadores incluem JRules, Corticon (JRules é o IMO mais famoso - o que não significa o melhor).
como eles se comparam em outras áreas, como facilidade de uso, desempenho, nível de integração com seu código?
Não posso te dizer com precisão, tenho apenas uma pequena experiência (positiva) com Drools. Mas você receberá algum feedback de postagens de blog como JBoss Drools vs ILog JRules - uma história anedótica (certifique-se de lê-la) ou Working with Drools a partir de uma perspectiva JRules . Tenho certeza que você pode encontrar mais deles no Google (mas eu daria uma chance ao Drools).
Estamos avaliando regras agora para uso com nosso servidor de aplicativos. Encontramos OpenRules , que é fácil de integrar com Java e, pelo que nossos testes mostraram, rápido o suficiente. A principal vantagem do OpenRules sobre os outros é a forma como as regras são modificadas e tratadas. Tudo acontece em tabelas do Excel, que é a maneira mais fácil para não programadores. Todos os envolvidos, mesmo os não técnicos, entenderam tudo perfeitamente :-)
Também temos drools integrados, mas as regras são muito mais complicadas de entender, pois é uma abordagem mais programática. É por isso que nós - muito provavelmente - vamos nos ater ao OpenRules.
Tivemos uma pergunta semelhante conosco, finalmente pegamos o Drools, deve-se usar o drools se você tiver o seguinte:
Tenha mais detalhes no seguinte URL
Basta acrescentar que muitas pessoas estão procurando por algo mais parecido com o gerenciamento de certas condições para ativar ou desativar determinados recursos em um aplicativo.
Fiquei cansado de reimplementar o mesmo padrão repetidamente em todos os lugares que eu ia, então decidi fazer um projeto de OSS para ele chamado Roolie http://sourceforge.net/projects/roolie/
Acabei de fazer isso e, como não houve bugs relatados desde 2010, quando foi lançado, atualizei-o para v 1.0 sem alterações além das necessárias para hospedá-lo no Maven Central (que estou em processo de fazer )
Basicamente, a JSR-94 é um exagero para a maioria das coisas, e há uma enorme curva de aprendizado e sobrecarga que acompanham as ofertas atuais. Tudo bem se é isso que você quer. Mas se você deseja apenas encadear regras simples escritas em Java junto com XML para manter seus testes de estado, Roolie é uma maneira muito rápida de fazer isso. Sem dependências e sem curva de aprendizado.
Quando precisávamos de um mecanismo de regras, decidimos lançar o nosso próprio, porque os disponíveis eram muito complicados para nossas tarefas simples. Se você tiver experiência, mesmo que remotamente, com a análise de expressões que os usuários possam usar, isso não é muito difícil de fazer. Em nosso caso, a maioria das especificações é tratada por um XSD e apenas alguns dos campos são analisados posteriormente.