9 Июнь 2008

1. Архитектура «клиент-сервер». Уровни систем «клиент-сервер».

написано в рубрике: Базы данных +УБД (Т) — Метки: , — Михаил @ 20:58

Распределенные системы - это системы “клиент-сервер”. Существует по меньшей мере три модели “клиент-сервер”:

· Модель доступа к удаленным данным (RDA-модель)

· Модель сервера базы данных (DBS-модель)

· Модель сервера приложений (AS-модель)

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

· Компонент интерфейса с пользователем

· Компонент управления данными (и базами данных в том числе)

а между ними расположено программное обеспечение промежуточного слоя (middleware), выполняющее функции управления транзакциями и коммуникациями, транспортировки запросов, управления именами и множество других. 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), которые и составляют предмет нашей профессиональной деятельности и базовый инструментарий при реализации больших проектов.

Технология клиент-сервер

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

Технология клиент-сервер подразумевает выполнение запросов пользователей специализированным компьютером, называемым сервером. Пользователи, которые отправляют запросы на этот сервер, называются клиентамиa. Запрос на выполнение операции с данными (например, обычная выборка), выдаваемый клиентом, порождает на сервере поиск и извлечение данных. Извлеченные данные транспортируются по сети от сервера к клиенту. Системы, использующие технологию клиент-сервер, разделяются на две части: клиентская часть обеспечивает графический интерфейс и находится на компьютере пользователя; серверная часть обеспечивает управление данными, разделение информации, администрирование и безопасность и находится на специально выделенных для этого компьютерах.

Уровни системы клиент-сервер

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

· GUI - графический пользовательский интерфейс. Состоит из окон, экранов и т. д.

· бизнес-логика - это часть программы, имеющая дело с расчетами.

· база данных, СУБД, занимающаяся хранением и получением данных.

Бизнес-правила - это процедуры управления, которые указывают, как клиент получает доступ к данным на сервере. Эти правила реализуются клиентом, сервером или ими обоими в виде программного кода. Важно понимать, что бизнес-правила определяют поведение системы. При их отсутствии у вас есть просто данные на одном компьютере и приложение на другом, но нет метода их соединения.

Двухуровневая система

В основе своей двухуровневая система имеет GUI и бизнес-логику с прямым доступом к базе данных. GUI находится на системе клиента, а база данных - либо у клиента, либо на сервере. Обычно GUI пишется на C++, Visual Basic, Access Basic и т.д. Типичными базами данных являются MIcrosoft Access, Personal Oracle и т.д.

Трехуровневые системы

Большинство клиент-серверных приложений следуют сегодня трехуровневой стратегии, при которой GUI, бизнес-логика и базы данных логически разбиты на три слоя. Здесь GUI пишется на Visual Basic, C++ или Power Builder, средствами разработки среднего слоя также служит C++ или Visual Basic. В качестве базы данных используются Oracle, Microsoft SQLServer и т.д. Трехуровневая концепция дала начало эпохе серверов баз данных, серверов приложений и клиентских GUI-машин. Такие операционные системы как UNIX, Windows NT и Solaris правят в мире серверов баз данных и приложений. Клиентские операционные системы (Windows) популярны среди разработчиков GUI. Двухуровневая архитектура может быть дополнена третьим программным уровнем во избежание встраивания логики приложения как в клиентскую часть, так и в базу данных. В трехуровневой архитектуре большая часть логики приложения зафиксирована на среднем уровне. В подобной архитектуре при изменении направления деловой активности или бизнес-процессов меняется только программное обеспечение программного слоя.

Многоуровневые системы

Сейчас, во времена Internet и Java изменились взгляды на отношения клиента и компьютерной сети. Апплеты Java с их объектами и методами привели к возникновению идеи многоуровневой клиент-серверной системы. Теоретически апплет Java может содержать бизнес-логику, GUI или СУБД. Каждый апплет можно рассматривать как отдельный слой. Концепция объектно-ориентированных многоуровневых систем возникла до появления Internet и Java. Архитектуры CORBA фирмы OMG и OLE (теперь ActiveX) фирмы Microsoft являются первыми модульными объектно-ориентированными системами, работающими на разных платформах. Internet и Java упростили реализацию этой концепции. Конструкция и реализация систем прошли путь от двух и трехуровневой архитектуры до современных межсетевых многоуровневых архитектур, основанных на апплетах Java.

© ?????? �????????-???????????�., 2008. ??? ????? ????????.
??????????? ?????????? ?????? ??? ??????? ???????? ?????? ?? ????????.
Powered by WordPress