Как и стоит ли интегрировать Java Webapp + drools + Guvnor?

Ответ 1

Я делаю что-то похожее на то, что вы хотите сделать.

Поскольку эти бизнес-правила будут очень часто выполняться бизнесом, я бы хотел, чтобы бизнес внес необходимые изменения в правила с помощью графического интерфейса.

ПРЕДУПРЕЖДЕНИЕ ПРЕДУПРЕЖДЕНИЕ!!! Это распространенное заблуждение, что до тех пор, пока есть GUI, не-программисты могут его использовать. Это... не вывод, к которому я пришел. Это помогает, но сложная часть программирования - это не написание кода, а придумывание хороших решений для правильных проблем. Я уверен, что некоторые из более умных и технически настроенных деловых людей могут делать что-то с Guvnor, но не ожидайте, что это будет какая-то желтая кирпичная дорога в Страну Магического Блаженства. Вы по-прежнему должны предоставлять деловым людям разумную модель данных и API, которые позволяют им делать то, что им нужно, но которые мешают им делать случайно то, что они не хотят делать.

1. Поддерживает ли Drools легкий графический интерфейс для редактирования правил?

2. Является ли Drools Guvnor легким графическим интерфейсом или есть способ сделать это?

Ну, "легкий" обсуждается, но Guvnor работает достаточно хорошо и не требует больше, чем браузер, поэтому я думаю, что все в порядке.

3. Как легко интегрировать приложение в Guvnor для чтения правил?

Хорошо, как только вы запустите Guvnor и подключитесь к вашему приложению, чтобы использовать KnowledgeAgent для подключения к Guvnor и прослушивания новых обновлений правил, это не особенно сложно.

К сожалению, у Drools вообще и Guvnor, в частности, есть куча причуд, которые вам, возможно, придется обойти (например, вам нужно взорвать файл WAR Guvnor и отредактировать файлы в WEB-INF/ beans.xml, чтобы настроить нестандартную конфигурацию...). Но как только вы это выпрямились, я думаю, что это работает очень хорошо.

Что касается документации, Javadocs может быть немного редкими время от времени, но веб-сайт имеет довольно неплохие вещи и включает в себя несколько книг.

В общем, Drools и Guvnor - мощные инструменты, но это не так, чтобы заставить их работать. Если вам действительно нужно то, что они могут предложить, они того стоят, но также стоит подумать, достаточно ли простого решения для сценариев.

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

Приложение, над которым я работаю, использует JPA для работы с базой данных, и было бы не очень приятно использовать эту модель данных в наших правилах. Несколько причин:

Что подходит вашему слою данных, не обязательно подходит для Drools и наоборот.

У нас есть древовидная структура, которая в JPA, естественно, является отношением @OneToMany с дочерними элементами в списке в родительском node. Работа со списками в Drools была довольно болезненной, поэтому мы сгладили ее до структуры, в которую мы вставляем один объект ParentNode и кучу объектов ChildNode, с которыми было гораздо легче работать.

Откажитесь от рефакторинга.

Модель данных правил также должна жить внутри Guvnor, и это означает, что вы можете нарушить все правила, если вы переименуете класс сущности или что-то в этом роде. Отдельная модель данных для правил означает, что вы можете без проблем реорганизовать базу данных.

Покажите им, что им нужно видеть.

Базы данных могут расти довольно сложно, но правилам обычно не нужно заботиться о многих из этих сложностей. Предоставление этих сложностей правилам редактирования людей может вызвать много лишней путаницы. Например, мы обнаружили, что для наших сценариев абсолютно нет необходимости подвергать писателей правил отношениям "многие ко многим" (которые очень сложно обрабатывать в Drools), поэтому мы делаем их похожими на "один ко многим", и все становится более естественным.

Защита.

Мы разработали большинство наших правил для работы как этот псевдокод:

rule "Say hello to user"
when 
  user : User
then
  insert(new ShowMessageCommand("Hello " + user.getName() + "!"))
end

... и поэтому для каждого пакета правил он четко определил, какие команды ответа вы можете вставить, и что они делают. После того, как мы запустили правила в нашем приложении, мы выбираем объекты, вставленные в сеанс по правилам, и действуем на них (шаблон оказалось очень полезным избежать длинных цепочек if instanceof/else if instanceof/else).

Я очень рад, что мы сделали это таким образом, вместо того, чтобы позволить авторам правил делать то, что они думают, что они хотят делать с нашими объектами JPA.

В любом случае, надеюсь, что это поможет.

Ответ 2

Вышеприведенный ответ хорошо объяснен. Но о том, как интегрировать Java и Drools-Guvnor, является следующее:

private static KnowledgeBase readKnowledgeBase() throws Exception {
KnowledgeAgent kagent = KnowledgeAgentFactory
        .newKnowledgeAgent( "MortgageAgent" );
kagent.applyChangeSet( ResourceFactory
        .newClassPathResource( "changeset.xml" ) );
KnowledgeBase kbase = kagent.getKnowledgeBase();
kagent.dispose();
return kbase;
}

<?xml version="1.0" encoding="UTF-8"?>
<change-set xmlns='http://drools.org/drools-5.0/change-set'
    xmlns:xs='http://www.w3.org/2001/XMLSchema-instance'
    xs:schemaLocation='http://drools.org/drools-5.0/change-set drools-change-set-5.0.xsd'>
  <add>
    <resource
  source='http://localhost:8080/guvnor-webapp/org.drools.guvnor.Guvnor/package/mortgages/LATEST'
  type='PKG' basicAuthentication='enabled' username='admin' password='admin' />

  </add>
</change-set>

Надеюсь, что это также полезно.