[Перевод] Service-Oriented Architecture and Legacy Systems
Корпоративные системы быстро эволюционируют из монолитных хранилищ в распределенные приложения, основанные на сервисах с гибкими схемами использования. Чтобы идти в ногу со временем, IT организации должны приспосабливать свои старые приложения к изменяющимся бизнес-требованиям почти что в режиме реального времени, и фактически без возможности второго шанса. Сервис-Ориентированная Архитектура (SOA) эволюционировала для поддержки гибкости операций и федеративности бизнес-процессов, подсистем. Авторы статьи Николас Серано (Nicolas Serrano), Хуасин Эрнандес (Josune Hernantes) и Горка Галлардо (Gorka Gallardo) дают обзор текущего состояния технологии SOA и как развиваться в существующем окружении. Предисловие от Кристофа Эберта (Christof Ebert)Современный бизнес должен быть способен гибко и быстро приспосабливаться к требованиям рынка, но даже незначительные изменения в процессах могут повлечь переработку множества информационных систем, которые изначально были разработаны как монолитные хранилища. Для сохранения конкурентоспособности, затраты на поддержку должны постоянно снижаться, а системы постоянно эволюционировать. SOA делает возможным переход от монолитных систем к сервис-ориентированным. Это содействует гибкости, слабой связанности, выделению абстракций из реальной инфраструктуры. Возможности по обнаружению сервисов и повторному использованию гораздо выше с SOA. Дополнительные возможности и принципы можно узнать из Манифеста SOA. [1][2]
Новизна SOA заключается в том, как моделируется инфраструктура архитектурного решения, основанная на сервисах, вместо фокусирования на всём приложении. Сервисы являются маленькими, обособленными элементами ПО, которые решают одну задачу и могут быть повторно использованы во многих приложениях. SOA основывается на принципе слабой связанности, что означает что каждый сервис — это изолированная сущность с ограниченными зависимостями от других общих ресурсов, таких как базы данных, легаси приложения или разные API. Такое архитектурное решение позволяет создать уровень абстракции между потребителями и создателями. Это влечёт за собой свободу в реализации и обновлениях без ущерба для потребителей сервиса. Да, SOA имеет немало плюсов для бизнеса, но это не лучшее решение для всех случаев. Среди плюсов подхода можно обозначить следующие пункты:
Естественный путь создания сложной модульной системы через интеграцию сервисов от разных поставщиков независимо от платформы и технологии. Подталкивает к слабосвязанным системам, помогает работать со старыми системами. Повышает эффективность путем повторного использования сервисов, что снижает расходы и время разработки Улучшает гибкость и масштабируемость, потому что многие сервисы могут быть разработаны с помощью различной компоновки существующих приложений. Делает возможным сокращение расходов, связанных с поддержкой решения. Можно разработать стандартный протокол общения между системами. Доступ к данным не зависит от географии пользователя, можно использовать мобильные средства связи. Возможность постепенного ввода в строй частей системы, что позволяет быстрее реагировать на нужды бизнеса. Из минусов можно назвать: Трудно реализовать асинхронное взаимодействие между сервисами Сложно и трудоемко реализовать ответы в «реальном времени», потому что XML дает надежность, а не скорость. Конечно есть альтернатива в виде Различные уязвимости в безопасности, связанные с процессом обмена данными между многими приложениями и системами. Сложный процесс управления транзакциями связанный с взаимодействием логически разных систем. Переход на сервис-ориентированную архитектуру не простой процесс. Предприятия, желающие перейти на SOA должны быть осведомлены о трудностях и сопутствующих проблемах. Вполне очевидно, что переход будет сопряжен со многими компромиссами, и у каждого они будут свои. Для более эффективного и безболезненного перехода, мы рекомендуем постепенный (инкрементальный) переход от старых монолитных систем к SOA. Написание веб-сервисов для многих организаций является простейшим способом для построения слабосвязанной модели взаимодействия. Оно достигается за счет набора открытых стандартов, основанных на XML, например: WSDL, SOAP, UDDI — все они дают одинаковый подход для определения, публикации и использования веб-сервисов.Веб-сервисы развились из веб-приложений, однако на деле, они — упрощение веб-приложений: вместо того, чтобы предоставлять пользовательский интерфейс и обработку данных, они работают только с данными. Ответственность за отображение данных переходит клиентскому приложению. Однако стоит заметить, что многие системы используют веб-сервисы, но не называют себя SOA системами.
Наследованная система может быть обернута в SOA сервис и отвечать по протоколу HTTP или работать за прокси (который скорее gateway — прим.пер.), который переводит запросы на понятный ей язык. В конце концов, сообщение в HTTP это простой текст, который может быть обработан любой системой и на любом языке программирования.
Решение, основанное на SOA, дает возможность строить более гибкие приложения, но выбор конкретной технологии реализации зависит от нужд и возможностей вашей организации. Давайте рассмотрим наиболее вероятные технологические соображения для организации, желающей перевести свои бизнес-процессы на SOA.SOAP vs. REST Во время проектировки веб-сервиса, нам нужно определить набор правил для обмена информацией. Основными средствами для этого являются SOAP и REST [3].SOAP более старый протокол. Он был разработан как интернет совместимая альтернатива для таких отлаженных технологий как CORBA. Протокол SOAP может использовать различный транспорт (HTTP, SMTP и так далее), который дает дополнительную гибкость. Обмен данными происходит в формате XML, поэтому могут возникнуть некоторые сложности с производительностью, если объем пересылаемых данных высок. SOAP может быть использована с Web Services Security — стандартом для шифрования и подписания сообщений, который обеспечивает более безопасный обмен данными. [4]
REST более новый протокол, который использует HTTP в качестве транспорта, но он поддерживает несколько форматов данных (XML, JSON и так далее). В отличие от SOAP он основывается на специальных URL адресах, вместо разбора XML. Так как он не предполагает жесткой реализации, то он гибок в реализации, является более легковесным и в меньшей степени зависит от документации. Так же REST может использовать GET методы, когда SOAP реализован на POST.
Естественно, что выбор между REST и SOAP зависит от ограничений и нужд организации. SOAP протокол поддерживает на более глубоком уровне вопросы безопасности и обработки ошибок, поэтому многие крупные интернет магазины отдают ему предпочтение. Простота, производительность и свобода в реализации делают REST предпочтительным протоколом для тех, кто работает над взаимодействием интернет сервисов на уровне API.
Несмотря на то, что SOA подход может быть лучшей альтернативой для бесшовной интеграции корпоративных систем и решением головной боли с протоколами[5] и платформами, большинство людей вынуждены работать с существующей инфраструктурой. Нет идеального решения в вопросе модернизации старых систем к SOA, потому что всё дело в нюансах. Вам необходимо принять во внимание существующий в компании технологический стек для выработки оптимального решения перехода с учетом рисков и стоимости.План постепенного перехода с учетом эволюции (а не революции) систем предприятия должен быть разработан с учетом использования гибридных систем на пути к чистому SOA, так как ключевые бизнес-процессы завязаны на легаси системах. И есть несколько стратегий для конвертации их в SOA.
Первый подход заключается в простой замене текущей системы на новую или набор систем. В целом, это нормальный подход, если рынок предлагает готовый продукт, полностью удовлетворяющее вашим требованиям. Такое решение снижает затраты на поддержку, но значительно увеличивает стоимость будущих модификаций. (Все мы знаем, что в этом мире постоянны только изменения — прим. пер.)
Альтернативным подходом будет создание обёртки для старой системы, которая может предоставить доступ к существующим интерфейсам через веб-сервисы. В этом случае старый функционал «обёрнут» сервис слоем и «включён» в 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), мониторинг бизнес процессов, управление критичными данными, репозиторий. Все эти фичи позволяют реагировать на изменения более быстро. Очень сложно сравнивать такие пакеты друг с другом.
Очевидно, что лучший выбор всегда зависит от специфических нужд и сложностей процесса, и лучше такую задачу решать методом исключения начиная с простых вариантов. Сначала вы должны решить, может быть вам достаточно только интеграционного фреймворка. Например, если у вас только два приложения нуждаются в общении, или вы можете работать только с одним протоколом (REST), то можно задействовать простейшее решение в виде интеграционного фреймворка, несмотря на дефицит инструментария и поддержки. В противном случае, ESB может быть более подходящим вариантом. Если же не хватает и его, то стоит погрузиться в изучение более сложных пакетов интеграции.
Следующий шаг может быть в направлении более легкой интеграции вашего SOA решения с облачными сервисами. Облака предоставляют возможность получения ресурсов по запросу, а также уже содержат богатый инструментарий по хранению данных, созданию сервисов и обработке данных.
В целом, основным вызовом сегодня для бизнеса является интеграция с облачными сервисами. В этом контексте iPaaS (integration platform as a service) набирают популярность как подходящее решение для широкого спектра интеграционных задач. iPaaS — это набор облачных сервисов, которые позволяют пользователям создавать, управлять и организовывать интеграционные потоки для многих приложений или данных без установки специализированного оборудования или библиотек.
Рассматривая будущее, исследователи из компании Garther предсказывают что в 2016 году как минимум 35 процентов всех крупных и средних компаний будут использовать как минимум одно iPaaS решение в том или ином виде. Однако эксперты не говорят, что iPaaS заменит SOA. Традиционные решения с SOA будут востребованы для сценариев, где важна скорость обработки сообщений и идет интенсивный обмен данных между базами и бизнесами в корпорации.
Gold et al., «Understanding ServiceOriented Software,» IEEE Software, vol. 21, no. 2, 2004, pp. 71–77.
Jones, «Toward an Acceptable Definition of Service,» IEEE Software, vol. 22, no. 3, 2005, pp. 87–93.
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.
Louridas, «SOAP and Web Services,» IEEE Software, vol. 23, no. 6, 2006, pp. 62– 67.
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! Если вам есть о чем рассказать, мы ждем ваших историй!
