Архитектура "клиент-сервер"
Распределенные системы - это системы "клиент-сервер". Существует по меньшей мере три модели
"клиент-сервер" (подробно о них рассказано в ):
- Модель доступа к удаленным данным (RDA-модель)
- Модель сервера базы данных (DBS-модель)
- Модель сервера приложений (AS-модель)
Первые две являются двухзвенными и не могут рассматриваться в качестве базовой модели
распределенной системы (ниже будет показано, почему это так). Трехзвенная модель хороша тем,
что в ней интерфейс с пользователем полностью независим от компонента обработки данных.
Собственно, трехзвенной ее можно считать постольку, поскольку явно выделены:
- Компонент интерфейса с пользователем
- Компонент управления данными (и базами данных в том числе)
выполняющее функции управления транзакциями и коммуникациями, транспортировки запросов,
управления именами и множество других. Middleware - это ГЛАВНЫЙ компонент распределенных
систем и, в частности, DDB-систем. Главная ошибка, которую мы совершаем на нынешнем этапе -
полное игнорирование middleware и использование двухзвенных моделей "клиент-сервер" для
реализации распределенных систем.
Существует фундаментальное различие между технологией "SQL-клиент - SQL-сервер" и
технологией продуктов класса middleware (например, менеджера распределенных транзакций
Tuxedo System). В первом случае клиент явным образом запрашивает данные, зная структуру базы
данных (имеет место так называемый data shipping, то есть "поставка данных" клиенту). Клиент
передает СУБД SQL-запрос, в ответ получает данные. Имеет место жесткая связь типа "точка-
точка", для реализации которой все СУБД используют закрытый SQL-канал (например, Oracle
SQL*Net). Он строится двумя процессами: SQL/Net на компьютере - клиенте и SQL/Net на
компьютере-сервере и порождается по инициативе клиента оператором CONNECT. Канал закрыт
в том смысле, что невозможно, например, написать программу, которая будет шифровать SQL-
запросы по специальному алгоритму (стандартные алгоритмы шифрования, используемые,
например, в Oracle SQL*Net, вряд ли будут сертифицированы ФАПСИ).
В случае трехзвенной схемы клиент явно запрашивает один из сервисов (предоставляемых
прикладным компонентом), передавая ему некоторое сообщение (например) и получает ответ
также в виде сообщения. Клиент направляет запрос в информационную шину (которую строит
Tuxedo System), ничего не зная о месте расположения сервиса. Имеет место так называемый
function shipping (то есть "поставка функций" клиенту). Важно, что для Клиента база данных (в том
числе и DDB) закрыта слоем Сервисов. Более того, он вообще ничего не знает о ее существовании,
так как все операции над базой данных выполняются внутри сервисов.
Сравним два подхода. В первом случае мы имеем жесткую схему связи "точка-точка" с передачей
открытых SQL-запросов и данных, исключающую возможность модификации и работающую
только в синхронном режиме "запрос-ответ". Во втором случае определен гибкий механизм
передачи сообщений между клиентами и серверами, позволяющий организовывать взаимодействие
между ними многочисленными способами.
Таким образом, речь идет о двух принципиально разных подходах к построению информационных
систем "клиент-сервер". Первый из них устарел и явно уходит в прошлое. Дело в том, что SQL
(ставший фактическим стандартом общения с реляционными СУБД) был задуман и реализован как
декларативный язык запросов, но отнюдь не как средство взаимодействия "клиент-сервер" (об этой
технологии тогда речи не было). Только потом он был "притянут за уши" разработчиками СУБД в
качестве такого средства. На волне успеха реляционных СУБД в последние годы появилось
множество систем быстрой разработки приложений для реляционных баз данных (VisualBasic,
PowerBuilder, SQL Windows, JAM и т.д.). Все они опирались на принцип генерации кода
приложения на основе связывания элементов интерфейса с пользователем (форм, меню и т.д.) с
таблицами баз данных. И если для быстрого создания несложных приложений с небольшим числом
пользователей этот метод подходит как нельзя лучше, то для создания корпоративных
распределенных информационных систем он абсолютно непригоден.
Для этих задач необходимо применение существенно более гибких систем класса middleware
(Tuxedo System, Teknekron), которые и составляют предмет нашей профессиональной деятельности
и базовый инструментарий при реализации больших проектов.
