Блог

В настоящее время мое корпоративное приложение работает на Weblogic 10.3.4, Java 1.6 и Spring 2.0.8. Это недавнее обновление, следовательно, Spring еще предстоит обновить, и часть базы кода Java все еще в старом стиле 1.4.

На данный момент мы используем движок propriatory rules engine для запуска наших бизнес-правил. Однако это излишество, поскольку мы не используем ни одну из функций механизма вывода и больше не можем оправдать затраты на лицензию. Планируется написать движок правил, управляемый базой данных.

С каждым запросом формы будет связано любое количество правил, которые будут настроены с использованием нескольких базовых таблиц базы данных.

На данный момент мой проект заключается в том, что каждое правило, определенное в базе данных, будет отображаться через Spring в одноэлементный компонент Spring Bean без состояния. При заданном состоянии формы каждое правило вернет объект respose result. Смотрите фрагмент кода ниже:

  //get List of rules for form from database
 List<RuleConfiguration>  rules = RulesService.getRulesForFormRuleset(formType, filingMethod, rsName, document);

    IssueDocument issues = new IssueDocumentImpl();

     for (RuleConfiguration ruleConfig : rules) {


         //create a rule instance from the Spring Bean Factory
         Rule rule = (Rule) beanFactory.getBean(ruleConfig.getRule().getRuleBeanName());
         RulesIssue issue = rule.runRule(document, ruleConfig);

            if (issue != null)  {  //Issue has been populated rule must have fired
                issues.addNewIssue(issue);
            }
     }

    return issues;
  

Звучит ли это как разумное решение? Я стремился внедрить «легкое» решение, избегающее EJB, поскольку существует более 500 правил, которые в конечном итоге придется написать. Меня больше всего беспокоит то, что, поскольку все это синглтоны и на мой «движок правил» будет большой спрос, нужно ли мне рассматривать какой-то пул компонентов? Любые другие отзывы были бы весьма желательны. Разорвите меня в клочья, если хотите — я могу это принять!

Большое спасибо

Очевидно, что в такого рода вещах есть две основные области работы.

Первый заключается в определении правил для запуска, а второй — в их фактическом выполнении.

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

Далее следует фактическое выполнение. Если все ваши вещи являются одиночными, то вам нужно будет беспокоиться о запуске singleton, безопасности потоков и т.д.

В принципе, просто убедитесь, что каждое из ваших правил имеет жизненный цикл. «запустить», «выполнить», «остановить». Если это настоящий синглтон, которому требуется некоторое состояние от запуска к запуску, то методы start и stop, скорее всего, будут содержать логику. Если для выполнения входных данных требуется всего лишь немного логики, то, вероятно, нет необходимости в start и stop (они могут быть пустыми методами) или вообще в том, чтобы это был синглтон, поэтому просто создайте новый экземпляр, запустите его и выбросьте.

Вы не упоминаете, что такое «правило» с точки зрения логики. Они легко могут быть простыми классами Java, которые следуют этому жизненному циклу. Добавьте аннотацию @SingeletonRule или реализуйте isSingleton, что угодно.

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

Простые системы правил просты.