Санкт-Петербургский государственный электротехнический университет им. В.И. Ульянова (Ленина)
WEB-СЕРВИСЫ: SOAP-СЕРВИСЫ И REST-СЕРВИСЫ
Студенты: |
Наволоцкий |
И.Р. |
Харитонов А.А. |
Группа: |
1302 |
АКТУАЛЬНОСТЬ И ЦЕЛЬ
•Актуальность: Выбор между SOAP (стандарт Enterprise/Banking) и REST (стандарт Web/Mobile) влияет на стоимость разработки и производительность системы.
•Цель: Разработать программный комплекс, реализующий оба подхода, и провести нагрузочное тестирование для выявления их сильных и слабых сторон.
•Задачи:
•Реализовать единый бэкенд (Node.js).
•Реализовать клиентское приложение (Vue 3).
•Сравнить метрики (трафик, CPU, время отклика). 2
СРАВНИТЕЛЬНАЯ ХАРАКТЕРИСТИКА ТЕХНОЛОГИЙ
Характеристика |
SOAP (Simple Object |
REST (Representational |
|
Access Protocol) |
State Transfer) |
||
|
|||
Тип |
Протокол (строгий |
Архитектурный |
|
стандарт) |
стиль (набор принципов) |
||
|
|||
Формат данных |
Только XML |
JSON, XML, HTML, Text и др. |
|
Структура |
Строгий конверт (Envelope, |
Ресурсы (URI) + HTTP |
|
Header, Body) |
методы (GET, POST...) |
||
|
|||
Контракт |
Обязательный WSDL (строг |
Опциональный |
|
ая типизация) |
(Swagger/OpenAPI) |
||
|
|||
Ключевые фичи |
WS-Security, WS- |
Кэширование, Stateless, |
|
AtomicTransaction |
Легковесность |
||
|
|||
Область |
Enterprise, Финтех, B2B |
Web, Mobile, IoT, Public API |
|
интеграции |
|||
|
|
3
АРХИТЕКТУРА РАЗРАБОТАННОЙ СИСТЕМЫ
• Единая кодовая база: TypeScript (Frontend + Backend).
• Изоляция данных: Общая БД для чистоты эксперимента.
• Принцип
BFF: Адаптация данных под клиента.
4
РЕАЛИЗАЦИЯ СЕРВЕРНОЙ ЧАСТИ (BACKEND) |
|
• Технологии: TypeS |
|
cript, Express.js, |
|
library soap, sqlite3. |
|
• Архитектурный |
|
паттерн: Layered |
|
Architecture |
|
(Controller -> |
|
Service -> |
|
Repository). |
|
• Особенность |
|
данных: Транзакц |
|
ионная генерация |
|
(Seeding) 20 000+ |
5 |
записей. |
|
РЕАЛИЗАЦИЯ КЛИЕНТСКОЙ ЧАСТИ (FRONTEND)
• Проблема: Отсутствие нативной поддержки SOAP в API браузера (fetch работает с текстом/JSON).
• Решение:
• Формирование: Ручная сборка XML-конверта (Template Strings).
• Транспорт: POST запрос с Content-Type: text/xml.
• Обработка: Парсинг ответа через DOMParser (обход дерева тегов).
• Метрики: Реализация обертки measure() для точного замера performance.now().
6
МЕТОДИКА ТЕСТИРОВАНИЯ
•Сценарий А (Localhost):
•Цель: Изоляция вычислительной нагрузки (CPU).
•Условия: No Throttling, Latency ≈ 0 ms.
•Сценарий Б (Slow 3G):
•Цель: Оценка влияния объема данных (Traffic Overhead).
•Условия: 500 kb/s, Latency = 2000 ms (стандартный пресет Chrome).
•Малый объем: 100 записей.
•Средний объем: 1 000 - 5 000 записей.
•Стресс-тест: 20 000 записей (~2 МБ текста).
•Payload Size: Объем трафика (байт).
•Parsing Time: Время работы JS-движка (мс).
•Total Duration: Полное время отклика (с).
7
АНАЛИЗ ВЫЧИСЛИТЕЛЬНОЙ СЛОЖНОСТИ (PARSING TIME)
• JSON (REST) обрабатываетс я в 30 раз быстрее.
• Разбор XML на 20 000 записях занимает ~150 мс (блокировк а интерфейса).
8
АНАЛИЗ ОБЪЕМА ПЕРЕДАВАЕМЫХ ДАННЫХ (PAYLOAD SIZE)
•REST: ~1.9 МБ (эффективная нагрузка).
•SOAP: ~2.2 МБ (эффективная + теги).
•Overhead (Избыточность): ~15%.
•JSON: {"id":1,"name":"Ivan"}
•XML: <tns:student><id>1</id><name>Ivan</name></tns:student>
9
ВРЕМЯ ОТКЛИКА В УСЛОВИЯХ НЕСТАБИЛЬНОЙ СЕТИ (SLOW 3G)
Ключевые
факторы
задержки:
• Лишний трафик (+300 КБ).
• Тяжелый парсинг (+150 мс).
• Накладные расходы TCP/IP.
10