Автор статьи: Артем Михайлов

SOA — это не просто модель разработки программного обеспечения, а целостный подход к организации бизнес-процессов. Ее преимущество заключается в том, что она позволяет создать гибкие и адаптивные IT-системы, способные быстро реагировать на изменения рынка и потребностей бизнеса.

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

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

История создания

История создания SOA архитектуры началась в 90-х годах прошлого века. В те времена компьютерные системы были достаточно простыми и "замкнутыми" — каждая система была предназначена для решения конкретной задачи и не могла взаимодействовать с другими системами без специально написанного программного кода.

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

Первые концепции SOA появились в конце 90-х годов, когда выходили стандарты на XML и SOAP — технологии, которые позволяли описывать структуру данных и передавать их между различными системами.

Однако наиболее популярной стала архитектура SOA в начале 2000-х, когда компании начали активно использовать веб-сервисы для взаимодействия между различными системами.

Сегодня SOA приобрела широкое распространение и применяется в различных областях, таких как финансы, телекоммуникации, здравоохранение, государственный сектор и т.д.

Создание SOA архитектуры стало важным этапом развития ИТ-индустрии, позволившим компаниям создавать гибкие и адаптивные системы, основанные на сервисах, а не на приложениях. SOA стала реальным достижением технологии, позволяющей решать сложные задачи бизнеса и упрощать интеграцию различных систем, что делает ее неотъемлемой средством для организаций всех уровней.

Основные цели SOA архитектуры

1. Улучшение производительности и масштабируемости системы. SOA архитектура позволяет создавать распределенные системы, что позволяет балансировать нагрузку и повышать скорость работы.

2. Упрощение разработки и поддержки системы. SOA архитектура упрощает интеграцию различных компонентов системы и снижает сложность ее разработки, что облегчает поддержку.

3. Уменьшение зависимостей между компонентами системы. SOA архитектура основана на сервисах, которые могут работать независимо друг от друга, что позволяет изменять компоненты системы без влияния на остальные.

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

5. Улучшение безопасности системы. SOA архитектура позволяет реализовать централизованную систему управления правами доступа к сервисам, что повышает безопасность и уменьшает риски нарушения конфиденциальности данных.

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

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

Для взаимодействия между сервисами используются протоколы, такие как SOAP, REST и другие, которые определяют формат передаваемых данных и правила взаимодействия между сервисами. Каждый сервис должен быть спроектирован таким образом, чтобы он мог быть использован другими сервисами, и чтобы он мог обмениваться данными с другими сервисами.

Роли в SOA

• Поставщик услуг

Этот участник создает веб-сервисы и добавляет их в реестр услуг. Он несет ответственность за параметры использования своих услуг.

• Сервисный реестр или брокер

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

• Пользователь услуг или потребитель

Пользователь услуг находит необходимую услугу в реестре или у брокера и устанавливает связь с поставщиком услуг для использования предоставляемого сервиса.

Сравнение SOA по сравнению с микросервисами

SOA:

• Более зрелый подход с длительной историей построения сложных распределенных систем.

• Сильное разделение бизнес-логики и инфраструктуры, что делает систему более гибкой.

• Ориентирован на использование корпоративных шин или реестров для доставки сообщений между сервисами.

• Гибкость и масштабируемость сервисов зависит от качества реестра.

Микросервисы:

• Более новый подход к построению систем, который получил популярность в последнее время.

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

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

• Создание нового сервиса Более проста.

• Повышенная сложность управления большим количеством микросервисов.

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

Краткий пример задачи, которая решает SOA

Задача: Создание распределенной системы обработки заказов в онлайн магазине с использованием SOA-архитектуры

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

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

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

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

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

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

Заключение

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

Уже сегодня вечером пройдет открытый урок, посвященный системам обмена сообщениями: RabbitMQ и Kafka. На нем рассмотрим:

• архитектурные концепции построения систем обмена сообщений;

• стили интеграции (File Transfer, RPI, Shared Database, Messaging);

• основные концепции обмена сообщениями;

• каналы, сообщение, маршрутизацию, трансляцию, конечную.

Успевайте записаться на урок на странице курса «Архитектура и шаблоны проектирования».