курсач / 1302_3_Курсовая

11

1.4. Сравнительная характеристика подходов

С точки зрения архитектуры, SOAP и REST решают разные задачи.

•SOAP ориентирован на действия (RPC – Remote Procedure Call). Он скрывает данные за вызовом метода. Это делает его идеальным для сложных операций и бизнес-логики.

•REST ориентирован на данные (Data-Oriented). Он выставляет данные наружу и предоставляет стандартный интерфейс для работы с ними.

Таким образом, выбор между SOAP и REST зависит от требований к системе: если необходима высокая производительность и работа с мобильными клиентами – выбирают REST; если важны строгие контракты и надежность в распределенных транзакциях – выбирают SOAP.

12

2. ПРОЕКТИРОВАНИЕ И ПРОГРАММНАЯ РЕАЛИЗАЦИЯ СИСТЕМЫ

Для проведения сравнительного анализа разработан программный комплекс «SOAP vs REST Comparison System». Приложение реализует паттерн «Backend for Frontend» (BFF) в упрощенном виде, предоставляя единую точку доступа к данным через различные протоколы.

2.1. Обоснование выбора стека технологий

В качестве технологической базы выбрана платформа Node.js. Этот выбор обусловлен следующими факторами:

1.Единый язык: Использование TypeScript как на сервере, так и на клиенте позволяет использовать общие интерфейсы (DTO) и избежать дублирования описания типов данных.

2.Асинхронность: Неблокирующая модель ввода-вывода Node.js идеально подходит для обработки множества одновременных HTTP и SOAP запросов [8].

3. Экосистема: Наличие развитых библиотек (express, soap, sqlite3) значительно ускоряет разработку прототипа.

Конфигурация среды разработки:

Для обеспечения качества кода и строгой типизации была произведена детальная

настройки paths: { "@/*": ["src/*"] } позволило избежать громоздких относительных импортов (например, ../../modules/student) и сделать архитектуру модулей более

(отступы, кавычки, точки с запятой) как в серверном, так и в клиентском репозитории, что упрощает поддержку проекта.

Для клиентской части выбран фреймворк Vue 3 (Composition API) в связке со сборщиком Vite, что обеспечивает высокую скорость рендеринга и удобство

13

реактивного связывания данных, необходимого для отображения метрик в реальном времени [9].

2.2. Архитектурная организация серверной части

Серверное приложение построено на основе многослойной архитектуры (Layered Architecture), что обеспечивает разделение ответственности (Separation of Concerns) и упрощает тестирование.

Выделены следующие слои:

1.Controller Layer (Контроллеры): Отвечает за прием входящих запросов

иотправку ответов. В проекте реализован StudentController, который обрабатывает HTTP-запросы для REST API. Он валидирует входные данные и делегирует выполнение сервису.

2. Service Layer (Сервисы): Содержит бизнес-логику приложения. Класс StudentService является ядром системы: он не зависит от способа получения данных (SOAP или REST) и оперирует чистыми объектами домена. Именно здесь происходит вызов методов репозитория.

3.Repository Layer (Репозитории): Отвечает за прямое взаимодействие с базой данных. Класс StudentRepository инкапсулирует SQL-запросы, предоставляя сервису удобные методы (findAll, create, seed).

4.Interface Layer (DTO): Общие интерфейсы (Data Transfer Objects), описывающие структуру данных Student, используются сквозным образом во всех слоях.

Такой подход позволил подключить два разных внешних интерфейса (SOAP Endpoint и REST API) к одной и той же бизнес-логике без дублирования кода.

2.3. Реализация уровня данных (Data Access Layer)

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

Реализован паттерн Repository, инкапсулирующий логику работы с базой данных. Это позволяет бизнес-логике (Service Layer) не зависеть от конкретной СУБД.

Особенности реализации массовой вставки данных (Seeding):

Для корректного сравнения производительности необходимо оперировать большими объемами данных (10 000 – 20 000 записей). Обычная циклическая вставка

14

(INSERT INTO...) в SQLite работает медленно из-за того, что каждый запрос открывает и закрывает файл базы данных.

Для оптимизации был использован механизм транзакций:

Листинг 1 – механизм транзакций db.serialize(() => {

db.run("BEGIN TRANSACTION");

const stmt = db.prepare("INSERT INTO students (...) VALUES (?, ?, ?)"); for (let i = 0; i < count; i++) {

stmt.run(...);

}

stmt.finalize();

db.run("COMMIT");

});

Данный подход позволил сократить время генерации 20 000 записей с нескольких минут до 1-2 секунд.

2.4. Реализация SOAP-сервиса

Разработка SOAP-сервиса выполнена по подходу Contract First (сначала контракт). Это означает, что разработка началась с проектирования файла WSDL, который жестко регламентирует типы данных и форматы сообщений.

Структура WSDL-контракта:

Файл student.wsdl определяет:

•Сложный тип Student, включающий поля id (int), name (string), specialization (string), course (int).

•Операцию getStudents, возвращающую массив элементов (используется атрибут maxOccurs="unbounded").

•Операцию createStudent, принимающую параметры и возвращающую созданный объект.

На стороне сервера используется библиотека soap, которая "слушает" определенный маршрут (/soap) и автоматически:

1.Парсит входящий XML-конверт.

15

2.Валидирует его на соответствие WSDL.

объекта serviceObject.

4.Сериализует результат выполнения функции обратно в XML.

2.5.Реализация REST-сервиса

REST-сервис реализован на базе фреймворка Express.js. В отличие от SOAP, здесь отсутствует строгий контракт на уровне протокола. Маршрутизация запросов:

•GET /api/students – Получение списка.

•POST /api/students – Создание записи.

•GET /api/admin/stats – Получение статистики БД.

Для обеспечения CORS (Cross-Origin Resource Sharing) настроены соответствующие заголовки, позволяющие клиентскому приложению (работающему на порту 5173) обращаться к серверу API (порт 8000).

2.6. Реализация клиентского приложения и сбор метрик

Клиентская часть представляет собой SPA (Single Page Application). Основная сложность заключалась в реализации работы с SOAP-протоколом в браузере, так как нативные инструменты (fetch, axios) не поддерживают SOAP "из коробки".

Механизм работы с SOAP на клиенте:

1.Формирование запроса: XML-конверт формируется вручную с использованием шаблонных строк (Template Literals).

Листинг 2 – использование шаблонных строк

const xml = `<soapenv:Envelope...><tns:getStudentsRequest/></soapenv:Envelope>`;

2.Отправка: Используется fetch с заголовком Content-Type: text/xml.

3.Парсинг: Полученная от сервера XML-строка преобразуется в DOMдерево с помощью DOMParser [7]. Далее происходит ручной обход дерева. Основная трудность заключалась в поиске нужных узлов, так как браузеры по-разному обрабатывают префиксы пространств имен (например, тег может называться tns:students или просто students).

Листинг 3 – итеративный алгоритм для извлечения данных const nodes = doc.getElementsByTagName('students');

16

for (let i = 0; i < nodes.length; i++) {

// Ручное извлечение текста из каждого дочернего узла

const id = nodes[i].getElementsByTagName('id')[0]?.textContent; // Приведение типов (String -> Number)

}

Методика замера производительности:

Для получения объективных данных о производительности была разработана функция-обертка measure. Она фиксирует метки времени с высокой точностью (performance.now()) на трех этапах:

1.Начало запроса.

2.Получение сырого ответа (конец сетевой фазы).

3.Окончание преобразования данных в JavaScript-объекты (конец фазы

парсинга).

Это позволило разделить общее время выполнения («Total Duration») на сетевую составляющую («Network Time») и вычислительную составляющую («Parsing Time»), что является ключевым аспектом данного исследования.

17

3. АНАЛИЗ ПРОИЗВОДИТЕЛЬНОСТИ

Для оценки эффективности разработанных веб-сервисов было проведено нагрузочное тестирование с изменяемым объемом данных и в различных сетевых условиях.

3.1. Методика тестирования

Тестирование проводилось в браузере Google Chrome с использованием инструментов разработчика (DevTools). Для минимизации погрешности каждый сценарий запускался 3 раза, после чего вычислялось среднее репрезентативное значение.

Тестовые сценарии:

1.Сценарий «Вычислительная нагрузка» (No Throttling): Замеры на локальном сервере без ограничения сети. Цель – изолировать и измерить время работы процессора (CPU) на парсинг данных.

2.Сценарий «Сетевая нагрузка» (Slow 3G): Ограничение пропускной способности до 500 кбит/с и добавление задержки (latency). Цель – оценить влияние объема трафика (Overhead) на скорость загрузки.

Градация данных:

•100 записей: Минимальный объем (базовая проверка).

•1 000 записей: Средний объем.

•5 000 записей: Высокая нагрузка.

•20 000 записей: Стресс-тест системы.

3.2. Результаты тестирования

3.2.1. Анализ размера данных (Traffic Overhead)

Вне зависимости от условий сети, объем передаваемых данных остается константой. Результаты замеров представлены в таблице 3.1.

18

Таблица 2

На рисунке 1 приведены результаты замеров для 20000 записей в базе данных на медленном интернете (3G)

Рисунок 1 – скриншот результата замеров для 20000 записей в базе данных на медленном интернете (3G)

Вывод: SOAP стабильно генерирует трафик на ~15% больше, чем REST. Эта разница обусловлена наличием открывающих и закрывающих тегов XML для каждого поля каждой записи. Хотя 15% кажутся небольшим значением, на больших объемах (2 МБ) это выливается в лишние 300 КБ данных, что критично для медленных сетей.

19

3.2.2. Анализ вычислительной сложности (Parsing Time)

Замеры времени, затраченного JavaScript-движком на преобразование ответа в объекты (без учета сети).

Таблица 3

Вывод: Это наиболее показательная метрика. График роста времени парсинга для SOAP значительно круче. На 20 000 записей браузер тратит 150 мс только на разбор XML, что уже может вызывать заметные микро-фризы интерфейса (пропуск кадров анимации). REST парсится за пренебрежимо малые 5 мс. Таким образом, REST эффективнее по CPU в среднем в 30 раз.

3.2.3. Анализ времени загрузки в плохих условиях (Slow 3G)

Имитация сети 500 кбит/с. В таблице приведены усредненные значения

20

Примечание: Для REST на 20 000 записей было зафиксировано значение ~30 секунд, что соответствует физической пропускной способности канала (2 МБ / 500 кбит/с ≈ 32 сек). Значения порядка 3 сек, встречавшиеся в тестах, были отброшены как результат локального кэширования браузера.

На рисунке 2 наглядно представлена разница в эффективности протоколов. Верхняя строка соответствует запросу к REST-сервису (students), нижняя – к SOAPсервису (soap). Из данных мониторинга видно, что при передаче одинакового набора данных транспортный объем SOAP-сообщения составляет 2.3 МБ, что значительно превышает объем JSON-ответа (1.4 МБ). В условиях нестабильного соединения (Slow 3G) эта разница в объеме, суммируясь с накладными расходами на обработку XML, приводит к увеличению времени ожидания с 30 секунд до 48 секунд.

Рисунок 2 – Сравнительный анализ сетевой активности (вкладка Network) при передаче 20 000 записей в условиях ограниченной пропускной способности (Slow 3G)