Однажды автору этих строк было предложено создать программное обеспечение для работы с базой данных ORACLE. У заказчика имелась база данных (БД) и был налажен процесс пополнения этой БД данными.
Нужно было разработать программное обеспечение (п.о.), которое позволяло бы пользователям (клиентам) получать информацию из этой БД по запросам. При этом нужно было учитывать следующие обстоятельства:

• Программное обеспечение должно быть ориентировано на пользователя с квалификацией оператора ПЭВМ и не обладающего знанием языка SQL.
  
• Информация в БД считается строго конфиденциальной. Несанкционированный доступ к данным недопустим;
• Пользователи должны получать доступ только к той части БД, которая им реально необходима и не должны знать реальную структуру обьектов БД и их взаимосвязи;
• Для доступа к БД клиенты должны будут использовать медленные модемные соединения;

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

Выбор архитектуры программного обеспечения

Традиционный клиент-сервер:

Клиентское п.о. непосредственно взаимодействует с сервером ORACLE. Все алгоритмы бизнес-логики реализуются на клиенте. Эта схема требует дополнительной установки необходимого п.о. используемой СУБД (в данном случае ORACLE SQL Net).

Трехзвенная архитектура с использованием сервера приложений:

Эта схема гораздо гибче предыбущей. Здесь появляется промежуточный слой (сервер приложений), в котором реализуются все необходимые алгоритмы бизнес-логики приложения и выполняется непосредственное взаимодействие с СУБД. Клиенту отводится лишь роль организации интерфейса с конечным пользователем и функциональное взаимодействие с сервером приложений.
Таким образом в этом случае программное обеспечение разделяется на 2 взаимосвязанные части, которые работают на разных хостах: тонкий клиент - устанавливается у конечного пользователя и сервер приложений - устанавливается на хосте с которого доступна БД.

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

• Так как тонкий клиент не взаимодействует непосредственно с СУБД, то ему не нужно клиентского п.о. этой СУБД, а значит можно предположить, что программа будет очень простой в эксплуатации и затраты по установке и настройке клиентских рабочих мест будут минимальны;
• Если возникнет необходимость внесения изменений в бизнес-логику уже работающего приложения, то в случае трехзвенной архитектуры это будет сделать проще, так как все реализовано в одном месте - на сервере приложений;
• Трехзвенная архитектура обеспечивает лучшую защиту от несанкционированного доступа к данным. В самом деле, самым уязвимым звеном в двухзвенной архитектуре является клиент, который всякий раз вынужден передавать серверу имя и пароль для открытия сессии доступа. Утечка пароля в этом случае может привести к несанкционированному доступу к данным. В трехзвенной архитектуре клиенту не нужен пароль доступа к БД (взаимодействие с СУБД - функция сервера приложений);
• Появляется заманчивая идея спроектировать сервер приложений так, чтобы он был независим от конкретной СУБД, что сделает продукт универсальным инструментом доступа не только к ORACLE, но и к другим базам данных.

Защита данных от несанкционированного доступа

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

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

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

Информационная модель данных

Коль скоро перед нами была поставлена задача создать п.о. для обычного оператора ПЭВМ, то нужно было решить вопрос об организации данных (информационной модели) в представлении конечного пользователя.

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

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

Если на клиенте схема выглядит очень просто, то на сервере приложений совсем наоборот. Все обьекты БД (таблицы), представляющие предметную область схемы включаются в специальное описание, которое хранится на сервере приложений и используется им при обработке запросов от клиента. Такое описание должно содержать всю информацию об обьектах БД - описание таблиц и их полей, описание взаимосвязей таблиц, форматы выдаваемых данных и т.д.

Итоги