Архитектура SOA

СОА (SOA, service-oriented architecture) — архитектурный стиль, при котором система собирается из независимых сервисов, а вызывают их через стандартизированные интерфейсы. Референсная модель OASIS описывает SOA как «парадигму организации и использования распределённых возможностей, которые могут находиться под контролем разных владельцев», а The Open Group формулирует короче: «архитектурный стиль, который поддерживает сервис-ориентированность».

Коротко, что нужно знать про СОА до разбора:

• Термин ввели аналитики Gartner в 1996 году, а технологический фундамент появился раньше: CORBA 1.0 вышла в октябре 1991-го.
• Канонических определений два — референсная модель OASIS SOA-RM (стандарт OASIS от 12 октября 2006 года) и формулировка рабочей группы The Open Group SOA Work Group.
• Сервисы связывают контракт и описание: SOAP 1.2 и WSDL 2.0 — рекомендации W3C 2007 года, каталог сервисов — реестр UDDI.
• Сервисная шина ESB даёт маршрутизацию и преобразование форматов и одновременно становится единой точкой отказа.
• Микросервисы не отменяют СОА: это другой масштаб. SOA стандартизирует интеграцию предприятия, микросервисы описывают устройство одного приложения.

Основные понятия SOA

Сервис в SOA — самостоятельная единица работы с внешним контрактом: её вызывают по сети, а внутреннее устройство потребителю недоступно. The Open Group определяет сервис как «логическое представление повторяемой бизнес-активности с определённым результатом» и добавляет три свойства: сервис самодостаточен, может быть составлен из других сервисов и остаётся «чёрным ящиком» для тех, кто им пользуется.

Базовые компоненты архитектуры остаются теми же, что и двадцать лет назад:

• Сервисы — компоненты, предоставляющие конкретные функции. В формулировке The Open Group это «проверить кредитоспособность клиента, выдать данные о погоде, свести отчёты по бурению».
• Бизнес-процессы — совокупность сервисов, работающих вместе для достижения бизнес-целей. Их сценарии описывают на языке WS-BPEL: спецификация Web Services Business Process Execution Language 2.0 принята как стандарт OASIS 11 апреля 2007 года.
• Реестр — хранилище метаданных и описаний, через которое потребитель находит нужный сервис.
• Шина — инфраструктура обмена данными между компонентами.

Референсная модель OASIS добавляет к этому набор понятий, без которых архитектуру не описать: описание сервиса, видимость (visibility), взаимодействие, эффект в реальном мире, контекст исполнения, политики и контракты. Модель намеренно оторвана от технологий — в самом документе OASIS сказано, что она «не привязана напрямую ни к каким стандартам, технологиям или конкретным деталям реализации».

Практическое следствие: SOA задаёт способ нарезки системы, а шина, реестр и конкретный протокол — только инструменты реализации, и они заменяемы.

ОБЗОРНЫЙ ПРАКТИКУМ ПО НАШУМЕВШИМ НЕЙРОСЕТЯМ

Нейросети DEEPSEEK И QWEN За 2 часа сделаем полный обзор новых мощных ИИ-моделей, которые бросают вызов нейросети ChatGPT

ТОП-подарки всем участникам лекции:

• Возможность получить Доступ в Нейроклуб на целый месяц
• Как ИИ ускоряет работу и приносит деньги
• За 2 часа вы получите четкий план, как начать работать с ИИ прямо сейчас!

Участвовать бесплатно

Откуда взялась SOA: 1991, 1996 и 2000-е

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

• Разбор на Хабре, который стоит первым в выдаче по запросу «соа», возводит подход к концу 1980-х — к эпохе CORBA и DCOM.
• Русская Википедия пишет, что сервис-ориентированная архитектура «получила распространение в конце 1990-х — начале 2000-х годов».
• Сам термин ввели аналитики Gartner Рой Шульте и Ефим Натис: отчёт «Service Oriented Architectures, Part 1» датирован 1996 годом и до сих пор числится в каталоге исследований Gartner.

Опорную точку можно проверить по первоисточнику. Object Management Group, консорциум-разработчик CORBA, основан в 1989 году, а CORBA 1.0 опубликована в октябре 1991-го: в неё вошли объектная модель, язык описания интерфейсов IDL и базовый набор API для динамического формирования и вызова запросов. Дальше релизы шли неравномерно. С октября 1991-го по март 2004-го OMG выпустила четырнадцать версий — от 1.0 до 3.0.3, с паузой почти в три года между 1.2 (декабрь 1993-го) и 2.0 (август 1996-го). После 3.0.3 темп упал: 3.1 вышла в январе 2008-го, 3.1.1 и 3.2 — в 2011-м, 3.3 — в ноябре 2012-го, а последняя версия 3.4 — в феврале 2021 года, спустя восемь с лишним лет после предыдущей.

Складывается непротиворечивая картина: технологический фундамент распределённых вызовов — начало 1990-х, имя архитектурного стиля — 1996-й, массовые корпоративные внедрения — 2000-е. Каждый источник датирует своё событие: один — технологию, другой — термин, третий — волну внедрений.

Как в SOA находят и вызывают сервис

Схема обмена в сервис-ориентированной архитектуре описана в документе W3C «Web Services Architecture» (Working Group Note от 11 февраля 2004 года). Веб-сервис определён там дословно: «программная система, спроектированная для поддержки совместимого межмашинного взаимодействия по сети», интерфейс которой описан в машиночитаемом формате — конкретно в WSDL.

Участников четверо, и путаница между ними — типичная ошибка в проектной документации:

• Provider entity — организация или человек, предоставляющий сервис.
• Provider agent — программа, которая реализует сервис на его стороне.
• Requester entity — организация или человек, который сервисом пользуется.
• Requester agent — программа, отправляющая запрос.

Связывает их механизм обнаружения. Классический цикл выглядит так: поставщик публикует описание сервиса в реестре, потребитель находит там подходящее описание, получает адрес и контракт, после чего вызывает сервис напрямую. W3C отмечает, что обнаружение бывает ручным (описание читает человек на этапе разработки) и автоматическим, когда каталог опрашивает сама программа.

Роль реестра в классической связке играл UDDI. Публичный UDDI Business Registry, узлы которого держали IBM, Microsoft и SAP, закрыли: объявление появилось в декабре 2005 года, публикация новых записей прекратилась в январе 2006-го. Три компании выпустили по этому поводу общий FAQ. Объяснение причины даёт пост Microsoft о закрытии UBR, и там это оценка автора с оговоркой: «мне это кажется историей в жанре трагедии общин… но на UBR не было ни контроля качества, ни управления, потому что не было прямого финансирования». Публиковать мог кто угодно, качество никто не проверял, и в каталоге скопились данные низкого качества. При этом протокол UDDI никто не отменял: он остался во внутренних корпоративных реестрах и в продуктах вендоров.

Отсюда рабочий вывод: единый каталог сервисов в SOA живёт внутри контура компании — идею общего публичного реестра рынок не принял.

Принципы SOA

Три принципа несут конструкцию, остальные из них выводятся.

Разделение ответственности

Каждый компонент отвечает за конкретную функциональность, что упрощает поддержку и модификацию системы. Граница проводится по бизнес-активности: «выдать выписку», «проверить лимит», «зарезервировать место». Так формулирует и The Open Group — решения строятся из сервисов, которые «отражают реальные бизнес-активности» предприятия и межкорпоративных процессов.

Стандартизированные интерфейсы

SOA предполагает использование стандартизированных интерфейсов — SOAP (Simple Object Access Protocol) и REST (Representational State Transfer), — что обеспечивает единообразие взаимодействия. Контракт при этом отделён от реализации: потребитель работает с описанием интерфейса и ничего не знает про код сервиса.

Независимость от языка программирования

Части системы могут быть реализованы на разных языках, и это даёт возможность выбирать технологию под конкретную задачу. Требование к инфраструктуре The Open Group формулирует жёстко: реализации должны опираться на открытые стандарты, иначе теряются совместимость и прозрачность расположения сервисов.

Что следует из этих трёх

• Слабая связанность. Сервисы знают друг о друге только контракт, поэтому замена реализации не ломает соседей.
• Повторное использование. Один сервис проверки клиента обслуживает и кредитный конвейер, и мобильное приложение.
• Композиция. Сервис допустимо собрать из других сервисов — это прямо записано в определении The Open Group.
• Управляемость. The Open Group отдельно отмечает: SOA требует сильного управления (governance) представлением и реализацией сервисов.

Мини-вывод: принципы SOA описывают дисциплину границ. Пока границы держатся, архитектура даёт заявленную гибкость.

Протоколы SOA: SOAP, WSDL и REST

SOAP версии 1.2 — рекомендация W3C от 27 апреля 2007 года (вторая редакция). В спецификации он описан как «лёгкий протокол, предназначенный для обмена структурированной информацией в децентрализованной, распределённой среде». Сообщение представляет собой XML-конверт с пространством имён http://www.w3.org/2003/05/soap-envelope; конверт состоит из необязательного заголовка и обязательного тела. От транспорта протокол не зависит: спецификация задаёт отдельный механизм привязки к нижележащим протоколам, чаще всего к HTTP.

Минимальный запрос баланса счёта выглядит так:

Описание такого сервиса живёт в WSDL. Web Services Description Language 2.0 — рекомендация W3C от 26 июня 2007 года, «XML-язык для описания веб-сервисов»: он задаёт абстрактную модель того, что сервис предлагает, и её привязку к конкретному транспорту.

REST решает ту же задачу без конверта — адресуемым ресурсом и методом HTTP:

Оба варианта укладываются в SOA. Референсная модель OASIS прямо допускает, что сервисы «могут становиться видимыми, поддерживать взаимодействие и порождать эффекты через другие стратегии реализации», помимо веб-сервисов. Русская Википедия к тому же перечисляет среди реализаций CORBA, Jini и REST наравне с SOAP. Разбор и генерацию контрактов сегодня частично снимают ИИ-ассистенты — про одну из моделей под разработку мы писали в материале Sonnet 4.6: новая модель от Claude для программирования.

Сервисная шина ESB в архитектуре SOA

Шина (Enterprise Service Bus) — инфраструктурный слой, через который сервисы обмениваются сообщениями. Она берёт на себя маршрутизацию, преобразование форматов и стыковку разных транспортов, поэтому системы, говорящие на несовместимых протоколах, соединяются без переписывания.

The Open Group называет каталог сервисов и сервисную шину двумя примерами технологических реализаций, которые «требуют следования соответствующим открытым стандартам, чтобы достичь совместимости, обещанной SOA». То есть шина — не самостоятельная ценность, её смысл в соблюдении контрактов.

У централизации есть цена, и она хорошо описана. Разбор на Хабре перечисляет в разделе о недостатках ESB шесть пунктов: ниже скорость связи, особенно между уже совместимыми сервисами; централизованная логика с единой точкой отказа, «способной обрушить системы связи всей компании»; большая сложность конфигурирования и поддержки; накопление в шине бизнес-правил; необходимость целой команды для управления шиной; высокая зависимость сервисов от ESB. Джеймс Льюис и Мартин Фаулер в статье о микросервисах (25 марта 2014 года) высказались резче: они видели «столько загубленных внедрений сервис-ориентированности — от склонности прятать сложность внутри ESB до провальных многолетних инициатив, которые стоили миллионы и не принесли пользы».

Практический ориентир такой: шина оправдана, когда в контуре десятки разнородных систем и интеграции между ними надо стандартизировать. Когда через шину начинают гонять ещё и бизнес-правила, она превращается в новый монолит — только распределённый и с более дорогим релизным циклом.

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

СОА и микросервисы: таблица различий

Русская Википедия называет микросервисную архитектуру «вариантом СОА, базирующимся на применении минимальных по размеру сервисов», популярность которого началась с середины 2010-х. Льюис и Фаулер к такому родству относятся осторожно: «SOA означает слишком много разных вещей», и то, что чаще всего встречается под этой вывеской, «значительно отличается от описываемого нами стиля».

Мини-вывод: спор «SOA или микросервисы» чаще всего подменяет вопрос о масштабе. Интеграция десятка унаследованных систем и внутреннее устройство одного продукта решаются разными средствами, и оба подхода уживаются в одной компании.

Пример: банковская система

Банк — учебный случай для SOA, потому что одни и те же операции нужны сразу нескольким каналам: отделению, мобильному приложению, колл-центру и партнёрскому API.

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

Как это собирается на практике:

• Сервис счетов публикует описание операции getBalance в корпоративном реестре.
• Мобильное приложение находит описание, получает адрес и вызывает операцию — SOAP-конвертом или REST-запросом из примеров выше.
• Сервис транзакций вызывает тот же сервис счетов при проверке остатка, повторно используя готовую функцию.
• Сценарий «перевод между счетами» описывается как бизнес-процесс на WS-BPEL: язык, по формулировке спецификации, «задаёт поведение бизнес-процесса на основе веб-сервисов».
• Отчётный сервис забирает данные через шину; прямой доступ к базе счетов ему закрыт.

Ровно в этом месте и появляется выигрыш архитектуры: новый канал подключается к готовым сервисам, и переписывать ядро не приходится. Тем же способом SOA применяют в финансах, здравоохранении и телекоммуникациях — там, где несколько независимых систем обязаны отвечать по одному контракту.

Преимущества SOA

Три выигрыша, ради которых архитектуру и выбирают:

• Гибкость — лёгкость добавления и изменения функциональности без влияния на остальную инфраструктуру: контракт остаётся прежним, а реализация за ним переписывается свободно.
• Масштабируемость — возможность масштабировать приложение путём добавления новых сервисов и наращивать мощность точечно, под нагруженной частью.
• Повторное использование — возможность применять готовые компоненты в различных контекстах: один сервис обслуживает несколько каналов сразу.

Учебный центр IBS добавляет к этому списку автономность сервисов, простоту обслуживания и единообразную структуру каталогов. Все выигрыши держатся на одном условии — стабильном контракте. Как только описание сервиса начинает меняться вместе с реализацией, преимущество обнуляется: потребители чинят интеграции при каждом релизе.

Недостатки SOA и когда она не нужна

Обратная сторона этих выигрышей — цена дисциплины, и она измеряется деньгами и сроками. В разборе учебного центра IBS перечислены четыре типичные проблемы: сложное управление, повышенная нагрузка на систему, несовместимость с приложениями, построенными вокруг графического интерфейса, и высокие инвестиционные затраты на старте.

К этому добавляются два эффекта из практики внедрений:

• Накладные расходы обмена. XML-конверт SOAP тяжелее компактного HTTP-запроса, и на высоких частотах вызовов разница становится заметной.
• Централизация. Пока шина остаётся тонким транспортом, архитектура работает. Как только в неё переносят бизнес-правила, релизный цикл всей компании упирается в конфигурацию одного компонента.

Скепсис доходил и до некрологов. В первых числах января 2009 года аналитик Burton Group Энн Томас Мэйнс опубликовала пост «SOA is Dead; Long Live Services», где написала: «SOA встретила свою кончину 1 января 2009 года, когда была сметена катастрофическим воздействием экономической рецессии». Там же — продолжение, которое цитируют реже: «У SOA остались наследники: мэшапы, BPM, SaaS, облачные вычисления и все прочие архитектурные подходы, которые опираются на сервисы».

Читать это стоит как приговор вывеске: сервисный способ нарезки систем пережил и термин, и волну корпоративных внедрений.

Когда SOA избыточна: одно небольшое приложение с одной командой; продукт на стадии проверки гипотез, где контракты меняются еженедельно; система без потребности переиспользовать функции между каналами. В этих случаях цена управления контрактами превышает выигрыш.

Чек-лист: подходит ли SOA вашей системе

Пройдите по семи пунктам. Чем больше «да», тем очевиднее выигрыш; при одном-двух совпадениях накладные расходы съедят эффект.

• В компании больше трёх систем, которым нужны одни и те же функции.
• Есть унаследованные приложения, переписать которые дороже, чем обернуть контрактом.
• Один и тот же бизнес-процесс обслуживает несколько каналов: сайт, приложение, партнёрское API.
• Есть владелец каждого сервиса — команда, отвечающая за контракт и его версии.
• Изменения интерфейсов удаётся согласовывать заранее, до релиза.
• Нагрузка допускает накладные расходы на сериализацию и сетевые вызовы.
• Руководство готово финансировать управление сервисами постоянно, отдельной строкой бюджета.

Отдельный практический совет: перед стартом опишите три-пять сервисов-кандидатов на языке бизнеса и защитите нарезку перед владельцами процессов. Если для такой защиты нужна наглядная подача, у нас есть подборка лучших ИИ для презентаций.

Заключение

SOA — подход, который позволяет строить гибкие и масштабируемые системы. Разделяя функциональность на независимые сервисы, он упрощает разработку, поддержку и модификацию программного обеспечения; успешное применение в финансах, здравоохранении и телекоммуникациях это подтверждает. Формальная опора у подхода есть: референсная модель OASIS 2006 года, определение The Open Group, спецификации SOAP 1.2, WSDL 2.0 и WS-BPEL 2.0 2007 года. Микросервисы выросли из той же идеи и заняли соседнюю нишу — уровень отдельного приложения.

Материал обновлён в августе 2026 года: сверены определения OASIS и The Open Group, даты спецификаций W3C и OASIS, история CORBA по данным Object Management Group.

Частые вопросы про СОА

Что такое СОА простыми словами?

СОА (SOA) — способ собрать информационную систему из независимых сервисов, каждый из которых делает завершённую бизнес-операцию и вызывается через стандартизированный интерфейс. OASIS определяет SOA как «парадигму организации и использования распределённых возможностей, которые могут находиться под контролем разных владельцев», The Open Group — как «архитектурный стиль, который поддерживает сервис-ориентированность».

Чем СОА отличается от микросервисов?

Масштабом и способом связи. SOA стандартизирует интеграцию на уровне предприятия и опирается на общую шину ESB, SOAP и WS-BPEL. Микросервисы описывают устройство одного приложения: «умные конечные точки и глупые трубы», простые REST-подобные протоколы и своя база у каждого сервиса. Русская Википедия называет микросервисную архитектуру вариантом СОА.

Обязательна ли шина ESB в SOA?

Нет. The Open Group приводит сервисную шину и каталог сервисов как примеры технологических реализаций SOA, а не как обязательное требование. Референсная модель OASIS вообще не привязана к конкретным технологиям и допускает другие стратегии реализации.

SOA — это обязательно SOAP?

Нет. SOAP 1.2 и WSDL 2.0 — рекомендации W3C 2007 года и классический набор для веб-сервисов, но SOA допускает и REST, и CORBA, и Jini. Референсная модель OASIS прямо говорит, что сервисы могут поддерживать взаимодействие через другие стратегии реализации.

Актуальна ли SOA сегодня?

Как термин SOA пережила громкий некролог: в начале января 2009 года аналитик Burton Group Энн Томас Мэйнс написала «SOA is Dead; Long Live Services». Как способ нарезки систем подход остался: стандарты OASIS и The Open Group действуют, а микросервисы, SaaS и облачные архитектуры выросли из той же идеи сервисов.