Санкт-Петербургский государственный электротехнический университет им. В.И. Ульянова (Ленина)

ПРОБЛЕМАТИКА ИНТЕГРАЦИИ: АРХИТЕКТУРА «ТОЧКА-ТОЧКА»

2

КОНЦЕПЦИЯ СЕРВИС-ОРИЕНТИРОВАННОЙ АРХИТЕКТУРЫ (SOA)

•Определение: SOA — это архитектурный стиль разработки ПО, основанный на использовании распределенных, слабосвязанных компонентов (сервисов).

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

•Принцип «Черного ящика»:

•Сервис полностью инкапсулирует (скрывает) свою внутреннюю логику и данные.

•Взаимодействие происходит исключительно через публичный контракт (интерфейс).

•Композиция: Сложные бизнес-процессы строятся путем объединения (оркестрации) простых сервисов.

3

ОСНОВНЫЕ ЦЕЛИ И ЗАДАЧИ ВНЕДРЕНИЯ SOA

•1. Повышение гибкости бизнеса (Business Agility):

•Возможность быстрой рекомпозиции сервисов для реализации новых бизнес-процессов.

•Сокращение времени вывода продуктов на рынок (Time-to-Market).

•2. Многократное использование (Reusability):

•Принцип «Write once, use many times».

•Унификация функциональности (единый сервис расчета стоимости для CRM, Web и Mobile).

•3. Экономическая эффективность:

•Снижение затрат на разработку за счет переиспользования.

•Удешевление поддержки и сопровождения систем.

•4. Стандартизация интеграции:

•Унификация протоколов обмена данными в гетерогенной (разнородной) среде.

4

СЕРВИС КАК ФУНДАМЕНТАЛЬНАЯ ЕДИНИЦА АРХИТЕКТУРЫ

•Бизнес-центричность: Сервис проецирует реальную бизнес-задачу (например, «Проверить остаток товара»), абстрагируясь от низкоуровневых операций БД.

•Автономность: Сервис полностью контролирует свою логику и данные. Он не делит базу данных с другими сервисами напрямую.

•Слабая связанность (Loose

Coupling): Сервисы независимы друг от друга. Потребитель сервиса ничего не знает о его внутренней реализации.

•Обнаруживаемость: Сервис публикует информацию о себе в Реестре сервисов, чтобы другие системы могли его найти и использовать.

5

ИНТЕРФЕЙС СЕРВИСА КАК КОНТРАКТ ВЗАИМОДЕЙСТВИЯ

•Интерфейс — это формализованный контракт, определяющий правила взаимодействия с сервисом.

•Описывает ЧТО делает сервис, скрывая КАК он это делает.

•Контракт:

•Операции: Список доступных методов (напр. GetBalance, CreateOrder).

•Входные данные: Структура запроса (напр. ClientID, Date).

•Выходные данные: Структура ответа или ошибки.

•Стандарты описания:

•WSDL (Web Services Description Language) — для SOAP-сервисов.

•OpenAPI / Swagger — для RESTful-сервисов.

6

ENTERPRISE SERVICE BUS (ESB): СВЯЗУЮЩЕЕ ЗВЕНО

•ESB — это инфраструктурный слой для управления взаимодействием сервисов.

•Маршрутизация (Routing): Определение адресата сообщения на основе его содержания.

•Трансформация

(Transformation): Преобразование форматов данных (например, XML -> JSON).

•Управление процессом: Координация сложных бизнес-процессов, затрагивающих несколько сервисов.

•Результат: Уход от связей "каждый с каждым" к схеме "все через шину"

7

ОБЛАСТЬ ПРИМЕНЕНИЯ И ТИПОВЫЕ СЦЕНАРИИ SOA

•Финансовый сектор (FinTech / Banking

•Телекоммуникации

•Ритейл и E-commerce

•Государственный сектор (e-Gov)

8

ЭВОЛЮЦИЯ: ОТ SOA К МИКРОСЕРВИСАМ (MSA)

9

ЗАКЛЮЧЕНИЕ

•Порядок вместо Хаоса: SOA решает проблему архитектуры «Точка-Точка»

•Бизнес-ориентированность: Сервис — это бизнес- функция

•Важность контрактов: Интерфейсы гарантируют, что изменения системы не сломают внешние процессы

•Фундамент для будущего: Принципы SOA являются базой для современной микросервисной архитектуры

10