Добавлен: 26.06.2023
Просмотров: 154
Скачиваний: 2
Иногда серверная часть может включаться в клиентское приложение. В этом случае происходит взаимодействие типа «клиент-клиент». Тогда один из клиентов по предварительной договоренности несет на себе функции сервера, в результате являясь и клиентом, и сервером. Такая реализация в случае большого количества пользователей приводит к излишней нагрузке на одного из участников. Это, несомненно, является узким местом такого подхода. Еще одним из его недостатков является «утяжеление» клиентской части. В дополнение к сказанному заметим, что совмещение функций клиента и сервера в одном приложении может быть оправдано при реализации подключения «точка-точка», когда обе стороны в разное время могут меняться ролями[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 узел, содержащий параметры объекта и подвергается десериализации. В результате на принимающей стороне мы имеем копию объекта в точно таком же состоянии, что и на передающей.