CC BY
78
ОБЗОР И ОЦЕНКА ВОЗМОЖНЫХ АРХИТЕКТУР СРЕДСТВ КОНТРОЛЯ ДОСТОВЕРНОСТИ ДАННЫХ В МНОГОУРОВНЕВЫХ КЛИЕНТ-СЕРВЕРНЫХ ИНФОРМАЦИОННЫХ СИСТЕМАХ
Шибанов С. В., Фишбейн А. И.
Пензенский Государственный Университет
УДК 004.4, 004.6
В статье рассматриваются проблемы обеспечения соответствия данных в информационных системах бизнес-правилам предметной области, исследуются особенности контроля достоверности данных в клиент-серверных информационных системах. Рассматриваются возможные архитектуры средств контроля достоверности в клиент-серверных информационных системах, приводится их сравнительные характеристики. Даются рекомендации по выбору варианта архитектуры.
Достоверность данных, контроль достоверности данных, информационные системы, технологии клиент-сервер
THE REVIEW AND ASSESSMENT OF POSSIBLE ARCHITECTURES OF DATA RELIABILITY CONTROL TOOLS IN MULTI-LEVEL CLIENT-SERVER INFORMATION SYSTEMS
Shibanov S., Fishbein A.
Penza State University
In article problems of data consistency in information systems to data domain business rules are considered, features of data reliability control in client-server information systems are researched. Possible architectures of data reliability monitoring tools in client-server information systems are considered, their comparative characteristics are resulted. Recommendations of for choice variant of architecture are made.
Data reliability, data reliability control, information systems, client-server technologies
Проблема контроля достоверности данных в клиент-серверных информационных системах. В информационных системах (ИС) важной задачей является организация контроля достоверности данных. Под достоверностью данных будем понимать соответствие данных некоторому набору правил, определяемому особенностями и стандартами предметной области, семантикой данных и, конечно, здравым смыслом. Эти правила, часто называемые бизнес-правилами, обычно определяют возможные значения данных и связи между ними. К примеру, количество товара, проданного за весь год, не должно быть меньше количества, проданного за месяц; перечисленная заработная плата должна равняться сумме оклада, надбавки и премии; и так далее. Проверка занесённой информации на соответствие бизнес-правилам помогает не только выявить случайные ошибки при вводе, но и, например, об-
наружить несоответствия в отчётности, найти глубинные расхождения при консолидации данных из разных филиалов организации.
Различные архитектурные решения, применяемые при проектировании программного обеспечения, разумеется, определяют производительность системы, удобство её развития и использования. В случае монолитных приложений проблема контроля достоверности, фактически, имеет одно архитектурное решение - соответствующие правила бизнес-логики жёстко прописываются в коде программы. Но информационные технологии развиваются чрезвычайно быстро, и современные системы практически всегда имеют значительно более сложную структуру. При проектировании всегда приходится закладывать возможность дальнейшего развития системы, причём желательно обновление уже запущенной системы без остановки её работы.
В данной статье рассматриваются варианты архитектурной реализации функциональности контроля достоверности данных для клиент-серверных информационных систем, наиболее распространённого типа ИС в настоящее время. Средства контроля достоверности данных могут быть разнесены по разным уровням системы, в зависимости от конкретной выбранной архитектуры и требований к ИС.
Клиент-серверные информационные системы. Уже довольно долго заслуженной популярностью для реализации ИС пользуется архитектура клиент-сервер. В общем случае, это такая архитектура программного обеспечения, в которой функции распределены между поставщиками услуг (серверами) и заказчиками услуг (клиентами). [8] В дальнейшем, говоря об информационных системах, мы будем подразумевать именно клиент-серверные ИС.
Основные группы функций ИС - функции хранения, обработки и представления данных. В случае, если обработка относительно несложна, может быть достаточно двухуровневой (двухзвенной) архитектуры - обычно, клиентское приложение и сервер баз данных. При использовании сложных алгоритмов обработки используются трёхзвенная и многозвенная архитектуры, в которых функция обработки данных вынесена соответственно на один или несколько отдельных серверов. Таким образом, при использовании многоуровневой клиент-серверной архитектуры появляется много возможностей организовать контроль достоверности данных максимально производительно и удобно.
Не следует забывать и о том, что сама база данных является полноценным элементом ИС, а не только местом хранения информации. Многие из современных БД обладают свойством активности, то есть, СУБД по отношению к ней способна выполнять не только те действия, которые явно указывает пользователь, но и некие дополнительные действия в соответствии с правилами, заложенными в саму БД. Наиболее распространённой реализацией этого свойства является механизм триггеров, то есть, условных воздействий. Также большинство СУБД обладают развитыми средствами для декларативного обеспечения целостности данных путём наложения сложных ограничений на допустимые значения в строках таблиц. Таким образом, некоторые
правила контроля достоверности данных могут описываться и выполняться на уровне сервера баз данных. Выбор наиболее подходящего варианта может зависеть от многих условий: от требуемой производительности, от частоты изменения бизнес-правил, и так далее.
Варианты размещения средств контроля достоверности данных. Будем рассматривать многозвенную архитектуру информационной системы, элементами которой являются клиентские приложения, серверы приложений, серверы правил (в более общем варианте, серверы бизнес-логики) и серверы баз данных с развернутыми на них БД. Соответственно, средства контроля достоверности могут быть расположены на любом из четырёх уровней системы или же разнесены по ним. Ниже выделены основные варианты размещения средств контроля достоверности данных.
Размещение средств контроля достоверности данных на стороне клиентского приложения. Возможны, например, следующие варианты:
- в виде кода классов, содержащих правила (данные) и методы (код проверки), напрямую включаемых в клиента. Этот подход реализуется легче всего и обеспечивает быстрое выполнение проверки, но он сильно затрудняет последующую модификацию правил, так как в этом случае требуется изменение и переустановка всех клиентских приложений. Данный способ подходит, если правила редко меняются, проверяются большие объёмы данных, а быстродействие критично.[9]
- в виде набора библиотек, содержащих сами правила и методы проверки данных на соответствие этим правилам. Этот способ обеспечивает неплохое быстродействие и позволяет изменять бизнес-правила. Для расширения наборов правил требуются навыки программирования либо наличие специализированного приложения-конструктора библиотек. [2] Некоторую сложность может представлять распространение актуальных версий правил для всех клиентов.
- в виде набора файлов, содержащих описание правил достоверности в некоторой промежуточной форме, и компонента, способного разбирать эти правила и выполнять проверку (исполнять интерпретируемый код). Этот метод поддерживает лёгкое обновление правил (не требующее навыков программирования), но скорость проверки будет довольно низкой (из-за проведения интерпретации правил). К тому же, в этом случае, все правила должны иметь заранее определённую форму, так как набор команд, исполняемых интерпретатором, жёстко вписывается в его код. [9]
Размещение средств контроля достоверности данных на стороне сервера приложений. В этом случае функции сервера правил берёт на себя сервер приложений. Возможны следующие варианты:
- в виде кода классов, непосредственно включённых в сервер приложений. При этом подходе в случае модификации правил необходимо заменить только сервер приложений, а не все клиентские приложения. Также отсутствует излишняя нагрузка на сервер баз данных (которая, однако, возлагается на сервер приложений).
- в виде набора библиотек, подключаемых статически либо динамически. Это облегчает обновление правил, тем не менее, тоже замедляя работу сервера приложений, как и в предыдущем случае.
- в виде отдельных файлов, содержащих описание правил достоверности в некоторой промежуточной форме, и компонента, способного разбирать эти правила и выполнять проверку. Этот вариант уменьшает скорость работы сервера приложений, позволяя при этом достаточно легко обновлять бизнес-логику.[3]
Размещение средств контроля достоверности данных на сервере правил. Возможны следующие варианты:
- на сервере правил для всех имеющихся наборов правил централизованно хранится выполняемый код проверки контроля достоверности, в виде, например, библиотек. Проекты правил хранятся отдельно. Проверка правил может инициироваться и клиентом, и сервером приложений, и СУБД по определённому интерфейсу. Сервер правил разбирает запрос и перенаправляет его соответствующей библиотеке. Достоинства этого подхода: лёгкость обновления правил; высокая скорость выполнения; возможность создавать проекты правил с помощью разных инструментов и языков программирования; простота реализации самого сервера правил; доступность для остальных компонентов ИС. Недостатки: необходимость обеспечить своевременную загрузку новейших версий наборов правил на сервер; рассредоточенность описания правил.
- на сервере правил централизованно хранятся проекты правил. Если правила описаны в одном формате, сервер может при поступлении запроса на проверку находить нужный проект и интерпретировать его. То есть, контроль достоверности проводит сам сервер согласно правилам бизнес-логики, хранимым в интерпретируемых им проектах. Таким образом, сервер правил одновременно является репозиторием правил. Достоинства: лёгкость обновления бизнес-правил; доступность для остальных компонентов системы, гарантированная актуальность используемых версий правил; централизованное хранение описания правил. Недостатки: уменьшение скорости выполнения проверки из-за проводящейся интерпретации правил; сложность реализации самого сервера правил.
- на сервере правил централизованно хранятся и проекты правил, и получаемый из них исполняемый код проверки. При поступлении запроса на проверку сервер правил может либо находить нужные библиотеки, и перенаправлять им запрос, либо динамически генерировать исполняемый код из имеющегося проекта (без проведения интерпретации) с последующим его вызовом (в этом случае можно или сохранять созданные библиотеки на сервере - этот вариант даёт выигрыш в скорости - или каждый раз генерировать их заново в целях экономии места). Достоинства: лёгкость обновления правил; доступность для всех компонентов ИС, гарантированная актуальность используемых версий правил; централизованное хранение описания правил; высокая скорость выполнения. Недостатки: сложность реализации такого сервера правил.
Размещение средств контроля достоверности данных на сервере баз данных. Возможны следующие варианты:
- ограничения на столбцы таблиц и ограничения на таблицу. Этот способ подходит только для простейших правил. Достоинства - проверка проводится средствами СУБД; правила можно менять с помощью стандартных запросов. [10] Недостатки: проверка не может вызываться другими компонентами системы; проведение проверки может замедлить операции добавления и обновления данных; правила нужно декомпозировать до уровня ограничений отдельных значений без связи с другими данными; возможен контроль только данных, которые находятся или добавляются в БД.[3]
- триггеры. Они выполняются автоматически при добавлении, изменении или удалении записей в БД, для некоторых СУБД - и при других событиях. Достоинства и недостатки этого метода почти такие же, как и в предыдущем случае. Синтаксические возможности определения кода проверки зависят от используемого языка (диалектов SQL или встроенных языков для объектных СУБД).
- хранимые процедуры и пользовательские функции. Среди достоинств этого варианта можно выделить возможность вызова проверки остальными компонентами ИС, и, для некоторых СУБД, возможность написания кода на различных языках программирования. [5]
- для объектных или постреляционных СУБД также возможно хранить код проверки правил в описании объектных таблиц. Достоинства: возможно описание сложных методов проверки; высокое быстродействие; возможно проведение проверки в любой момент; возможен вызов проверки остальными компонентами ИС. Недостатки: возможна проверка только тех данных, которые уже сохранены в БД; изменение правил требует изменения объектных таблиц.[3]
Варианты размещения и выполнения бизнес-правил контроля достоверности данных. Возможны следующие варианты размещения и выполнения бизнес-правил.
1) Бизнес-правила контроля достоверности данных размещаются и выполняются на стороне СУБД (в виде процедур или функций), их выполнение инициируется клиентским приложением (рисунок 1).
Рисунок 1 - Правила размещаются и выполняются на стороне СУБД, выполнение инициируется клиентским приложением
2) Бизнес-правила контроля достоверности данных размещаются и выполняются на стороне СУБД (в виде процедур или функций), их выполнение инициируется сервером приложений (рисунок 2).
Рисунок 2 - Правила размещаются и выполняются на стороне СУБД, выполнение инициируется сервером приложений Этот подход обеспечивает неплохое быстродействие; функции контроля достоверности также доступны остальным компонентам системы; правила контроля могут достаточно легко модифицироваться. Однако, проверены могут быть только данные, уже хранящиеся в БД. [3] Для реляционных СУБД остаётся проблема декомпозиции правил с уровня бизнес-логики до уровня схемы БД.
3) Бизнес-правила контроля достоверности данных размещаются и выполняются на стороне СУБД, а их проверка инициируется сервером правил (рисунок 3).
Рисунок 3 - Правила размещаются и выполняются на стороне СУБД, проверка инициируется сервером правил
Достоинством этого метода, по сравнению с предыдущим, является централизация общей логики вызовов контроля достоверности (какие именно данные следует проверять, какова должна быть реакция на ошибки и пр.) на специализированном сервере.
4) Бизнес-правила контроля достоверности данных в виде динамически подключаемых библиотек размещаются и выполняются на стороне клиентского приложения, проверка инициируется также клиентским приложением (рисунок 4).[4]
Рисунок 4 - Правила размещаются и выполняются на стороне клиентского приложения, проверка инициируется клиентским приложением
5) Бизнес-правила контроля достоверности данных в виде динамически подключаемых библиотек размещаются и выполняются на сервере приложений, проверка инициируется клиентским приложением (рисунок 5).
Рисунок 5 - Правила размещаются и выполняются на сервере приложений, проверка инициируется клиентским приложением
6) Бизнес-правила контроля достоверности данных в виде динамически подключаемых библиотек размещаются на сервере правил, а вызываются из триггеров, хранимых процедур, пользовательских функций или методов объектных таблиц и выполняются на стороне СУБД (рисунок 6). Это возможно, если СУБД поддерживает вызов внешнего исполняемого кода.
Рисунок 6 - Правила размещаются на сервере правил, проверка выполняется
и инициируется СУБД
7) Бизнес-правила контроля достоверности данных в виде динамически подключаемых библиотек размещаются и выполняются на сервере правил на сервере правил, а вызываются клиентским приложением или сервером приложений (рисунок 7).
Рисунок 7 - Правила размещаются и выполняются на сервере правил, проверка инициируется сервером приложений или клиентом
7) Возможно совмещение некоторых описанных выше вариантов, то есть, разнесение мест хранения кода и описания бизнес-правил, вызовов контроля достоверности и места проведения проверки по разным уровням ИС. К примеру, часть правил может быть описана в виде триггеров и хранимых процедур, вызываться СУБД и сервером приложений, выполняясь СУБД, а часть - храниться на сервере правил и вызываться клиентом, выполняясь сервером правил (рисунок 8).
Рисунок 8 - Правила хранятся на стороне СУБД и на сервере правил, проверка инициируется сервером приложений и клиентскими приложениями
Выбор архитектуры средств контроля достоверности данных. Выбор архитектуры средств контроля достоверности данных возможен на основе следующих критериев:
1) скорость выполнения проверки;
2) возможность изменения бизнес-правил;
3) возможность изменения бизнес-правил без переустановки системы в ходе её работы;
4) сложность описания правил;
5) допустимость повышенной нагрузки на сеть при передаче больших объёмов данных; [5]
В таблице 1 приведена сравнительная характеристика вариантов архитектур, в соответствии с выделенными критериями.
В случае, если критичны быстродействие и простота обновления правил, рекомендуются варианты с библиотеками на сервере правил либо сервере приложений. Если же принципиальным является уменьшение нагрузки на сеть, рекомендуются варианты реализации контроля на стороне сервера БД, особенно в случае использования объектной или постреляционной СУБД.
Таблица 1 - Сравнительная характеристика вариантов архитектур
^м_Критерий Реализациям^ Скорость выполнения проверки Изменение бизнес- правил Изменение бизнес-правил без переустановки системы Сложность описания правил Допустимость повышенной нагрузки на сеть
Правила контроля хранятся на стороне СУБД, их проверка вызывается сервером приложений или клиентом, производится внутри СУБД Зависит от быстродействия используемой СУБД Правила можно быстро заменить, так как они хранятся централизованно Поскольку изменяются только объекты БД, переустановка серверов и клиентов не требуется Сложное описание (на языке SQL), либо подключаемые процедуры на языке высокого уровня Избыточная нагрузка на сеть отсутствует, т. к. данные проверяются там же, где хранятся
Описание правил хранится на стороне СУБД, а их проверка инициируется сервером правил. Зависит от быстродействия используемой СУБД, выигрыш в скорости за счёт применения специализированного сервера Правила можно быстро заменить, так как они хранятся централизованно Поскольку изменяются только объекты БД, переустановка серверов и клиентов не требуется Сложное описание (на языке SQL), либо процедуры на языке высокого уровня Избыточная нагрузка на сеть отсутствует, так как данные проверяются там же, где хранятся
Описание правил хранится на стороне клиента в виде набора библиотек Высокая, поскольку выполняется скомпилированный код, и нет зависимости от работы сети В случае изменения правил нужно обновить библиотеки для всех клиентов Поскольку изменяются только отдельные библиотеки, переустановка компонентов системы не требуется Описание правил на высокоуровневом языке программирования Нагрузка на сеть зависит от расположения источника проверяемых данных
Библиотеки правил хранятся на сервере приложений, и контроль инициируется клиентом Довольно высокая, поскольку выполняется скомпилированный код Правила можно быстро заменить, так как библиотеки хранятся Поскольку изменяются только отдельные библиотеки, переустановка компо- Описание правил на высокоуровневом языке программирования Нагрузка на сеть зависит от расположения источника проверяемых данных
централизо- ванно нентов системы не требуется
Библиотеки, содержащие код проверки, централизованно хранятся на сервере правил, а вызываются СУБД Высокая, поскольку выполняется скомпилированный код, выигрыш в скорости за счёт применения специализированного сервера (и снятия при этом части нагрузки с сервера приложений) Правила можно быстро заменить, так как библиотеки хранятся централизованно Поскольку изменяются только отдельные библиотеки, переустановка компонентов системы не требуется Описание правил на высокоуровневом языке программирования Нагрузка зависит от конкретного взаимного расположения сервера БД и сервера правил
Библиотеки, содержащие код проверки, хранятся на сервере правил, а вызываются клиентом или сервером приложений Высокая, поскольку выполняется скомпилированный код, выигрыш в скорости за счёт применения специализированного сервера Правила можно быстро заменить, так как библиотеки хранятся централизованно Поскольку изменяются только отдельные библиотеки, переустановка компонентов системы не требуется Описание правил на высокоуровневом языке программирования Нагрузка зависит от конкретного взаимного расположения источника данных (клиента, сервера приложений либо БД) и сервера правил
Комбинированный вариант (разнесение мест хранения бизнесправил, вызовов контроля достоверности и места проведения проверки по разным уровням ИС) Может быть довольно высокой (при удачном варианте разнесения правил) Зависит от того, какие конкретно правила меняются, и где хранятся эти правила Зависит от того, какие конкретно правила меняются, и где (и в виде чего) хранятся эти правила Может быть достаточно сложным, так как, помимо прочего, разные правила описываются разными способами Нагрузка зависит от конкретного взаимного расположения источника данных и места их обработки; может различаться для разных наборов правил
Заключение. Декомпозиция подсистемы контроля достоверности данных в многоуровневых клиент-серверных ИС повышает гибкость системы, облегчает её поддержку и развитие.
Предлагаемые архитектуры позволяют реализовать контроль достоверности данных в максимальном соответствии с требованиями к работе ИС.
Список источников
1 Маглинец Ю. А. Анализ требований к автоматизированным информационным системам. Издательство “Питер”, 2004. - 446с.
2 Фишбейн А.И., Шибанов С.В. Автоматизация разработки программных средств контроля достоверности данных в виде динамически подключаемых библиотек // Технологии Microsoft в теории и практике программирования. Материалы конференции. - Н. Новгород: Изд-во Нижегородского гос. ун-та 2010. - С. 384-388.
3 Фишбейн А.И., Шибанов С.В. Оценка подходов к реализации контроля достоверности данных в информационных системах // Технологии Microsoft в теории и практике программирования. Материалы конференции. - Н. Новгород: Изд-во Нижегородского гос. ун-та 2010. - С. 388-391.
4 Фишбейн А.И., Шибанов С.В. Реализация подсистемы контроля достоверности данных с использованием технологии позднего связывания // Технологии Microsoft в теории и практике программирования. Материалы конференции. - Н. Новгород: Изд-во Нижегородского гос. ун-та 2010. - С. 165-168.
5 Шибанов С.В., Фишбейн А.И., Шашков Б.Д., Гришко А.К. Проблемы обеспечения достоверности данных в информационных системах и подходы к их решению // Надежность и качество: Труды международ. симпозиума, т. I. - Пенза, Информац.-изд. центр Пенз. гос. ун-та, 2010. - с. 301-306.
6 Райтберг Г. Теория информационных систем. Изд-во Диалектика, 2000 г.
7 Троелсен Э. C# и платформа .NET. Библиотека программиста. -СПБ.: Издательство “Питер”, 2004. - 796с.;
8 Многоуровневые системы клиент-сервер.
http://www.osp .ru/nets/1997/06/142618/;
9 Шибанов С.В. Организация вычислений и контроля достоверности данных в АИС «Прокуратура-Статистика» // Надежность и качество: Труды меж-дународ. симпозиума, т. II. - Пенза, Информац.-изд. центр Пенз. гос. ун-та, 2008. - С. 302-305.
10 Коннолли Т., Бегг К. Базы данных. Проектирование, реализация и сопровождение. Теория и практика. Пер с англ. - М. Издательский дом “Вильямс”, 2003. - 1440с.
