Является ли Drools наиболее эффективным способом сопоставления бизнес-правил/логики?

Question

В нашем проекте мы должны реализовать бизнес-логику относительно сопоставления определенных объектов с некоторыми действиями. У нас будет ряд условий для определенных типов объектов, которые будут проверены до того, как окончательное решение будет разрешено. Другими словами, для 7 типов объектов мы можем иметь ряд действий (из почти 45 действий).

Мы подумывали использовать Drools для записи вышеупомянутых правил. У кого-нибудь есть положительный/отрицательный опыт использования Drools в отношении его эффективности? Существует также структура jBPM, которая может быть использована (если я не ошибаюсь, там используются Drools) - кто-нибудь знаком с этой структурой? Возможно, у вас есть другие идеи о том, как решить проблему?

Answer 1

Что касается эффективности, у вас не должно быть проблем с Drools. Это звучит как довольно сложный набор фактов и правил для меня. Механизм Rete, на котором он основан, почти наверняка быстрее принимает решения, чем любая команда if-then-else, которую вы сами кодируете. И особое преимущество, которое я заметил, заключается в том, что время отклика чрезвычайно предсказуемо.

Очевидно, что все модели фактов и правила различаются, но в качестве примера приложение, которое я сейчас создаю, содержит сотни фактов в рабочей памяти в любое время и более 1000 правил. Он способен принимать решения о входящих запросах примерно за 20 миллисекунд.

Полная структура jBPM не является необходимой для того, что вы описываете. Тем не менее, это хорошо, что он делает. Например, есть графический интерфейс моделирования процессов, если вы хотите разработать рабочие процессы, и Guvnor может использоваться для авторов нетехнических правил, если техническая команда прилагает некоторые усилия для написания DSL и построения таблиц решений.

Для полноты основных конкурентов, вероятно, являются FICO Blaze Adviser или IBM ILog JRules. Обычно, когда дело доходит до контрольных показателей, они, как правило, немного опережают Drools, но они дороги. По общему признанию, если вы решите заплатить за контракты на обслуживание JBoss/RedHat, то это не сильно отличается, но если вы счастливы принять поддержку сообщества на Drools, тогда это бесплатно!

Answer 2

Моя единственная забота о Drools заключается в том, что для нее нет достойного графического интерфейса, который действительно могут использовать люди, не связанные с ИТ. Многие продукты утверждают, что они предоставляют такой интерфейс, но это всегда оказывается не совсем правдой. Таким образом, вы должны признать тот факт, что ваша команда разработчиков закончит создание и тестирование всех этих правил на основе таблиц решений или некоторых других форматов.

Помимо этого, Drools является отличным BRE, используемым правительствами, банками и крупными компаниями.

Answer 3

Drools очень эффективный и быстрый. Но, как и для любой технологии &, она потребует инвестиций для интеграции в ваш проект, и это не волшебная пуля. Вы должны учитывать:

• Сколько у вас правил? Я бы не рекомендовал ни одного механизма правил, если существует менее 20 правил. Это может не оправдать усилия, которые вы потратите на сложность добавления механизма правил только для 7 объектов и 45 действий ...
• Вам нужны функции DSL (Domain Specific Language)? То есть. будут ли нетехнические люди писать правила? IMHO это не очень удобно в Drools по сравнению, например. Oracle OPA. Но опять же я не видел, чтобы нетехнический человек благополучно возился с системой правил. Помимо изменения значений в таблице решений.
• Как часто изменяются ваши правила? Если вам нужна централизованная система для управления, версии, пакета, проверки ваших правил, то Drools Guvnor - очень способный продукт.

Answer 4

jBPM не является двигателем правил, это механизм рабочего процесса. Drools - это механизм правил. Так что Drools - это то, что вы ищете.

Drools и jBPM - это сопутствующие проекты: они прекрасно интегрируются, если вам нужны рабочие процессы с правилами.

Drools - хорошая скважина JBPM немного сложна по сравнению с другими двигателями BPMN. Я бы предложил пойти на Activiti, потому что это немного легче, и интеграция чего-либо говорит Spring, LDAP и т. Д .; с Activiti проще. Также вы можете интегрировать Drools с Activiti .. так что идите на Activiti в качестве механизма aworkflow и Drools для механизма правил.