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

МИНОБРНАУКИ РОССИИ САНКТ-ПЕТЕРБУРГСКИЙ ГОСУДАРСТВЕННЫЙ ЭЛЕКТРОТЕХНИЧЕСКИЙ УНИВЕРСИТЕТ «ЛЭТИ» ИМ. В.И. УЛЬЯНОВА (ЛЕНИНА) Кафедра САПР

КУРСОВАЯ РАБОТА по дисциплине «Архитектура параллельных вычислительных систем»

Тема: Web-сервисы: SOAP-сервисы и REST-сервисы

Санкт-Петербург 2025

2

ЗАДАНИЕ НА КУРСОВУЮ РАБОТУ

Студенты: Наволоцкий И.Р., Харитонов А.А.

Группа: 1302 Тема работы:

Содержание пояснительной записки: Оглавление, Введение, Основная часть, Заключение, Приложения, Список используемых источников.

Предполагаемый объем пояснительной записки: Не менее 20 страниц.

Дата выдачи задания: 12.09.2025

Дата сдачи задания: 26.12.2025

Дата защиты задания: 26.12.2025

3

АННОТАЦИЯ

Курсовая работа посвящена исследованию двух доминирующих подходов к построению распределенных веб-сервисов: протокола SOAP (Simple Object Access Protocol) и архитектурного стиля REST (Representational State Transfer).

В ходе работы был разработан программный комплекс, включающий серверную часть на платформе Node.js, реализующую оба типа сервисов с единой базой данных, и клиентское приложение на Vue 3 для взаимодействия с ними.

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

SUMMARY

The course work is devoted to the study of two dominant approaches to building distributed web services: the SOAP protocol (Simple Object Access Protocol) and the REST architectural style (Representational State Transfer).

During the work, a software complex was developed, including a server part on the Node.js platform implementing both types of services with a single database, and a client application on Vue 3 for interacting with them.

A comparative performance analysis was conducted based on key metrics: traffic volume, client-side processing time (parsing), and total response time under various network conditions.

5

ВВЕДЕНИЕ

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

На сегодняшний день существуют два основных стандарта реализации вебсервисов: SOAP (Simple Object Access Protocol) и REST (Representational State Transfer). Выбор между ними является важным архитектурным решением, влияющим на производительность, масштабируемость и сложность разработки системы.

Несмотря на широкую популярность REST в веб-разработке благодаря его простоте и использованию JSON, протокол SOAP остается стандартом де-факто в корпоративном секторе (Enterprise), банковской сфере и государственных системах, где требуются строгие контракты взаимодействия и гарантии безопасности.

Целью данной курсовой работы является практическая реализация обоих типов сервисов и проведение сравнительного анализа их эффективности. Для достижения поставленной цели решены следующие задачи:

1.Изучены теоретические основы протокола SOAP и архитектурного стиля

REST.

2.Разработан сервер на платформе Node.js, предоставляющий доступ к базе данных SQLite через интерфейсы SOAP и REST.

3.Разработано клиентское веб-приложение для визуализации данных и сбора

метрик.

4.Проведено нагрузочное тестирование и проанализированы показатели производительности: время парсинга, объем трафика и задержки передачи данных.

6

1. ТЕОРЕТИЧЕСКИЕ ОСНОВЫ И АРХИТЕКТУРНЫЕ ПРИНЦИПЫ WEBСЕРВИСОВ

Веб-сервис (Web Service) – это программная система, идентифицируемая строкой URI, чьи общедоступные интерфейсы определены на языке XML (или описаны иным способом), использующая эти интерфейсы для взаимодействия с другими программными системами посредством сообщений на базе XML (или JSON) через протоколы интернета.

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

1.1. Протокол SOAP и стандарты WS-*

SOAP (Simple Object Access Protocol) – это стандартизированный протокол обмена структурированными сообщениями в распределенной вычислительной среде. Первоначально разработанный Microsoft в 1998 году, сейчас он поддерживается консорциумом W3C [2].

Структура сообщения SOAP

В отличие от произвольных HTTP-запросов, SOAP строго регламентирует структуру каждого передаваемого пакета. Сообщение представляет собой XMLдокумент, состоящий из следующих элементов:

1.Envelope (Конверт): Корневой элемент, который определяет XMLдокумент как сообщение SOAP.

2.Header (Заголовок): Необязательный элемент, содержащий метаданные запроса, такие как токены аутентификации, информация о транзакциях или маршрутизации. Это позволяет отделять инфраструктурные данные от бизнес-данных.

3.Body (Тело): Обязательный элемент, содержащий полезную нагрузку (payload) – данные запроса или ответа.

4.Fault (Ошибка): Специальный элемент внутри Body, используемый для передачи информации об ошибках, возникших при обработке сообщения.

7

Язык описания WSDL

Неотъемлемой частью SOAP является WSDL (Web Services Description Language). Это XML-формат для описания сетевых сервисов как набора конечных точек (endpoints). WSDL выполняет роль строгого контракта между клиентом и сервером [3].

Структура WSDL включает:

•Types: Определение типов данных (обычно через XSD – XML Schema

Definition).

•Message: Абстрактное определение передаваемых данных.

•PortType: Абстрактный набор операций (интерфейс сервиса).

•Binding: Привязка операций к конкретному протоколу (SOAP) и формату

данных.

•Service: Физический адрес сервиса (URL).

Семейство стандартов WS-*

Одним из главных преимуществ SOAP в корпоративной среде является поддержка расширений WS-* (WS-Security, WS-ReliableMessaging, WSAtomicTransaction) [10]. Эти стандарты позволяют реализовать на уровне протокола такие функции, как:

•Гарантированная доставка сообщений (даже при сбоях сети).

•Сквозное шифрование и цифровая подпись сообщений.

•Распределенные ACID-транзакции.

Рассмотрим ключевые спецификации WS-* подробнее, так как именно они являются решающим фактором выбора SOAP в банковской и государственной сферах:

• WS-Security (WSS): Обеспечивает безопасность на уровне сообщения, а не транспортного канала. В отличие от HTTPS, который шифрует весь канал «трубу», WS-Security позволяет зашифровать только часть XML-документа или подписать его цифровой подписью. Это позволяет сообщению безопасно проходить через множество промежуточных узлов, сохраняя целостность и конфиденциальность payload-а.

• WS-ReliableMessaging: Протокол гарантированной доставки. Он определяет механизм подтверждений (ACK) и повторных отправок, гарантируя, что сообщение будет доставлено получателю ровно один раз, в правильном порядке, даже при нестабильном сетевом соединении (например, при обрыве связи).

• WS-AtomicTransaction: Позволяет координировать транзакции между несколькими разнородными сервисами. Поддерживает протокол двухфазной фиксации

8

(Two-Phase Commit), гарантируя, что изменения будут применены либо во всех системах, участвующих в транзакции, либо ни в одной, обеспечивая соблюдение принципов ACID в распределенной среде.

1.2. Архитектурный стиль REST

REST (Representational State Transfer) – это архитектурный стиль, описанный Роем Филдингом в 2000 году [1]. В отличие от SOAP, REST не является протоколом и не имеет официального стандарта W3C. Это набор ограничений и рекомендаций для построения масштабируемых систем.

Шесть ограничений REST:

Для того чтобы система считалась RESTful, она должна удовлетворять следующим принципам:

1.Клиент-Сервер (Client-Server): Разделение ответственности. Сервер занимается хранением данных, клиент – интерфейсом.

2.Отсутствие состояния (Stateless): Сервер не хранит информацию о состоянии сессии клиента между запросами. Каждый запрос должен содержать всю необходимую информацию для его обработки.

3.Кэшируемость (Cacheable): Ответы сервера должны быть явно помечены как кэшируемые или некэшируемые.

4.Единообразие интерфейса (Uniform Interface): Унифицированный способ обращения к ресурсам (обычно через URI) и использование стандартных методов HTTP.

5.Слоистая система (Layered System): Клиент не знает, общается ли он напрямую с сервером или через промежуточные узлы (балансировщики, прокси).

6.Код по требованию (Code on Demand): (Опционально) Сервер может передавать исполняемый код (например, скрипты JS) клиенту.

Ресурсы и методы HTTP

В REST ключевой абстракцией является «Ресурс». Каждая сущность (например, «Студент») имеет свой уникальный идентификатор (URI). Манипуляции с ресурсами производятся с помощью стандартных HTTP-методов, которые семантически соответствуют CRUD-операциям [4]:

• GET: Получение представления ресурса (безопасный и идемпотентный метод).

9

•POST: Создание нового ресурса.

•PUT / PATCH: Полное или частичное обновление ресурса.

•DELETE: Удаление ресурса.

При проектировании RESTful систем критически важными являются понятия идемпотентности и уровней зрелости API.

Идемпотентность методов

Свойство идемпотентности означает, что многократный повторный вызов одного и того же метода с теми же параметрами приведет к тому же состоянию сервера, что и однократный вызов.

•Методы GET, PUT, DELETE являются идемпотентными. Например, повторная отправка запроса DELETE /students/1 не приведет к ошибке логики: если студент удален, он останется удаленным. Это свойство критически важно для надежности сетевого взаимодействия: если клиент не получил ответ из-за сбоя сети, он может безопасно повторить идемпотентный запрос.

•Метод POST не является идемпотентным. Повторная отправка POSTзапроса может привести к созданию дубликата ресурса.

HATEOAS и Модель зрелости Ричардсона [6]

Вершиной развития REST-архитектуры (Уровень 3 по модели Ричардсона) является принцип HATEOAS (Hypermedia as the Engine of Application State). Согласно этому принципу, клиент взаимодействует с приложением исключительно через гипермедиа, предоставляемую сервером. В ответе сервера, помимо данных, содержатся ссылки (links) на возможные следующие действия. Это снижает связность (coupling) между клиентом и сервером, так как логика переходов диктуется сервером динамически.

1.3. Сравнение форматов данных: XML против JSON

Выбор между SOAP и REST часто сводится к выбору формата сериализации данных: XML (для SOAP) или JSON (для REST).

XML (eXtensible Markup Language)

• Преимущества: Поддержка сложных структур данных, наличие пространств имен (Namespaces), возможность строгой валидации через XSDсхемы, читаемость человеком.

10

•Недостатки: Избыточность синтаксиса (открывающие и закрывающие теги), большой объем передаваемых данных.

•Парсинг: Требует построения DOM-дерева, что является ресурсоемкой операцией для CPU и оперативной памяти.

JSON (JavaScript Object Notation)

•Преимущества: Лаконичность (отсутствие тегов), прямая совместимость с объектами JavaScript, меньший размер сообщений [5].

•Недостатки: Отсутствие встроенной поддержки пространств имен, слабая поддержка валидации (хотя существует JSON Schema), ограниченный набор типов данных (строки, числа, булевы значения, массивы, объекты).

•Парсинг: Выполняется нативно в браузерах и большинстве современных языков программирования, значительно быстрее XML.

Отдельного внимания заслуживает сравнение механизмов валидации данных в обоих подходах.

Валидация в SOAP (XML Schema Definition – XSD):

В экосистеме XML валидация является встроенной и обязательной частью процесса. XSD-схемы позволяют определять сложнейшие правила: регулярные выражения для строк, диапазоны значений для чисел, списки допустимых значений (enumerations) и структуру вложенности. SOAP-парсерах на сервере часто автоматически отвергают запрос, если он не соответствует XSD, еще до того, как управление будет передано бизнес-логике. Это обеспечивает строгий контракт («Contract First»).

Валидация в REST (JSON Schema):

Исторически JSON не имел встроенного механизма схем. Однако с развитием стандарта появился JSON Schema – декларативный формат для описания структуры JSON-данных. В отличие от SOAP, использование JSON Schema в REST является опциональным. Часто валидация реализуется программно на уровне контроллера (например, с помощью библиотек Joi или Zod в экосистеме Node.js), что дает большую гибкость, но лишает систему жестких гарантий контракта на уровне протокола.