Добавил:
ivanov666
Опубликованный материал нарушает ваши авторские права? Сообщите нам.
Вуз:
Предмет:
Файл:Введение в распределенные системы. Учебное пособие
.pdf
Клиент
Запрос
Сервер
Рис. 4. Модель взаимодействия "клиент-сервер"
Модель, представленная на рис. 4, дает всего лишь
сведения об организации обмена информацией. Она широко
используется на практике, но ее реализация в различных программных продуктах имеет свои особенности. Модель предполагает разделение функций разрабатываемого приложения
на три части, принипиально отличающихся друг от друга.
Одна из них отвечает за функции ввода и отображения информации. Другая – за прикладные функции, присущие сфере
использования приложения. Последняя – за функции хранения и управления данными (БД, файловыми системами и
т. д.).
В соответствие со сказанным выше стандартное приложение структурно разделяется на три составляющих:
компоненту представления (поддержка функ-
ций ввода и отображения информации);
прикладную компоненту (поддержка приклад-
ных функций);
компоненту доступа к информационным ре-
сурсам или менеджер ресурсов (поддержка функций последней группы).
Разновидности модели «клиент-сервер» перечислены
ниже:
41
модель доступа к удаленным данным (Remote
Date Access - RDA);
модель сервера базы данных (DateBase Server -
DBS);
модель сервера приложений (Application Server -
AS).
Функции первых двух компонентов реализуются на
стороне клиента. Поскольку клиентом поддерживаются
функции ввода и отображения информации, а также прикладные функции, то организовать доступ к информационным ресурсам можно при помощи операторов специального язнка
(например, SQL для обращения к БД) или посредством вызова функций специальной библиотеки (при наличии требуемого API). Под API (application programming interface) понимают интерфейс программирования приложений, т.е. набор готовых классов, процедур, функций, структур и констант, востребованных во внешних программных продуктах. В RDAмодели запросы к информационным ресурсам посылаются по
сети удаленному компьютеру-серверу (например, серверу
БД). На стороне сервера запросы обрабатываются, выполняются, и клиенту отправляются результаты выполнения запросов. На рис. 5 структурно проиллюстрирована реализация
обмена, предусмотренного в рассмотренной выше модели.
В DSB-модели процессы на стороне клиента реализуют лишь функции представления. На рис. 6 структурно проиллюстрирована реализация обмена, предусмотренного в
DSB-модели. Прикладные функции реализованы в хранимых
процедурах (в литературе используются синонимы - компилируемые резидентные процедуры, процедуры БД). Из рисунка видно, что весь этот функционал, а также БД и ядро
СУБД (управляет доступом к данным, хранящимся в БД),
находятся на компьютере-сервере.
Понятие информационного ресурса в RDA-модели
ограничено БД. Это обстоятельство объясняется тем, что ме-
42
ханизм хранимых процедур (отличительная черта DBS-
Запрос
Блоки
клиент
Комп
о-
ления
При
кла
д-
Компо-
Запрос
SQL
модели) имеется только в СУБД.
Компонент
представле-
ния
Компьютер-клиент
Прикладной
компонент
данных
Компьютер-сервис
Рис. 5. Модель доступа к удаленным данным
нент
представ-
Компьютер-
ной ком-
понент
Компьютер-сервер
Рис. 6. Модель сервера базы данных
Компонент
дрступа к
ресурсам
нент
дрступа
к БД
БД
На рис. 6 представлена стандартная модель. На практике она может видоизменяться. Поддержка целостности БД,
а также ряд простых прикладных функций осуществляются
хранимыми процедурами на стороне сервера, а сложные
функции предметной области – в прикладной программе, выполняемой на компьютере-клиенте. В таких ситуациях говорят об использовании смешанной модели RDA и DBS.
Таким образом, схема разделения функций определяет
основное различие RDA- и DBS- моделей. В RDA-модели
43
сторона клиента обеспечивает выполнение прикладных
Комп
о-
ления
При
кла
д-
Компо
нент
Запрос Вызов
функций, а прикладной компонент и компонент представления представляют собой единое целое. В DBS-модели ядро
СУБД обеспечивает выполнение прикладных функций. Компонент доступа к БД и прикладной компонент представляют
собой единое целое.
Рассмотренные выше классы двухзвенных системы
относят к РС условно. Представители этих классов считаются
простейшими РС.
Дальнейшим развитием двухзвенных моделей являются трехзвенные. Рис. 7 структурно представляет такую модель
РС. Она имеет свое название – AS-модель. Рисунок показывает, что процесс, осуществляющий ввод и отображение данных, выполняется на компьютере-клиенте, а процессы, реализующие прикладные функции, – на стороне сервера. Группу
процессов, реализующих прикладные функции, называют
серверами приложений. Серверы приложений размещаются
на одном или нескольких удаленных компьютерах. Доступ к
информационным ресурсам осуществляется так же, как и
аналогично RDA-модели.
Транзакция – это группа логически объединённых последовательных операций по работе с данными, обрабатываемая или отменяемая целиком. Отдельный процесс – мони-
тор транзакций – координирует все транзакции.
нент
представ-
ной ком-
понент
дрступа к
ресурсам
Компьютер-клиент
Компьютер-сервер
Компьютер-сервер
Рис. 7. Модель сервера приложений
44
Прикладным компонентам РС доступны общие ресурсы: БД, очереди, обслуживание запросов и др. Серверы приложений реализуются обычно на компьютере, где функционирует менеджер ресурсов. Допускается реализация на других компьютерах. На уровне прикладного компонента используются технологии многозадачной ОС и имеются стандарты интерфейсов с двумя другими компонентами ASмодели.
На стороне сервера приложения имеется ряд прикладных функций, предназначенных для предоставления определенных услуг программам, имеющим возможность ими пользоваться. Серверов приложений может быть несколько. За
каждым из них закреплен лишь определенный набор услуг.
Особенности реализации прикладных функций в сервере
приложений являются прозрачными для клиента приложения.
Клиент всегда обращается с запросом не к серверу приложений, а к какой-то определенной службе сервера. Такая технология эффективна для управления балансом загрузки. Запросы от клиентов организуются в очередь к процессу сервера
приложений. Каждый такой запрос имеет свой приоритет.
Согласно приоритету сервер приложений достает очередной
запрос и отсылает его требуемой службе.
Клиенту присущи самые различные функции: поддержка интерфейса с конечным пользователем (выступает как
компонент представления); обеспечение обмена информацией с периферийными устройствами и др. Клиенту могут
назначаться функции сервера приложений – технология
предназначена для реализации многоуровневых РС. При этом
в AS системах не ограничивается количество уровней серверов.
6.2. Понятие промежуточной среды
С позиций одного из компьютеров РС, другие входящие в РС компьютеры являются удаленными системами.
Теоретически взаимодействие удаленных систем внутри РС
45
основывается на модели взаимодействия открытых систем
OSI/ISO (Open Systems Interconnection). Согласно стандартам
модели процесс взаимодействия двух сторон разделяется на 7
уровней: физический, канальный, сетевой, транспортный, сеансовый, прикладной, представительский. Приложение содержит описание модели.
Стандартные протоколы определяют процессы взаимодействия узлов в открытых системах. Стек протоколов это иерархически организованный набор сетевых протоколов,
достаточный для организации взаимодействия узлов в сети. В
сетях распространенного стека протоколов TCP/IP
(Transmission Control Protocol/Internet Protocol) протокол TCP
есть протокол транспортного уровня, а IP – протокол сетевого
уровня. Интерфейс к транспортному уровню обычно обеспечивает сетевая компонента ОС. При этом интерфейс для
верхних уровней обычно основывается на сокетах.
Со кет – это название программного интерфейса,
обеспечивающего обмен данными между процессами. При
этом процессы могут выполняться как на одном, так и на различных компьютерах одной сети.
Протокол TCP/IP дает возможность организовать путем использования сокетов стандартный, межплатформенный, но низкоуровневый сервис для обмена данными между
компонентами. Функции высоких уровней – сеансового и
представительского – выполняет промежуточная среда (другое встречающееся в литературе название – промежуточное
программное обеспечение). Эта среда позволяет организовать
взаимодействие различных компонент РС, и тем самым помогает создавать открытые, масштабируемые и устойчивые РС.
Одна РС может использовать несколько видов промежуточных сред. Выделение промежуточного уровня является
изменением базовой модели OSI. Промежуточный уровнь заменяет уровени представления и сеансовый, т.е. вместо двух
уровней используется один, содержащий протоколы, не зависящие от приложений.
46
Службы промежуточной среды обеспечивают:
– единое и независимое от механизма ОС использование одними программными компонентами служб других
компонент;
– безопасность РС;
– целостность данных;
– балансировку нагрузки на серверы с программными
компонентами;
– обнаружение удаленных компонент.
6.3. Концепции взаимодействия программных
компонент
Взаимодействия программных компонент могут осу-
ществляться посредством:
1) обмена сообщениями между компонентами;
2) вызова процедур или методов объекта удаленной
компоненты (по аналогии с локальными вызовами процедуры).
В конечном итоге, в основе перечисленных взаимодействий лежит использование сокетов TCP/IP. Первичным, с
позиций промежуточной среды, является обмен посредством
сообщений на низком уровне. Он проводится на основе сетевых сокетов, сервис которых не устанавливает формат для
передаваемого сообщения. Затем, посредством протоколов
TCP или HTTP (HyperText Transfer Protocol), могут быть
сформированы прикладные протоколы обмена сообщениями
более высокого уровня абстракции. Подобная технология
позволяет реализовать различные и достаточно сложные алгоритмы обмена сообщениями, а также удаленный вызов
процедур.
6.3.1. Обмен сообщениями
Обмен сообщениями между удаленными системами
может осуществляться следующими двумя методами: непо-
47
средственный обмен сообщениями и использование очередей сообщений.
Первый метод предполагает, что передача сообщения
происходит напрямую, но необходимо учитывать готовность
принимающей стороны к принятию сообщения.
Второй метод передачи сообщения невозможен без
посредника – менеджера очередей сообщений. Согласно
этой технологии программный компонент передается сообщение в одну из очередей менеджера, параллельно с работой
менеджера и независимо от него. Программный компонент не
прекращает свою работу, а сообщение выбирается из очереди
менеджера принимающей стороной, и далее происходит его
обработке.
Область промежуточного программного обеспечения
богата разработками: Microsoft Message Queuing, IBM
MQSeries, Sun Java System Message Queue и др. В рамках
этой технологии промежуточная среда позволяет:
добавить сообщение в очередь;
проверить наличие сообщений в очереди;
выбрать из очереди первое сообщение;
приостановить процесс, пока в очереди не появится
хотя бы одно сообщение;
установить обработчик, вызываемый при появле-
нии сообщений в очереди.
Как менеджер очереди сообщений, так компоненты, и
принимающие участие в обмене, могут размещаться на разных компьютерах. В этом случае сообщение сначала помещается в очередь на компьютере, на котором содержится компонента, посылающая сообщение, а затем передается менеджеру.
Маршрутизация сообщений применяется для достаточно сложных систем обмена. Такая технология предполагает, что сообщения передаются через несколько промежуточных менеджеров очередей сообщений. Схематично передача
48
Приложение
Мененджеры очередей
Сервер
Промежуто
ч-
Промежуто
ч-
Промежуточная
Очередь Очередь
сообщений с использованием очередей сообщений представлена на рис. 8.
Клиент
Клиент
Приложение Приложение
сообщений
ная среда
Исходящая
среда
ная среда
Рис. 8. Системы очередей сообщений
Основные достоинства технологии передачи сообщений с использованием очередей сообщений:
– независимость друг от друга времени функционирования сервера и времени работы клиентов;
– независимость промежуточной среды от средств разработки компонент и используемого языка программирования;
– упрощение алгоритмов разработки устойчивых и
масштабируемых РС благодаря тому, что считывание и обработка заявки из очереди может выполняться несколькими независимыми компонентами;
Недостатки систем очередей сообщений:
необходимость явного использования очередей со-
общений;
алгоритмы синхронного обмена отличаются сложно-
стью;
применение менеджеров очередей требует опреде-
ленные накладные расходы;
49
для каждого компонента, отправляющего заявки,
требуется очередь, что обуславливает сложность получения
ответа на запрос.
6.3.2. Удаленный вызов процедур
Технология удаленного вызова процедур RPC (remote
procedure call) разрабатывалась в середине 80-х годов про-
шлого столетия. Смысл этой технологии – использование
промежуточной программной среды для вызова функции на
удаленном компьютере по аналогии с вызовом функции на
локальном компьютере.
Чтобы разобраться в сути технологии вспомним некоторые определения.
Процесс — это выполнение инструкций компьютерной программы на процессоре ЭВМ.
Процедура - это подготовленный специальными синтаксическими средствами фрагмент программы, доступный
для других программ через применение стандартных операций вызова процедур.
Процедура-заглушка – это фиктивная часть заменяемого фрагмента (модуля), которая удовлетворяет требованиям интерфейса, но не выполняет функций фрагмента (модуля), или выполняет их частично.
Процедура-заглушка используется для того, чтобы
удаленный вызов происходил прозрачно, т.е. программист не
замечал, откуда вызывается процедура. Клиентскому приложению для вызова процедура-заглушка (stub) предоставляется промежуточной средой.
Технология RPC очень результативна в приложениях,
имеющих интерактивную связь между удаленными компонентами, где имеются относительно небольшая временная
длительность ответов и небольшое количество передаваемых
данных. Подобные приложения именуются RPC-
ориентированными. С позиций реализации вызовы локаль-
ных процедур проще, чем RPC вызовы, поскольку реализация
50
Соседние файлы в предмете [НЕСОРТИРОВАННОЕ]