CC BY
26
УДК 004.65
ПРИМЕР РЕАЛИЗАЦИИ ИНТЕРОПЕРАБЕЛЬНОСТИ БОЛЬШИХ ДАННЫХ ДЛЯ МОБИЛЬНЫХ ПРИЛОЖЕНИЙ
М.А.Бойкова, С.Ю.Петрова IMPLEMENTATION OF INTEROPERABILITY OF BIG DATA FOR MOBILE APPLICATIONS
M.A.Boikova, S.Iu.Petrova
Институт электронных и информационных систем НовГУ, sevostyanovamaria@gmail.com
Аппаратные ресурсы мобильных устройств имеют ограничения по объему памяти, не позволяя разместить на них полноценные системы хранения информации. В этой связи возникает проблема интеграции систем хранения мобильных устройств с каким-либо хранилищем данных. Большинство СУБД поддерживают одну модель данных, что не подходит для решения поставленной задачи. В результате был использован шаблон проектирования Repository, позволяющий связывать мобильное приложение и базу данных. В нашем примере в качестве Repository использовался файл PHP. По нашему мнению, такое решение возможно, но оно не является оптимальным. Прокладка в виде файла PHP задает гибкость в плане интероперабельности больших данных, но PHP закладывает ряд ограничений, которые являются недостатком. Ключевые слова: мобильное приложение, большие данные, шаблон проектирования
The hardware resources of mobile devices have limitations on the amount of memory not allowing one to place full-fledged storage systems on them. In this connection, the problem arises of integrating storage systems of mobile devices with any data store. Most DBMSs support one data model, which is not suitable for solving this task. In our research we used a Repository design pattern which allows organizing connection between a mobile application and a database. The PHP file was used as the Repository. In our opinion, this solution is possible but not optimal. Using the PHP file as a laying makes the interoperability of big data flexible but PHP lays down a number of limitations which are a drawback. Keywords: mobile application, big data, design pattern
Введение
В современном мире мобильные технологии получили широкое распространение: практически у всех есть мобильные устройства (смартфоны, планшеты, КПК), которые активно используются в повседневной жизни, предоставляя пользователям постоянный и неограниченный доступ в интернет, а следовательно, доступ к большому объёму информации. Но аппаратные ресурсы мобильных устройств по-прежнему имеют ограничения по объему памяти, не позволяя разместить на них полноценные системы хранения информации. В этой связи возникает проблема интеграции систем хранения мобильных устройств с каким-либо хранилищем данных. На сегодня нет единого варианта организации систем хранения данных. Появились новые NoSQL СУБД, которые позволяют хранить данные в виде пар ключ/значение, графов, XML документов, JSON текста и RDF-утверждений в виде ориентированного графа. Такая диверсификация систем хранения возникла потому, что объем, разнообразие и скорость больших данных требуют большего разнообразия методов хранения данных, чем традиционные реляционные СУБД.
Модель данных — совокупность понятий, которые могут быть использованы для описания структуры базы данных. Модель данных обеспечивает необходимые средства для достижения абстракции. Большинство СУБД поддерживают одну модель данных, например, реляционная модель и, соответственно, РСУБД ориентированы на хранение данных в виде таблиц, а документ-модель и, соответственно, XML- или JSON-документы — на хранение текста. А вот для хранилищ данных типа ключ/значение и RDF понятие «модель» обычно не используется.
Постановка задачи
При проектировании приложения для мобильного устройства, ориентированного на обработку больших данных, перед разработчиком вста-
ет проблема создания гетерогенной системы хранения, использующей разные модели данных. Обычно программист использует соответствующий шаблон проектирования в соответствии с выбранной архитектурой приложения [1]. Для реализации мобильного приложения чаще всего используется шаблон проектирования Repository [2] (см. рис.1). Данный шаблон предполагает разделения логики на три уровня: бизнес-логика, репозиторий и источник данных. На уровне бизнес-логики должно быть реализовано мобильное приложение, на уровне источника данных должна быть реализована система хранения данных, необходимых для работы приложения. Репозиторий (объект запроса) связывает мобильное приложение и БД, а также осуществляет выборку информации из БД в соответствии с бизнес-логикой мобильного приложения, которая накладывает ограничения на входные данные. Допустим, нам необходимо иметь два разнородных подключения: одно — к РСУБД (например, MS SQL) и другое — к NoSQL (например, MongoDB). РСУБД будет хранить основной массив данных и располагаться в стационарном хранилище, а NoSQL — располагаться непосредственно на мобильном устройстве и иметь минимальный объем данных, необходимых для инициализации приложения. Шаблон Repository позволяет реализовать в программе гибкость, необходимую при работе с разными типами подключений.
Мобильное приложение направляет список необходимых данных к репозиторию, который осуществляет запрос к источнику данных. Далее репозито-рий отображает результат запроса к БД в виде массива, который можно изменять с помощью интерфейса мобильного приложения.
Развертывание приложения происходит согласно компонентной диаграмме, представленной на рис.2.
Рис.1. Описание архитектуры реализации мобильного приложения
Рис.2. Диаграмма развертывания мобильного приложения
Вся необходимая информация хранится в БД, работа с которой осуществляется с помощью стандартизированного языка запросов SQL. Для работы с информацией на сервере имеется программная обертка PHP, которая используется для приема JSON запросов пользователей с последующей передачей обертке БД и передача результатов обработки запросов пользователям. Для передачи запросов от сервера к СУБД и получения результатов запросов используется скрипт PHP.
На рис.3 представлена диаграмма деятельности, отображающая три уровня взаимодействия: мобильное приложение (МП), сервер и БД. Мобильное приложе-
ние инициирует запрос на регистрацию и передает его на сервер. Если сервер доступен, то выполняется запрос к БД с целью проверки, свободен ли номер мобильного телефона. БД осуществляет выборку данных и предоставляет их серверу. В свою очередь, сервер получает данные от БД и генерирует ответ. Если данный номер телефона занят, то происходит возврат к МП. Если данный номер телефона свободен, то от сервера происходит запрос к БД на создание записи, БД создает запись и возвращает ответ — user_id, сервер генерирует ответ и передает данные в мобильное приложение.
МП "Автодоктор 53"
[повторить]
[прервать]
Сервер
[не доступен]
БД
Рис.3. Диаграмма деятельности 8
Практическая реализация алгоритмов
В мобильном приложении получение данных из БД будет происходить с помощью JSON запроса к серверу методом POST. Рассмотрим пример реализации этого подхода в мобильном приложении «Автодоктор 53». При регистрации клиента в мобильном приложении пользователь заполняет поля с контактной информацией и информацией об автомобиле, так как предполагается, что у клиента на момент регистрации есть минимум один автомобиль; другие автомобили клиент после регистрации сможет добавить в своём профиле. В случае если пользователь заполнил не все обязательные поля или заполнил их некорректно, выводится сообщение об ошибке, в противном случае происходит запрос к серверу с помощью следующего кода: Response.Listener<String>responseListener = new Response.Listener<String>() { @Override
public void onResponse(String response) { try {
JSONObjectjsonResponse = new JSONObject(response); booleansuccess = jsonResponse.getBoolean("success"); if (success) {
Intent intent = new Intent(RegisterActivity.this, LoginActivity. class); RegisterActivity.this.startActivity(intent); } else {
AlertDialog.Builder builder = new AlertDia-log.Builder(RegisterActivity.this); builder.setMessage("Данный номер телефона уже ис-пользуетсяЛиПожалуйста, попробуйте еще раз.") .setNegativeButton("OK", null) .create() .show();
}
} catch (JSONException e) {
e.printStackTrace(); }
}
};
RegisterRequestregisterRequest = new Register-
Request(phone, password, surname, name, patronymic,
eMail, brand, model, vin, year, engine, engineType,
DateandTime, responseListener);
RequestQueue queue = Volley.newRequestQueue
(RegisterActivity.this);
queue.add(registerRequest);
Описание класса запроса к БД RegisterRequest показано ниже:
public class RegisterRequestextends StringRequest { private static final String REGISTER_REQUEST_URL = "http://Autodoctor.co.nf/Register.php"; private Map<String, String>params; public RegisterRequest(String phone, String password, String surname, String name, String patronymic, String eMail, String brand, String model, String vin, int year, double engine, String engineType, String DateandTime, Response.Listener<String> listener) { super(Method.POST, REGISTER_REQUEST_URL, listener, null);
params= new HashMap<>();
params.put("phone", phone); params.put("password", password); params.put("surname", surname); params.put("name", name); params.put("patronymic", patronymic); params.put("eMail", eMail); params.put("brand", brand); params.put("model", model); params.put("vin", vin); params.put("year", year + ""); params.put("engine", engine + ""); params.put("engineType", engineType);
params.put("DateandTime", DateandTime); }
@Override
public Map<String, String>getParams() {
return params; }
}
Для передачи запросов от сервера к СУБД и получения результатов запросов используется скрипт PHP. Листинг файла Register.php показан ниже: <?php
require("password.php");
$connect = mysqli_connect("fdb14.biz.nf", "2255124_dev", "gjlfhjr123", "2255124_dev"); mysqli_set_charset($connect, "utf8"); $phone = $_POST["phone"]; $password = $_POST["password"]; $surname = $_POST["surname"]; $name = $_POST["name"]; $patronymic = $_POST["patronymic"]; $eMail = $_POST["eMail"]; $brand = $_POST["brand"]; $model = $_POST["model"]; $vin = $_POST["vin"]; $year = $_POST["year"]; $engine = $_POST["engine"]; $engineType = $_POST["engineType"]; $DateandTime = $_POST["DateandTime"]; $ChangeDateandTime= ""; $sum = 0; $discount = 0; function registerUser() { global $connect, $phone, $password, $surname, $name, $patronymic, $eMail, $brand, $model, $vin, $year, $engine, $engineType,
$DateandTime, $ChangeDateandTime, $sum, $discount, $user_id;
$passwordHash = password_hash($password, PAS SWORD_DEFAULT); //Добавление машины
$statement2 = mysqli_prepare($connect, "INSERT INTO car (phone, brand, model, vin, year,
engine, engineType, DateandTime, ChangeDateandTime) VALUES (?, ?, ?, ?, ?, ?, ?, ?, ?, ?)");
mysqli_stmt_bind_param($statement2, "ssssidsss", $phone, $brand, $model,
$vin, $year, $engine, $engineType, $DateandTime, $ChangeDateandTime); mysqli_stmt_execute($statement2); mysqli_stmt_close($statement2);
$result = mysqli_query($connect, "SELECT car _id FROM car WHERE phone = '$phone'") or die(mysqli_error($link));
$row = mysqli_fetch_array($result); $car_id = $row[car _id'] ; $statement = mysqli_prepare($connect, "INSERT INTO user (phone, password, surname, name, patronymic, eMail, car_id, DateandTime, ChangeDateandTime, sum, discount)
VALUES (?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?)"); mysqli_stmt_bind_param($statement, "ssssssissii", $phone, $passwordHash, $surname, $name, $patronymic, $eMail, $ car_id, $DateandTime, $ChangeDateandTime, $sum, $discount);
mysqli_stmt_execute($statement); mysqli_stmt_close($statement);
}
function phoneAvailable() { global $connect, $phone;
$statement = mysqli_prepare($connect, "SELECT * FROM user WHERE phone = ?");
mysqli_stmt_bind_param($statement, "s", $phone);
mysqli_stmt_execute($statement);
mysqli_stmt_store_result($statement);
$count = mysqli_stmt_num_rows($statement);
mysqli_stmt_close($statement);
if ($count < 1){
return true; } else { return false;
}
}
$response = array(); $response["success"] = false; if (phoneAvailable()){ registerUser(); $response["success"] = true;
}
print_r(j son_encode($response));
?>
На сервере происходит проверка на существование пользователя с заданным номером телефона. В случае успешного выполнения запроса пользователь переходит к экрану авторизации. Если пользователь с таким номером телефона уже существует, то клиенту выводится сообщение об ошибке и предлагается использовать другой номер телефона.
Выводы
Проектирование взаимодействия мобильного приложения с двумя моделями данных представляет сложную задачу. Одним из решений может служить использование архитектурного шаблона Repository, который является посредником между уровнем области определения и источником данных, тем самым связывая МП и БД. В нашем примере в качестве Repository использовался файл PHP. Такое решение возможно, но оно не является оптимальным. Прокладка в виде файла PHP хотя и задает гибкость в плане интероперабельности больших данных, но PHP закладывает ряд ограничений, которые являются недостатком. В идеале выбор поставщика СУБД не должен ограничивать разработчика приложения одной или двумя моделями хранения данных, так как на сегодня нет единой модели хранения данных, которая хорошо бы подходила для каждого варианта реализации [3]. Именно поэтому необходимо проводить исследования и разработки интероперабельных систем хранения больших данных.
1. Smith J. Patterns - WPF Apps With The Model-ViewViewModel Design Pattern. MSDN Magazine, February 2009. Available at: https://msdn.microsoft.com/en-us/magazine/dd419663.aspx.
2. The Repository Pattern. Home page on MSDN. Community site 2017. Available at: https://msdn.microsoft.com/en-us/library/ff649690.aspx.
3. Hills T. NoSQL and SQL Data Modeling. Basking Ridge, Technics Publications, 2016. 258 p.
