Технология (модель взаимодействия) «Клиент-Сервер»

МИНИCTEPCTBO ОБРАЗОВАНИЯ И НАУКИ РОССИЙСКОЙ ФЕДЕРАЦИИ

Федеральное государственное  автономное образовательное  
учреждение высшего профессионального образования

«»

 

Кафедра

 

 

 

Контрольная рабоота

по дисциплине: «Информационные технологии»

на тему: Технология (модель взаимодействия) «Клиент-Сервер»

 

 

 

Выполнил:  студент

 

 

Проверил:  профессор

 

 

 

 

Ставрополь, 2013

 
Оглавление

1. Технология «Клиент – сервер» 3

2. Классическая двухуровневая архитектура «Клиент – сервер» 4

3. Трехуровневая модель 9

4. Различные модели технологии «Клиент – сервер» 12

5. Программное обеспечение технологии «Клиент – сервер» 22

6. Организация обработки данных в СУБД с архитектурой «Клиент-сервер» 26

7. Технология "Клиент-сервер" применительно к Internet 33

8. Технология «Клиент-сервер» применительно к Intranet 39

 

1. Технология «Клиент – сервер»

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

Со временем малофункциональную модель файлового сервера для  локальных сетей (FS) заменили появившиеся  одна за одной модели структуры «Клиент- сервер» (RDA, DBS и AS).

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

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

2. Классическая двухуровневая архитектура «Клиент – сервер»

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

Технология «Клиент –  сервер» - это архитектура программного комплекса, в которой происходит распределение прикладной программы по двум логически различным компонентам (клиент и сервер), взаимодействующим по схеме «запрос-ответ» и решающим свои определенные задачи (рисунок 1).

Рисунок 1. – Архитектура «Клиент – сервер»

Компьютер (или программа), управляющий и/или владеющий каким-либо ресурсом, называют сервером этого ресурса.

Компьютер (или программа), запрашивающий и пользующийся каким-либо ресурсом, называют клиентом этого ресурса.

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

Основной принцип технологии «Клиент-сервер» заключается в  разделении функций приложения как  минимум на три группы:

- модули интерфейса с пользователем;

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

- модули хранения данных;

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

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

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

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

В соответствии с разделением  функций в любом приложении выделяются следующие компоненты:

- компонент представления  данных;

- прикладной компонент;

- компонент управления  ресурсом.

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

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

Чтобы избежать несогласованности  различных элементов архитектуры  были созданы две модификации  двухзвенной архитектуры «Клиент  – сервер»: «Толстый клиент» («Тонкий  сервер») и «Тонкий клиент» («Толстый сервер»).

В данных архитектурах разработчики попытались выполнять обработку  данных на одной из двух физических частей - либо на стороне клиента («Толстый клиент»), либо на сервере («Тонкий клиент).

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

Есди все-таки разрабатывается  двухуровневая классическая архитектура  «Клиент – сервер», то необходимо помнить следующее:

- архитектура «Толстый  сервер» аналогична архитектуре  «Тонкий клиент» (рисунок 2);

Рисунок 2. – Архитектура «Тонкий клиент»

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

- усложняется реализация, так как языки типа SQL не приспособлены  для разработки подобного ПО  и нет хороших средств отладки;

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

- программы, написанные  на СУБД-языках, обычно работают  недостаточно надежно; ошибка  в них может привести к выходу  из строя всего сервера баз  данных;

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

- архитектура «Тонкий  сервер» аналогична архитектуре  «Толстый клиент» (рисунок 34).

Обработка запроса происходит на стороне клиента, то есть происходит передача клиенту всех необработанных данных с сервера. При этом архитектуры  имеют следующие недостатки:

- усложняется обновление  ПО, поскольку его замену нужно  производить одновременно по  всей системе;

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

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

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

Рисунок 3. – Архитектура  «Толстый клиент»

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

 

 

3. Трехуровневая модель

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

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

Сервер приложений – это программное обеспечение, являющееся промежуточным слоем между клиентом и сервером (рисунок 3).

Рисунок 4. - Сервер приложений

Существует несколько  категорий продуктов промежуточного слоя:

- 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.

 

 

4. Различные модели технологии «Клиент – сервер»

Самой первой базовой технологией  для локальных сетей являлась модель файлового сервера (FS). В свое время данная технология была очень среди отечественных разработчиков, использовавших такие системы, как FoxPro, Clipper, Clarion, Paradox и так далее.

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

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

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

Рисунок 5. - Модель файлового сервера

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

- простота разработки  приложений;

- удобство администрирования  и обновления ПО из-за компактного расположения всех компонентов на одном компьютере;

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

Но достоинства FS – модели перекрывают ее недостатки:

- большая загрузка сети;

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

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

- отсутствие графического  интерфейса.

Благодаря решению проблем, присущих технологии «Файл – сервер»  появилась более прогрессивная  технология, получившая название «Клиент  – сервер».

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

Различия в реализации приложений в рамках технологии «Клиент-сервер»  определяются четырьмя факторами:

- какие виды программного обеспечения в логических компонентах;

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

- как логические компоненты  распределяются компьютерами в  сети;

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

Исходя из этого, выделяются три подхода, каждый из которых реализован в соответствующей модели технологии «Клиент – сервер»:

- модель доступа к удаленным  данным (Remote Date Access - RDA);

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

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

Рассмотрим функции и  характеристики различных моделей  технологии «Клиент-сервер».

Модель доступа к удаленным  данным (RDA) – сетевая архитектура технологии «Клиент – сервер», при которой коды компонента представления и прикладного компонента совмещены и выполняются на компьютере-клиенте. Доступ к информационным ресурсам обеспечивается при помощи непроцедурного языка (например ,SQL – запросов для баз данных) или вызовами функций специальной библиотеки (если имеется специальный интерфейс прикладного программирования - API).

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

Рисунок 6. - Модель доступа к удаленным данным

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

При этом RDA-модель имеет  ряд ограничений.

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

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

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

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

Несмотря на широкое распространение, RDA-модель уступает место более технологичной DBS-модели.

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

В DBS-модели приложение является распределенным. Компонент представления  выполняется на компьютере-клиенте, в то время как прикладной компонент (реализующий бизнес-функции) оформлен как набор хранимых процедур и  функционирует на компьютере-сервере  БД. Хранимые процедуры также называют компилируемыми резидентными процедурами  или процедурами базы данных (рисунок  7).

Рисунок 7. - Модель сервера базы данных.

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

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

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

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

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

Все недостатки DBS - модели учтены в AS-модели, которая в наибольшей степени отражает сильные стороны  технологии «клиент-сервер».

Модель сервера приложений (AS) (рисунок 8)- сетевая архитектура технологии «Клиент – сервер», представляющая собой процесс, выполняемый на компьютере-клиенте и отвечающий за интерфейс с пользователем (ввод и отображение данных). Основным элементом данной модели является прикладной компонент, называющийся сервером приложения, функционирующий на удаленном компьютере (или нескольких компьютерах). Сервер приложений реализован как группа прикладных функций, оформленных в виде сервисов (служб). Каждый сервис предоставляет некоторые услуги всем программам, которые желают и могут ими воспользоваться.

Рисунок 8. - Модель сервера приложений.

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

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

Так как данные «спрятаны» за сервером приложений, в котором  обычно встроена проверка полномочий клиента, в СУБД обеспечивается высокий  уровень защиты данных.

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