Преподаватель который помогает студентам и школьникам в учёбе.

Технология «клиент-сервер»

Содержание:

Введение

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

Объект исследования – клиент-серверные технологии.

Предмет исследования – архитектуры клиент-серверных приложений.

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

Для выполнения цели исследования, необходимо выполнить следующие задачи исследования:

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

Метод и методология проведения исследования – систематизация и анализ информации из открытых источников и научной литературы.

Глава 1. Теоретический обзор технологии клиент-серверной технологии

1.1 Технология клиент-сервер, основные принципы

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

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

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

Итак, в общих чертах система клиент-серверная система выглядит так:

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

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

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

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

• Прикладной программный интерфейс (Application Programming Interface, API) Набор функций и подпрограмм, обеспечивающих взаимодействие клиентов и серверов

• Клиент Объект, запрашивающий информацию по сети. Как правило, это персональный компьютер или рабочая станция, запрашивающая информацию у сервера

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

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

• Сервер Компьютер (как правило, высокопроизводительная рабочая станция, миникомпьютер или мэйнфрейм), хранящий информацию, с которой работают сетевые клиенты

• Язык структурированных запросов (Structured Query Language, SQL) Разработанный корпорацией IBM и стандартизованный институтом ANSI язык для создания, управления и изменения баз данных

Иногда программы являются равноправными участниками обмена информацией, поэтому нельзя однозначно утверждать, что одна программа обслуживает другую. Однако, в случае использования стека протокола TCP/IP это различие более четкое. Сервер – это та часть, которая прослушивает порт в ожидании входящих TCP-соединений или UDP-датаграмм от одного или нескольких клиентов [1]. Но в одном приложении могут быть совмещены функции как клиента, так и сервера. В качестве примера, можно привести вариант, когда одно приложение является клиентом по отношению ко второму, и сервером – по отношению к третьему. Как следствие, разделение ролей частей ПО на клиентов и серверы лишь условность, оговоренная используемым стеком протоколов.

1.2 Сетевая инфраструктура клиент-серверного приложения

Каждой точке подключения устройства к сети присваивается уникальный номер – IP-адрес (Internet Protocol Address). IP-адрес присваивается не устройству (компьютеру), а интерфейсу подключения. В принципе устройства могут иметь несколько точек подключения, а значит несколько различных IP-адресов.

IP-адрес это 32х разрядное число или 4 байта. Для наглядности принято записывать его в виде 4 десятичных чисел от 0 до 255, разделенных точками. Например, IP-адрес моего сервера 31.31.196.216.

Для того чтобы сетевому оборудованию было проще выстраивать маршрут доставки пакетов в формат IP-адреса введена логическая адресация. IP-адрес разбит на 2 логических поля: номер сети и номер узла. Размеры этих полей зависят от значения первого (старшего) октета IP-адреса и разбиты на 5 групп – классов. Это так называемый метод классовой маршрутизации. (см таблица 1).

Таблица 1 – IP-адресация в клиент-серверных приложениях

Класс	Старший октет	Формат (С-сеть, У-узел)	Начальный адрес	Конечный адрес	Количество сетей	Количество узлов
A	0	С.У.У.У	0.0.0.0	127.255.255.255	128	16777216
B	10	С.С.У.У	128.0.0.0	191.255.255.255	16384	65534
C	110	С.С.С.У	192.0.0.0	223.255.255.255	2097152	254
D	1110	Групповой адрес	224.0.0.0	239.255.255.255	-	2²⁸
E	1111	Резерв	240.0.0.0	255.255.255.255	-	2²⁷

Класс A предназначен для применения в больших сетях. Класс B используется в сетях средних размеров. Класс C предназначен для сетей с небольшим числом узлов. Класс D используется для обращения к группам узлов, а адреса класса E зарезервированы.

Существуют ограничения на выбор IP-адресов. Например:

Адрес 127.0.0.1 называется loopback и используется для тестирования программ в пределах одного устройства. Данные посланы по этому адресу не передаются по сети, а возвращаются программе верхнего уровня, как принятые.
“Серые” адреса – это IP-адреса разрешенные только для устройств, работающих в локальных сетях без выхода в Интернет. Эти адреса никогда не обрабатываются маршрутизаторами. Их используют в локальных сетях.
- Класс A: 10.0.0.0 – 10.255.255.255
- Класс B: 172.16.0.0 – 172.31.255.255
- Класс C: 192.168.0.0 – 192.168.255.255
Если поле номера сети содержит все 0, то это означает, что узел принадлежит той же самой сети, что и узел, который отправил пакет.

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

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

Сетевому узлу присваивается не только IP-адрес, но и маска подсети. Она имеет такой же размер, как и IP-адрес, 32 бит. Маска подсети и определяет, какая часть IP-адреса относится к сети, а какая к узлу.

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

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

По сути, маска позволяет одну большую сеть разбить на несколько подсетей. Размер любой подсети (число IP-адресов) должен быть кратным степени числа 2. Т.е. 4, 8, 16 и т.д. Это условие определяется тем, что биты полей адресов сети и узлов должны идти подряд. Нельзя задать, например, 5 битов - адрес сети, затем 8 битов – адрес узла, а затем опять биты адресации сети.

Пример формы записи сети с четырьмя узлами выглядит так:

Сеть 31.34.196.32, маска 255.255.255.252

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

Сеть 31.34.196.32/30

/30 это число единиц в маске подсети. В данном примере остается два нуля, что соответствует 2 разрядам адреса узла или четырем узлам.

Таблица 2 – Соотношение размера сети и маски подсети

Размер сети (количество узлов)	Длинная маска	Короткая маска
4	255.255.255.252	/30
8	255.255.255.248	/29
16	255.255.255.240	/28
32	255.255.255.224	/27
64	255.255.255.192	/26
128	255.255.255.128	/25
256	255.255.255.0	/24

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

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

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

Доменное имя — это последовательность из двух или более слов, разделенных точками. Последнее слово — это домен первого уровня, предпоследнее – домен второго уровня и т.д. Думаю, об этом знают все.

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

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

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

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

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

В общем случае использование сетевого шлюза выглядит так:

Допустим у нас система из нескольких плат Ардуино, подключенных через локальную сеть Ethernet к маршрутизатору, который в свою очередь подключен к Интернету.
В локальной сети мы используем «серые» IP-адреса (выше об этом написано), которые не допускают выхода в Интернет. У маршрутизатора два интерфейса: нашей локальной сети с “серым” IP-адресом и интерфейс для подключения к Интернету с «белым» адресом.
В конфигурации узла мы указываем адрес шлюза, т.е. “белый” IP-адрес интерфейса маршрутизатора, подключенного к Интернету.
Теперь, если маршрутизатор получает от устройства с «серым» адресом пакет с запросом на получение информации из Интернета, он заменяет в заголовке пакета «серый» адрес на свой «белый» и отправляет его в глобальную сеть. Получив из Интернета ответ, он заменяет «белый» адрес на запомненный при запросе «серый» и передает пакет локальному устройству.

MAC-адрес — это уникальный идентификатор устройств локальной сети. Как правило, он записывается на заводе-производителе оборудования в постоянную память устройства.

Адрес состоит из 6 байтов. Принято записывать его в шестнадцатеричной системе исчисления в следующих форматах: c4-0b-cb-8b-c3-3a или c4:0b:cb:8b:c3:3a. Первые три байта это уникальный идентификатор организации-производителя. Остальные байты называются «Номер интерфейса» и их значение является уникальным для каждого конкретного устройства.

IP-адрес является логическим и устанавливается администратором. MAC-адрес – это физический, постоянный адрес. Именно он используется для адресации фреймов, например, в локальных сетях Ethernet. При передаче пакета по определенному IP-адресу компьютер определяет соответствующий MAC-адрес с помощью специальной ARP-таблицы. Если в таблице отсутствуют данные о MAC-адресе, то компьютер запрашивает его с помощью специального протокола. Если MAC-адрес определить не удается, то пакеты этому устройству посылаться не будут.

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

Порт используется для определения процесса приемника пакета в пределах одного IP-адреса.

Под номер порта выделено 16 бит, что соответствует числам от 0 до 65535. Первые 1024 портов зарезервированы под стандартные процессы, такие как почта, веб-сайты и т.п. В своих приложениях их лучше не использовать.

Выводы по главе:

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

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

Глава 2. Анализ архитектуры клиент-серверных приложений

2.1 Многослойная организация приложения как основа клиент-серверной архитектуры

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

Рис. 1 – Руководство по проектированию клиент-серверных приложений от Microsoft

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

В приведенной схеме выделены следующие функционально-ориентированные слои:

Представление (вид, View) - компоненты и процессы отображения и взаимодействия с пользователем или внешней средой. Первое правило «хорошего тона» - код взаимодействия с пользователем (отображение, ввод/вывод) не должен находиться в компонентах, отвечающих за представление и обработку данных в программе;

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

Доступ к данным – объекты бизнес-модели (бизнес-сущности и бизнес-компоненты, а также связи между ними) хранятся в таблицах БД, из которых производится их сборка/разборка. Возможно также хранение (сериализация) бизнес-объектов в двоичных или текстовых (XML,JSON) форматах;

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

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

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

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

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

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

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

2.1. – представление (View), в которое включаются все элементы реализации интерфейса пользователя;
2.2. – логика бизнес-модели - описание «долгосрочного» ее поведения (Controller);
2.3. – объекты бизнес-модели и методы их преобразования, не связанные с долгосрочным поведением (Model);
2.4. – средства сборки объектов бизнес-модели из табличных объектов БД;

слой 3 – база данных (СУБД). В свою очередь, может состоять из 3 подслоев:

3.1. табличные объекты БД, DAO (data access objects) – объекты доступа к данным;
3.2. библиотека программного доступа к БД;
3.3. сама программная компонента БД (СУБД).

слой 4 – данные на физическом носителе (файлы).

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

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

Рис. 2 – Слои клиент-серверного приложения

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

Рассмотрим варианты создания клиента в зависимости от выбора точки «разрезания» слоев:

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

Слои 1-2. Типичный тонкий клиент, который управляется сервером на уровне отображения отдельных графических примитивов, изменения содержимого оконных объектов (тестовых полей, списков и т.п..), а также передачи серверу всех событий, происходящих в них (нажатие кнопок, выбор в списках, получение/потеря фокуса). Требует передачи большого объема данных, особенно при использовании графики. Пример: язык разметки HTML – браузер исполняет роль тонкого клиента, отображая сгенерированное сервером описание графического интерфейса (web-страницы) и уведомляя его о происходящих в нем событиях. В мобильных приложениях тонкие клиенты такого рода не особенно распространены, но его идеи могут использоваться, если структура графического интерфейса программируется сервером.

Слой 2. Поскольку этот слой связан с бизнес-моделью (программной моделью предметной области), то и объектами протокола являются элементы бизнес модели – команды (действия над бизнес-объектами) и сами бизнес-объекты. Внутри слоя возможны несколько вариантов границы клиент-сервер:

если граница располагается между подслоями 2.1-2.2, то получается максимально возможный тонкий клиент, сами бизнес-объекты и их поведение контролируются сервером, а клиент отображает бизнес-объекты и передает серверу сообщения о действиях, производимых пользователем над ними;
если граница лежит между подслоями 2.2-2.3, или 2.3-2.4, то клиент уже является толстым («в меру упитанным») – управляющая логика приложения находится в клиенте, а на сервер выносятся алгоритмы автономной работы с бизнес-объектами, а также средства их сборки/разборки из объектов БД.

Слой 3. Стандартным вариантом разделения внутри этого слоя является БД с сетевым (удаленным) доступом, т.е. на подслое 3.2. Многие СУБД используют соединения сети TCP/IP и свой внутренний протокол для доступа внешних клиентов к БД, в том числе и для администрирования, поэтому принципиальной разницы между локальным и дистанционным доступом к БД нет. Фактически граница разделения клиентской и серверной частей находится в библиотеке программного доступа к БД (ODBC, для Java - JDBC). Получившийся клиент является «толстым». Объем передаваемых данных по сети может быть относительно небольшим, поскольку передаются результаты SQL-запросов, содержащих необходимые выборки данных.

2.2 Классификация клиент-серверных приложений

На серверной машине могут находиться несколько серверных ПО, которые предоставляют необходимые ресурсы своим клиентам. Клиентские ПО не разделяют свои ресурсы с серверными ПО, а получают их при надобности — с помощью запросов на сервер. Серверные ПО ждут запросов от клиентских ПО и могут отправить им необходимые ресурсы в виде данных (например, загрузка файловых данных с помощью протоколов FTP, HTTP и т. д.) [4].

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

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

В каждом приложении, на базе модели клиент-сервер, можно выделить нижеперечисленные логические компоненты:

Компонент представления (англ. presentation) — предоставляющие возможности ввода / вывода и отображения данных.
Прикладной компонент (англ. business application) — поддерживающий прикладной функционал, типичный для конкретной предметной области.
Компонент доступа к информационным ресурсам (англ. Resource manager) —  поддерживающий возможности обработки и хранения данных, а также управления вычислительными ресурсами.
Протоколы взаимодействий, которые вводят и уточняют методы взаимодействия вышеперечисленных частей.

Существуют еще и факторы, которые определяют различия между реализациями модели клиент-сервер. В их число входят программные методы, используемые для реализации функционалов вышеперечисленных трех групп; разновидности ПО, в которые внедрены три компоненты; подходы распределения логических компонентов между узлами в сети; методы, применяемые для связывания этих же компонентов [4].

Выделяются четыре различающейся друг от друга модели и методы реализации клиент-сервер технологии [19]:

Модель и метод файл-сервера (англ. file server—FS). Во время этой модели один узел выступает в качестве файл-сервера и предоставляет другим узлам сети возможности обработки файловых данных. Файл-сервер функционирует с помощью сетевой ОС и дает возможность доступа к файловым данным.

Рис. 3 - Модель FS

Модель и метод доступа к удаленным данным (англ. remote data access — RDA). Главным различием данной модели от FS-модели является метод получения данных. В RDA-модели компонент прикладной программы и компонент представления (человеко-машинный интерфейс) реализовываются на стороне клиента. Получение доступа к данным осуществляется с помощью специальных языковых операторов (например, SQL) или вызовов функций API, предоставляемого серверным ПО.

Рис. 4 - Модель RDA

Модель и метод сервера баз данных (англ. data base server — DBS). При данном подходе понятие ресурса сужается до баз данных. Только компонент представления выполняется на стороне клиента, а компонент прикладной программы реализован в виде набора хранимых процедур и предназначен для работы на сервере базы данных.

Рис. 5 - Модель DBS

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

Рис. 6 - Модель AS

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

Выводы по главе:

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

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

Глава 3. Разработка архитектуры типового клиент-серверного веб приложения

3.1 Общая структура приложения

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

Рис. 7 – Взаимодействие клиента и сервера

1. а) Запрос на получение списка комнат.

б) Получение ответа со списком комнат.

2. а) Запрос на присоединение к комнате.

б) Получение ответа на запрос присоединения к комнате.

3. Цикл отправки/получения сообшений в пределах комнаты.

4. а) Запрос на выход из комнаты.

б) Получение ответа на запрос выхода из комнаты.

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

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

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

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

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

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

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

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

Клиент и сервер могут обмениваться различными типами сообщений. В их состав входят:

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

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

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

3.2 Клиентская часть

Как упоминалось в п.3.1, клиент взаимодействует с серверной частью посредством доступа к методам web-службы, также называемым web-методами, по протоколу SOAP. Таким образом, устраняется проблема блокировки межсетевым экраном нестандартных пользовательских портов. В результате для большинства пользователей обеспечивается беспрепятственное подключение к серверу.

Рис. 8 – Работа web-службы на WSDL

В коде клиента создается прокси-класс web-службы, на основе которого клиент может создавать объекты и вызывать методы этих объектов. Он генерируется в соответствии с WSDL описанием web-службы (см. рис. 6) с помощью утилиты предоставляемой средой разработки. Прокси-класс содержит такой же набор методов, что и у оригинального класса (здесь имеются в виду методы, помеченные в реализации web-службы атрибутом WebMethod, то есть возможные для удаленного вызова). Для клиента, таким образом, вызов web-метода ничем не отличается от вызова обычного метода. Принципиальным отличием здесь является механизм передачи параметров и возвращаемого значения.

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

Данные SOAP можно передавать, используя различные интернет-протоколы (HTTP, SMTP и пр.) В нашем случае, SOAP-сообщение содержится в заголовке HTTP.

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

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

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

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

3.3 Серверная часть

Серверную часть приложения удобно реализовать в виде XML web-службы, разворачиваемой в составе web-приложения на web-сервере Internet Information Services. Основными функциями серверной части являются: управление комнатами, подключениями клиентов и их состоянием, выполнение синхронизации между клиентами. Web-служба также содержит набор методов для предоставления клиентам дополнительной информации.

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

ASP. Net – технология Microsoft, предназначенная для разработки webприложений. ASP. Net расширяет базовую функциональность IIS, позволяя webсерверу обрабатывать запросы элементов ASP.Net web-приложения. Клиенты обращаются к ресурсам web-приложения с помощью URL. Web-сервер транслирует URL в физический путь на диске сервера и имя файла. ASP. Net является ISAPI расширением IIS.

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

Жизненный цикл ASP.Net приложения начинается, когда клиент отправляет web-серверу запрос. IIS анализирует расширение запрашиваемого файла и, в соответствии с ним, определяет, какое ISAPI расширение должно обрабатывать этот запрос. Затем запрос передается этому расширению для обработки. Например, ASP.Net обрабатывает такие типы файлов, как aspx, .ascx, .ashx, и .asmx. Помимо этих стандартных расширений, к ASP.Net могут быть привязаны другие расширения файлов. Для этого расширение нужно зарегистрировать в IIS и поставить ему в соответствие обработчик ASP.Net.

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

После инициализации HostingEnvironment, ASP.Net создает объекты класса HTTPContext, HTTPResponse и HTTPRequest. Эти объекты создаются для каждого запроса. HTTPRequest содержит информацию о запросе, включая cookies, HTTPResponse – ответ, посылаемый клиенту, а HTTPContext включает в себя эти объекты.

После этого приложение запускается, путем создания объекта HTTPApplication. Web-приложение может содержать файл Global.asax, в котором описан класс-наследник HTTPApplication с реализацией специфической для webприложения реакции на внутренние события. В этом случае для создания экземпляра приложения ASP.Net использует не оригинальный класс HTTPApplication, а производный от него.

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

Рис. 9 - Схема отношения экземпляра HTTPApplication и запроса клиента

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

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

Процесс обработки запроса в течение жизненного цикла можно расширить с помощью реализации HTTP модулей. ASP.Net предоставляет несколько реализаций модулей HTTP, в их числе SessionStateModule. Этот модуль вызывает события, относящиеся к сессии пользователя, такие как Session_Start и Session_End. Приложение может подписаться на эти события и производить соответствующую обработку, некоторым образом реагируя на них.

Рис. 10 – Сеансы подключения в приложении

Для обработки доступа к методу web-службы, приложение создает экземпляр класса web-службы и вызывает соответствующий метод. Класс web-службы может быть производным от базового класса System.Web.Services.WebService, что позволяет получить прямой доступ к объектам Application и Session (типов HttpApplicationState и HttpSessionState). Эти объекты являются коллекциями пар «ключ-значение» и предоставляют способ сохранения информации о состоянии сессии пользователя и состоянии приложения между вызовами. Состояние приложения разделяется между всеми сеансами (см рисунок).

Данные сессии хранятся в памяти процесса ASP.Net, на сервере состояний (State server) или в базе данных. Хранение данных в памяти процесса обеспечивает высокую скорость доступа при условии, что объем данных не настолько большой, чтобы израсходовать оперативную память сервера и задействовать виртуальную дисковую память.

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

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

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

Выводы по главе:

В данной главе была рассмотрена разработка проекта приложения для сетевой коммуникации. Были рассмотрены основные принципы взаимодействия с webслужбами. Предложена структура приложения на основе XML web-службы и windows-приложения .Net.

Технология web-служб позволяет передавать различные типы параметров. Используя протоколы HTTP-GET и HTTP-POST возможно передавать простые типы CLR, массивы из этих типов и строки. Однако использование протокола SOAP представляется более гибкой альтернативой. В дополнение к уже перечисленным типам данных он позволяет передавать массивы сложных классов и структур, любые узлы XML и пользовательские типы. Передача данных производится в формате XML.

Заключение

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

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

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

В третьей главе была разработана архитектура типового клиент-серверного веб-приложения, которое осуществляет обмен сообщениями между множеством клиентов и сервером. Клиент взаимодействует с сервером по web-методам при участии протокола SOAP. Соединение осуществляет посредством сеансов обмена сообщениями между клиентами и сервером. Серверная часть приложения должна состоять из web-службы в виде XML. Основой серверного приложения является платформа Microsoft ASP.net.

Библиография

Амелин К. С., Граничин О. Н., Кияев В. И., Корявко А. В.. Введение в разработку приложений. Издательство ВВМ, 2017.
Варакин М.В. Разработка мобильных приложений под Android. УЦ «Специалист» при МГТУ им. Н. Э. Баумана, 2015.
ГолощаповА.Л. GoogleAndroid. Создание приложений для смартфонов и планшетных ПК. Издательство Питер 2015.
Каймин В.А. Информатика: Учебное пособие: Изд. 2-е. Издательство РИОР, 2017.
Коржов В. Многоуровневые системы клиент-сервер // Сети. 2017. N 6. С.72-75
Котляров В.П. Основы тестирования программного обеспечения. Издательство Бином, 2016.
Лекция на тему «Классификация клиент – серверных приложений» http://www.4stud.info/networking/lecture5.html
Никлаус Вирт Алгоритмы и структуры данных. Новая версия для Оберона ДМК Пресс, 2018
Простые клиент-серверные взаимодействия на Android https://habrahabr.ru/post/269135/
Сайт Habrahabr. Архитектура мобильного клиент-серверного приложения. – https://habrahabr.ru/post/246877/
Bill Phillips, Brian Hardy. Android Programming: The Big Nerd Ranch Big. NerdRanchGuides, 2013.
Herbert Schildt Java: The Complete Reference, Ninth Edition, 2015
John Wiley & Sons. Reto Meier Professional Android 4 Application Development. Wrox, 2016.
Martin Fowler. UML Distilled: A Brief Guide to the Standard Object Modeling Language (Object Technology Series). Addison Wesley, 2018.