Содержание:

Введение

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

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

Первейшие достижения в компьютерных сетях были довольно примитивными – скорость работы сетей была очень медленной по сравнению с современными сетевыми технологиями, но для того времени это было большим достижением.

С развитием аппаратной части, несомненно, совершенствовалось программное обеспечение компьютерных сетей. Со временем потребовалось усовершенствование самих технологий, а не только развитие аппаратуры и программного обеспечения. Развитие современных сетевых технологий привело к созданию множества различных связей. Одной из таких связей является технология «клиент-сервер», позволяющая пользователям сети получать быстрый и удобный доступ к ресурсам. О данной сетевой технологии пойдет речь в моей работе.

2. Клиент — сервер

2.1 Основные понятия

2.1.1 Определения.

Архитектура информационной системы - концепция, определяющая модель, структуру, выполняемые функции и взаимосвязь компонентов информационной системы. [3]

Клиент-сервер (Client-server) — сетевая или вычислительная архитектура, в которой задачи или сетевая нагрузка распределены между представителями услуг (сервисов), называемыми серверами, и клиентами, заказчиками услуг.

Сервер — это персональный компьютер, предназначенный для выполнения запросов, функций и решения задач, поставленных клиентом, без непосредственного участия человека.

Клиент — это персональный компьютер, предназначенный для отправки запросов и команд серверу. Все команды отправляются с помощью специальных программных и аппаратных средств с непосредственным участием человека

Однако физически «клиент» и «сервер» могут находиться на одном компьютере. Одна и та же программа может быть и клиентом, и сервером одновременно.

Конфигурируемость – изолированность уровней друг от друга позволяет быстро и простыми средствами переконфигурировать систему при возникновении сбоев или при плановом обслуживании на одном из уровней;

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

Сетевая модель OSI –  (базовая эталонная модель взаимодействия открытых систем, англ. Open Systems Interconnection Basic Reference Model) — абстрактная сетевая модель для коммуникаций и разработки сетевых протоколов.

2.1.2 История возникновения архитектуры «клиент-сервер»

Появление архитектуры связано, в первую очередь, с широким распространением компьютерных сетей. Именно тогда стала актуальной задача доступа к удаленным ресурсам (данные, вычислительные ресурсы).

Технологии клиент – сервер начала свое возрождение вначале 1980-х годах. Развитие этой системы сразу пошло по трем направлениям:

• Базы данных. В 1982 году в одной молодой компании, специализирующейся в области СУБД, решили отделить базы данных от приложений, которые их используют. Это была компания Britton-Lee, которую основали Боб Эпштейн, Паула Хауторн и Майк Убелл. Их целью было создание автономного аппаратно-программного сервера баз данных, получившего название Intelligent Database Machine (IDM).

Реализация оказалось неудачна.

Но идею не забыли. В скором времени тот же Эпштейн уже значился в числе основателей другой компании, разрабатывающей программные продукты. Это была уже компания Sybase, сделавшая клиент-серверные технологии более практичными и популярными.

Успех принесло чисто программное решение!!!

• Вычислительные ресурсы. В 1983 году двое ученых из исследовательского центра Xerox в Пало-Альто (PARC), Эндрю Биррелл и Брюс Джей Нельсон, придумали удаленный вызов процедур (Remote Procedure Call, RPC), т. е. механизм, используя который, один компьютер в сети может «попросить» другой компьютер выполнить часть его вычислительной работы.

В настоящее время стандартное решение для всех сетевых операционных систем (семейство Unix, Windows, MAC OS и т.д.)

Пример. 2006. Дыра в системе RPC Windows XP – вирус Lovesan (Mblaster)

• Удаленный доступ к файлам. В 1984 году Билл Джой из компании Sun Microsystems возглавил разработку сетевой файловой системы NFS (Network File System), использующей RPC для того, чтобы дать возможность компьютерам обращаться к файлам, размещенным на других компьютерах в той же сети.
• Добрые люди поставьте троечку)

Однако все это были частные решения. Реальное распространение архитектуры "клиент-сервер" стало возможным благодаря развитию и широкому внедрению в практику концепции открытых систем.

2.1.3 Концепция открытых систем

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

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

Основу составила модель OSI (Open System Interconnection), принятая ISO в 1974 г. Переход к этой модели на практике оказался весьма длительным.

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

• Свойство мобильности означает сравнительную простоту переноса програмной системы в широком спектре аппаратно-программных средств, соответствующих стандартам (независимость от аппаратуры и ОС).
• Интероперабельность означает возможность КОМПЛЕКСИРОВАНИЯ новых программных систем на основе использования готовых компонентов, выпускаемых различными производителями, со стандартными интерфейсами.

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

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

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

На аппаратном уровне большинство проблем было решено примерно к середине 1990-х годов – с массовым внедрением сети Internet.

Общим решением проблемы мобильности систем, основанных на архитектуре "клиент-сервер" является опора на программные пакеты, реализующие протоколы удаленного вызова процедур (RPC - Remote Procedure Call).

В области СПО - стандартизованная на уровне сетевых интерфейсов операционная система.

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

2.2 Клиент-серверная архитектура в БД.

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

Файл-серверная система тоже использует технологию клиент-сервер, однако с точки зрения архитектуры прикладных программ важным является то, какого рода ресурсы клиентам предоставляет сервер.

В файл-серверной системе данные хранятся на файловом сервере (к примеру, Novell NetWare или Windows NT Server), а их обработка производится на рабочих станциях, на которых, как правило, функционирует одна из, так называемых, "настольных СУБД" - Access, FoxPro, Paradox и т.п.

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

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

Прикладная программа

Клиентские

компьютеры

База данных

Файловый сервер

Прикладная программа

2.3 Файл-серверная архитектура.

Архитектура клиент-сервер в системах управления предприятием связано с делением любых прикладных программ на три основных компонента или уровня. Такие как:

• представление (визуализация) данных;
• прикладная логика;
• управление базой данных.
• Зато сам xD

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

Условием, позволяющим отнести прикладную программу к архитектуре клиент-сервер, является то, что как минимум один из 3-х ее составляющих полностью выполняется на ином компьютере, и связь между компонентами на разных компьютерах осуществляется через ту или иную сетевую среду посредством отправки запросов на получение какого либо ресурса.

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

2.4 Двухуровневая модель архитектуры клиент-сервер

Такая архитектура получила свое развитие в начале 1990-х годов на фоне роста рынка персональных компьютеров и снижения спроса на мэйнфреймы.

Изначально эта системы строилась на стандартной двухуровневой клиент-серверной системе (архитектуре). Двухуровневая клиент-серверная архитектура основана только на использовании сервера базы-данных (DB-сервера), когда клиентская часть содержит уровень представления данных, а на сервере располагается БД вместе с СУБД и прикладными программами.

DB-сервер отличается от файл-сервера тем, что в его оперативной памяти, помимо сетевой ОС, функционирует СУБД, которая обеспечивает совместное использование рабочими устройствами базы данных, размещенной во внешней памяти данного DB-сервера. Он предоставляет возможность отказаться от перепосылке по сети файлов данных целиком и передавать только то, что позходит запросу пользователя. В этом случае возможно разделение пользовательского приложения на две части: первая выполняется на сервере и связана с выборкой данных из БД, а вторая часть по представлению данных для анализа и принятия решения выполняется на клиентском компьютере. Поэтому, увеличивается сумарная производительность такой информационной системы после объединения вычислительных ресурсов сервера и клиентской станции.

Обращение к БД осуществляется на языке SQL, который стал стандартом для БД. Поэтому сервер БД называют SQL-сервером, который поддерживается всеми реляционными СУБД (Informix, Oracle, ADABAS D, InterBase, SyBase, MS SQL, и др.)

Клиентское приложение может быть реализовано на языке настольных СУБД (MS Access, FoxPro, Paradox, Clipper и др.). При этом взаимодействие клиентского приложения с SQL-сервером осуществляется через ODBC-драйвер, который обеспечивает возможность пересылки и преобразования данных из глобальной БД в структуру БД клиентского приложения.

Позднее была разработана концепция активного сервера, в котором была заложена система – механизм хранимых процедур. Это позволило часть прикладного компонента перенести на сервер (модель распределенного приложения).

В словаре базы данных хранятся процедуры, они разделяются между несколькими клиентами и выполняются на одном и том же компьютере, что и SQL-сервер.

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

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

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

Достоинства такой архитектуры:

- допускается централизованное управление прикладными функциями,

- значительно снижается сетевой трафик (т.к. передаются вызовы хранимых процедур, а не SQL-запросы).

-возможность, в большинстве случаев, распределить функции вычислительной системы между несколькими независимыми компьютерами в сети;

-все данные хранятся на сервере, который защищен гораздо лучше компьютеров клиентов, также на сервере легче обеспечить контроль полномочий, для того, чтобы доступ к данным имели клиенты с соответствующими правами;

-возможность работы в многопользовательском режиме;

- целостность данных.

Недостатоки этой архитектуры:

- ограниченность технологий разработки хранимых процедур с языками общего вида и назначения (C и Pascal). На практике обычно используют смешанный подход: простые прикладные функции выполняются сохраненными процедурами на сервере;

- наиболее сложные прикладные функции выполняются на клиенте в прикладной программе

- вся работоспособность вычислительной сети зависит от работоспсобности сервера;

- для управления системой требуется квалифицированный профессионал;

- высокая стоимость оборудования;

- бизнес логика приложений осталась в клиентском программном обеспечении.

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

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

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

В качестве альтернативы появилась также двухзвенная архитектура "с тонким клиентом". В этом случае, в идеале программа-клиент реализует только графический интерфейс пользователя (GUI) и передает/принимает запросы, а вся бизнес-логика выполняется сервером. В идеальном случае, клиентом является просто интернет-браузер, который имеется в стандартной операционной системе любого пользовательского компьютера, а так же не требует особой настройки и установки специального ПО. К сожалению, такая схема тоже не без недостатков, потому, что серверу иногда приходится брать на себя несвойственные для него задачи реализации бизнес логики приложения (к примеру, серверу СУБД приходится выполнять расчеты).

2.5 Многоуровневая архитектура клиент-сервер.

Multitier architecture (многоуровневая архитектура) – одна их видов архитектуры клиент-сервер, в которой обработка данных вынесена на один или несколько отдельных серверов. Это дает возможность разделить функции хранения, обработки и представления данных, чтобы наиболее эффективно использовать сервера и клиенты.

Среди многоуровневой архитектуры клиент-сервер наиболее распространена трехуровневая архитектура (трехзвенная архитектура, three-tier), имеющая в наличии наличие следующие компоненты: клиентское приложение ( «тонкий клиент» или терминал), подключенное к серверу приложений, который в свою очередь подключен к серверу базы данных.

Клиент не должен иметь прямых связей с базой данных (по условию безопасности), быть под нагрузкой основной бизнес-логикой (по требованиям масштабности) и хранить состояние приложения (по требованиям надежности). На первый уровень возможно вынесение и обычно выносится простейшая бизнес-логика: система авторизации, алгоритмы шифрования, проверка вводимых значений на допустимость и соответствие формату, простые операции (сортировка, группировка, подсчет значений) с данными, уже загруженными на терминал.

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

Сервер базы данных хранит информацию и выносится на третий уровень. Обычно это стандартная реляционная или объектно-ориентированная СУБД. Если третий уровень представляет собой базу данных в состав с хранимыми процедурами, триггерами и схемой, тогда второй уровень организуется как программный интерфейс, связывающий клиентские компоненты с прикладной логикой базы данных.

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

В "правильной" (по безопасности, надежности, масштабности) структуре сервер базы данных находится на отдельном компьютере, к которому по сети подсоединены один или несколько серверов приложений, к которым, по сети подключаются терминалы.

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

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

Минусы этой архитектуры:

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

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

В лучшем случае:

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

Преимущества данной архитектуры очевидны:

• на каждом из звеньев можно независимо вносить изменения;
• уменьшается нагрузка на сеть, так как звенья не передают между собой большими объемами информации;
• обеспечивается простая модернизация оборудования и программного обеспечения;
• приложения создаются на стандартных языках третьего или четвертого поколения (Java, C/C++).

Следующим логическим шагом - являеся увеличение колличества звеньев. Современные корпоративные программные системы представляют сложные системы взаимодействующих на разных уровнях компонентов, каждые из которых могут являться клиентами для одних компонентов и серверами для других.

Главной проблемой систем, основанных на двухзвенной архитектуре "клиент-сервер", или тем более на многозвенной архитектуре, является то, что от них требуется мобильность в наиболее широком классе аппаратно-программных сред. Даже если ограничиться UNIX-ориентированными локальными сетями, в разных сетях применяется различная аппаратура и протоколы связи. Создания систем, поддерживающих все возможные протоколы, приводит к перегрузке, приносит ущерб функциональности. Еще более сложный аспект этой проблемы связан с возможностью использования разных представлений данных в разных узлах неоднородной локальной сети. В разных компьютерах существует различная адресация, представление чисел, кодировка и другие криптографические ньюансы. Это наиболее существенно влияет на сервера высокого уровня: телекоммуникационных, вычислительных, баз данных.

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

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

Некоторые авторы представляют многозвенную архитектуру (трехзвенную) в виде пяти уровней:

1. Представление;

2. Уровень представления;

3. Уровень логики;

4. Уровень данных;

5. Данные.

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

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

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

Все данные системы хранятся в базе данных.

2.6 Клиент-серверная архитектура применительно к ИС.

Термин "клиент-сервер" означает архитектуру программного комплекса, в которой его части взаимодействуют по схеме "запрос-ответ". Если рассмотреть две взаимодействующие части комплекса, то одна из них (клиент) выполняет активную функцию, т. е. определяет запросы, а другая (сервер) пассивно на них отвечает. Во время развития системы роли могут меняться, например какой то программный блок будет одновременно выполнять функции сервера по отношению к одному блоку и клиента по отношению к третьему блоку.

Любая информационная система должна иметь три основные функциональные части - модули хранения данных, обработки этих данных и интерфейса с пользователем. Каждая из этих частей может быть реализована независимо от остальных двух. Например, не меняя программ, используемых для хранения и обработки данных, можно изменить интерфейс с пользователем так, что одни и те же данные будут отображаться в виде таблиц, графиков или гистограмм. Не меняя программ представления данных и их хранения, можно изменить программы обработки, например, изменив алгоритм полнотекстового поиска. Так же не изменяя программ представления и обработки данных, можно изменить программное обеспечение для хранения данных, перейдя, на другую файловую систему. В классической клиент-серверной архитектуре три основные части приложения приходится распределять по двум физическим модулям. Обычно, ПО хранения данных располагается на сервере (например, сервере базы данных), интерфейс с пользователем - на стороне клиента, а обработку данных приходится распределять между клиентской и серверной частями. В этом-то и заключается основной недостаток двухуровневой архитектуры, из них вытекает несколько неприятных особенностей, сильно усложняющих разработку клиент-серверных систем. А именно, при разбиении алгоритмов обработки данных необходимо синхронизировать поведение обеих частей системы. Все разработчики должны иметь полную информацию о последних изменениях, внесенных в систему, и понимать эти изменения. Это создает большие сложности при разработке клиент-серверных систем, их установке и обслуживании, поскольку необходимо тратить значительные усилия на координацию действий разных групп специалистов. В действиях разработчиков часто возникают противоречия, а это, несомненно, тормозит развитие системы и принуждает менять уже готовые и проверенные элементы системы. Чтобы избежать несогласованности различных элементов архитектуры, пытаются выполнять обработку данных на одной из двух физических частей - либо на стороне клиента ("толстый" клиент), либо на сервере ("тонкий" клиент, или архитектура, называемая "2,5- уровневый клиент-сервер"). Каждый подход имеет свои недостатки. В первом случае неоправданно перегружается сеть, поскольку по ней передаются необработанные, а значит, избыточные данные. Кроме того, усложняется поддержка системы и ее изменение, так как замена алгоритма вычислений или исправление ошибки требует одновременной полной замены всех интерфейсных программ, а иначе могут возникнуть ошибки или несогласованность данных. Систему с обработкой информации на сервере абсолютно невозможно перенести на другую платформу, что является серьезным недостатком.

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

Как значится в словаре Free Online Dictionary of Computing, тонкий клиент - это клиентское устройство (или программа), передающее большую часть исполняемых им функций серверу. Толстый клиент определить намного проще - это все клиенты, не являющиеся тонкими.

Тонкий клиент (thin client) — терминал сети без жестких дисков, вычислительная мощность которого и объем памяти определяются задачами пользователя. Все программы и приложения, хранящиеся на сервере, становятся доступными для пользователя при включении его устройства и выполнении процедуры регистрации на сервере. Тонким клиентом называют

Также персональные компьютеры (и мобильные) с оптимально низкой мощностью процессора, малой ROM и RAM, позволяющий пользователю осуществлять ввод и отображение данных с помощью выполнения вычислений и хранения информации на более мощном ПК или серверах, с которыми он может содействовать с помощью каналов не высокой пропускной способности. К тонкому клиентуесть возможность подключения внешних устройства ввода/вывода данных (мониторы, скан-системы, устройства печати и проекторы).

Клиент называется тонким, если он совсем не содержит или содержит малую часть бизнес-логики, т. е. представляет собой исключительно презентационный слой. К толстым принадлежат клиенты с большей долей бизнес-логики. Лучший пример тонкого клиента — Web-браузер, настолько универсальный, что способен подключаться к абсолютно разным прикладным программам, о них "не знает" ничего, и, тем не менее обеспечивать приемлемый интерфейс пользователя. Вся концепция сетевого компьютера строится на идее создания дешевого небольшого устройства, на котором будет работать Web-браузер.

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

Преимущества тонких клиентов

Технология «тонкий клиент-сервер» базируется на трех основных составляющих: 1) 100% выполнение прикладных задач на терминальном сервере, 2)операционная система, рассчитанная на многих пользователей

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

Пользователи имеют возможность одновременно заходить в систему и выполнять приложения на сервере в разных, защищенных друг от друга сессиях сервера.

В системе с использованием тонкого клиента по сети или коммутируемой телефонной линии на сервер передаются сигналы, отражающие нажатие на ту или иную клавишу либо то или иное движение мыши. А сервер производит соответствующие действия и формирует изменения экрана пользователя и передаѐт эти изменения тонкому клиенту.

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

При работе в терминальной системе все прикладные программы, данные и параметры настроек хранятся на терминальном сервере. Это даѐт много преимуществ в плане изначального разворачивания рабочих мест (нет необходимости устанавливать программное обеспечение на каждом терминале), более удобного проведения резервного копирования данных (надо копировать только содержимое сервера), восстановления сессий после сбоев (все пользовательские сессии автоматически сохраняются на сервере). Еще одно преимущество технологии тонких клиентов состоит в том, что она ориентирована на с0трудников, пользующихся дистанционным д0ступом. Если какое-то время сотрудникам компании нужно работать вне офиса (скажем, в командировке, в другом офисе или дома), эта проблема легко решается с помощью систем на базе тонких клиентов.

Технология тонких клиентов предоставляет высокую производительность и на низко производительных рабочих местах, за счѐт использования вычислительных ресурсов терминального сервера. При необходимости увеличить вычислительную мощность всей системы достигается заменой всего лишь одного устройства – терминального сервера, все рабочие места автоматически переходят на более высокий уровень производительности без необходимости замены каких-либо устройств

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

Большинство современных средств быстрой разработки приложений (RAD), которые работают с различными базами данных, реализует стратегию: "толстый" клиент обеспечивает интерфейс с сервером базы данных через встроенный SQL. Такой вариант реализации системы с "толстым" клиентом, кроме перечисленных выше недостатков, обычно обеспечивает недопустимо низкий уровень безопасности. Например, в банковских системах приходится всем операционистам давать права на запись в основную таблицу учетной системы. Кроме того, данную систему почти невозможно перевести на Web-технологию, так как для доступа к серверу базы данных используется специализированное клиентское ПО.

Итак, рассмотренные выше модели имеют следующие недостатки:

"Толстый" клиент:

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

"Толстый" сервер:

• усложняется реализация, так как языки типа PL/SQL не приспособлены для разработки подобного ПО, и нет хороших средств отладки;
• производительность программ, написанных на языках типа PL/SQL, значительно ниже, чем созданных на других языках, что имеет важное значение для сложных систем;
• программы, написанные на СУБД-языках, обычно работают недостаточно надежно; ошибка в них может привести к выходу из строя всего сервера баз данных;
• получившиеся таким образом программы полностью непереносимы на другие системы и платформы.

Для решения перечисленных проблем используются многоуровневые (три и более уровней) архитектуры клиент-сервер.

Рассмотрим следующие компоненты:

• презентационная логика (Presentation Layer - PL);
• бизнес-логика (Business Layer - BL);
• логика доступа к ресурсам (Access Layer - AL).

Таким образом, можно придти к нескольким моделям клиент-серверного взаимодействия 1):

"Толстый" клиент. Наиболее часто встречающийся вариант реализации архитектуры клиент-сервер в уже внедренных и активно используемых системах. Такая модель подразумевает объединение в клиентском приложении как PL, так и BL. Серверная часть, при описанном подходе, представляет собой сервер баз данных

2 Реализующий AL. К описанной модели часто применяют аббревиатуру RDA - Remote Data Access.

"Тонкий" клиент. Модель 3), начинающая активно использоваться в корпоративной среде в связи с распространением Internet-технологий и, в первую очередь, Web-браузеров. В этом случае клиентское приложение обеспечивает реализацию PL, а сервер объединяет BL и AL.

Сервер бизнес-логики. Модель с физически выделенным в отдельное приложение блоком BL.

1) Рассматриваемые в этой части варианты разделения функциональности между клиентом и сервером являются "классическими", далее будет использоваться не только устоявшаяся традиционная, но и более новая терминология, возникшая вследствие распространения в корпоративных средах Internet/intranet-технологий и стандартов.

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

3). Модели, основанные на Internet-технологиях и применяемые для построения внутрикорпоративных систем получили название - intranet. Хотя intranet-системами сегодня называют все, что так или иначе использует стек протоколов TCP/IP, с ними скорее следует связать использование Web-браузеров в качестве клиентских приложений. При этом важно отметить тот факт, что браузер не обязательно является HTML-"окном", но, в не меньшей

степени, представляет собой универсальную среду загрузки объектных приложений/компонент - Java или Active X.

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

Заключение

Любая компьютерная сеть по сути является сетью клиент-сервер. Пользователь, подключивший свой компьютер к Интернет, будет иметь дело с сетью клиент-сервер, и даже если компьютер не имеет выхода в сеть, его программное обеспечение, да и сам он, скорее всего, организованы по схеме клиент-сервер. Основная идея архитектуры «клиент-сервер» состоит в разделении сетевого приложения на несколько компонентов, каждый из которых реализует специфический набор сервисов. Компоненты такого приложения могут выполняться на разных компьютерах, выполняя серверные и/или клиентские функции. Это позволяет повысить надежность, безопасность и производительность сетевых приложений и сети в целом.

Изучив и проанализировав архитектуру информационной системы, в структуру которой входят файл-сервер и клиент-сервер мною был сделан вывод, что файл-сервер во многом уступает клиент-серверу.

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

При этом возникают такие ограничения:

- невозможность организации равноправного одновременного доступа пользователей к одному и тому же участку базы данных;

- количество одновременно работающих с системой пользователей не превышает пяти человек для ЛВС;

- невысокая скорость обработки и представления информации;

- высокие требования к ресурсам компьютеров.

При всем этом система обладает одним очень важным преимуществом - низкой стоимостью.

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

Рассмотрев языки запросов SQL и QBE, был сделан вывод, что SQL является более гибким и динамичным, а также он поддерживает высокий уровень безопасности данных, их централизованное хранение, а так же он ориентирован на конечный результат обработки данных.

В принципы разработки приложений архитектуры клиент-сервер входит обеспечение безопасности данных, организация взаимодействия клиента и сервера, все это образуется при использовании языка SQL.

Используемая литература

1. Олифер В. Г., Олифер Н. А. Компьютерные сети. Принципы, технологии, протоколы: Учебник для вузов. 4-е изд.-СПб.:Питер,2015.
2. Калюжный В. П., Осипов Л. А. Администрирование информационных сетей: учебное пособие. – СПб.: ГУАП, 2010.
3. Палмер М., Синклер Р.Б. Проектирование и внедрение компьютерных сетей. 2-е изд.-Спб:БХВ- Петербург, 2004.
4. Информатика / Под ред. Н.В. Макаровой. Финансы и статистика, 1998.
5. Евдокимов В.В. и др. Экономическая информатика. СПб.: Питер, 2004.
6. Информатика. Базовый курс / Под ред. С.В. Симоновича: Питер, 2004.
7. Казаков С.И. Основы сетевых технологий – М.: Радио и связь, 2004.
8. Когаловский М.Р.,  Технология баз данных на персональных ЭВМ, – М.: Финансы и статистика, 2003.
9. Попов В.В. Основы компьютерных технологи: Финансы и статистика.
10. Фигурнов В.Э. IBM PC для пользователя. М., 2000.