Бизнес-правила. Размещение бизнес-правил (защита данных, целостность данных, централизованное управление данными, распределение работ) на сервере и клиенте.
Сервер исполнения бизнес правил ( англ. 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, распиханными по хранимкам. Теперь объясните мне, накуда при такой архитектуре нужен апп-сервер, и что он будет делать?
Двухуровневая модель «клиент-сервер: модель файлового сервера (File Server — FS); модель удаленного доступа к данным (Remote Data Access—RDA); модель сервера базы данных (DataBase Server — DBS); модель сервера приложений (Application Server — AS).
Двухуровневые
модели.
Эти
модели фактически являются распределением
пяти указанных функций между двумя
процессами, которые выполняются на двух
платформах - клиенте и сервере.
Модель
удаленного управления данными (модель
файлового сервера).
В
этой модели BL и PL располагаются на
клиенте. На сервере располагаются файлы
с данными и доступ к ним. Функции
управления информационными ресурсами
в этой модели находятся на клиенте.
Модель
файл-сервера.
В
этой модели файлы БД хранятся на сервере,
клиент обращается к серверу с файловыми
командами, а механизм управления всеми
информационными ресурсами (база
метаданных (БМД)) находится на
клиенте.
Достоинства:
разделение монопольного приложения на два взаимодействующих процесса.
сервер может обслуживать множество клиентов, которые обращаются к нему с запросами.
Алгоритм
выполнения запроса клиента.
Запрос
клиента формируется в командах ЯМД.
СУБД переводит этот запрос в
последовательность файловых команд.
Каждая файловая команда вызывает
перекачку блока информации на клиента.
Далее на клиенте СУБД анализирует
полученную информацию и если в полученном
блоке не содержится ответ на запрос, то
принимается решение о перекачке
следующего блока информации до тех пор,
пока не будет найдено ответа на
запрос.
Модель
удаленного доступа к данным.
В
модели удаленного доступа (RDA) база
данных хранится на сервере. На нем же
находится и ядро СУБД. На клиенте
располагаются PL и BL приложения. Клиент
обращается к серверу с запросами на
языке SQL.
Достоинства:
перенос компонента представления и прикладного компонента на клиентский ПК существенно разгружает сервер БД, сводя к минимуму общее число процессов в ОС.
процессор сервера целиком загружается операциями обработки данных, запросов и транзакций.
резко уменьшается загрузка сети, запросы на ввод-вывод и на SQL уменьшаются в объеме, т.е. в ответ на запросы клиент получает только данные, удовлетворяющие данному запросу.
унификация интерфейса клиент-сервер.
стандартным при обращении приложения клиента и сервера становится язык SQL.