Я пишу презентацию о технологии двигателей правил, в частности JBoss Drools.
Каковы некоторые из "мифов" о механизмах правил.
Я могу подумать, что он позволяет бизнес-пользователям контролировать механизм правил, я считаю, что это возможно, но для этого требуется контроль и образование, и не все бизнес-пользователи могут это сделать.
Вы согласны/не согласны? У кого-нибудь еще есть мысли?
С удовольствием опубликую мои заключительные "выводы" в Creative Commons...
Я не знаю о мифах, но я согласен с тем, что соблюдение правил ведения бизнеса не является препятствием.
Я думаю, что ожидая, что деловые люди получат терпение и внимание, уделяя внимание деталям, необходимым для работы на ИТ, - это фантазия. Он был в игре с тех пор, как языки 3G (графические подходы к программированию) были предложены как способ заставить секретарей писать код, чтобы все программисты могли быть уволены.
Я бы отметил, что по мере увеличения размера набора правил вероятность того, что он будет исправлен и самосогласован, снизится. Если ваш набор правил содержит тысячи правил, это будет трудно проверить.
Говоря об этом, комбинаторный взрыв комбинаций затруднит проверку механизма правил.
Двигатели правил - потрясающая технология, но будьте осторожны.
На самом деле, сильно используя слюни, я не согласен с вами в отношении пользователей, которые легко могут делать вещи, я думаю, что это довольно тривиально, чтобы предоставить пользователям простой интерфейс для генерации мощных правил динамически.
Один, который я обязательно добавлю в список:
Миф: двигатели правил медленны!
Не так, опять же, я пропустил даже тысячи событий в секунду с помощью слюни довольно легко.
Другой, который я совершенно ненавидел, был:
Миф: он слишком тяжелый и сложный для использования.
Глупость, синтаксис тривиальна и с несколькими строками java, вы можете сделать некоторые действительно фанки! Извините, если это похоже на напыщенность, были месяцы этого дерьма у предыдущего работодателя, поскольку я пытался внедрить эту технологию!
Мифы...
1/Бизнес-пользователи могут:
правила автора
развернуть их
протестировать их
запустите их
Без помощи ИТ... Я поставил тренинг для клиента, который на самом деле думал, что это правда, потому что продавец сказал так... ах ах ах они сделали мой день/месяц/год!!!
Можете ли вы серьезно подумать о компании, которая будет рисковать для развертывания службы в задней части ИТ-команды? нет!
Вам также нужна безопасность, чтобы я не написал правило:
если имя клиента "Damien", то скидка 100% - groovy baby!
Архитектура проекта не может быть выполнена нетехническими пользователями
2/Вы можете легко управлять проектом правил, не беспокоясь ни о чем.
Существует ограничение количества правил, с которыми вы можете иметь дело. Теоретически можно иметь столько правил, сколько они хотят, но это не совсем правильно.
JRules останавливает синхронизацию правил между Eclipse и RTS примерно с 3000 правил.
Это займет навсегда, если у вас есть проект с 100 000 правил, все в RETE. Построение дерева займет много времени. Даже в последовательном режиме требуется много времени.
Вы не можете использовать репозиторий правил, например папку "Мои документы", и просто продолжайте добавлять правила.
3/Бизнес-пользователи могут писать все виды правил без какой-либо подготовки.
Разные вещи:
a/порядок условий может повлиять на производительность.
b/некоторые правила сложны и нуждаются в хорошем понимании языка
c/используемый алгоритм может повлиять на результат выполнения
d/одно плохо написанное правило может умножить время выполнения на n.
Я работал над проектом, в котором за некоторые случайные таймауты отвечало только 1 правило.
e/Некоторая сложная проблема может быть выражена в одном правиле.
Эта проблема решается в одном правиле и имеет один результат:
<Я > Есть четыре гольца, стоящих за чаем, на линии слева направо.
- Гольфист к непосредственному праву Фредса одет в синие штаны
- Джо второй в очереди
- Боб носит брюки из пледа
- Том не в положении один или четыре, и он не носит оранжевые штаны
BTW: Это пример JBoss.
Как бизнес-пользователь может это сделать?
4/Механизм правил может выполнять обратную цепочку
Я думаю, что JBoss говорит, что может, но я не уверен в этом. Blaze и JRules не могут.
5/Для написания правил не нужен какой-либо язык программирования.
Правильно, но вам понадобятся некоторые для выполнения правил. Кроме того, если вы используете простой XSD в качестве объектной модели. Но ваша Служба принятия решений не будет делать так много умной вещи.
6/Это медленнее, чем JAVA
Конечно, но, используя BRMS, вы нарушаете бизнес-логику, поэтому она имеет стоимость.
Точно так же, как при экстернализации данных. Вызов базы данных имеет стоимость.
Я отправил 5000 рабочих мест в рабочую память JRules с проектом, содержащим 4 фиктивных правила, которые вызывали друг друга... Цель теста производительности
Результат: 19 миллионов правил, выполненных за 75 секунд. Сделайте свою математику... это не так медленно.
7/Вы можете сделать что-нибудь в правиле
Не делайте запрос базы данных в правиле (особенно в условиях). Используя Rete, теоретически правило может "протестировать" условие, чтобы найти результат сопоставления в памяти тысячи раз.
Никто не хочет вызывать базу данных, которая много в приложении.
Надеюсь, что это поможет.