Клиент-серверное взаимодействие интеллектуальных мобильных устройств

Клиент-серверное

взаимодействие

интеллектуальных

мобильных

устройств

Е.В. Назарова,

студентка 4-го курса, специальность «Информационные системы и технологии»

П.С. Драничников,

студент 4-го курса, специальность «Информационные системы и технологии»

Общая информации о клиент-серверной системе

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

Интеллектуальное мобильное устройство предоставляет собой устройство, на котором выполняется клиентское приложение, осуществляющее взаимодействие с пользователем, выполняющее запросы к удаленному серверу, а также имеющее возможность сохранять информацию в локальной реляционной базе данных (РЛБД).

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

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

67

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

Выполнение запроса от ИМУ к удаленному серверу

Взаимодействие между клиентской и серверной частей системы осуществляется в 7 этапов:

1. Формирование запроса к серверу.

Таблица 1

Спецификация типов запроса

Добавление нового объекта add_object

Добавление нового описания к объекту add_description

Запрос объекта с сервера get_object

2. Отправка запросов к серверу.

68

3. Получение запроса сервером и его анализ.

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

4. Выполнение серверного сценария, инициированного запросом.

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

5. Возврат результатов выполнения сценария сервера интеллектуальному мобильному устройству.

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

Полученные данные передаются интеллектуальному мобильному устройству с помощью XML-документа, имеющего определенную структуру. Пример такого документа представлен на листинге 1.

<?xml version=»1.0» encoding=»utf-8»?>

<Object>

<lat>56.654</lat>

<lon>12.345</lon>

<М1е>Университет Печати<ДШе>

<descriptions>

<description аиФог=»Павел»>Московский Государственный Университет Печати имени И. Федорова</descпptюn>

69

<description аи^ог=»Екатерина»>Улица Прянишникова, д.2а</ description>

</descriptions>

</Object>

Листинг 1. Структура возвращаемого XML-документа

6. Анализ и разбор ответа сервера.

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

7. Синхронизация с локальной базой данных.

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

Выполнение запросов к ИМУ с применением удаленного сервера

Основная задача, стоящая перед разработчиком системы, заключается в опросе произвольным устройством, входящим в состав системы, равноценных ему других ИМУ, при этом не применяя связь p2p, а организуя данный процесс через удаленный сервер. При этом сложность состоит в том, что связь ИМУ с сервером непостоянна, поэтому на последнем должен реализовываться механизм отложенного выполнения (кеширования) запросов. Отсюда очевидно, что начало и завершение запроса значительно разнесены по времени, поэтому в данной системе представляется возможным только использование асинхронных запросов. При такой архитектуре может возникнуть состояние «таймаута».

Кеширование осуществляется путем добавления новой записи в специальную таблицу БД на сервере. В этой таблице содержатся сведения об индивидуальном номере запроса, отправившего его ИМУ, текст запроса, тип и текущий статус выполнения. Табл. 2 содержит возможные в системе коды статусов выполнения запроса. Изначально каждый добавленный в очередь запрос имеет статус «waiting».

70

Таблица 2

Статусы обработки запроса

Статус Значение

waiting Ожидание доступных ИМУ для адресации запроса

sent Запрос был передан одному или нескольким ИМУ

received Получен результат запроса

timeout Не удалось получить результат запроса

finished Результат запроса передан ИМУ-отправителю

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

Опционально, сервер, будучи посредником между разными ИМУ, может накапливать данные, проходящие через него, выступая в роли своего рода центра синхронизации. При таком подходе, а также накоплении им некоторого объема данных, удаленный сервер сможет самостоятельно отвечать на запросы ИМУ, не переадресуя их другим устройствам. Этот механизм позволит существенно сократить необходимое на получение ответа время.

71