Бизнес-правила. Размещение бизнес-правил (защита данных, целостность данных, централизованное управление данными, распределение работ) на сервере и клиенте.

Сервер исполнения бизнес правил (англ. Business Rule Engine - движок исполнения бизнес-правил) — компонент системы управления бизнес-правилами предприятия, в функции которого входит выполнение правил. Он предоставляет сервисы принятия решений, которые могут вызывать внешние приложения.

Современные сервера исполнения бизнес-правил обеспечивают:

· горячее развертывание правил

· исполнение правил

· публикацию наборов правил в виде веб-сервисов или других интерфейсов

· сбор статистики по выполнению правил

· управление наборами правил

· высокую производительность и масштабируемость

Частным случаем сервера исполнения бизнес-правил является продукционная система.

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

Основные вендоры на рынке BRE

· G2 Rule Engine Platform

· InRule Business Rule Engine

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

· Кроме того, для описания серверных бизнес-правил в наиболее типичных ситуациях (как в примере с заказчиками и заказами) существуют весьма удобные инструменты - так называемые CASE-средства (CASE означает Computer-Aided System Engineering), позволяющие описать подобные правила, и создавать реализующие их объекты базы данных (индексы, триггеры), буквально рисуя мышью связи между таблицами без какого бы то ни было программирования. В этом случае клиентское приложение будет избавлено от значительной части кода, связанного с реализацией бизнес-правил непосредственно в приложении. Отметим также, что часть кода, связанного с обработкой данных, также может быть реализована в виде хранимых процедур сервера, что позволяет еще более "облегчить" клиентское приложение, а это означает, что требования к рабочим станциям могут быть не столь высоки. Это в конечном итоге удешевляет стоимость информационной системы даже при использовании дорогостоящей серверной СУБД и мощного сервера баз данных.

· Из личного опыта могу сказать, что бизнес-логику надо держать в одном месте: или на сервере, или на клиенте.

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

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

Такой проблемы нет, если держать все бизнес-правила на сервере, но тут тоже есть определенные проблемы.

Есть третий путь: создание трехуровневого приложения, в котором все бизнес-правила выполняются на неком сервере приложений.

· Для начала - что такое бизнес-логика? Это очень размытое определение, в которое вкладывается всё, что не удалось реализовать в виде табличек в БД. Лично мне кажется куда более логичным разделение БЛ на 2 части - логику доступа к данным и логику поведения наших объектов.

Вторая часть БЛ должна располагаться на клиенте (мы говорим о толстом клиенте, не так ли?).

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

Теперь шаг 2. Раз мы решили держать часть логики на клиенте, нам потребуется обновлять клиентов, и вести лог, чтобы определить причины падения клиента (а падения будут). То есть нам потребуются некоторые системные сервисы, которые, опять-таки должны располагаться на стороне клиента

Шаг три. Теперь разберёмся с логикой доступа к данным. Если мы делаем хоть чуть-чуть безопасную систему, нам надо сделать так, чтобы люди не лазили туда, куда им не надо - это раз, и два - возможность отслеживать критические изменения. То есть требуется система аутиентификации, что влечёт за собой разработку утилиты администрирования - пользователями-то надо как-то рулить, не так ли?

Кроме того, нам потребуется ещё и поддержка транзакций - мы же не хотим всяких ghost rows и helloween trouble, так? То есть, чтобы не изобретать велосипед, нам потребуется серьёзная СУБД с поддержкой транзакций, системой безопасности и прочими приятными мелочами.

Шаг четыре. Для того, чтобы использовать систему безопасности, нам нужно создать объекты, к которым мы будем разрешать/запрещать доступ. То есть, нам понадобытся хранимые процедуры.

Итак. С одной стороны, мы имеем обновляемого толстого клиента, на котором хранится логика поведения объектов, с другой - мощную субд с действующей системой безопасности и действиями типа CRUD, распиханными по хранимкам. Теперь объясните мне, накуда при такой архитектуре нужен апп-сервер, и что он будет делать?

49 Двухуровневая модель «клиент-сервер: модель файлового сервера (File Server — FS); модель удаленного доступа к данным (Remote Data Access—RDA); модель сервера базы данных (DataBase Server — DBS); модель сервера приложений (Application Server — AS).

Не нашли, что искали? Воспользуйтесь поиском: