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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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