Сервис-ориентированная архитектура — service-oriented architecture

SOA по версии «Голубого гиганта»

Рынок средств реализации SOA еще только формируется, а
потому ни один из современных поставщиков программного обеспечения пока не
может предложить решений с полным спектром необходимой функциональности .
Аналитики ZapThink выделяют несколько компаний, которые уже имеют солидный
продуктовый багаж в тех областях, на базе которых развивается переход к SOA, и
уже проделали немалую работу по поддержке в своих системах стандартов
Web-сервисов и принципов SOA в целом. Среди них компании НР, IBM, Microsoft и
Computer Associates, а также ряд игроков с более сфокусированной
направленностью, включая BEA Systems, Ascential Software, Sybase, Progress
Software, webMethods, Software AG.

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

IBM предлагает четырехуровневый подход к адаптации
принципов SOA . Каждый из уровней может включать несколько этапов жизненного
цикла сервиса, которых также четыре: создание (build), развертывание (deploy),
использование (use), управление и защита (manage and secure).

Общая архитектура брокера объектных запросов (CORBA)

В 1980-х началось активное использование корпоративных сетей и клиент-серверной архитектуры. Возникла потребность в стандартном способе взаимодействия приложений, которые созданы с использованием разных технологий, исполняются на разных компьютерах и под разными ОС. Для этого была разработана CORBA. Это один из стандартов распределённых вычислений, зародившийся в 1980-х и расцветший к 1991 году.

Стандарт CORBA был реализован несколькими вендорами. Он обеспечивает:

• Не зависящие от платформы вызовы удалённых процедур (Remote Procedure Call).
• Транзакции (в том числе удалённые!).
• Безопасность.
• События.
• Независимость от выбора языка программирования.
• Независимость от выбора ОС.
• Независимость от выбора оборудования.
• Независимость от особенностей передачи данных/связи.
• Набор данных через язык описания интерфейсов (Interface Definition Language, IDL).

Сегодня CORBA всё ещё используется для разнородных вычислений. Например, он до сих пор является частью Java EE, хотя начиная с Java 9 будет поставляться в виде отдельного модуля.

Хочу отметить, что не считаю CORBA паттерном SOA (хотя отношу и CORBA, и SOA-паттерны к сфере распределённых вычислений). Я рассказываю о нём здесь, поскольку считаю недостатки CORBA одной из причин возникновения SOA.

Принцип работы

Сначала нам нужно получить брокер объектных запросов (Object Request Broker, ORB), который соответствует спецификации CORBA. Он предоставляется вендором и использует языковые преобразователи (language mappers) для генерирования «заглушек» (stub) и «скелетов» (skeleton) на языках клиентского кода. С помощью этого ORB и определений интерфейсов, использующих IDL (аналог WSDL), можно на основе реальных классов генерировать в клиенте удалённо вызываемые классы-заглушки (stub classes). А на сервере можно генерировать классы-скелеты (skeleton classes), обрабатывающие входящие запросы и вызывающие реальные целевые объекты.

Вызывающая программа (caller) вызывает локальную процедуру, реализованную заглушкой.

1. Заглушка проверяет вызов, создаёт сообщение-запрос и передаёт его в ORB.
2. Клиентский ORB шлёт сообщение по сети на сервер и блокирует текущий поток выполнения.
3. Серверный ORB получает сообщение-запрос и создаёт экземпляр скелета.
4. Скелет исполняет процедуру в вызываемом объекте.
5. Вызываемый объект проводит вычисления и возвращает результат.
6. Скелет пакует выходные аргументы в сообщение-ответ и передаёт его в ORB.
7. ORB шлёт сообщение по сети клиенту.
8. Клиентский ORB получает сообщение, распаковывает и передаёт информацию заглушке.
9. Заглушка передаёт выходные аргументы вызывающему методу, разблокирует поток выполнения, и вызывающая программа продолжает свою работу.

Достоинства

• Независимость от выбранных технологий (не считая реализации ORB).
• Независимость от особенностей передачи данных/связи.

Недостатки

• Независимость от местоположения: клиентский код не имеет понятия, является ли вызов локальным или удалённым. Звучит неплохо, но длительность задержки и виды сбоев могут сильно варьироваться. Если мы не знаем, какой у нас вызов, то приложение не может выбрать подходящую стратегию обработки вызовов методов, а значит, и генерировать удалённые вызовы внутри цикла. В результате вся система работает медленнее.
• Сложная, раздутая и неоднозначная спецификация: её собрали из нескольких версий спецификаций разных вендоров, поэтому (на тот момент) она была раздутой, неоднозначной и трудной в реализации.
• Заблокированные каналы связи (communication pipes): используются специфические протоколы поверх TCP/IP, а также специфические порты (или даже случайные порты). Но правила корпоративной безопасности и файрволы зачастую допускают HTTP-соединения только через 80-й порт, блокируя обмены данными CORBA.

SOA – это архитектура

SOA – ServiceOrientedArchitecture – архитектура, ориентированная на сервисы. SOA – это прежде всего бизнес-концепция архитектурного подхода к построению предприятия. Более ранние концепции не ставили в центр внимания архитектуру предприятия

SOA – первая широко известная бизнес-концепция, концентрирующаяся на архитектуре. Таким, образом, SOAнадо понимать и применять в контексте управления архитектурой предприятия (EnterpriseArchitectureManagement). Архитектура предприятия включает разные слои: бизнес-архитектура, информационная архитектура, техническая архитектура и т.д. SOAначинается с уровня бизнес-архитектуры.

Принципы

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

Стандартизированный контракт на обслуживание

Услуги соответствуют стандартному соглашению о взаимодействии, как определено в совокупности одним или несколькими документами с описанием услуг в рамках данного набора услуг.

Ссылка на услугу автономия (аспект слабой связи)

Взаимосвязь между службами сведена к минимуму до уровня, на котором они знают только о своем существовании.

Прозрачность местоположения службы (аспект слабой связи)

Службы можно вызывать из любого места в сети, где бы они ни находились.

Срок службы

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

Абстракция службы

Службы действуют как черные ящики, которые их внутренняя логика скрыта от потребителей.

Автономность службы

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

Отсутствие состояния службы

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

Гранулярность службы

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

Нормализация сервиса

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

Возможность компоновки сервисов

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

Обнаружение сервисов

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

Повторное использование службы

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

Служба инкапсуляция

Многие службы, которые изначально не планировались SOA, может быть инкапсулирован или стать частью SOA.

Сервис или процесс

Бизнес-потенциалы (BusinessCapabilities) легко декомпозировать в бизнес-сервисы, но трудно – в бизнес-процессы. Сервисный подход ориентирован на стратегические цели компании – создание и сохранение бизнес-потенциалов.

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

В сервисном подходе –именно бизнес-сервис является основным объектом планирования и управления. Бизнес-процесс – это способ реализации бизнес-сервиса. В процессном подходе первичен бизнес-процесс, как уникальная цепочка создания стоимости. Бизнес-сервис в процессном подходе либо не актуализируется вовсе и заменяется на технический сервис, либо является подчиненным элементом бизнес-процесса, кирпичиком из которых строится бизнес-процесс.

SOA – это не технологическая платформа

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

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

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

См. Также

Разработка программного обеспечения

• Компонентная разработка программного обеспечения
• Распределенные вычисления
• Переносимый объект
• Сервис ориентированная архитектура (SOA)

Программные технологии на основе компонентов

• Freedesktop.org D-Bus — текущая открытая межъязыковая кроссплатформенная объектная модель
• GNOME Bonobo — устаревшая межъязыковая объектная модель GNOME
• KDE DCOP — устаревшая система межпроцессного взаимодействия и взаимодействия компонентов программного обеспечения KDE
• KDE — Структура компонентов KDE
• Компонентная объектная модель (COM) — Межъязыковая объектная модель только для Microsoft Windows
• DCOM (Distributed COM) — расширение, позволяющее COM работать в сетях
• Common Language Infrastructure — Текущая .NET межъязыковая кроссплатформенная объектная модель
• XPCOM (Cross Platform Component Object Model) — разработана Mozilla для приложений на основе на нем (например, Mozilla Application Suite, SeaMonkey 1.x)
• Системная объектная модель IBM SOM и DSOM — компонентные системы от IBM, используемые в OS / 2 и AIX
• Internet Communications Engine (ICE)
• Вызов удаленного метода Java (Java RMI)
• Платформа Java, Enterprise Edition (Java EE)
• JavaBean
• OpenAIR
• Удаленный вызов процедуры (RPC)
• Windows Communication Foundation (WCF)
• Software Communications Architecture (SCA) — компоненты для встроенных систем, кросс-языковые, кросс-транспорт, кроссплатформенность

языковые привязки

• языковые привязки
• интерфейс внешней функции
• соглашение о вызовах
• интерфейс динамического вызова
• изменение имени
• интерфейс прикладного программирования — API
• Бинарный интерфейс приложения — ABI
• Сравнение виртуальных машин приложений
• SWIG генератор привязок автоматических интерфейсов с открытым исходным кодом со многих языков на многие языки

Обзор

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

Как выбрать стратегию распределенных транзакций

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

Рисунок 12: Характеристики шаблонов двойной записи

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

Мне нравится организовывать и оценивать подходы, описанные в этой статье, на основе их атрибутов согласованности данных и масштабируемости, как показано на рисунке 13.

Рисунок 13: Характеристики относительной согласованности данных и масштабируемости шаблонов двойной записи

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

Высокий уровень масштабирования и доступности: параллельные конвейеры и хореография.

Если ваши шаги временно изолированы, тогда имеет смысл запустить их в методе параллельных конвейеров. Скорее всего, вы можете применить этот шаблон к определенным частям системы, но не ко всем. Далее, предполагая, что между этапами обработки существует временная связь, и определенные операции и службы должны выполняться раньше других, вы можете рассмотреть подход “хореография”. Используя хореографию сервисов, можно создать масштабируемую, управляемую событиями архитектуру, в которой сообщения перетекают от сервиса к сервису через децентрализованный процесс оркестровки. В этом контексте реализации шаблона “Исходящие” с Debezium и Apache Kafka (например, Red Hat OpenShift Streams для Apache Kafka ) особенно интересны и набирают обороты.

Средний уровень масштабирования и доступности: оркестровка и двухфазная фиксация

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

Низкий уровень масштабирования и доступности: модульный монолит

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

Сервисная шина предприятия (ESB)

Сервисная шина предприятия использовала веб-сервисы уже в 1990-х, когда они только развивались (быть может, некоторые реализации сначала использовали CORBA?).

ESB возникла во времена, когда в компаниях были отдельные приложения. Например, одно для работы с финансами, другое для учёта персонала, третье для управления складом, и т. д., и их нужно было как-то связывать друг с другом, как-то интегрировать. Но все эти приложения создавались без учёта интеграции, не было стандартного языка для взаимодействия приложений (как и сегодня). Поэтому разработчики приложений предусматривали конечные точки для отправки и приёма данных в определённом формате. Компании-клиенты потом интегрировали приложения, налаживая между ними каналы связи и преобразуя сообщения с одного языка приложения в другой.

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

В этой архитектуре используется модульное приложение (composite application), обычно ориентированное на пользователей, которое общается с веб-сервисами для выполнения каких-то операций. В свою очередь, эти веб-сервисы тоже могут общаться с другими веб-сервисами, впоследствии возвращая приложению какие-то данные. Но ни приложение, ни бэкенд-сервисы ничего друг о друге не знают, включая расположение и протоколы связи. Они знают лишь, с каким сервисом хотят связаться и где находится сервисная шина.

Клиент (сервис или модульное приложение) отправляет запрос на сервисную шину, которая преобразует сообщение в формат, поддерживаемый в точке назначения, и перенаправляет туда запрос. Всё взаимодействие идёт через сервисную шину, так что если она падает, то с ней падают и все остальные системы. То есть ESB — ключевой посредник, очень сложный компонент системы.

Это очень упрощённое описание архитектуры ESB. Более того, хотя ESB является главным компонентом архитектуры, в системе могут использоваться и другие компоненты вроде доменных брокеров (Domain Broker), сервисов данных (Data Service), сервисов процессной оркестровки (Process Orchestration Service) и обработчиков правил (Rules Engine). Тот же паттерн может использовать интегрированная архитектура (federated design): система разделена на бизнес-домены со своими ESB, и все ESB соединены друг с другом. У такой схемы выше производительность и нет единой точки отказа: если какая-то ESB упадёт, то пострадает лишь её бизнес-домен.

Главные обязанности ESB:

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

У этого архитектурного паттерна есть положительные стороны. Однако я считаю его особенно полезным в случаях, когда мы не «владеем» веб-сервисами и нам нужен посредник для трансляции сообщений между сервисами, для оркестрирования бизнес-процессами, использующими несколько веб-сервисов, и прочих задач.

Также рекомендую не забывать, что реализации ESB уже достаточно развиты и в большинстве случаев позволяют использовать для своего конфигурирования пользовательский интерфейс с поддержкой drag & drop.

Достоинства

• Независимость набора технологий, развёртывания и масштабируемости сервисов.
• Стандартный, простой и надёжный канал связи (передача текста по HTTP через порт 80).
• Оптимизированный обмен сообщениями.
• Стабильная спецификация обмена сообщениями.
• Изолированность контекстов домена (Domain contexts).
• Простота подключения и отключения сервисов.
• Асинхронность обмена сообщениями помогает управлять нагрузкой на систему.
• Единая точка для управления версионированием и преобразованием.

Недостатки

• Ниже скорость связи, особенно между уже совместимыми сервисами.
• Централизованная логика:
  • Единая точка отказа, способная обрушить системы связи всей компании.
  • Большая сложность конфигурирования и поддержки.
  • Со временем можно прийти к хранению в ESB бизнес-правил.
  • Шина так сложна, что для её управления вам потребуется целая команда.
  • Высокая зависимость сервисов от ESB.

Русский вариант

До недавнего времени (примерно до середины 2007 года)
казалось, что интерес к теме СОА на российском рынке поддерживается только
усилиями ведущих западных поставщиков ПО, которые чаще всего говорили о
достоинствах этой архитектуры исключительно в теоретическо-методическом плане,
не приводя при этом конкретных примеров. Но к концу прошлого года, когда
маркетинговая активность вендоров явно пошла на убыль, выяснилось, что целый
ряд российских компаний уже имеет определенную практику использования СОА в
рамках создания и развития своих информационных систем. Так, несколько успешных
СОА-проектов в банковском секторе реализовала компания «Неофлекс», EPAM/VDI выполнила порядка 10 проектов. О работе
в СОА объявили несколько крупных системных интеграторов, среди них IBS, «Открытые технологии».

Если говорить о непосредственных пользователях ИТ-систем,
то о применении СOA в своих
организациях заявили руководители ИТ-служб банка «Русфинанс» (группа Societe Generale), банка «Ренессанс Капитал», «Альфа-Банка», «Русского банка
развития», Московского банка реконструкции и развития, «Аэрофлота», «Вымпелкома».
Доминирование в этом списке банковских структур определяется во многом тем, что
как раз здесь идет реальное освоение нового подхода к созданию ИТ-систем.
Приведенный перечень хорошо иллюстрирует, где в первую очередь нужна СOA: в сегментах рынка с высоким
уровнем конкуренции, с динамично изменяющейся внутренней структурой бизнеса, с
предоставлением услуг массовому потребителю.

Характеристики

широко известной статьеФаулерЛьюис

Что такое микросервис?

определением Эдриана Кокрофтамикросервисы должны

• дёшево заменяться;
• быстро масштабироваться;
• быть устойчивыми к сбоям;
• никоим образом не замедлять нашу работу.

Насколько велик микросервис?

настолько большим, чтобы умещаться в рукеописывает случаисоотношение количества сотрудников и сервисовФред Джордж полагаетмикросервис должен соответствовать ограниченному контексту, который способен полностью понять один человекв Netflix их около 800Фред ДжорджРебекка Парсонспри разработке микросервисов труднее всего определять их границы

Компонентное представление через сервисы

1. Компонент — это элемент системы, который можно независимо заменить, усовершенствовать (Мартин Фаулер) и масштабировать (Ребекка Парсонс).
2. При разработке ПО мы используем два типа компонентов:
   А. Библиотеки: куски кода, применяемые в приложениях, которые могут дополняться или заменяться другими библиотеками, желательно без воздействия на остальную часть приложения. Взаимодействие происходит через языковые конструкты. Однако если интересующая нас библиотека написана на другом языке, мы не можем использовать этот компонент.
   Б. Сервисы: части приложений, по факту представляющие собой маленькие приложения, выполняющиеся в собственных процессах. Взаимодействие выполняется за счёт межпроцессной связи, вызовов веб-сервисов, очереди сообщений и т. д. Мы можем использовать сервис, написанный на другом языке, поскольку он выполняется в собственном процессе (этот подход предпочитает Чед Фаулер).
3. Независимая масштабируемость — каждый сервис может быть масштабирован независимо от остального приложения.

Гетерогенность

Мартин ФаулерЧед Фаулердолжны

• Предотвращает возникновение тесных связей благодаря использованию разных языков.
• Разработчики могут экспериментировать с технологиями, что повышает их собственную ценность и позволяет не уходить в другие компании, чтобы попробовать новинки.
  Правило. При экспериментах с новыми технологиями:
  — нужно использовать маленькие элементы кода (code unit), модули/микросервисы, чтобы снизить риск;
  — элементы кода должны быть одноразовыми (disposable).

Автоматизация инфраструктуры

Непрерывное развёртываниеМартин ФаулерРебекка ПарсонсЧед ФаулерЭрик Эванс

1. «Голубое» и «зелёное» развёртывание: нулевое время простоя.
2. Автоматизация: нажатием одной кнопки можно развернуть несколько серверов.
3. Серверы Phoenix: быстрый запуск и остановка.
4. Мониторинг: можно заметить, когда что-то пошло не так, и отладить.

Архитектура с эволюционным развитием

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

Критика

SOA была объединена с Web-сервисами ; однако веб-службы — это лишь один из вариантов реализации шаблонов, составляющих стиль SOA. В отсутствие собственных или двоичных форм удаленного вызова процедур (RPC) приложения могут работать медленнее и требовать большей вычислительной мощности, что увеличивает затраты. Большинство реализаций несут эти накладные расходы, но SOA может быть реализована с использованием технологий (например, Java Business Integration (JBI), Windows Communication Foundation (WCF) и служба распределения данных. (DDS)), которые не зависят от удаленных вызовов процедур или преобразования через XML или JSON. В то же время появляющиеся технологии синтаксического анализа XML с открытым исходным кодом (такие как VTD-XML ) и различные XML-совместимые двоичные форматы обещают значительно улучшить производительность SOA.

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

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

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

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

SOAP vs. REST

Модернизация старых решений

И есть несколько стратегий для конвертации их в SOA.

• Первый подход заключается в простой замене текущей системы на новую или набор систем. В целом, это нормальный подход, если рынок предлагает готовый продукт, полностью удовлетворяющее вашим требованиям. Такое решение снижает затраты на поддержку, но значительно увеличивает стоимость будущих модификаций. (Все мы знаем, что в этом мире постоянны только изменения – прим. пер.)
• Альтернативным подходом будет создание обёртки для старой системы, которая может предоставить доступ к существующим интерфейсам через веб-сервисы. В этом случае старый функционал «обёрнут» сервис слоем и «включён» в SOA окружение. Это не решит всех ваших проблем, например, сложно будет добиться желаемой степени независимости сервисов, потому что старое приложение может тесно связывать некоторые возможные сервисы. В финансовом плане, такой ход может сработать, когда переписывание всей системы очень дорогое, но части решения могут быть переиспользованы и бюджеты ограничены.
• Последним вариантом является решение переписать легаси систему. Если вы можете влиять на архитектуру приложения и знаете в целом как достичь необходимого уровня независимости между сервисами, то это будет хорошим выбором. Однако легаси системы обычно критичны для бизнеса, и сложность с дороговизной в их замене заключается в использовании старых технологий и отсутствии документации, что ведет к некоторым проблемам реверс инжиниринга с повышением рисков по реализации проекта. В этом варианте основная сложность заключается в понимании всех рисков.

Интеграция в масштабах предприятия

• Интеграционные фреймворки наиболее простой способ для формирования библиотек с определенным API для разных окружений разработки. В качестве примеров таких фреймворков можно привести Apache Camel и Spring Integration для Java и NServiceBus для .NET
• Enterprise Service Bus (ESB) предлагает возможности интеграционных фреймворков, а также инструменты для его разворачивания, администрирования и мониторинга в «боевом» режиме. ESB поддерживает соединения между поставщиками данных и потребителями, дополнительно предлагая улучшенный инструментарий, позволяющий заметно уменьшить стоимость и сложность в решении интеграционных проблем на более высоком уровне абстракции. Примерами ESB могут служить: Oracle Service Bus и Mule ESB.
• Интеграционные пакеты предлагают полный стек инструментария, который содержит не только возможности ESB, но и ориентированные на бизнес инструменты, такие как BPM (business process management), мониторинг бизнес процессов, управление критичными данными, репозиторий. Все эти фичи позволяют реагировать на изменения более быстро. Очень сложно сравнивать такие пакеты друг с другом.

Ссылки

1. Gold et al., “Understanding ServiceOriented Software,” IEEE Software, vol. 21, no. 2, 2004, pp. 71–77.
2. Jones, “Toward an Acceptable Definition of Service,” IEEE Software, vol. 22, no. 3, 2005, pp. 87–93.
3. Mumbaikar and P. Padiya, “Web Services Based on SOAP and REST Principles,”   Int’l J. Scientific and Research Publications, vol. 3, no. 5, 2013, pp. 1–4.
4. Louridas, “SOAP and Web Services,” IEEE Software, vol. 23, no. 6, 2006, pp. 62– 67.
5. Vinoski, “REST Eye for SOA Guy,” IEEE Internet Computing, vol. 11, no. 1, 2007, pp. 82–84.

 http://www.infoq.com/articles/service-oriented-architecture-and-legacy-systemsЕсли вам близка тематика статьи или вы хотите узнать больше о том, как правильно проектировать, поддерживать и работать с API, приходите на нашу конференцию API & Backend! Если вам есть о чем рассказать, мы ждем ваших историй!

Заключение

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

Эволюция шла по классическому пути: сложные проблемы разбивались на более мелкие, простые в решении.

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

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

Заключение

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

В конце концов, неважно, какую стратегию вы выберете; что имеет значение, так это осознанный выбор стратегии и правильная ее реализация