Технология Клиент-сервер 3

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-модели, которая в наибольшей степени отражает сильные стороны технологии «клиент-сервер».

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

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

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

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

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

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

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

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

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

Результаты анализа моделей технологий «Файловый сервер» и «Клиент – сервер» представлены в таблице 1.

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

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

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

Таблица 1 - Результаты анализа моделей технологий «Файловый сервер» и «Клиент – сервер»

Критерии	«Файловый сервер»	«Клиент – сервер»
	FS - модель	RDA-модель	DBS-модель	AS-модель
1	2	3	4	5
Сложность разработки приложений	Низкая	Низкая	Высокая	Высокая
Сложность администрирования	Низкая	Высокая	Высокая	Высокая
Степень защиты данных	Высокая	Низкая	Высокая	Высокая
Требования к характеристикам сервера	Высокие	Низкие	Высокие	Высокие
Трафик, создаваемый в сети	Низкий	Очень высокий	Низкий	Низкий
Сложность обновления ПО	Низкая	Высокая	Низкая	Низкая
Требования к характеристикам сети	Низкие	Очень высокие	Низкие	Низкие
Распределение загрузки	Нет	Есть	Есть	Есть
Требования к характеристикам рабочих станций	-	Очень высокие	Низкие	Низкие
Использование графического интерфейса	-	+	+	+
Использование символьного интерфейса	+	+	+	+

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

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

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

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

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

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

Программное обеспечение сервера предусматривает и другие действия над информацией: обновление, удаление, добавление, защита и так далее.

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

Инструментальные средства, приложения и утилиты для интерфейсной части дополняют возможности модели «Клиент-сервер». К ним относятся средства запросов, которые упрощают доступ к данным сервера, используя предопределенные запросы и встроенные возможности для построения отчетов, пользовательские приложения, которые могут работать в качестве интерфейсной части, предоставляя доступ к серверу базы данных. Другие приложения (такие, как Microsoft Access) имеют свой собственный SQL, который обеспечивает доступ к системам управления базами данных от разных производителей. Для реализации систем «Клиент-сервер» необходимы специально разработанные интерфейсные части. Средства разработки программ (например, Microsoft Visual Basic) значительно облегчают программистам и администраторам информационных систем создание приложений, которые отвечают за доступ к серверам базы данных.

В зависимости от выбора операционной системы (ОС) и поставленных задач определяется программное обеспечение. Так, если используется ОС Windows, то на компьютере – клиенте обычно используется пакет Microsoft Office, в состав которого входят текстовый процессор Word, табличный процессор Excel, система подготовки презентаций PowerPoint, система управления базами данных Access и программа управления информацией Outlook

В связи с успехом распространения пакета Microsoft Office корпорация Microsoft решила собрать комплекс программ для сервера –пакет MS BackOffice. В состав названного пакета входят Windows Server – сетевая операционная система, System Management Server – система администрирования сети, SQL Server – сервер управления базами данных, SNA Server – сервер для соединения с хост-компьютерами, Exchange Server – сервер системы электронной почты и Internet Information Server – сервер для работы с Internet.

Windows Server 2000/2003/2008 способна обеспечить совместное использование файлов, печатающих устройств, предоставить услуги по соединению с рабочими станциями (клиентскими компьютерами) и другой сервис.

В качестве сетевой операционной системы используют Windows 2000/2003/2008 Server, которую можно использоваться и на рабочей станции для реализации дополнительных возможностей.

Windows Server 2000/2003/2008 обеспечивает совместное использование не только множества процессов, но и ресурсов многими пользователями. Возможность соединения с удаленными сетями реализуется через сервис удаленного доступа – RAS (Remote Access Service), а также через средства связи с сетями других фирм (Novell, Digital Pathworks и Apple).

System Management Server (SMS) позволяет сетевому администратору централизованно управлять всей сетью. При этом обеспечивается возможность администрирования каждого компьютера, подключенного к сети, включая установленное на нем программное обеспечение. SMS предоставляет различные виды сервиса, например управление сетевыми приложениями и инвентаризацией программного и аппаратного обеспечения. SMS включает в себя автоматизацию установки и распространения программного обеспечения, включая его обновление, удаленное устранение неисправностей и предоставление полного контроля администратору за устройствами ввода и экранами всех компьютеров в сети.

SQL Server представляет собой систему управления реляционными базами данных, использующую принципы технологии «Клиент-сервер». MS SQL Server поддерживает систему обработки транзакций и механизм распределенных транзакций, систему сохранения ссылочной целостности и тиражирование данных.

SNA Server позволяет нескольким настольным ПЭВМ, работающим под управлением различных операционных систем «видеть» хост-компьютеры.

Exchange Server обеспечивает средства передачи и приема сообщений в информационной сети организации. Этот сервис включает электронную почту (E-mail) и обмен информационными сообщениями для рабочих групп. Microsoft Exchange Server построен на принципах технологии «Клиент-сервер» и масштабируется в соответствии с возрастанием вычислительных возможностей сети.

Internet Information Server обеспечивает возможность создания Web-, FTP- и Gopher-серверов для сети Internet, поддерживает управление ими с помощью встроенной программы Internet Service Manager.

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

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

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

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

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

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

Поэтому любая СУБД не может одинаково успешно применяться при работе с БД разных классов.

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

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

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

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

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

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

Если же все составляющие транзакции были успешно выполнены, то происходит процесс фиксирования транзакции.

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

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

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

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

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

- менеджер транзакций, управляющий распределенными операциями;

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

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

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

Первые менеджеры транзакций появились еще в начале 70-х годов прошлого века и использовались еще в технологии «Файловый сервер». С приходом технологии «Клиент - сервер» они незначительно изменились идеологически, но весьма существенно - технологически. Наибольшие идеологические изменения произошли в коммуникационном менеджере, так как в этой области появились новые объектно-ориентированные технологии (CORBA, DCOM и так далее).

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

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

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

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

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

Основными характеристиками мониторов транзакций являются:

- гибкость доступа к данным;

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

- производительность.

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

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

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

Одним из современных мониторов транзакций является Microsoft Transaction Server (MTS). Microsoft Transaction Server обеспечивает поддержку транзакций, служб масштабирования, управления подключениями и администрирования, которые позволяют создавать и развертывать масштабируемые серверные приложения, делая при этом управление транзакциями прозрачным для разработчика компонентов.

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

Рисунок 5 – Конфигурация СУБД с архитектурой «Клиент-сервер» для работы с мониторами обработки транзакций.

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

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

С появлением глобальных сетей многоуровневая архитектура «Клиент – сервер» нашла свое применение в Internet. Другими словами, архитектура Internet не что иное, как архитектура «Клиент – сервер»: пользователь всегда работает с программой - клиентом (Internet Explorer или Netscape Navigator), которая обращается к web-серверам, обслуживающим одновременно десятки и сотни запросов от клиентов по всему миру.

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

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

Помимо клиентов-браузеров бывают и другие клиенты, например, клиенты электронной почты (Outlook Express, Netscape Messenger, The Bat, Pegasus Mail, Pine, Eudora и другие.), клиенты для приема и передачи файлов (ftp-клиенты), telnet-клиенты, которые необходимы для интерактивной работы на удаленном узле (простейший telnet-клиент - программа telnet.exe) и многие другие.

Программы-серверы также разнообразны: web – сервер, DNS – сервер, ftp-сервер (для передачи файлов), сервер приложений (для удаленной работы с приложениями), сервер электронной почты и другие.

Технология «Клиент – сервер» для Internet организована следующим образом (рисунок 55):

- клиент формирует и посылает запрос на сервер;

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

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

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

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

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

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

Цикл повторяется, пока пользователь не закончит работу с сервером.

Риунок 55 - Технология «Клиент – сервер» для Internet

В сервисе WWW для передачи информации применяется протокол НТТР, при работе которого сервер не имеет никакой информации о состоянии браузера. При этом взаимодействовать с сервером возможно только через механизм URL, это создает некоторые трудности при реализации клиентской части. Схема передачи информации по протоколу НТТР состоит из следующих этапов (рисунок 56):

- браузер преобразует доменное имя из URL в IP-адрес и устанавливает соединение с сервером;

- браузер передает остальную часть URL на сервер;

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

- сервер пересылает файл браузеру;

- сервер разрывает соединение;

- браузер отображает документ.

Существует множество технологий и языков программирования для написания серверных и клиентских Internet – приложений. В настоящее время большое распространение получила технология Java, с помощью которой можно строить универсальные системы со смешанной архитектурой, приложения, выполняемые на стороне клиента, называются апплетами (applets), на стороне сервера - сервлетами (servlets). Достаточно большой популярностью пользуется Flash-технология, в рамках которой можно создавать медиа-насыщенные интерактивные ресурсы, основная рабочая нагрузка при этом ложится на компьютер пользователя.

Рисунок 56. - Схема работы по HTTP в архитектуре «Клиент-сервер» для Internet

С помощью CGI (Common Gateway Interface) приложений возможно взаимодействие с любыми базами данных через формирование SQL запросов, или другие механизмы; также возможна реализация счетчиков посещений, гостевых книг и других расширений. CGI реализуется через скрипты на любом из языков программирования высокого уровня (наиболее часто используют С++, Perl, VisualBasic, Pascal, Java).

Server Sides Includes (SSI/SSI+) - технология динамического формирования документов (в том числе и работы с БД). Скрипт (точнее серверные инструкции) находится в HTML файле обычно имеющем расширение sht или shtm, при этом серверные инструкции размещаются между специальными разделителями (tokens), а сами инструкции записаны на языке Сscript, хотя это в большей степени зависит собственно от сервера. При пересылке такой файл сканируется сервером на наличие SSI инструкций и результат динамически подставляется в посылаемый документ. SSI реализуется через специальные компоненты (динамические библиотеки), которые входят в состав сервера. По аналогичному принципу организована работа со скриптами на языке PHP, в этом случае, программные конструкции включаются в HTML с помощью разделителей <? php и ?>.

Схожей по технике формирования динамических страниц является технология Active Server Pages (ASP) от Microsoft. Данная технология опирается на использование разнообразных объектов и компонент (COM, ActiveX и тому подобное), работа с которыми ведётся средствами языков VBScript или JavaScript.

Internet Server Application Programming Interface (ISAPI), реализуется через механизм DLL. C помощью ISAPI Internet connector возможно взаимодействие с базами данных (SQL Server, Oracle, RBase, Access, Paradox, dBASE) через драйверы Open Database Connectivity (ODBC), также возможна реализация других расширенных функций (создание различных фильтров запросов). Основным средством разработки приложений является Microsoft Visual C++ (The Internet Server API Extension Wizard). Данный механизм поддерживается Microsoft Internet Information Server (MS IIS).

Также нашли свое применение JavaScript, VBScript, SGML, HTML, XML и другие языки, ориентированные на описание структур документов.

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

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

Intranet - частная компьютерная сеть, являющаяся внутренней web-системой, локализованной в пределах одной организации, в которой используются стандарты и протоколы Internet (сервисы Web, TCP/IP, http, протоколы связи и HTML – страницы). Другими словами, Intranet – это частная, защищенная внутрикорпоративная сеть, при построении которой используются технологии Internet, доступная только сотрудникам организации, причем независимо от их физического местонахождения, ведь для доступа в Intranet сети используется Internet как транспорт

Термин «Intranet» впервые появился 19 апреля 1995 году в журнале Digital News & Review.

Для преобразования локальной или региональной компьютерной сети в Intranet не потребуется распродавать старое оборудование, можно обойтись уже существующими ресурсами.

Архитектура Intranet основана на архитектуре «Клиент-сервер» (рисунок 57).

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

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

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

- криптографию - шифрование секретной информации.

- экранирование - возможность односторонней передачи данных.

Рисунок 56 – Простейшая схема Intranet с архитектурой «Клиент – сервер»

Наличие диалоговых свойств в HTML и интерфейса CGI позволяет строить Internet-приложения с доступом к БД. Наиболее распространена схема динамической публикации отчетов. При этом в качестве CGI-процедуры используется параметризуемый генератор отчетов. Однако это не единственная схема, возможно применять программы ввода и обновления информации в БД.

Если используются традиционные статичные страницы гипертекста, то в ответ на запрос клиента Web-сервер передает страницу в формате HTML. При работе с базой данных клиент указывает в форме программу или сценарий для запуска на сервере. Серверная процедура получает введенные пользователем данные, формирует и передает SQL-запрос (определяющий логику управления данными) и, возможно, данные к СУБД. Сервер БД по запросу выполняет обновление, вставку, удаление или выборку записей из БД. CGI-процедура преобразует полученные результаты в формат HTML или в формат диалоговых переменных. Затем Web-сервер посылает полученную HTML-cтраницу или значения диалоговых переменных браузеру для отображения.

Использование CGI-процедур имеет ряд недостатков – статичное представление информации, преобразование результата-отчета в HTML-файл, отсутствие динамического просмотра изменения информации в базе данных, процедура «не помнит состояний запросов» – каждое обращение к БД требует повторного установления соединения. Кроме того, такой принцип работы перегружает коммуникационную среду и имеет системные издержки при запуске серверных процессов.

Для устранения недостатков CGI используют возможности специальных API для Web-серверов и включают дополнительное «релейное» звено в архитектуру. Все это только подталкивает к дальнейшему совершенствования архитектуры «Клиент-сервер».

Intranet имеет пять основных функций:

- электронная почта;

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

- каталогизация;

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

- поиск и управление сетью.

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

Основные достоинства Intranet:

-универсальность;

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

-прозрачная интеграция;

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

-гибкость;

Web, как средство доступа к базам данных и приложениям, меняет традиционное отношение к архитектуре «Клиент – сервер». Используя браузер, как средство доступа к корпоративной сети, пользователь получает единый инструмент для работы с базами данных, приложениями и различными другими службами.

-ценовая эффективность;

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

- безопасность;

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

-высокая производительность.

Для достижения такого уровня производительности в сети используется один из основополагающих принципов построения Intranet - наращиваемость.

Недостатки Intranet:

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

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

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