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

Реализация серверной и клиентской части

Содержание:

Введение

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

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

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

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

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

- ввод и отображение данных (взаимодействие с пользователем);

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

- функции управления ресурсами (файловой системой, БД и т.д.)

Что позволяет решить следующие задачи:

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

- разделяемый доступ к данным;

- разделение функций по управлению данными;

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

- защищенность от сбоев и потери информации при помощи системы отката транзакций.

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

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

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

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

Недостатки:

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

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

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

Цель настоящей работы - раскрыть сущность технологии «клиент – сервер», и на примере рассмотреть взаимодействие клиентской и серверной частей. Для этого будут решены следующие задачи:

- рассмотрена сущность и принцип технологии «клиент – сервер»;

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

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

Предмет исследования – применение технологии «клиент - сервер».

Глава 1. Сущность технологии "клиент - сервер"

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

Основное предназначение клиент/серверных систем – это обмен информацией между клиентским и серверным приложениями.

Идея технологии «клиент-сервер» заключается в том, чтобы расположить серверы на мощных машинах, а приложения клиентов, использующих язык инструментальных средств, – на менее мощных машинах. Тем самым будут задействованы ресурсы более мощного сервера и менее мощных машин клиентов. Ввод-вывод к базе основан не на физическом дроблении данных, а на логическом, т.е. клиентам отправляется не полная копия базы, а сервер посылает только логически необходимые порции, тем самым, сокращая трафик сети.^[2] В технологии «клиент-сервер» программы клиента и его запросы хранятся отдельно от СУБД. Сервер обрабатывает запросы клиентов, выбирает необходимые данные из базы данных, посылает их клиентам по сети, производит обновление информации, обеспечивает целостность и сохранность данных.

Итак, клиент-сервер — это вычислительная или сетевая архитектура, в которой задания или сетевая нагрузка распределены между поставщиками услуг, называемыми серверами, и заказчиками услуг, называемыми клиентами. Фактически клиент и сервер — это программное обеспечение. Обычно эти программы расположены на разных вычислительных машинах и взаимодействуют между собой через компьютерную сеть посредством сетевых протоколов, но их можно расположить также и на одной машине^[3]. Программы — сервера, ожидают от клиентских программ запросы и предоставляют им свои ресурсы в виде данных (например, загрузка файлов посредством HTTP, FTP, BitTorrent, потоковое мультимедиа или работа с базами данных) или сервисных функций (например, работа с электронной почтой, общение посредством систем мгновенного обмена сообщениями, просмотр web-страниц во всемирной паутине)^[4]. Поскольку одна программа-сервер может выполнять запросы от множества программ-клиентов, ей может потребоваться высокопроизводительная вычислительная машина. Из-за особой роли этой машины в сети, специфики её оборудования и программного обеспечения её так же называют сервером – Рисунок 1.1.

Рисунок 1.1 – Упрощенная схема взаимосвязей в рамках функционирования технологии клиент-сервер

В клиент-серверной системе функционируют (как минимум) два приложения - клиент и сервер делящие между собой те функции которые в файл-серверной архитектуре целиком выполняет приложение на рабочей станции. Хранением и непосредственным манипулированием данными занимается сервер баз данных в качестве которого может выступать Microsoft SQL Server Oracle Sybase и т.п.^[5]

Плюсы технологии клиент сервер^[6]:

- Надежность. Сервер баз данных осуществляет модификацию данных на основе механизма транзакций;

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

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

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

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

- RPC (Remote Procedure Call) удаленный вызов процедур — система интеграции серверов в виде процедур доступных для вызова удаленным пользователем через унифицированный интерфейс. Интерфейс изобретенный Sun Microsystems для своей операционной системы (SunOS Solaris; Unix-система) в настоящее время используется как в большинстве Unix-систем так и в Windows.

- Серверы удаленного доступа. Серверы удаленного доступа через соответствующую клиентскую программу обеспечивают пользователя консольным доступом к удаленной системе. Для обеспечения доступа к командной строке служат серверы telnet RSH SSH.

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

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

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

- Защита пересылаемых данных только при установлении соединения клиента с сервером.

- Надежная система аутентификации администратора системы.

- Подтверждение подлинности источника данных.

- Использование надежных методов криптографии.

- Подтверждение подлинности источника, целостности и конфиденциальности данных.

- Использование сертифицированных средств защиты.

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

Глава 2. Пример взаимодействия серверной и клиентской частей в приложении для обмена текстовой и графической информацией в реальном времени

2.1. Описание приложения

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

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

Иногда серверная часть может включаться в клиентское приложение. В этом случае происходит взаимодействие типа «клиент-клиент». Тогда один из клиентов по предварительной договоренности несет на себе функции сервера, в результате являясь и клиентом, и сервером. Такая реализация в случае большого количества пользователей приводит к излишней нагрузке на одного из участников. Это, несомненно, является узким местом такого подхода. Еще одним из его недостатков является «утяжеление» клиентской части. В дополнение к сказанному заметим, что совмещение функций клиента и сервера в одном приложении может быть оправдано при реализации подключения «точка-точка», когда обе стороны в разное время могут меняться ролями^[9].

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

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

Для полного описания общей структуры приложения рассмотрим описание платформы Microsoft .Net, так как эта платформа предоставляет гибкие средства для разработки распределенных приложений. В их числе CLR (Common Language Runtime), единая среда исполнения, основанная на исполнении кода, реализованного на различных языках программирования. При этом используется преобразование такого кода в платформонезависимый промежуточный язык – MSIL (Microsoft Intermediate Language), а компиляция под конкретную платформу происходит по требованию, в момент исполнения. Также обратим внимание на наличие мощной библиотеки классов .Net Framework, в которой реализовано множество функций, необходимых для создания широкого спектра приложений. Архитектура .Net предлагает разноплановые средства исполнения сетевого взаимодействия. Они включают в себя реализации сетевых протоколов и механизмов доступа к удаленным объектам, в их числе XML web-сервисы, .Net Remoting и пр.^[10]

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

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

Web-сервисы (XML Web Services) тоже могут рассматриваться как удаленные объекты^[11]. В широком смысле, web-сервис – это класс, расположенный на web-сервере и использующий для предоставления доступа к своим методам HTTP - как протокол передачи данных и XML – как их формат. Клиент может обращаться к web-сервису с помощью URL и взаимодействовать с ним посредством прокси-объекта. Прокси содержит все те же методы, что и оригинальный класс, но его реализация просто перенаправляет вызовы методов оригинальному объекту.

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

Рисунок 1. Статическая генерация прокси-класса web-сервиса

Web-сервис .Net может быть размещен на web-сервере IIS. Клиент имеет описание web-службы на WSDL и вызывает ее методы, выполняя SOAP запросы согласно этому описанию. IIS обрабатывает запросы, направляя их экземпляру web-сервиса с помощью ISAPI расширений^[12].

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

Рисунок 2. Пример вызова web-сервиса через firewall

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

Клиентскую часть реализуем в виде Windows приложения на платформе .Net. Это дает возможность воспользоваться мощным инструментарием разработчика, библиотеками .Net, поддержкой генерации прокси-класса web-службы, сборкой мусора и другими удобствами Microsoft. Хотя, как уже упоминалось, для взаимодействия с web-службой нет особых ограничений на язык и платформу реализации клиентской части, кроме понимания HTTP и XML.

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

Рисунок 3. Основные этапы взаимодействия клиента и севера

1. а) запрос на получение списка комнат; б) получение ответа со списком комнат.

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

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

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

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

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

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

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

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

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

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

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

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

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

- сообщения о смене статуса пользователя,

- текстовые сообщения, содержащие текстовый ввод пользователя – сообщения чата,

- сообщения, включающие данные о графическом вводе – графические команды.

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

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

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

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

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

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

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

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

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

2.2. Структура серверной части

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

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

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

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

Жизненный цикл ASP.Net приложения начинается, когда клиент отправляет web-серверу запрос. IIS анализирует расширение запрашиваемого файла и, в соответствии с ним, определяет, какое ISAPI расширение должно обрабатывать этот запрос^[18]. Затем запрос передается этому расширению для обработки. Например, 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 может повторно использовать эти экземпляры для повышения производительности. Отношение запросов клиентов и экземпляров приложений отражено на Рисунке 2, Приложение 1.

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

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

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

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

Рисунок 4. Приложение и сеансы подключения

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

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

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

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

2.3. Структура клиентской части

Клиентская часть представляет собой Windows-приложение на платформе .Net, которое взаимодействует с сервером и предоставляет интерфейс пользователя. Структура клиентского приложения будет содержать несколько взаимосвязанных модулей, каждый из которых будет служить для выполнения одной из функций:

• взаимодействие с пользователем, обеспечение ввода текстовых и графических команд,

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

• преобразование ввода пользователя в последовательность графических команд и отображение графических команд.

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

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

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

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

2.4. Реализация серверной и клиентской части

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

Рассмотрим реализацию web-службы. Класс web-службы является производным от класса System.Web.Services.WebService, и содержит методы, доступные для удаленного вызова и методы описывающие внутреннюю логику. Для того, чтобы метод был доступен для удаленного вызова, он помечается атрибутом WebMethod. Если метод должен иметь доступ к состоянию сессии, свойство SessionEnabled этого атрибута устанавливается в true.

Класс содержит два статических элемента данных:

• Hashtable rooms – таблица комнат, ключом является идентификатор комнаты, значением – класс Room,

• Hashtable users – таблица пользователей, ключом является имя пользователя, значением – класс User.

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

Список команд реализован в виде класса CommandList, порожденного от базовой коллекции SortedList<long, Command>, и содержит список пар <ключ, команда>. Реализация производного класса позволяет выбрать или добавить к списку массив команд

• Command[] getNextItems(ref long key) – выбирает из списка и возвращает команды, находящиеся после указанного ключа, меняет значение переданного параметра key на ключ последнего элемента в списке,

• void insertItems(long key, Command[] cmds) – добавляет в конец списка массив команд, последовательно помечая каждую команду ключом key, каждый раз увеличивая его на 1.

Класс User содержит имя пользователя, номер комнаты, в которой он находится и его статус. Статус пользователя может принимать одно из значений перечисления UserStatus. Приведем их в порядке возрастания прав:

• SPERCTATOR – наблюдатель, может только наблюдать за рисованием других участников и общаться в чате,

• DRAWER – художник, в дополнение имеет право рисовать,

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

Класс web-службы содержит следующие web-методы:

• RoomInfo[] getRoomList() – возвращает список описаний комнат. Описание содержит имя комнаты, список пользователей в комнате и оценку активности в комнате.

• int Connect(string userName, int roomId, string roomName, int canvasWidth, int canvasHeight) – присоединение пользователя к комнате roomId или создание новой комнаты, если такой комнаты не существует. В случае, если пользователь уже осуществлял вход, ему возвращается ошибка с помощью SoapException. Функция возвращает номер комнаты, в которую добавлен пользователь.

• string Disconnect() – выход пользователя из комнаты. Пользователь удаляется из комнаты и списка пользователей. Сессия прерывается.

• Command[] ExchangeCommands(Command[] inputCommands) – обмен командами. Входной массив фильтруется в соответствии со статусом пользователя, добавляется к списку команд комнаты пользователя и помечается текущим временем, преобразованным в long. Возвращается массив новых команд. В данные сессии заносится ключ последней команды в списке.

• void GrantUser(string userName, int state) – назначение статуса пользователя с именем userName. Метод успешно выполняется, если вызывающий пользователь является владельцем комнаты и целевой пользователь также находится в ней.

Класс приложения содержит обработчик события Session_End, который вызывается при окончании сессии пользователя. Если сессия была прервана по истечению тайм-аута, вызывается метод web-службы disconnectBySessionTimeOut(), который производит принудительное отключение пользователя.

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

• подключение к удаленному серверу,

• обеспечение подключения через прокси-сервер,

• получение списка доступных комнат,

• преобразование ввода пользователя в команды и отправка на сервер,

• получение команд с сервера.

Интерфейс пользователя должен позволять:

• настроить параметры подключения,

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

• просмотреть список комнат на сервере,

• присоединиться к существующей комнате или создать новую,

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

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

• просмотреть список пользователей,

• ограничивать возможности пользователя в соответствии с его правами,

• изменять права пользователей,

• воспользоваться для ввода графическим планшетом.

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

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

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

• BeginInvoke() – производит асинхронный вызов метода web-службы,

• EndInvoke() – завершает асинхронный вызов метода web-службы,

• Invoke() – производит синхронный вызов метода web-службы,

• Proxy – позволяет получить или установить информацию о настройках прокси-сервера при подключении через firewall,

• TimeOut – позволяет получить или установить тайм-аут ожидания возврата при синхронном вызове,

• Url – позволяет получить или установить URL-адрес web-службы.

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

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

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

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

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

После успешного отключения возникает событие ConnectionFinished.

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

Инструменты реализованы в виде классов, порожденных от абстрактного класса ToolBuffer. Рассмотрим его наиболее важные члены и методы.

• Bitmap buffer – растровый буфер, в который происходит отрисовка,

• List<Point> points – список точек,

• addPoint(Point pt) – добавление точки в соответствие с логикой инструмента,

• drawBuffer() – отрисовка массива точек в буфер,

• getBuffer() – получение буфера инструмента.

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

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

Формирование графической команды происходит в следующих методах:

• startCommand(ToolParameters tool, int buf) – начало ввода команды, инициализация инструмента на отснове параметров tool, второй параметр – PRIMARY или SECONDARY инструмент,

• addPoints(Point[] pts, int[] pressures, int buf) – добавление нескольких точек и динамической информации к буферу инструмента,

• DrawCommand endCommand(int buf) –формирование команды на основе инструмента и сохранение буфера инструмента в фоновый буфер.

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

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

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

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

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

Структура Axis содержит данные диапазона и разрешения оси координат графического планшета. Этой структурой описываться не только оси X и Y плоскости ввода, но и другие параметры, например, «ось» нажатия на перо.

Структура Packet описывает пакет данных и содержит информацию о нажатии кнопок на пере планшета, координатах пера и степени нажатия.

Заключение

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

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

Серверы — это компьютеры или программы, которые предоставляют какие-либо сервисы клиентам, например, веб-сервер или сервер электронной почты.

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

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

Преимущества технологии «клиент-сервер»:

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

- добавление сервера или рабочей станции повышает общую мощность системы;

- пользователь имеет большой выбор платформ;

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

Недостатки технологии «клиент-сервер»:

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

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

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

Список использованных источников

Абдуллаева Н.И. Распределённая система с многофункциональной клиентской частью / Н.И. Абдуллаева // SCIENCE TIME, Номер: 10 (34) Год: 2016 Страницы: 8-13
Академия Microsoft: Распределенные базы и хранилища данных. Лекция №4: Логическая модель РБД. Бизнес-логика файл-серверной, клиент-серверной и N-уровневой архитектуры // ИНТУИТ / Режим доступа: https://www.intuit.ru/studies/courses/1145/214/lecture/5511?page=1 (доступ на 10.06.2018)
Академия Microsoft: Распределенные базы и хранилища данных. Лекция №4: Логическая модель РБД. Бизнес-логика файл-серверной, клиент-серверной и N-уровневой архитектуры // ИНТУИТ / Режим доступа: https://www.intuit.ru/studies/courses/1145/214/lecture/5511?page=2 (доступ на 10.06.2018)
Академия Microsoft: Распределенные базы и хранилища данных. Лекция №5: Базовые объектные архитектуры распределенных систем. Технологии .NET, (D)COM+, CORBA, EJB // ИНТУИТ / Режим доступа: https://www.intuit.ru/studies/courses/1145/214/lecture/5513?page=2 (доступ на 10.06.2018)
Беляков С.Л. Технология клиент/сервер в геоинформационных системах / С.Л. Беляков // Известия ТРТУ, Номер: 1 (24) Год: 2002 Страницы: 180-181
Войтиков К.Ю. Архитектура надстраиваемых приложений клиент/сервер с обобщенным протоколом передачи данных / К.Ю. Войтиков, О.А. Змеев, А.Н. Моисеев, А.А. Якушев // Вестник томского государственного университета, Номер: 284 Год: 2004 Страницы: 166-170
Дальви Динар XML.NET. Руководство / Дальви Динар, Джоши Бипин, Грэй Джо. - М.: Лори, 2015г. - 642с.
Исаев Е.А. Использование трехзвенной архитектуры "клиент-сервер" в современных системах обработки информации / Е.А. Исаев, П.А. Тарасов, В.В. Корнилов, Г.В. Детков // Известия института инженерной физики, Том: 3 Номер: 37 Год: 2015 Страницы: 38-43
Кацко С.Ю. Классификация и принципы работы геоинформационных web-серверов в интернет-системе "клиент-сервер" / С.Ю. Кацко // ГЕО-СИБИРЬ, Том: 1 Номер: 1 Год: 2006 Страницы: 211-215
Лисьев Г.А. Программное обеспечение компьютерных сетей и web-серверов. Учебное пособие / Г.А. Лисьев, П.Ю. Романов, Ю.И. Аскерко. М.: Инфра-М, 2018г. – 145с
Маркин Е.И. Разработка web-приложения с использованием архитектуры "клиент-сервер" / Е.И. Маркин, К.М. Рябова, Е.А. Артюшина // Международный студенческий научный вестник, Номер: 3-1 Год: 2016 Страницы: 84-86
Медведев Ю.С. Проектирование интерактивных web-приложений / Ю.С. Медведев, В.В. Терехов // Современные проблемы науки и образования, Номер: 1-1 Год: 2015 Страницы: 43
Мурчиков А.М. Выбор и обоснование средств разработки web-серверных приложений / А.М.Мурчиков, В.В.Воробьев // Теория и практика современной науки, Номер: 3 (21) Год: 2017 Страницы: 558-564
Нестеров Г.Д. Трехзвенная клиент-серверная информационная система по конфигурированию баз данных // Политематический сетевой электронный научный журнал кубанского государственного аграрного университета, Номер: 110 Год: 2015 Страницы: 308-317
Николаев В.Н. Метод и устройство управления информационно-вычислительными ресурсами вида "клиент-сервер" / В.Н. Николаев // Известия юго-западного государственного университета. серия: управление, вычислительная техника, информатика. медицинское приборостроение, Номер: 1 Год: 2013 Страницы: 208-211
Осипов Д.Л. InterBase и Delphi. Клиент-серверные базы данных / Д.Л. Осипов. М: ДМК Пресс, 2015г. - 536с
Пахомов А. Webview на службе быстрой разработки. интегрируем функционал веб-сайта в мобильное приложение / А.ПахомоВ // Системный администратор, Номер: 3 (172) Год: 2017 Страницы: 45-49
Поташов Н.О. Сравнительный анализ популярных веб-серверов / Н.О. Поташов // Аллея науки, Том: 4Номер: 9 Год: 2017 Страницы: 875-879
Проектирование информационных систем. Лекция 1: Основные понятия технологии проектирования информационных систем (ИС) // ИНТУИТ / Режим доступа: https://www.intuit.ru/studies/professional_skill_ improvements/1901/courses/55/lecture/1618?page=3 (доступ на 10.06.2018)
Сычев А.В. Web-технологии / А.В. Сычев / Режим доступа: http://window.edu.ru/resource/423/61423 (доступ на 11.06.2018)
Тарханова О.В. Системы "клиент-сервер" для автоматизации процессов взаимодествия в локальной сети / О.В. Тарханова // Научный альманах, Номер: 2-2 (28) Год: 2017 Страницы: 205-208
Трофимов В.В. Синхронизация списков данных в клиент-серверных системах / В.В. Трофимов, Д.В. Завьялов // Известия волгоградского государственного технического университета, Номер: 6 (163) Год: 2015 Страницы: 87-90
Хорсдал Кристиан Микросервисы на платформе. NET / Хорсдал Кристиан. - СпБ.: Питер, 2018г. - 352с.
Шапошников И. Web-сервисы Microsoft. NET / И.Шапошников. - СпБ.: БХВ-Петербург, 2002г. - 336с.
Эспозито Д. Программирование с использованием Microsoft ASP.NET 3.5 / Д. Эспозито. - СпБ.: Питер, 2009г. - 544с.

Приложения

Приложение 1

Рисунок 1. Пример фрагмента описания web-службы на WSDL

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

Тарханова О.В. Системы "клиент-сервер" для автоматизации процессов взаимодействия в локальной сети / О.В. Тарханова // Научный альманах, Номер: 2-2 (28) Год: 2017 с.206 ↑
Там же. ↑
Нестеров Г.Д. Трехзвенная клиент-серверная информационная система по конфигурированию баз данных // Политематический сетевой электронный научный журнал кубанского государственного аграрного университета, Номер: 110 Год: 2015 с.309 ↑
Академия Microsoft: Распределенные базы и хранилища данных. Лекция №4: Логическая модель РБД. Бизнес-логика файл-серверной, клиент-серверной и N-уровневой архитектуры // ИНТУИТ / Режим доступа: https://www.intuit.ru/studies/courses/1145/214/lecture/5511?page=2 (доступ на 18.04.2018) ↑
Осипов Д.Л. InterBase и Delphi. Клиент-серверные базы данных / Д.Л. Осипов. М: ДМК Пресс, 2015г. ↑
Исаев Е.А. Использование трехзвенной архитектуры "клиент-сервер" в современных системах обработки информации / Е.А. Исаев, П.А. Тарасов, В.В. Корнилов, Г.В. Детков // Известия института инженерной физики, Том: 3 Номер: 37 Год: 2015 с: 38-43 ↑
Осипов Д.Л. InterBase и Delphi. Клиент-серверные базы данных / Д.Л. Осипов. М: ДМК Пресс, 2015г. ↑
Войтиков К.Ю. Архитектура надстраиваемых приложений клиент/сервер с обобщенным протоколом передачи данных / К.Ю. Войтиков, О.А. Змеев, А.Н. Моисеев, А.А. Якушев // Вестник томского государственного университета, Номер: 284 Год: 2004 ↑
Медведев Ю.С. Проектирование интерактивных web-приложений / Ю.С. Медведев, В.В. Терехов // Современные проблемы науки и образования, Номер: 1-1 Год: 2015 ↑
Эспозито Д. Программирование с использованием Microsoft ASP.NET 3.5 / Д. Эспозито. - СпБ.: Питер, 2009г. - 544с. ↑
Дальви Динар XML.NET. Руководство / Дальви Динар, Джоши Бипин, Грэй Джо. - М.: Лори, 2015г ↑
Шапошников И. Web-сервисы Microsoft. NET / И.Шапошников. - СпБ.: БХВ-Петербург, 2002г ↑
Хорсдал Кристиан Микросервисы на платформе. NET / Хорсдал Кристиан. - СпБ.: Питер, 2018г ↑
Маркин Е.И. Разработка web-приложения с использованием архитектуры "клиент-сервер" / Е.И. Маркин, К.М. Рябова, Е.А. Артюшина // Международный студенческий научный вестник, Номер: 3-1 Год: 2016 ↑
Там же. ↑
Дальви Динар XML.NET. Руководство / Дальви Динар, Джоши Бипин, Грэй Джо. - М.: Лори, 2015г ↑
Академия Microsoft: Распределенные базы и хранилища данных. Лекция №5: Базовые объектные архитектуры распределенных систем. Технологии .NET, (D)COM+, CORBA, EJB // ИНТУИТ / Режим доступа: https://www.intuit.ru/studies/courses/1145/214/lecture/5513?page=2 (доступ на 10.06.2018) ↑
Шапошников И. Web-сервисы Microsoft. NET / И.Шапошников. - СпБ.: БХВ-Петербург, 2002г ↑