Service-Oriented Architecture and Legacy Systems

http://www.infoq.com/articles/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 дает надежность, а не скорость. Конечно есть альтернатива в виде JSON
  • Различные уязвимости в безопасности, связанные с процессом обмена данными между многими приложениями и системами.
  • Сложный процесс управления транзакциями связанный с взаимодействием логически разных систем.

Переход на сервис-ориентированную архитектуру не простой процесс. Предприятия, желающие перейти на 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 реализацию, может быть облегчён с помощью продуктов сторонних разработчиков. Но, как всегда это и бывает, все предложения отличаются по возможностям поддержки и сложности, так что правильный выбор жизненно важен. Вы можете разбить все решения на три группы в зависимости от сложности интеграции.

soalegacy01
  • Интеграционные фреймворки наиболее простой способ для формирования библиотек с определенным 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 может быть более подходящим вариантом. Если же не хватает и его, то стоит погрузиться в изучение более сложных пакетов интеграции.

soalegacy02

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

В целом, основным вызовом сегодня для бизнеса является интеграция с облачными сервисами. В этом контексте iPaaS (integration platform as a service) набирают популярность как подходящее решение для широкого спектра интеграционных задач. iPaaS – это набор облачных сервисов, которые позволяют пользователям создавать, управлять и организовывать интеграционные потоки для многих приложений или данных без установки специализированного оборудования или библиотек.

Рассматривая будущее, исследователи из компании Garther предсказывают что в 2016 году как минимум 35 процентов всех крупных и средних компаний будут использовать как минимум одно iPaaS решение в том или ином виде. Однако эксперты не говорят, что iPaaS заменит SOA. Традиционные решения с SOA будут востребованы для сценариев, где важна скорость обработки сообщений и идет интенсивный обмен данных между базами и бизнесами в корпорации.

Ссылки


  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_back

Если вам близка тематика статьи или вы хотите узнать больше о том, как правильно проектировать, поддерживать и работать с API, приходите на нашу конференцию API & Backend! Если вам есть о чем рассказать, мы ждем ваших историй!
  • +11
  • 15,3k
  • 6
GeekFamily
31,00
Компания
Поделиться публикацией

Похожие публикации

Комментарии 6

    0
    Конечно есть альтернатива в виде
    перечень потеряли.
      0
      Если про SOA через SOAP WebServices

      > Трудно реализовать асинхронное взаимодействие между сервисами

      поясните в чем трудность?
      можно делать через Callback WSDL а можно (и более правильно) через очередь + ESB

      > Сложно и трудоемко реализовать ответы в «реальном времени», потому что XML дает надежность, а не скорость.

      Смотря что подразумевать под «реальным временем». Если говорить про Java то проекты Axis2, Apache CXF добавляют довольно небольшие накладные расходы связанные с SOAP. Конечно все относительно и зависит от требований.

      Если про REST

      Проблема с REST в том что нет стандартизированного (= общепринятого) способа описания сервисов (аналога WSDL)
      Кто во что горазд (например есть «раздутый» Swagger). Нет возможности создать быстро клиента на основе опубликованного сервиса.
      Для каждого REST API надо писать своего клиента.

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

      По моему мнению правильным является сделать так 1) «обернуть» Legacy систему в SOA 2) сделать чтобы все взаимодействие с ней было через SOA 3) заменить или переписать систему не трогая сервисы т.о. связанные системы затронуты не будут.
        0
        Перед глазами такая вот Legacy корпорация, чего там только нет — начиная от Кобола и заканчивая Hadoop. Да, SOA тоже есть, но подавляющее большинство приложений написано 15+ лет назад и заняты тем, что пишут файлы друг другу. Работа, конечно, идет, но конца и краю этому не видно — лет на 20 еще хватит (а тогда уже и SOA устареет)
          +2
          SOA как таковая вообще бесполезна. Есть база данных или даже несколько. Базы данных — это наше все. Как они соединены через скольких посредников — это уже тема интеграторов. Многие вообще используют DBLink и радуются. Многие обмениваются файлами, обычно ночью.

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

          Технологии и их интеграция — не проблема. Webservices — не единственная кроссплатформенная технология. Есть CORBA, к базе данных есть коннекторы практически к любой платформе. Передать и получить данные не пробема — хоть через MQ, хоть через Socket, хоть через email. Нет коннектора — сделай shared directory. Файлы умеют читать все.

          Подталкивает к слабосвязанным системам, помогает работать со старыми системами.

          Сомнительная помощь, просто еще один посреднеческий уровень. Системы среднесвязаны на уровне контракта. SOAP/Http еще и подталкивает к сильной связанности, т.к. binding и адрес сервиса жестко прописывается в самом WSDL. Конечно, это можно (и нужно) обойти, но есть кадры, которые для этого меняют IP в hosts, а для импорта WSDL требуют задеплоить и запустить сервис.

          Повышает эффективность путем повторного использования сервисов, что снижает расходы и время разработки

          Теория. На практике каждый WSDL делается и затачивается практически для одного потребителя.

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

          Опять теория. Для доступа к базе данных между разными вызовами WS отсутствует целостность (кто-нибудь пробовал поднять транзакционный WS? это адище!). Фактически в большинстве случаев компоновка продьюсер-консумер 1:1. Особенно, если вы используете очереди JMS.

          Делает возможным сокращение расходов, связанных с поддержкой решения.

          Ложь и провокация! Придется оплачивать недешевый дополнительный уровень с комадной бестолковых бездельников. Использование SOA само по себе создает новые проблемы, которых бы не было без нее, начиная от постоянных ошибок в меппинге данных и кончая сложными отказами SOA-продуктов, за которыми приходится стучаться в службу поддержки. Один из недостатков SOA — огромные ресурсозатраты при сомнительном выигрыше. Решения SOA стоят занебесных цен (Oracle SOA Suite, IBM Websphere Business Integration). Специалисты по этим системам стоят дороже, нежели core-разработчики. Разработка, как ни странно, усложняется в разы, а тестирование систем — в десятки раз. Плюс, все решения глючные, неповоротливые и черезмерно навороченные.

          Можно разработать стандартный протокол общения между системами.

          Есть такой велосипед. Обычно добавляют хидеры для роутинга сообщения и адрес для callback. Однако всегда есть очень дорогой и понтовый «legacy систем», который будет класть на весь ваш SOA и протокол общения.

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

          SOA не предназначена для фронтендов. Это корпоративная архитектура. Для фронтендов обычно делают легкий бекенд.

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

          Вырезка из PowerPoint презентации… Что мешает делать это без SOA?
            0
            SOA не предназначена для фронтендов. Это корпоративная архитектура. Для фронтендов обычно делают легкий бекенд.


            Можно поподробнее??? Как быть если фронт системка должна данные получать из других систем/пинать их?

            С остальным более-менее согласен… Вот только базы данных это некая условность… А dblink и ему подобные вообще не поддерживаемое решение.
              0
              Обычно для фронтенда (под ним мы понимаем удаленного пользовательского клиента) делают бекенд, с которым он будет эксклюзивно общаться по специально заточенному для этого клиента интерфейсу. А уже бекенд в свою очередь разруливает запросы по корпоративным системам. Более того, чтобы ускорить работу и не напрягать системы бесполезными запросами, (коих больше 95%) зачастую бекенд содержит кеш всех требуемых клиентом данных, который обновляется асинхронно через месседжи. То есть по сути бекенд содержит копию данных корпоративных систем, зачастую в денормализированном виде.

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

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

            Самое читаемое