Лекции - Корпоративные информационные системы и технологии

Подождите немного. Документ загружается.

3. Многоуровневые информационные системы. Клиент- серверные технологии.

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

архитектуру клиент-сервер, когда с рабочих станций осуществляется удаленный доступ к БД, и

не более того. В самых простых, примитивных системах даже не используются возможности

,предоставляемые РСУБД, такие, как триггеры и сохраненные процедуры, и, хотя разработчики

именуют подобные системы клиент-сервером, они имеют весьма мало общего с истинными

распределенными приложениями. Более того, идеология “толстого” клиента принуждает к

установке на рабочих местах весьма дорогостоящих Wintel-компьютеров, потому что на них

производятся все основные вычисления, и обмен данными с удаленным сервером БД

производится сквозь толстый многоуровневый слой драйверов, которые должны быть

установлены на персональной рабочей станции и лицензированы их разработчиками для

каждого рабочего места. Иногда получается совершенно нелепая вещь: если пропускная

способность сети недостаточно велика или недостаточно эффективно организован поток

прохождения транзакций, то при этом быстродействующие процессоры клиентских машин

совершенно бездействуют, а в обратном случае, наоборот, сервер БД задыхается и не успевает

отвечать каждому из многочисленных и буквально забивающих его клиентов. При числе

одновременно работающих клиентов более 30 необходимо переходить на трехзвенную

архитектуру (рис. 3.1).

В трехзвенной архитектуре всю логику работы с сервером БД можно возложить на

специальный сервер приложений, а разделенные на отдельные фрагменты приложения

уменьшают нагрузку и на машину-клиента, и на сервер БД, перенося соответствующие

операции на специализированный сервер приложений. Серверная часть приложений лучше

защищена, а сами приложения могут либо непосредственно адресоваться к другим серверным

приложениям, либо маршрутизировать запросы к ним . Достоинства этой архитектуры (рис.

3.2) можно разбить на 2 категории – клиентскую часть в виде броузера и серверную часть.

Рис. 3.1. Трехуровневая архитектура

клиент-сервер

Рис. 3.2 Клиент-сервер с броузером

3.1 Двухуровневая архитектура "клиент-сервер"

Рис. 3.3. Ранние архитектуры клиент-сервер

Стремление исправить архитектуру разделения файлов привело к замене файлового

сервера сервером баз данных (рис. 3.3). Вместо передачи файлов целиком он

пересылает только ответы на запросы клиентов, уменьшая нагрузку на сеть. Эта

стратегия вызвала появление архитектуры клиент-сервер. Появившись в 80-х годах, она

ввела понятие «клиента» (сторона, запрашивающая функции/обслуживание) и

«сервера» (сторона, предоставляющая функции/обслуживание). На уровне

программного обеспечения разделение на клиента и сервер является логическим:

процессы клиента и сервера могут физически размещаться как на одной, так и на

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

архитектуры: двухзвенная, трехзвенная и многозвенная.

Рис. 3.4. Двухзвенная архитектура

Самая старая — двухзвенная (рис. 3.4). Она разделяет приложение на две части,

клиентскую и серверную. Сторона клиента содержит логику представления, а логика

доступа к данным, СУБД и сама база находятся на стороне сервера.

Остаются алгоритмы бизнес-логики, которые могут быть размещены как на машине

клиента вместе с логикой представления (конфигурация «толстый клиент»), так и на

стороне сервера (конфигурация «тонкий клиент»), или даже могут быть разделены

между ними. Конфигурация «толстый клиент» более распространена: суммарная

вычислительная мощность клиентов, по крайней мере, в теории, предполагается

большей, чем мощность единственного сервера. Подобный ход рассуждений привел

некоторых из разработчиков к созданию приложений, где даже логика доступа к

данным размещается на клиенте, оставляя серверу только поддержание самой базы

данных.

Двухзвенная архитектура, особенно конфигурация «толстый клиент», имеет ряд

недостатков. Например, как и в архитектуре разделения файлов, — это ограничение,

вытекающее из вычислительной мощности отдельных машин клиентов. Но еще хуже

имеющее фундаментальный характер ограничения на число одновременных

соединений с сервером. Сервер поддерживает открытое соединение со всеми

активными клиентами, даже если никакой работы нет. Это необходимо, чтобы сервер

мог получать сигналы тактового импульса, что не так страшно, когда клиентов менее

100 [9-12]; однако сверх этого числа производительность начинает быстро

деградировать до недопустимо низкого уровня. Хорошим примером возникновения

подобной проблемы может служить работа прокси- сервера.

В некоторых прикладных системах бизнес-логику пытаются реализовать, используя

хранимые процедуры. Идея состоит в том, чтобы в соответствии с «тонкой»

конфигурацией клиента переместить алгоритмы бизнес-логики на серверную машину,

ближе к данным, которые требуются им постоянно. Это выглядит как хорошая идея,

однако только усугубляет главную проблему. Так как осуществляющие бизнес-

правила процессы теперь управляются СУБД, число пользователей, которых может

поддерживать такая система, ограничено максимумом возможных активных

соединений с СУБД. Кроме того, от СУБД к СУБД механизмы хранимых процедур

разнятся. Тем не менее, двухзвенная архитектура хорошо работает в маленьких

рабочих группах [9-12]. С начала 90-х годов появилась масса инструментальных

средств, упрощающих создание систем в такой архитектуре, в том числе Delphi и

PowerBuilder.

3.1.1. Место и функции сервера БД

Информационная система в двухуровневой архитектуре, использующая сервер

с базой данных, включает два вида программного обеспечения:

• Программное обеспечение общего назначения для поддержания БД,

называемое системой управления базами данных - СУБД;

• Прикладное ПО, которое использует средства СУБД для выполнения

конкретных задач.

Прикладные программы используют средства СУБД для обращения к данным и

их обработки, решая те или иные задачи, создавая различные документы и отчеты.

СУБД предназначена для обеспечения управления БД. Сервер БД выполняет

следующие функции:

- Одновременный доступ к данным для многих приложений;

- Защиту данных и обеспечение их целостности механизмами СУБД;

- Ориентированные на пользователей типовые запросы к

соответствующим БД, в том числе и распределенной информации

по разным БД;

- Ориентированные на программистов сервисы для создания

приложений.

С развитием и расширением функций СУБД двухуровневая архитектура

клиент-сервер прошла несколько стадий, которые характеризуются различным

распределением выполняемых функций приложений и, наконец, установилось

следующее разделение:

- Сервер БД

* Хранение данных и управление ими;

* Контроль доступа к данным согласно назначаемым правам

пользователей и приложений;

* Выполнение части логики приложений, которая определена в виде

связей между реляционными таблицами и реализуется в виде триггеров

и хранимых процедур;

* Выполнение репликаций данных для сегментов распределенных БД

или систем БД, расположенных в различных узлах корпоративной сети.

- Рабочая станция

* Ввод и модификация данных хранимых в БД;

* Выполнение основной обработки данных приложений;

* Хранение и реализация графических компонент

приложений;

* Доступ к данным в БД через "клиента" СУБД.

Такая архитектура оставалась эффективной при эксплуатации БД, которые

размещались на больших компьютерах, типа меинфреймов или IBM-360, но с

появлением серверных систем, оказалось допустимым при количестве рабочих

станций до 30.

3.1.2. Понятие клиента СУБД. Функции СУБД.

Каждая многопользовательская СУБД предоставляет доступ к базам данных

через специальную интерфейсную программу, которая называется "клиентом" СУБД.

Эта программа является, обычно, лицензированным продуктом для СУБД типа

ORACLE, OS/2, DB2, Informix, Sybase и др. Только MS SQL-server имеет встроенные

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

может быть осуществлен доступ к СУБД и к БД.

СУБД обычно выполняет следующие функции:

- Централизованное определение и контроль данных определяемое как

словарь/каталог данных;

- Обеспечение целостности данных и их защита;

- Выполнение операций по управлению транзакциями (журнализация

транзакций, "откат" транзакций и т.п.);

- Управление доступом к данным одновременно для множества пользователей;

- Выполнение архивирования служебных данных и ведение системных

журналов;

- Создание и поддержание виртуальных моделей данных для приложений.

3.1.3. Основные принципы и критерии при разработке

программных компонентов систем клиент-сервер

При разработке приложений в технологиях клиент-сервер желательно

придерживаться следующих критериев [9]:

1. Сохранение автономности сервера. Клиенты не должны ограничивать

доступность серверов (например, путем блокирования больших объемов

данных) и не должны нарушать целостность каких-либо данных сервера.

2. Сохранение автономности клиента. Функционирование клиента не должно

зависеть от местоположения данных.

3. Поддержка независимости приложений от сервера. Клиент приложения

должен быть независим от аппаратной платформы, вида операционной

системы и используемых сервисов серверов БД.

4. Доступность специфических средств сервера. Клиенту должны быть

доступны специфические функции конкретного сервера для более

качественного выполнения работы.

5. Минимум дополнительных требований к рабочей станции. Программное

обеспечение клиента не должно быть ресурсоемким и не иметь

особенностей для доступа к конкретному серверу БД.

6. Полнота вариантов соединения. Должна быть обеспечена возможность

прямых соединений с сервером.

7. Возможность прототипирования приложений. Удаленность данных не

должна препятствовать возможности прототипирования прикладного ПО.

8. Полнота пользовательского инструментария. В состав среды приложения

должны входить инструментальные средства для создания экранных форм,

генерации запросов и создания источников данных.

9. Полнота среды разработки приложений. Среда разработки должна

включать средства для установления межсетевых соединений и управления

ими, доступа к сервисам глобального назначения.

10. Открытая среда включающих языков. Приложение не должно быть

критическим к расширению его компонентов с использованием других

языков.

11. Следование стандартам. Создание приложений должно максимально

опираться на международные стандарты и рекомендации (стандартные

интерфейсы клиент-сервер образуют программное обеспечение

промежуточного слоя).

3.1.4. Основные недостатки двухуровневой архитектуры

К основным недостаткам двухуровневой архитектуры можно отнести:

- Невозможность создания распределенных приложений;

- Критичность сервера БД к числу пользовательских одновременно

работающих приложений (оптимальным является около 30);

- Критичность сервера к модификации больших объемов данных в

одной транзакции (т.е. к длине транзакции);

- Сложности при создании приложений работающих с разнотипными

СУБД (необходимость использования разных клиентов СУБД);

- Невозможность использования составных транзакций (т.е. сложных

транзакций, которые подлежат раздельному исполнению в разных

БД);

- Трудности в сопровождении и модификации клиентов приложения

(необходимость синхронного обновления dll-библиотек, ОС, SQL-

запросов, новых компонентов приложения и интерфейсов);

- Повышенные требования к ресурсам рабочей станции (все

вычисления делаются на клиентской РС, графические средства

поддерживаются там же и т.д.).

Несмотря на приведенные недостатки, для малого количества РС можно

использовать двухуровневую архитектуру при небольшом числе приложений и

стабильности деятельности организации.

3.2.1. Понятия "тонкого" и "сверхтонкого" клиентов

По мере развития архитектуры "клиент-сервер" и появлением трехуровневой и

других многозвенных архитектур возникло понятие "тонкого" клиента, которое

обозначает отсутствие на рабочей станции пользователя некоторых компонент,

которые раньше требовались для взаимодействия с сервером БД для нормальной

работы приложений. Причем, эти компоненты переместились с клиента на сервер

приложений и стали использоваться многими клиентами одновременно.

К таким компонентам можно отнести:

• "клиент" СУБД;

• ODBC- драйверы для соединения с БД;

• части приложений, реализующую SQL-запросы к базам данных;

• части приложений, которые используют для расчетов и вычислений

одни и те же алгоритмы, т.е. создавался общий вычислительный

ресурс.

Все эти технологические изменения привели к требованию дальнейшего

увеличения мощности сервера приложений и увеличению сетевого трафика между

рабочими станциями и серверами.

На рабочей станции оставались средства графической поддержки приложений и

стандартные приложения вида MS Office. Поэтому к ресурсам рабочих станций стали

предъявляться меньшие требования, хотя появление ОС более поздних модификаций и

развитие мультимедийных приложений быстро компенсировали этот "недостаток".

Появление новых Web-технологий и их развитие привело к внедрению Internet-

технологий в корпоративную компьютерную среду "броузеров", которые стали основой

клиентской части приложений Web- архитектур нового уровня, получивших название

"сверхтонкого" клиента.

В такой архитектуре все данные и все приложение целиком располагалось на

сервере приложений и сервере БД. Броузер "подкачивал" данные из Web- сервера и

"визуализировал" экраны приложения. Так появилась среда слабоструктурированных

приложений, в которой картинки приложений строятся динамически, в зависимости от

данных вводимых пользователем. Ясно, что использование броузера предъявляет еще

меньше требований к ресурсам рабочих станций.

Кроме того, при такой технологии отпадает необходимость модифицировать

клиентские части приложения, что упрощает их сопровождение и отпадает

необходимость в периодическом обучении пользователей. Можно говорить об

интеграции пользовательских интерфейсов в результате этого.

3.2. Трехуровневая архитектура "клиент-сервер"

По мере развития технологии интегрирования распределенных данных в

клиент-серверных приложениях и появлением все большего числа пользователей,

которые контактировали непосредственно с СУБД, проявилось, что при числе

пользователей в корпоративной сети более 30 необходимо удваивать ресурсы серверов

БД потому, что резко возрастает время реакции системы на запросы приложений.

Появление и развитие распределенных БД поставило вопрос о такой организации

данных, при которой приложение могло бы с помощью специальных средств

выполнять распределенные транзакции, направляя запросы к разным БД,

расположенным в разных узлах сети и, часто, имеющих различные программно-

аппаратные платформы.

Кроме того, начали интенсивно развиваться графические приложения, которые

требовали перекачки больших объемов информации между рабочей станцией и

сервером БД. Появились аудио- и видеоданные, требовавшие передачи и обработки

гигабайтов информации. Развитие дорогих кластерных систем резко ограничивалось их

высокой стоимостью.

Увеличение числа приложений, в которых использовались многочисленные

одинаковые фрагменты программ, породило развитие объектного программирования,

что в свою очередь поставило задачу размещения указаных фрагментов в одном месте с

целью удобства их модернизации и сопровождения.

Появление и развитие сетевого вычислительного ресурса, когда отдельные

фрагменты вычислительных программ размещаются на высокопроизводительном

оборудовании, также показало необходимость создания серверов, которые бы

специализировались на этом классе задач.

Все это породило необходимость создания специального класса серверов,

которые получили название серверов приложений и которые давали возможность

разгрузить многочисленные приложения от типовых задач обработки информации и

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

клиент-сервер, которые являются средним, промежуточным звеном между клиентской

частью приложений и серверами БД. Через компоненты DCOM,сокеты и т.п. они

взаимодействуют между собой, упрощая создание новых и сопровождение старых

приложений в корпоративной сети предприятий.

3.2.2 Функции сервера приложений и его назначение

Приложения доступны любому пользователю сети Internet/Intranet , имеющему

право обращаться к ним. Поскольку все операции по созданию и усовершенствованию

системы производятся на сервере, возникает необходимость сопровождать и

модернизировать части приложений, находящиеся на машинах-клиентах. Такая

конфигурация способна обеспечить работу десятка тысяч или даже миллиона

пользователей, являясь идеальной архитектурой для унаследованных программ.

Клиентские приложения обращаются не непосредственно к серверной СУБД

путем вызова функций клиентских API, а к серверу приложений, являющемуся для них

источником данных. При этом собственно клиентская часть серверной СУБД и

библиотеки типа BDE на рабочей станции, где используется такое клиентское

приложение, присутствовать не обязаны. Вместо них используется одна-единственная

динамически загружаемая библиотека dbclient.dll размером около150 Кбайт. Таким

образом, созданная информационная система становится трехзвенной, а сервер

приложений является средним звеном в цепи “тонкий” клиент – сервер приложений –

сервер БД.

Данная технология может быть реализована с помощью набора компонентов и

классов Delphi 3, обеспечивающих создание серверов приложений и клиентских

прикладных программ. Сначала все-таки рассмотрим создание классического клиент-

серверного приложения, а уже потом перейдем к схеме Intranet с применением Web.

Подготовка данных для сервера приложений

Для создания сервера приложений требуется СУБД, клиентом которой будет

сервер приложений. В принципе можно использовать любую серверную СУБД (и

вообще говоря, даже набор таблиц Dbase или Paradox). В примерах, приводимых ниже,

используется СУБД Oracle для платформы Windows NT.

Создадим нового пользователя Oracle и перенесем с помощью утилиты Data

Migration Wizard таблицы CLIENTS.DBF и HOLDINGS.DBF из БД DBDEMOS,

входящей в комплект поставки Delphi 3, в СУБД Oracle. После этого можно приступить

к созданию простейшего сервера приложений.

Создание сервера приложений

Создадим простейшую форму со значением свойства FormStyle, равным

fsStayOnTop. Главное назначение этой формы – быть индикатором запущенного