Технология модели клиент-сервер Системные модели

Технология модели «клиент-сервер»

Системные модели • • • Системная модель определяет: Архитектуру информационной системы Роли и функции компонентов системы Правила взаимодействия компонентов Состав оборудования Состав программных средств, необходимых для функционирования системы

Программные средства • Программы общего назначения (например, операционные системы) • Системы управления базами данных • Специализированные пакеты программ • Уникальные программные компоненты (созданные для этой информационной системы)

Роли программных компонентов • Клиент: реализует взаимодействие с человеком • Функциональный модуль: реализует основные функции системы • Сервер данных: обеспечивает хранение и доступ к хранимой информации • Преобразователь данных • Другие

Классы архитектур информационных систем • • Однокомпонентные Клиент-сервер Многослойные архитектуры (обычно 3) Гибридные архитектуры

Роли • Компьютер, управляющий тем или иным ресурсом, принято называть сервером этого ресурса • Компьютер, желающий воспользоваться ресурсов – клиентом. • Программы – аналогично • Можно для одного ресурса выполнять роль клиента, для другого - сервера

4 группы функций приложения: • функции ввода и отображения данных • прикладные функции • фундаментальные функции хранения и управления информационными ресурсами • служебные функции, играющие роль связок между функциями первых трех групп.

Логические компоненты приложения: • компонент представления, реализующий функции первой группы; • прикладной компонент, поддерживающий функции второй группы; • компонент доступа к информационным ресурсам,

Различия в реализациях технологии «клиент-сервер» • В какие виды программного обеспечения интегрированы каждый из компонентов • Какие механизмы программного обеспечения используются для реализации функций всех трех групп. • Как логические компоненты распределяются между компьютерами в сети. • Какие механизмы используются для связи компонентов между собой.

Однокомпонентные системы • Все роли программных компонентов реализуются в одной компоненте • Специализированный код встроен в базу данных (или наоборот) • Как правило, однопользовательские • Многие роли необязательны • Могут работать автономно

Архитектура клиент-сервер • Роли клиента и сервера данных выполняются, вообще говоря, на разных системах • Толстые и тонкие клиенты • Особенности: – Постоянное соединение на время сеанса – Совместное использование данных – Высоконадежные системы для ограниченного количества пользователей

Выделяются четыре подхода, реализованные в моделях: • модель файлового сервера (File Server – FS); • модель доступа к удаленным данным (Remote Access Data – RDA); • модель сервера базы данных (Data. Base Server – DBS); • модель сервера приложений (Application Server – AS).

Файловый сервер (FS) Компонент представления Прикладной компонент Клиент файлы Компонент доступа к ресурсам Сервер

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

Файловый сервер (FS) • Высокий трафик (передача множества файлов, необходимых приложению) • Узкий спектр операций манипуляции с данными ( «данные – это файлы» ) • Отсутствие адекватных средств безопасности доступа к данным (защита только на уровне файловой системы) и т. д.

Модель доступа к удаленным ресурсам (RDA) SQL Компонент представления Прикладной компонент Клиент данные Компонент доступа к ресурсам Сервер

Модель доступа к удаленным ресурсам (RDA) • унификация интерфейса «клиент-сервер» в виде языка SQL • перенос компонента представления и прикладного компонента на компьютерыклиенты существенно разгружает сервер БД • администрирование приложений практически невозможно из-за совмещения в одной программе различных по своей природе функций (функции представления и прикладные).

Модель сервера базы данных (DBS) Компонент представления Клиент Вызов данные Прикладной компонент Компонент доступа к ресурсам Сервер

Модель сервера базы данных (DBS)- особенности • Основа - механизм хранимых процедур. Процедуры хранятся в словаре базы данных, разделяются между несколькими клиентами и выполняются на том же компьютере, где функционирует SQL–сервер. • Язык, на котором разрабатываются хранимые процедуры, представляет собой процедурное расширение языка запросов SQL и уникален для каждой конкретной СУБД.

Модель сервера базы данных (DBS)- достоинства • Возможность централизованного администрирования прикладных функций • Снижение трафика (вместо SQL–запросов по сети направляются вызовы хранимых процедур) • Возможность разделения процедуры между несколькими приложениями, и экономия ресурсов компьютера за счет использования единожды созданного плана выполнения процедуры.

Модель сервера базы данных (DBS) - недостатки • Ограниченность средств, используемых для написания хранимых процедур, которые представляют собой разнообразные процедурные расширения SQL, не выдерживающие сравнения по изобразительным средствам и функциональными возможностями с языками третьего поколения. • Сфера их использования ограничена конкретной СУБД, не во всех СУБД отсутствует возможность отладки и тестирования хранимых процедур.

RDA + DBS • Поддержка целостности базы данных и некоторые простейшие прикладные функции поддерживаются хранимыми процедурами (DBS-модель), • Более сложные функции реализуются непосредственно в прикладной программе, которая выполняется на компьютереклиенте

Модель сервера приложений Компонент представления Клиент API Прикладной компонент Сервер Компонент доступа к ресурсам Сервер

Трехуровневые ИС • Количество уровней (слоев) программного обеспечения может быть больше двух. (WEBбраузер WEB-сервер баз данных. • Поскольку с самого сервера баз данных можно обращаться с запросами к другим серверам, то теоретически может быть построена система, имеющая более чем три уровня. Возможно выделение специфических функций приложения на отдельный сервер приложений. Такая модель называется также AS-модель (AS – Application Server).

Достоинства многоуровневых архитектур • Существует большое количество компонентов • Массовое использование в относительно простых системах • Средства генерации кода

Недостатки многослойных систем • Неэффективное использование серверов данных • Слишком большое количество сетевых обменов • Искусственное привязывание ролей к слоям

Многослойные архитектуры • Обычно различают 3 слоя – Клиент <-> > представление – Средний слой <-> функциональность – Сервер данных <-> хранение

«Толстые» и «тонкие» клиенты • «Тонкий» клиент - только запуска сетевого приложения через web-интерфейс. • «Толстый» клиент - совмещает компонент представления данных (графический пользовательский интерфейс ОС) и прикладной компонент (вычислительные мощности клиентского компьютера).

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

АКТИВНЫЙ СЕРВЕР • Данные должны быть взаимно непротиворечивы. • База данных должна отражать некоторые правила предметной области, по которым она функционирует. • Необходим постоянный контроль за состоянием базы данных, отслеживание всех изменений и адекватная реакция на них. • Необходимо, чтобы возникновение некой ситуации в базе данных четко и оперативно влияло на ход выполнения прикладной программы.

Активный сервер включает в себя: • • процедуры базы данных; правила (триггеры); события в базе данных; типы данных, определяемые пользователем.

Процедуры базы данных • Общие части (часто используемые) прикладных программ оформляются в отдельные процедуры, которые хранятся непосредственно в базе данных. • Одна процедура может использоваться несколькими прикладными программами. • Сокращаются затраты на написание прикладных программ – они составляются из готовых процедур. • Прикладная программа, вызывающая процедуру, передает серверу лишь ее имя и параметры.

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

События в базе данных • Механизм событий в базе данных позволяет прикладным программам и серверу базы данных уведомлять другие программы о наступлении в базе данных определенного события и тем самым синхронизировать их работу. • Различные прикладные программы и процедуры вызывают события в базе данных, а сервер оповещает монитор прикладных программ об их наступлении. Реакция монитора на события заключается в выполнении действий, которые предусматривает его разработчик.

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

Типы данных, определяемые пользователями • Описание нового типа данных хранится в базе данных и его обработка происходит так же, как и обработка стандартных типов данных.

Распределенные ИС • Процессы децентрализации и информационной интеграции. • Адекватное развитие глобальной сетевой инфраструктуры • Применении реальных технологий создания распределенных информационных систем.

Распределенные ИС

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

Распределенные ИС • РБД состоит из набора узлов, связанных коммуникационной сетью, в которой: – каждый узел — это полноценная СУБД сама по себе; – что пользователь любого узла может получить доступ к любым данным в сети так, как будто они находятся на его собственном узле. • Для пользователя распределённая система должна выглядеть так же, как нераспределённая система.

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

Типы распределенных архитектур • Системы недублирующего разбиения (при большом объеме часто меняющихся данных) • Системы частичного дублирования (при небольшом объеме часто меняющихся данных) • Системы полного дублирования (при небольшом объеме редко меняющихся данных)

Определение Дэйта распределенных баз данных (DDB) • • • • Локальная автономия (local autonomy) Независимость узлов (no reliance on central site) Непрерывные операции (continuous operation) Прозрачность расположения (location independence) Распределенные ограничения целостности Прозрачная фрагментация (fragmentation independence) Прозрачное тиражирование (replication independence) Обработка распределенных запросов (distributed query processing) Обработка распределенных транзакций (distributed transaction processing) Независимость от оборудования (hardware independence) Независимость от операционных систем (operating system independence) Прозрачность сети (network independence) Независимость от баз данных (database independence)

Локальная автономия • Узлы в распределённой системе должны быть независимы, или автономны. Локальная независимость означает, что все операции на узле контролируются этим узлом.

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

Непрерывные операции • Это качество можно трактовать как возможность непрерывного доступа к данным ("24 часа в сутки, семь дней в неделю"). «Данные доступны всегда, а операции над ними выполняются непрерывно» . • Обработка, выполняемая в локальном узле БД, не может быть прервана командами из другого узла. Т. е. в каждом узле обработка выполняется независимо и целиком.

Прозрачность расположения • Пользователь ничего не должен знать о реальном, физическом размещении данных в узлах информационной системы. Все операции над данными выполняются без учета их местонахождения. Транспортировка запросов к базам данных осуществляется встроенными системными средствами. • Изменение места хранения данных не ведет к изменению работающих с этими данными приложений.

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

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

Обработка распределенных запросов • Это возможность выполнения операций выборки над распределенной базой данных, сформулированных в рамках обычного запроса на языке SQL. То есть операцию выборки из DDB можно сформулировать с помощью тех же языковых средств, что и операцию над локальной базой данных. Например,

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

Независимость от оборудования • Это свойство означает, что в качестве узлов распределенной системы могут выступать компьютеры любых моделей и производителей - от мэйнфреймов до "персоналок".

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

Прозрачность сети • Доступ к любым базам данных может осуществляться по сети. В распределенной системе возможны любые сетевые протоколы.

Независимость от СУБД • Это качество означает, что в распределенной системе могут сосуществовать СУБД различных производителей, и возможны операции поиска и обновления в базах данных различных моделей и форматов.