Файл: Варианты архитектуры клиент-сервер (Модели клиент-сервер).pdf

ВУЗ: Не указан

Категория: Курсовая работа

Дисциплина: Не указана

Добавлен: 25.06.2023

Просмотров: 83

Скачиваний: 3

ВНИМАНИЕ! Если данный файл нарушает Ваши авторские права, то обязательно сообщите нам.

Терминал – это интерфейсный компонент, который представляет первый уровень, собственно приложение для конечного пользователя. По требованиям первый уровень не должен иметь прямых связей с 22 базой, быть нагруженным основной бизнес-логикой и хранить состояние приложения. На первый уровень выносится простая бизнес-логика такие как: проверка вводимых значений на допустимость и соответствие формату, несложные операции с данными, уже загруженными на терминал, интерфейс авторизации, алгоритмы шифрования. Сервер приложений находится на 2-ом уровне. На 2-ом уровне сконцентрирована значительная часть бизнес-логики. За его пределами остаются элементы, экспортируемые на терминалы, а кроме того погруженные в третий уровень хранимые процедуры и триггеры. Сервер базы данных обеспечивает хранение данных и выносится на 3-ий уровень. Как правило это обычная объектно-ориентированная СУБД. Если 3-ий уровень представляет собой базу данных совместно с сохранёнными процедурами, триггерами и схемами, описывающие приложение в виде реляционной модели, то 2-ой уровень строится как программный интерфейс, связывающий клиентские элементы с прикладной логикой базы данных. В простейшей конфигурации, сервер приложений и сервер базы данных могут находиться на одной машине с подключенными к ней терминалами. Согласно требованиям безопасности, надежности, масштабирования конфигурации сервер должен находиться на отдельном компьютере, с подключенными к нему серверами приложений, к которым, в свою очередь, по сети подключаются терминалы.

Плюсами данной архитектуры являются:

  • Клиентское ПО не нуждается в администрировании;
  • Масштабируемость;
  • Конфигурируемость – изолированность уровней друг от друга позволяет быстро и простыми средствами переконфигурировать систему при возникновении сбоев или при плановом обслуживании на одном из уровней;
  • Высокая безопасность;
  • Высокая надежность;
  • Низкие требования к скорости канала (сети) между терминалами и

сервером приложений;

  • Низкие требования к производительности и техническим характеристикам терминалов, как следствие снижение их стоимости.

Минусами данной архитектуры являются:

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

администрирование и обслуживание;

  • Более высокая сложность создания приложений;
  • Сложнее в разворачивании и администрировании;
  • Высокие требования к производительности серверов приложений и сервера базы данных, а, значит, и высокая стоимость серверного оборудования;
  • Высокие требования к скорости канала (сети) между сервером базы данных и серверами приложений.

В рамках технологии "клиент-сервер" было, положено начало развития корпоративного программного обеспечения в многозвенной архитектуре. Совместно с клиентской частью приложения в них появились серверы приложений. Особенности:

  • Программа-клиент реализует GUI (graphical user interface), передает запросы серверу приложений и принимает от него ответ,
  • Сервер приложений создает бизнес-логику и обращается с запросами к серверу "3-его уровня",
  • Сервер 3-его уровня обслуживает запросы сервера приложений.

Программа-клиент, таким образом, может быть "тонкой". Данная архитектура имеет следующие преимущества:

  • Внесение изменений на каждом из звеньев можно производить независимо;
  • Звенья не обмениваются между собой большими объемами информации, что позволило снизить нагрузку на сеть;
  • Обеспечивается масштабирование и простая модернизация оборудования и программного обеспечения, поддерживающего каждое из звеньев, в том числе обновление серверного парка и терминального оборудования, СУБД и т.д.;
  • приложения могут разрабатываться на языках 3-его или 4-ого поколения например: Java, C/C++.

Следующий шаг – это увеличение количества звеньев, и возрастает не только благодаря разбиению при "утоньшении" каждого звена, но и вся бизнес-модель разрабатывается как многозвенная. Современные корпоративные программные системы это сложный комплекс взаимодействующих между собой на разных уровнях компонентов, каждые из которых могут играть роль клиента для одних компонентов и сервера для других. Часто встречаемой проблемой систем, основанных на двухзвенной и/или на многозвенной архитектуре, является требование к мобильности в как можно более широком классе аппаратно-программных сред. Но даже выбрав только UNIX-ориентированные локальные сети, то всё равно применяется разная аппаратура и протоколы связи. Попытки создания межплатформенных систем, приводит к их высокой загруженности сетевыми деталями в ущерб функциональности. Еще более затрудненный момент этой проблемы связан с возможностью использования разных представлений данных в разных узлах неоднородной локальной сети. В разных компьютерах может существовать различная адресация, представление чисел, кодировка символов и т.д. Это особенно важно для серверов высокого уровня, телекоммуникационных, вычислительных, баз данных. Общим решением проблемы мобильности такого рода систем является использование технологий, реализующие протоколы удаленного вызова процедур (RPC - Remote Procedure Call) стандартным и платформо-независимым способом. При использовании таких технологий обращение к сервису в удаленном узле выглядит как обычный вызов процедуры. Средства RPC, в которых, естественно, содержится вся информация о специфике аппаратуры локальной сети и сетевых протоколов, переводит вызов в последовательность сетевых взаимодействий. Тем самым, специфика сетевой среды и протоколов скрыта от прикладного программиста. При вызове удаленной процедуры, программы RPC производят изменение форматов данных с клиентской стороны в собственные форматы, и затем преобразование в форматы данных сервера. При отправлении ответных параметров производятся обратные преобразования. Благодаря этому системы основанные на стандартном пакете RPC, могут быть легко перенесены в любую открытую среду. К представлению относится вся информация, непосредственно отображаемая пользователю: сгенерированные html-страницы, таблицы стилей, изображения. Уровень представления охватывает все, что имеет отношение к общению пользователя с системой. К главным функциям слоя представления относятся отображение информации и интерпретация вводимых пользователем команд с преобразованием их в соответствующие операции в контексте логики и данных. Уровень логики содержит основные функции системы, предназначенные для достижения поставленной перед ним цели. К таким функциям относятся вычисления на основе вводимых и хранимых данных, проверка всех элементов данных и обработка команд, поступающих от слоя представления, а также передача информации уровню данных. Уровень доступа к данным – это подмножество функций, обеспечивающих взаимодействие со сторонними системами, которые выполняют задания в интересах приложения. Данные системы обычно хранятся в базе данных.


3.Модели клиент-сервер.

Существует, не меньше, 3-х вариантов модели клиент-сервер:

1. доступ к удаленным данным (RDA-модель);

2. сервер базы данных (DBS-модель);

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

RDA-модель и DBS-модель представляют собой двухзвенную архитектуру и поэтому не подходят в качестве базовой модели распределенной системы. AS-модель уже трехзвенная. Преимущество у этой модели в независимости интерфейса пользователя от компонентов обработки данных. Трехзвенной считают из-за наличия следующих черт:

  • компонент интерфейса с пользователем;
  • программное обеспечение промежуточного слоя (middleware);
  • компонент управления данными.

Middleware - это ключевой элемент трехзвенных распределенных систем. Он исполняет операции такие как - управление транзакцией и коммуникацией, транспортировка запросов и прочие функции. Присутствует базовое отличие среди технологий вида "сервер запросов — клиент запросов" и трехзвенными технологиями. В первоначальном случае клиент очевидным способом запрашивает данные, понимая структуру базы данных. Например, клиент отправляет на сервер СУБД, SQL-запрос, а в обратно получает данные. Создается жесткая связь типов, и для их создания все СУБД используют закрытый SQL-канал. Он строится двумя процессами: SQL/Net на компьютере-клиенте и SQL/Net на компьютере-сервере и порождается по инициативе клиента оператором connect. Канал называют закрытым из-за невозможности, написать программу, способная зашифровать SQL-запросы по особенному алгоритму или будет иначе вмешиваться в процесс передачи данных между клиентским и серверным приложением. В случае трехзвенной схемы клиент явно запрашивает один из сервисов, например, передавая ему некоторое сообщение, и получает ответ также в виде сообщения. Клиент направляет запрос во внешнюю среду, ничего не зная о месте расположения сервиса. Имеет место так называемая "поставка функций" клиенту. Для клиента сама база данных видна исключительно посредством набора сервисов. Более того, он вообще ничего не знает о ее существовании, т. к. все операции над базой данных выполняются внутри сервисов. Таким образом, речь идет о двух принципиально разных подходах к построению информационных систем клиент-сервер. Двухзвенная архитектура на сегодняшний день может считаться достаточно устаревшей и, в связи с развитием распределенных информационных систем, постепенно отходит на второй план. И если для быстрого создания несложных приложений с небольшим числом пользователей этот метод подходит как нельзя лучше, то при построении корпоративных распределенных информационных систем он абсолютно непригоден в силу вышеперечисленных причин. Термин "клиент-сервер" означает такую архитектуру программного комплекса, в которой его функциональные части взаимодействуют по схеме "запрос-ответ". Если рассматривать взаимодействующие части этого комплекса, то часть называемая клиент исполняет активную функцию, иначе говоря инициирует запросы, а серверная часть пассивную функцию отвечает на них. По ходу развития системы роли могут изменяться, например, некоторый программный блок будет одновременно выполнять функции сервера по отношению к одному блоку и клиента по отношению к другому. Любая информационная система должна иметь, следующие основные части - модули хранения данных, обработки и интерфейса. Каждая из этих частей может быть создана или изменена независимо друг от друга. Например, можно изменить графический интерфейс пользователя, не изменяя программы хранения и обработки данных. В обычной клиент-серверной архитектуре основные части приложения распределяют по двум физическим модулям. Как правило ПО хранения данных находится на сервере, интерфейс пользователя уже устанавливают на стороне клиента, а обработку данных разделяют между клиентом и сервером. В данном случаи и состоит главный недостаток двухуровневой архитектуры, с которого вытекают ряд неприятных отличительных черт, очень усложняющих разработку клиент-серверных систем. А именно, при разбиении алгоритмов обработки данных необходимо синхронизировать поведение обеих частей системы. Все разработчики обязаны обладать полной информацией о последних изменениях, внесенных в систему, и понимать эти изменения. Это требование вызывает большие сложности при разработке клиент-серверных систем, установке и сопровождении, поскольку необходимо тратить значительные усилия на координацию действий разных групп специалистов. При разработке часто появляются противоречия, что тормозит развитие системы и заставляет изменять готовые элементы. Чтобы избежать несогласованности частей архитектуры, то пытаются выполнить обработку данных на стороне клиента, либо на сервере. Каждый подход имеет свои недостатки. В первом способе нерационально используется сеть, по причине передачи необработанных, иначе говоря, избыточных данных. К тому же сложнее поддерживать системы и ее изменение, иначе могут возникнуть ошибки или несогласованность данных из-за того, что замена алгоритма вычислений или исправление ошибки требует одновременной полной замены всех интерфейсных программ. Если же вся обработка информации выполняется на сервере (когда такое вообще возможно), то возникает проблема описания встроенных процедур и их отладки. Дело в том, что язык описания встроенных процедур обычно является декларативным и, следовательно, в принципе не допускает пошаговой отладки. Кроме того, систему с обработкой информации на сервере абсолютно невозможно перенести на другую платформу, что является серьезным недостатком.


4.Толстый и тонкий клиенты.

Как значится в словаре Free Online Dictionary of Computing, тонкий клиент - это клиентское устройство (или программа), передающее большую часть исполняемых им функций серверу. Толстый клиент определить намного проще - это все клиенты, не являющиеся тонкими. Тонкий клиент (thin client) — терминал сети без собственных запоминающих устройств, которого вычислительная мощность и объем памяти ограничивается нуждами пользователя. Все программы и приложения, становятся доступны для пользователей при выполнении регистрации на сервере. Тонким клиентом называю компьютер, имеющий малую мощность железной начинки и позволяющий пользователю осуществлять ввод и вывод данных при помощи вычислительной мощности на более мощном компьютере или сервере, он осуществляет связь при помощи каналов средней пропускной способности, так же к данному клиенту возможно подключение устройств ввода/вывода данных такие как - сканеры, мониторы, принтеры и проекторы. Клиент называется тонким, если он не имеет совсем или имеет лишь малую часть бизнес-логики, т. е. отображает только графический интерфейс пользователя. Толстым клиентом называются клиенты, имеющие основную часть бизнес-логики. Лучший и часто встречаемый пример тонкого клиента является Web-браузер, он настолько универсальный, что способен работать с полностью разным прикладным программам, о которых не имеет информации, и, тем не менее обеспечивает пользователя удобным интерфейсом. Упрощение технологии обслуживания рабочих мест используя соответствующие сервисные инструменты, позволяет администратору системы единовременно обслуживать любое количество устройств. Так же возможность контроля за действиями пользователя обеспеченное отсутствию накопителей на рабочем месте клиента, пользователь не может вносить свои изменения в конфигурацию программного обеспечения или устанавливать свои программы. Мобильность пользователей, не привязанный к конкретному рабочему месту, может на своё усмотрение перемещаться в пределах локальной сети, применяя устройства дистанционного доступа. Тонкий клиент позволяет сэкономить на эксплуатации при не слишком большом различии в стоимости оборудования. Технология «тонкий клиент-сервер» основан на 3-х составляющих:

1) стопроцентное выполнение прикладных задач на терминальном сервере,

2) многопользовательская операционная система,


3) технология распределенного отображения пользовательского интерфейса приложений.

Пользователи имеют возможность одновременно заходить в систему и выполнять приложения на сервере в разных, защищенных друг от друга сессиях сервера. В системе с использованием тонкого клиента по сети или коммутируемой телефонной линии на сервер передаются сигналы, отражающие нажатие на ту или иную клавишу либо то или иное движение мыши. А сервер производит соответствующие действия и формирует изменения экрана пользователя и передаѐт эти изменения тонкому клиенту. Тонкий клиент получает от сервера изменѐнные образы экрана и отображает их на дисплее (в современных системах может передаваться не весь изменѐнный экран, а лишь части изображения с соответствующими командами, на основании которых программное обеспечение тонкого клиента формирует изменѐнную картинку). В роли клиента может выступать любой ПК, но, поскольку на нем почти не выполняются операции по обработке данных, в качестве тонких клиентов можно применять и недорогие терминалы, имеющие низкую производительность, не содержащие компоненты с движущимися частями, оснащенные, как правило, устройствами с весьма ограниченным объемом ОЗУ. При работе в терминальной системе все прикладные программы, данные и параметры настроек хранятся на сервере. Это дает много преимуществ в плане начального развертывания рабочих мест одно из них — это отсутствие необходимости устанавливать ПО на каждом терминале, что дает больше удобства проведения резервного копирования данных, восстановления сессий после сбоев. Технология тонкого клиента имеет преимущество - она ориентирована на дистанционный доступ для сотрудников. Это позволяет работать вне офиса или рабочего места. При необходимости повысить вычислительную мощность всей системы достигается заменой всего лишь одного устройства – терминального сервера, все рабочие места автоматически переходят на более высокий уровень производительности без необходимости замены каких-либо устройств. Толстый или Rich-клиент - это приложение, обеспечивающее (в противовес тонкому клиенту) расширенную функциональность независимо от центрального сервера. Часто сервер в этом случае является лишь хранилищем данных, а вся работа по обработке и представлению этих данных переносится на машину клиента.

Достоинства:

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