Клиент-серверная архитектура (курсовая) (548451), страница 4

Просмтор этого файла доступен только зарегистрированным пользователям. Но у нас супер быстрая регистрация: достаточно только электронной почты!

Текст из файла (страница 4)

2.2.3.1. Представление многоуровневой архитектуры "клиент-сервер"Терминал – это интерфейсный (обычно графический) компонент,который представляет первый уровень, собственно приложение дляконечного пользователя. Первый уровень не должен иметь прямых связей с21базой данных (по требованиям безопасности), быть нагруженным основнойбизнес-логикой (по требованиям масштабируемости) и хранить состояниеприложения (по требованиям надежности). На первый уровень может бытьвынесена и обычно выносится простейшая бизнес-логика: интерфейсавторизации, алгоритмы шифрования, проверка вводимых значений надопустимость и соответствие формату, несложные операции (сортировка,группировка, подсчет значений) с данными, уже загруженными на терминал.Сервер приложений располагается на втором уровне. На втором уровнесосредоточена большая часть бизнес-логики.

Вне его остаются фрагменты,экспортируемые на терминалы, а также погруженные в третий уровеньхранимые процедуры и триггеры.Сервер базы данных обеспечивает хранение данных и выносится натретий уровень. Обычно это стандартная реляционная или объектноориентированная СУБД. Если третий уровень представляет собой базуданныхвместесхранимымипроцедурами,триггерамиисхемой,описывающей приложение в терминах реляционной модели, то второйуровень строится как программный интерфейс, связывающий клиентскиекомпоненты с прикладной логикой базы данных.В простейшей конфигурации физически сервер приложений можетбыть совмещен с сервером базы данных на одном компьютере, к которому посети подключается один или несколько терминалов.В"правильной"(сточкизрениябезопасности,надежности,масштабирования) конфигурации сервер базы данных находится навыделенном компьютере (или кластере), к которому по сети подключеныодин или несколько серверов приложений, к которым, в свою очередь, посети подключаются терминалы.Плюсами данной архитектуры являются:клиентское ПО не нуждается в администрировании;масштабируемость;22конфигурируемость – изолированность уровней друг от другапозволяет быстро и простыми средствами переконфигурироватьсистему при возникновении сбоев или при плановом обслуживании наодном из уровней;высокая безопасность;высокая надежность;низкие требования к скорости канала (сети) между терминалами исервером приложений;низкиетребованиякпроизводительностиитехническимхарактеристикам терминалов, как следствие снижение их стоимости.Минусами данной архитектуры являются:растет сложность серверной части и, как следствие, затраты наадминистрирование и обслуживание;более высокая сложность создания приложений;сложнее в разворачивании и администрировании;высокие требования к производительности серверов приложений исервера базы данных, а, значит, и высокая стоимость серверногооборудования;высокие требования к скорости канала (сети) между сервером базыданных и серверами приложений.Начало процессу развития корпоративного программного обеспечения вмногозвенной архитектуре было положено еще в рамках технологии "клиентсервер".

В них наряду с клиентской частью приложения и сервером базданных появились серверы приложений (Application Servers).В идеале:программа-клиентреализуетGUI,передаетзапросысерверуприложений и принимает от него ответ,сервер приложений реализует бизнес-логику и обращается с запросамик серверу "третьего уровня" (например, серверу базы данных заданными),23сервер третьего уровня обслуживает запросы сервера приложений.Программа-клиент, таким образом, может быть "тонкой".Преимущества такой архитектуры очевидны: изменения на каждом из звеньев можно осуществлять независимо; снижаются нагрузки на сеть, поскольку звенья не обмениваются междусобой большими объемами информации; обеспечиваетсямасштабированиеипростаямодернизацияоборудования и программного обеспечения, поддерживающего каждоеиз звеньев, в том числе обновление серверного парка и терминальногооборудования, СУБД и т.д.; приложения могут создаваться на стандартных языках третьего иличетвертого поколения (Java, C/C++).Следующий логический шаг - дальнейшее увеличение числа звеньев,причем возрастет не только за счет разбиения, когда "утоньшается" каждоеиз известных технических звеньев, но вся бизнес-модель строится какмногозвенная.Современныекорпоративныепрограммныесистемыпредставляют собой, как правило, сложные системы взаимодействующихмежду собой на разных уровнях компонентов, каждые из которых могутявляться клиентами для одних компонентов и серверами для других.Основной проблемой систем, основанных на двухзвенной архитектуре"клиент-сервер", или тем более на многозвенной архитектуре, является то,что от них требуется мобильность в как можно более широком классеаппаратно-программныхсред.ДажееслиограничитьсяUNIX-ориентированными локальными сетями, в разных сетях применяется разнаяаппаратура и протоколы связи.

Попытки создания систем, поддерживающихвсе возможные протоколы, приводит к их перегрузке сетевыми деталями вущерб функциональности. Еще более сложный аспект этой проблемы связанс возможностью использования разных представлений данных в разныхузлах неоднородной локальной сети. В разных компьютерах можетсуществоватьразличнаяадресация,24представлениечисел,кодировкасимволов и т.д. Это особенно существенно для серверов высокого уровня:телекоммуникационных, вычислительных, баз данных.Общим решением проблемы мобильности такого рода систем являетсяиспользование технологий, реализующие протоколы удаленного вызовапроцедур (RPC - Remote Procedure Call) стандартизованным и платформонезависимым способом.

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

[11]Некоторыеавторыпредставляют(трехзвенную) в виде пяти уровней (рис 2.2.3.2)1. Представление;2. Уровень представления;3. Уровень логики;4. Уровень данных;5. Данные.25многозвеннуюархитектуруРис. 2.2.3.2. Пять уровней многозвенной архитектуры "клиент-сервер"Кпредставлениюотноситсявсяинформация,непосредственноотображаемая пользователю: сгенерированные html-страницы, таблицыстилей, изображения.Уровень представления охватывает все, что имеет отношение кобщению пользователя с системой.

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

[12]262.2.4. Модели клиент-сервер.Существует, по меньшей мере, три модели клиент-сервер:1. модель доступа к удаленным данным (RDA-модель);2. модель сервера базы данных (DBS-модель);3. модель сервера приложений (AS-модель).Первые две модели являются двухзвенными и не могут рассматриваться вкачестве базовой модели распределенной системы. Третья модель —трехзвенная. Она (как и все многозвенные модели) хороша тем, что в нейинтерфейс работы с пользователем полностью независим от компонентаобработки данных.

Собственно, трехзвенной ее можно считать постольку,поскольку в ней явно выделены:компонент интерфейса с пользователем;программное обеспечение промежуточного слоя (middleware);компонент управления данными.Middleware — это главный компонент трехзвенных распределенныхсистем.Онвыполняетфункцииуправлениятранзакциямиикоммуникациями, транспортировки запросов, управления именами и иныефункции.Существует фундаментальное различие между технологией типа"сервер запросов — клиент запросов" и трехзвенными технологиями. Впервом случае клиент явным образом запрашивает данные, зная структурубазы данных (имеет место так называемая "поставка данных" клиенту).Клиент передает СУБД, например, SQL-запрос, а в ответ получает данные.Осуществляется жесткая связь типов, для реализации которой все СУБДиспользуют закрытый SQL-канал.

Он строится двумя процессами: SQL/Netна компьютере-клиенте и SQL/Net на компьютере-сервере и порождается поинициативе клиента оператором connect. Канал называется закрытым в томсмысле, что невозможно, например, написать программу, которая будетшифровать SQL-запросы по специальному алгоритму или другим образом27будет вмешиваться в процесс передачи данных между клиентским исерверным приложением.В случае трехзвенной схемы клиент явно запрашивает один изсервисов (предоставляемых прикладным компонентом), например, передаваяему некоторое сообщение, и получает ответ также в виде сообщения. Клиентнаправляет запрос во внешнюю среду, ничего не зная о месте расположениясервиса. Имеет место так называемая "поставка функций" клиенту.Для клиента сама база данных видна исключительно посредствомнабора сервисов.

Характеристики

Список файлов курсовой работы