Файл: Возможности и назначение программы «Клиент- Сервер».pdf

Прикладная логика «rich»-клиента также реализована на сервере. Данные отправляются в стандартном формате обмена, на основе того же XML (протоколы SOAP, XML-RPC) и интерпретируются клиентом.

Некоторые основные протоколы «rich»-клиентов на базе XML приведены ниже:

XAML (eXtensible Application Markup Language) — разработан Microsoft, используется в приложениях на платформе .NET;

XUL (XML User Interface Language) — стандарт, разработанный в рамках проекта Mozilla, используется, например, в почтовом клиенте Mozilla Thunderbird или браузере Mozilla Firefox;

Flex — мультимедийная технология на основе XML, разработанная Macromedia/Adobe. [3]

Многоуровневая архитектура клиент-сервер — разновидность архитектуры клиент-сервер, в которой функция обработки данных вынесена на один или несколько отдельных серверов. Это позволяет разделить функции хранения, обработки и представления данных для более эффективного использования возможностей серверов и клиентов. [4.С.122]

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

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

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

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

Рис.2. Компоненты сетевого приложения

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

компонент представления отвечает за пользовательский интерфейс;

прикладной компонент реализует алгоритм решения конкретной задачи;

компонент управления ресурсом обеспечивает доступ к необходимым ресурсам. [1]

Автономная система (компьютер, не подключенный к сети) представляет все эти компоненты как на различных уровнях (ОС, служебное ПО и утилиты, прикладное ПО), так и на уровне приложений (не характерно для современных программ). Так же и сеть — она представляет все эти компоненты, но, в общем случае, распределенные между узлами. Задача сводится к обеспечению сетевого взаимодействия между этими компонентами.

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

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

Двухзвенная архитектура

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

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

Расположение компонентов на стороне клиента или сервера определяет следующие основные модели их взаимодействия в рамках двухзвенной архитектуры:

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

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

сервер БД — удаленное представление данных;

сервер приложений — удаленное приложение.

Исторически первой появилась модель распределенного представления данных (модель сервер терминалов). Она реализовывалась на универсальной ЭВМ (мэйнфрейме), выступавшей в роли сервера, с подключенными к ней алфавитно-цифровыми терминалами. Пользователи выполняли ввод данных с клавиатуры терминала, которые затем передавались на мэйнфрейм и там выполнялась их обработка, включая формирование «картинки» с результатами. Эта «картинка» и возвращалась пользователю на экран терминала. [2]

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

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

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

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

возможно централизованное администрирование прикладных функций;

снижение стоимости владения системой (TOC, total cost of ownership) за счет аренды сервера, а не его покупки;

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

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

Реализация прикладного компонента на стороне сервера представляет следующую модель — сервер приложений. Перенос функций прикладного компонента на сервер снижает требования к конфигурации клиентов и упрощает администрирование, но представляет повышенные требования к производительности, безопасности и надежности сервера. [2]

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

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

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

Представление данных — на стороне клиента.

Прикладной компонент — на выделенном сервере приложений (как вариант, выполняющем функции промежуточного ПО).

Управление ресурсами — на сервере БД, который и представляет запрашиваемые данные.

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

2.4 Физически клиент и сервер

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

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

Преимущества:

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

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

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

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

Классические недостатки:

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

Поддержка работы данной системы требует отдельного специалиста — системного администратора.

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

Однако, классические недостатки при реализации данного метода не являются существенными, так как:

Производительность сервера, например, при расчете задачи в Microsoft Excel, вообще не является определяющей.

Стоимость оборудования не очень высока, это обычный ПК или ноутбук.

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

3. Структурная схема и практическая реализация метода

Принципиальная схема данного метода:

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

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

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

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

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

Программа «Temper-3d», которая используется для расчета, зарегистрирована в реестре алгоритмов и программ для ЭВМ [4].

Клиентская часть, инструкции, документация, а также другая информация выложена на официальном сайте [5].

Расчет МКЭ это сложный математический алгоритм, его программная реализация представляет собой коммерческий, достаточно дорогостоящий продукт, который не может быть выложен в сеть Интернет в свободном доступе.

Ранее (в 2000 г.), в программе «Temper-3d» (версия 4.9) для защиты использовался метод привязки программы к компьютеру пользователя, который не позволял производить бесконтрольное копирование продукта на другой ПК. Также использовались ключи HASP На протяжении более 10 лет этот метод (версия 4.9) успешно использовался, но в настоящее время это не стало отвечать всевозрастающим потребностям. Вот уже 3 года, как реализован метод клиент-серверного обслуживания.