Добавлен: 26.06.2023
Просмотров: 148
Скачиваний: 2
Данные 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 – наблюдатель, может только наблюдать за рисованием других участников и общаться в чате,