1. Характеристика технологии «Клиент – сервер»
1.2 Двухзвенная архитектура «Клиент-сервер»
1.5 Модель доступа к удаленным данным
Введение
Распространение архитектуры «клиент-сервер» стало возможным благодаря развитию и широкому внедрению в практику концепции открытых систем.
Основным смыслом подхода открытых систем является упрощение комплексирования вычислительных систем за счет международной и национальной стандартизации аппаратных и программных интерфейсов.
В основе широкого распространения локальных сетей компьютеров лежит известная идея разделения ресурсов. Высокая пропускная способность локальных сетей обеспечивает эффективный доступ из одного узла локальной сети к ресурсам, находящимся в других узлах.
Развитие такой идеи приводит к функциональному выделению компонентов сети: нужно иметь не только доступ к ресурсам удаленного компьютера, но также получать от компьютера некоторый сервис, который специфичен для ресурсов данного рода и программные средства. Так мы приходим к различению клиентов и серверов локальной сети.
Технология “клиент-сервер” применительно к СУБД сводится к разделению системы на две части: приложение-клиент и сервер базы данных. Эта архитектура совмещает лучшие черты обработки данных при помощи мэйнфреймов и файл-серверов. От систем для мэйнфрейма в технологию «клиент-сервер» была добавлена такая функция, как централизованное администрирование, безопасность, надежность работы. У технологии файл-серверных машин была перенята низкая стоимость нужного оборудования и возможность распределенного обрабатывания данных, используя при этом ресурсы компьютера-клиента. Со времени возникновения архитектуры клиент-сервер появилось много вариантов архитектуры процессора баз данных, поскольку он во многом определяет успех всей системы.
1. Характеристика технологии «Клиент – сервер»
Технология «Клиент – сервер» — представляет собой архитектуру программного комплекса, которая распределяет прикладную программу на два логически различных компонента, а именно клиент и сервер, которые взаимодействуют по схеме «запрос-ответ» решая свои определенные задачи (рис.1).
Рисунок 1– Архитектура «Клиент – сервер»
Компьютер, который управляет (владеет) каким-либо ресурсом, называется сервером этого ресурса.
Компьютер, который запрашивает и пользуется каким-либо ресурсом, называется клиентом этого ресурса.
Клиенты и серверы могут располагаться как на одном персональном компьютере (ПК), так и на разных ПК объеденные сетью. Также могут возникать такие ситуации, когда некоторые программные блоки одновременно выполняют функции сервера, работая с одним блоком и работу клиента работая с другим.
Основными принципами технологии «Клиент-сервер» является разделение функции приложения как минимум на три группы:
- Модуль интерфейса с пользователем.
Эту группа называется логикой представления. Через эту группу пользователь взаимодействует с приложением. Независимо от конкретной характеристики логики представления (командная строка, сложный графический пользовательский интерфейс, интерфейс через посредника) её главной задачей является обеспечение средств, чтобы можно было производить эффективный обмен информацией между пользователями и информационной системой.
- Модуль хранения данных.
Эта группа называется бизнес-логикой. В бизнес-логике определяется, конкретное предназначение приложения (к примеру, прикладная функция приложения, характерна для предметных областей использования). Разделение приложения на границе между программами позволяет обеспечить естественные основы, чтобы приложение могло работать на нескольких компьютерах одновременно.
- Модуль обработки данных (управление ресурсами).
Эта группа называется логика доступа к данным или алгоритмы доступа к данным. Алгоритм доступа к данным представляет собой специфические для конкретного приложения интерфейсы взаимодействия с механизмом постоянного хранения данных представляющий подобие файловой системы или системы управления базами данных (СУБД). Данный модуль обработки данных позволяет работать в специальном для приложения интерфейсе доступа к СУБД. Используя данный интерфейс, приложение может управлять процессом соединения с базой данных и обработкой запросов к ней, а также получать результаты и переводить эти результаты обратно в специальную для конкретного приложения структуру данных.
Каждая из вышеописанных групп может работать независимо от двух других групп. Согласно разделению функций, для любого приложения выделяются следующие компоненты:
— компоненты для представления данных;
— прикладные компоненты;
— компоненты для управления ресурсами.
1.2 Двухзвенная архитектура «Клиент-сервер»
Классическая архитектура клиент-сервер распределяет три основные части приложения на два физических модуля. Обычно прикладной компонент располагается на сервере, компонент представления данных на стороне клиента, а компонент управления ресурсом распределяется между клиентской и серверной частями. В этом заключается основной недостаток классической двухуровневой архитектуры.
Используя двухзвенную архитектуру во время распределения алгоритма обрабатывания данных, разработчик должен обладать полной информацией о том, какие последние изменения, были внесены в систему, и какова значимость этих изменений, из-за чего возникает большая сложность во время разработки клиент-серверной системы, её установки и обслуживании. Так как такие мероприятия стоят значительных усилий, и постоянной координации действий совершаемые разными группами специалистов.
Чтобы предотвратить сопутствующую несогласованность работы различных элементов такой архитектуры специалисты создали две модификации для двухзвенной архитектуры «Клиент – сервер»: одна модификация стала называться «Толстый клиент» («Тонкий сервер»), а другая «Тонкий клиент» («Толстый сервер»).
В данной двухзвенной архитектуре разработчики пытались перенести процесс выполнения обработки данных на одну из двух физических частей — на сторону клиента («Толстого клиента»), или на сторону сервера («Тонкого клиента»).
Каждый из описанных подходов обладал своими недостатками. В первом подходе неоправданно перегружалась сеть, так как по ней передавались необработанные а, следовательно, избыточного размера данные. Также был усложнён процесс поддержки системы и процесс её изменения, так как, чтобы заменить алгоритм для вычисления или исправления ошибок нужно одновременно полностью заменить весь интерфейс в программах, чтобы не возникли ошибки или несогласованности в обработке данных. Если же весь процесс обработки информации выполнялся бы на сервере, то возникла бы проблема в процессе описания встроенных процедур и процесса их отладки. Систему, обрабатывающую информацию на сервере невозможно было ни как перенести на другую платформу или операционную систему, без серьезных сбоев в работе.
В том случае если всё равно будет требоваться разработка двухуровневой классической архитектуры «Клиент – сервер», то надо знать следующее: структура архитектуры «Толстый сервер» аналогична структуре в архитектуре «Тонкий клиент» (рис.2);
Рисунок 2 – Архитектура «Тонкий клиент»
У этих архитектур имеются следующие недостатки:
— усложнён процесс реализации, так как в таких языках как SQL не приспособлены коды, чтобы разрабатывать программное обеспечение и для них отсутствуют хорошие средства отладки;
— производительность работы программ, которые написаны на языке типа SQL, довольно невысока, в отличие от созданных программ на других языках, что очень важно, если речь идёт о создании сложной системы;
— программа, которая написана на языке СУБД, обычно работает недостаточно надежно; ошибка, которая может в них возникнуть может привести тому, что весь сервер баз данных может выйти из строя;
— получившаяся программа на языке СУБД становится полностью непереносимой на другую систему или платформу.
1.3 Трехуровневая модель
В середине 90-х годов ХХ века получила признание среди специалистов созданная трехзвенная архитектура «Клиент – сервер», в которой информационная система делилась по своим функциональным возможностям на 3-и отдельные компонента: логика представления, бизнес-логика и логика доступа к данным. В отличие от классической двухзвенной архитектуры в трехзвенную архитектуру было добавлено дополнительное звено, которая стало называться сервер приложений. Сервер приложений предназначался для того, чтобы осуществлять бизнес-логику, полностью разгружая, клиент, который в итоге мог направлять запросы промежуточному программному обеспечению, максимально используя все имеющиеся возможности сервера.
В трехуровневой архитектуре клиент не перегружается, выполняя функции обработчика данных, а может выполнять свою основную функцию в системе, а именно представлять информацию, которая поступает с сервера приложений. Интерфейс для такой архитектуры можно создать, используя стандартные средства Web-технологии — браузера, и языки CGI и Java. Такой подход уменьшил объёмы данных, которые передаются между клиентом и сервером приложений, что дало возможность подключать клиентские компьютеры даже к медленным линиям передачи данных (телефонные каналы). Клиентская часть стала довольно простой, благодаря чему могла воспроизводиться при помощи универсального браузера. В случае если систему надо будет всё-таки менять, то эта процедура может быть осуществлена быстро и безопасно для системы и программ.
Сервер приложений – является программным обеспечение, которое представляет собой промежуточный слой между клиентом и сервером (рис.3).
Рисунок 3 — Сервер приложений
Создано несколько категорий продуктов для осуществления работы промежуточного слоя:
— Message orientated – ярким представителем являются MQseries и JMS;
— Object Broker – ярким представителем является CORBA и DCOM;
— Component based – ярким представителем является .NET и EJB.
Создано много серверов приложений при поддержке таких знаменитых компаний как Sun Microsystem, Borland, IBM, Oracle и каждое из которых отличается своим набором количества предоставляемых сервисов (не учитывая производительность). При помощи этих сервисов облегчается процесс программирования и развертывания приложений в масштабе предприятия. Обычно сервером приложений предоставляются следующие сервисы:
— WEB Server – чаще всего в поставку включают самый популярный и мощный сервер, в настоящее время это Apache-серверы;
— WEB Container – при помощи него можно выполнять JSP и сервлеты. Apache среди таких сервисов использует Tomcat;
— CORBA Agent – это сервис предоставляет распределенные директории, чтобы хранить CORBA объекты;
— Messaging Service – является своего рода брокером сообщений;
— Transaction Service – является сервисом транзакций;
— JDBC – драйвер, служащий для подключения к базам данных, так как именно сервер приложений приходиться работать с базами данных, поэтому он должен уметь подключаться к используемой в компании базе данных;
— Java Mail – сервис предоставляющий доступ к сервисам SMTP;
— JMS (Java Messaging Service) – сервис служащий, чтобы обрабатывать синхронные и асинхронные сообщения;
— RMI (Remote Method Invocation) – сервис для вызова удаленных процедур.
Многоуровневая клиент-серверная система достаточно легко может быть перенесена на системы Web-технологии — для этого нужно произвести замену клиентской части на универсальный или специализированный браузер, а на сервере приложений установить дополнительный Web-сервер и небольшие программы для вызова процедур сервера. Чтобы разрабатывать такие программы можно воспользоваться как Common Gateway Interface (CGI), так и более современным языком Java.
Для работы в трехуровневой системы каналов связи между сервером приложений и СУБД можно пользоваться более скоростными линиями, которые требовали бы минимальных затрат, так сервер мог бы находиться в одном помещении (серверной) и не перегружал бы сеть во время передачи большого количества информации.
Из всего вышеописанного можно понять, что двухуровневая архитектура сильно отстаёт от многоуровневой архитектуры, поэтому в современных системах используют только многоуровневую архитектуру «Клиент – сервер», которая может быть выполнена в трёх модификациях — RDA, DBS и AS.
1.4 Модель файлового сервера
Среди первых базовых технологий для локальной сети самой первой является модель файлового сервера (FS). В своё время данная технология была особенно популярна среди отечественных разработчиков, которые пользовались такими системами, как FoxPro, Clipper, Clarion, Paradox и подобные.
В моделях FS функции всех трёх компонентов совмещаются в одном коде, который выполняет компьютер-сервер (хост). В такой архитектуре компьютер-клиент вообще отсутствует, вводом и отображением данных занимается терминал или компьютер, работающий в режиме эмуляции терминала. Приложения для такой модели разрабатывают на языках четвертого поколения (4GL). Согласно FS один из компьютеров сети должен считаться файловым сервером и должен предоставлять другим компьютерам услугу по обработке файлов. Файловый сервер управляется при помощи сетевых ОС и служит компонентом доступа к информационным ресурсам. На других же ПК в сети установлено и функционирует приложение, в коде которого совмещен компонент представления и прикладные компоненты.
Взаимодействие клиента и сервера осуществляется по следующей технологии: запрос передаётся на файловый сервер, который отправляет его СУБД, которая размещает на компьютере-клиенте, требуемые блоки данных. Весь процесс обработки осуществляется терминалом (рис.4).
Протоколы обмена представляют собой наборы вызовов, которые обеспечивают приложению доступы к файловой системе на файл-сервере.
Рисунок 4 — Модель файлового сервера
Преимущества данной технологии:
— простая разработка приложений;
— удобные инструменты администрирования и обновления программного обеспечения благодаря компактному расположению всех компонентов на одном персональном компьютере;
— низкая цена необходимого оборудования для организации рабочих мест.
Недостатки, которые перекрывают преимущества FS – модели:
— большая загруженность сети;
Несмотря на небольшие объёмы данных, которые пересылаются по сети, время отклика от них является критичным, так как каждый символ, который ввёл пользователь на терминале, передаётся на сервер, обрабатывается приложением и возвращается обратно, чтобы быть выведенным на экран терминала. Кроме этого существуют проблемы распределения нагрузки на несколько компьютеров.
— дорогая стоимость аппаратного обеспечения сервера, так как его ресурсы должны быть распределены на всех пользователей;
— отсутствует графический интерфейс.
Чтобы решить проблемы, присущие технологии «Файл – сервер» стала применяться прогрессивная технология «Клиент – сервер».
В современных системах управления базами данных архитектура «клиент-сервер» стала стандартом. Если в проектируемой сетевой технологии будет применена архитектура «клиент-сервер», это значит, что реализуемые в её рамках прикладные программы будут распределенного характера, а это означает, что функции приложений будет реализовываться в программе-клиенте и в программе-сервере.
1.5 Модель доступа к удаленным данным
Модель доступа к удаленным данным (RDA) – представляет собой сетевую архитектуру технологии «Клиент – сервер», в которой коды компонентов представления и прикладных компонентов совмещаются и выполняются на компьютере-клиенте. Доступы к информационному ресурсу обеспечивает непроцедурный язык (к примеру, язык запрос к базам данных SQL) или вызовы функций из специальной библиотеки (при наличии специального интерфейса прикладного программирования — API).
Запрос к информационному ресурсу направляется по сети к удаленному компьютеру, в котором происходит обработка и выполнение запроса, после чего клиенту возвращают блок данных с результатом (рис.5).
Рисунок 5 — Модель доступа к удаленным данным
Главное преимущество RDA-модели — это предоставление широкого выбора среди инструментальных средств нужных для разработки приложения, обеспечивая быстрое создание desktop-приложения, которое сможет работать с ориентированными на язык SQL СУБД. Обычно в таких инструментальных средствах имеется графический интерфейс для пользователя, работающего в ОС, а также программные средства для автоматического генерирования кода, в которых имеются прикладные функции и функции представления.
Но, несмотря на вышеописанные возможности, RDA-модель имеет некоторый ряд ограничений:
1) Процесс взаимодействия клиента и сервера при помощи SQL-запросов сильно загружает сеть. Так приложение нераспределенное, вся его логика обрабатывается на компьютере-клиенте, в результате чего при взаимодействии его с сервером при помощи SQL-запроса может привести к передаче через сеть данных слишком большого для узла связи объёма. Из-за чего при возрастании числа клиентов, сеть становится загруженной, происходит ограничение быстродействия всей информационной системы.
2) Процесс положительного администрирования приложений в RDA-моделях практически невозможен. Бывает, что различные по своей природе функции (функция представления и прикладная функция) смешиваются в одной и той же программе, которая написана при помощи языка четвертого поколения (4GL), что в результате приводит к необходимости во время изменения какой-нибудь прикладной функции переписывать всю программу заново целиком.
3) Во время коллективных работ над проектом, каждому разработчику надо поручать реализацию отдельной прикладной функции, из-за чего невозможен нормальный контроль над взаимной непротиворечивостью функций. Каждый из разработчиков вынужден программировать для себя пользовательский интерфейс, из-за чего трудно сформировать единый стиль интерфейса и его целостность. Иногда процесс обновления программного обеспечения сложен, так как обновление программного обеспечения надо произвести одновременно на всех компьютерах-клиентах.
4) Невозможно реализовать разграничение доступа по функциям только на сторонах сервера, а можно только на сторонах клиента, из-за чего уровень безопасности становится довольно низким. Сам процесс разграничения выполняется только по таблице базы данных, из-за чего тоже снижается защищенность.
Несмотря на широкую распространённость, RDA-модели вскоре была заменена более технологичной DBS-моделью.
1.6 Модель сервера баз данных
Модель сервера баз данных (DBS) – является сетевой архитектурой технологии «Клиент – сервер», основа которой состоит из механизма хранимых процедур, которые реализуют прикладные функции. В DBS – модели информационным ресурсом является база данных из-за работы механизма хранимых процедур, который реализуется в СУБД.
В DBS-модели приложения являются распределенными. Процесс выполнения компонента представления происходит на компьютере-клиенте, а прикладной компонент, который реализует бизнес-функции, оформляется как в виде набора хранимых процедур и процесс его функционирования происходит на компьютере-сервере БД. Хранимая процедура также называется компилируемой резидентной процедурой или процедурой базы данных (рис.6).
Рисунок 6 — Модель сервера базы данных.
Преимущества DBS-модели перед RDA-моделью в следующем:
— возможность организации централизованной администрации различных функций, что существенно снизит трафик сети так как, вместо SQL-запроса по сети будет передаваться вызов хранимой процедуры;
— возможность разделить процедуру между несколькими работающими приложениями, что существенно экономит ресурсы компьютера, так как счет использования происходит благодаря единожды созданному плану выполнения процедуры.
У DBS-модели есть и свои недостатки:
1) Разные процедурные расширения на языке SQL, которые используются для написания хранимой процедуры, не являются языками для программирования. Так как они встроены в конкретную СУБД из-за чего, имеют ограниченные возможности. Поэтому система, которая прикладные компоненты реализует с помощью хранимых процедур, не может называться мобильной по отношению к СУБД. В большинстве СУБД отсутствует возможность отладки и тестирования хранимой процедуры, что часто приводит к сбою, который может привести к полной неработоспособности всей базы данных.
2) В DBS-модель не встроены разнообразные способы взаимодействия клиента с сервером, которые необходимы, чтобы децентрализовать некоторые приложения, например хранимую очередь, асинхронный вызов и другие.
3) DBS-модель не может обеспечить требуемую эффективность использования вычислительного ресурса. Ограничение присутствующие в ядре СУБД не позволяет полностью организовать эффективную балансировку загрузки, миграции процедур на другой компьютер-сервер БД и реализовать другие полезные функции, к примеру, запрос с приоритетом.
На практике часто используют синтез RDA и DBS-модели, чтобы выполнять построение многопользовательской информационной системы: поддержку целостности базы данных и некоторых её простейших прикладных функций хранимой процедуры выполняет DBS-модель, а за реализацию других более сложных функций, которые работают непосредственно в прикладной программе на компьютере-клиенте, отвечает RDA-модель.
1.7 Модель сервера приложений
Все недостатки DBS — модели были исправлены в AS-модели, в которой в большей степени реализованы сильные стороны технологии «клиент-сервер».
Модель сервера приложений (AS) (рис. 7) – является сетевой архитектурой технологии «Клиент – сервер», она представляет собой процесс, который выполняется на компьютере-клиенте и отвечает за интерфейс с пользователем (процесс ввода и отображения данных). Основной элемент данной модели — это прикладной компонент, который называется сервером приложения, который функционирует на удаленном компьютере. Сервер приложений представляет собой группу прикладных функций, которые оформлены в виде сервисов (служб). Каждым сервисом предоставляются некоторые услуги для всех программ, которыми ими могут воспользоваться.
Рисунок 7 — Модель сервера приложений.
Серверов приложений может иметься несколько, и каждый из них может предоставлять свой определенный вид услуг. Любая программа, которая начинает пользоваться ими, в дальнейшем рассматривается как клиент приложения.
Детали процесса реализации работы прикладных функций на сервере приложений скрываются от клиента приложения. Клиентом, может быть и стандартный браузер, который обращаться с запросом к конкретным службам, при условии, что серверы приложений являются обезличеными и служат лишь для того, чтобы создавать графический интерфейс для пользователя, позволяя повысить эффективность управления балансом загрузки. Запросы, которые поступают от клиента, строятся в очередь к AS-процессу, который в это время занимается их извлечением и передачей их для прохождения обработки соответствующим службам согласно их приоритетам.
Учитывая, то, что данные являются «спрятанными» за сервером приложений, который имеет встроенную проверку полномочий клиента, СУБД может гарантировать высокий уровень защиты данных.
Процесс обеспечения доступа к информационным ресурсам, которые необходимы для решения прикладных задач, такой же, как и в RDA-модели, т.е. при помощи менеджера ресурсов (к примеру, SQL-сервера). Среди прикладных компонентов являются доступными такие ресурсы как, база данных, очередь, почтовая служба и другие компоненты. Сервер приложений работает, как правило, на том же компьютере, где происходит функционирование менеджера ресурсов, что позволяет избавиться от необходимости направлять SQL-запросы по сети и позволяет повысить производительность системы. Сервер приложений можно переносить на другие компьютеры.
AS-модель представляет собой универсальную систему, которая может состоять из любого числа уровней, которые могут взаимодействовать между собой. AS-модель обеспечивает процесс чёткого разграничения логических компонентов, предоставляет возможности для балансировки уровня загрузки среди нескольких серверов, и даёт возможность рационального выбора среди программных средств, для реализации. Обеспечить такой уровень гибкости, такой уровень защиты данных и открытость, является на данный момент, недостижим для RDA- и DBS-моделей. AS-модель может функционировать, используя и медленные линии связи, тем самым значительно снижая трафик между клиентом и сервером приложений.
Заключение
Учитывая то, что процесс обработки может быть осуществлён в любом месте сети, распределенная система вычисления в архитектуре «Клиент–сервер» может гарантировать эффективное масштабирование. Для того чтобы получить баланс между клиентом и сервером, компоненты приложения должны выполняться на сервере только в случае, если централизованный способ обработки более эффективен.
Таким образом, можно понять, если предстоит работа в небольших информационных системах, которые не будут требовать графический интерфейс для пользователя, то лучше всего воспользоваться FS — моделью. Проблема графического интерфейса пользователя легко может быть решена при помощи RDA-модели. DBS-модель является хорошим вариантом для управления СУБД. AS-модель лучший вариант для создания большой информационной системы, а также хорошо сгодиться, когда приходиться работать с низкоскоростными каналами связи.
Архитектура клиент-сервер значительно упрощает и ускоряет разработку приложений за счет того, что правила проверки целостности данных находятся на сервере. Неправильно работающее клиентское приложение не может привести к потере или искажению данных. Все эти возможности, ранее свойственные только сложным и дорогостоящим системам, сейчас доступны даже небольшим организациям. Стоимость оборудования, программного обеспечения и обслуживания для персональных компьютеров в десятки раз ниже, чем для мэйнфреймов.
В заключении можно отметить, что архитектура клиент-сервер предоставляет разработчикам программного обеспечения особую свободу выбора и согласования различных типов компонентов для клиента, сервера и промежуточных звеньев.
Список источников
- Понятие и модели архитектуры «клиент-сервер» [Электронный ресурс]. — URL: https://otherreferats.allbest.ru/programming/00168288_0.html
- Типы клиент-серверной архитектуры [Электронный ресурс]. — URL: https://itelon.ru/blog/arkhitektura-klient-server/
- Технология «клиент-сервер» [Электронный ресурс]. — URL: https://www.evkova.org/kursovye-raboty/tehnologiya-klient-server———-#1.3%20Различные%20модели%20технологии%20«Клиент%20–%20сервер»
- Модели архитектуры клиент-сервер [Электронный ресурс]. — URL: https://studfile.net/preview/7386820/page:5/
- Понятие и модели архитектуры «клиент-сервер» [Электронный ресурс]. — URL: https://www.evkova.org/kursovye-raboty/ponyatie-i-modeli-arhitekturyi-klient-server