Ответы:
Каковы плюсы и минусы внедрения механизмов правил Java JESS и Drools?
Используйте механизм правил, если вам нужно отделить бизнес-правила от логики приложения. В статье « Нужен ли вашему проекту механизм правил» есть хороший пример:
Например, типичная система витрины может включать код для расчета скидки:
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; }Механизм правил заменяет приведенный выше код, который выглядит следующим образом:
ruleEngine.applyRules(product);
Вам решать, хорошо ли отдавать консоль администратора правил в руки нетехническим людям :)
Дополнительные сведения см. В разделе «Следует ли мне использовать систему правил?» , Зачем использовать систему правил? , Некоторые рекомендации по выбору использования системы правил и в Google .
Есть ли другие игроки?
Среди других игроков - JRules, Corticon (JRules - самый известный IMO, что не означает, что он лучший).
как они сравниваются в других областях, таких как простота использования, производительность, уровень интеграции с вашим кодом?
Не могу сказать точно, у меня лишь небольшой (положительный) опыт работы с Drools. Но вы получите обратную связь из сообщений в блогах, таких как JBoss Drools против ILog JRules - анекдотический рассказ (обязательно прочтите его) или Работа с Drools с точки зрения JRules . Я уверен, что вы можете найти больше из них в Google (но я бы попробовал Drools).
Сейчас мы оцениваем правила для использования с нашим сервером приложений. Мы столкнулись с OpenRules , которые легко интегрируются с Java и, как показало наше тестирование, достаточно быстро. Основное преимущество OpenRules над другими - способ изменения и обработки правил. Все это происходит в таблицах Excel, что является самым простым способом для непрограммистов. Все участники, даже нетехнические люди, все прекрасно понимали :-)
Мы также интегрировали слюни, но правила сложнее понять, поскольку это более программный подход. Поэтому мы, скорее всего, будем придерживаться OpenRules.
У нас был аналогичный вопрос с нами, мы, наконец, выбрали Drools, следует использовать слюни, если у вас есть следующие:
Более подробная информация по следующему URL-адресу
Просто добавлю, что многие люди ищут что-то более похожее на управление выполнением определенных условий для включения или отключения определенных функций в приложении.
Мне надоело заново реализовывать один и тот же шаблон везде, куда бы я ни пошел, поэтому я решил создать для него проект OSS под названием Roolie http://sourceforge.net/projects/roolie/
Я просто изучил его, и поскольку с 2010 года, когда он был выпущен, не было сообщений об ошибках, я обновил его до версии 1.0 без каких-либо изменений, кроме тех, которые необходимы для его размещения в Maven Central (что я сейчас делаю ).
По сути, JSR-94 является излишним для большинства вещей, и есть огромная кривая обучения и накладные расходы, которые связаны с текущими предложениями. Ничего страшного, если ты этого хочешь. Но если вы просто хотите связать простые правила, написанные на Java, вместе с XML для поддержки ваших тестов состояния, Roolie - очень быстрый способ сделать это. Никаких зависимостей и никакой кривой обучения.
Когда нам понадобился движок правил, мы решили применить свои собственные, потому что доступные правила были слишком сложны для наших простых задач. Если у вас есть хотя бы отдаленный опыт синтаксического анализа выражений, которые могут вводить пользователи, это не очень сложно сделать. В нашем случае большая часть спецификации обрабатывается XSD, и только некоторые поля анализируются дальше.