Корпоративные базы данных - статьи


2. Архитектура "клиент-сервер" - часть 2


запросы по специальному алгоритму (стандартные алгоритмы шифрования, используемые,
например, в Oracle SQL*Net, вряд ли будут сертифицированы ФАПСИ).

В случае трехзвенной схемы клиент явно запрашивает один из сервисов (предоставляемых
прикладным компонентом), передавая ему некоторое сообщение (например) и получает ответ
также в виде сообщения. Клиент направляет запрос в информационную шину (которую строит
Tuxedo System), ничего не зная о месте расположения сервиса. Имеет место так называемый
function shipping (то есть "поставка функций" клиенту). Важно, что для Клиента база данных (в том
числе и DDB) закрыта слоем Сервисов. Более того, он вообще ничего не знает о ее существовании,
так как все операции над базой данных выполняются внутри сервисов.

Сравним два подхода. В первом случае мы имеем жесткую схему связи "точка-точка" с передачей
открытых SQL-запросов и данных, исключающую возможность модификации и работающую
только в синхронном режиме "запрос-ответ". Во втором случае определен гибкий механизм
передачи сообщений между клиентами и серверами, позволяющий организовывать взаимодействие
между ними многочисленными способами.

Таким образом, речь идет о двух принципиально разных подходах к построению информационных
систем "клиент-сервер". Первый из них устарел и явно уходит в прошлое. Дело в том, что SQL
(ставший фактическим стандартом общения с реляционными СУБД) был задуман и реализован как
декларативный язык запросов, но отнюдь не как средство взаимодействия "клиент-сервер" (об этой
технологии тогда речи не было). Только потом он был "притянут за уши" разработчиками СУБД в
качестве такого средства. На волне успеха реляционных СУБД в последние годы появилось
множество систем быстрой разработки приложений для реляционных баз данных (VisualBasic,
PowerBuilder, SQL Windows, JAM и т.д.). Все они опирались на принцип генерации кода
приложения на основе связывания элементов интерфейса с пользователем (форм, меню и т.д.) с
таблицами баз данных. И если для быстрого создания несложных приложений с небольшим числом
пользователей этот метод подходит как нельзя лучше, то для создания корпоративных
распределенных информационных систем он абсолютно непригоден.

Для этих задач необходимо применение существенно более гибких систем класса middleware
(Tuxedo System, Teknekron), которые и составляют предмет нашей профессиональной деятельности
и базовый инструментарий при реализации больших проектов.




- Начало -  - Назад -  - Вперед -