Что такое ESB и SOA

An excellent description of system-of-systems thinking
Nick Coghlan, Core Python Developer

Also available in Català, Deutsch, English, Français, italiano, Nederlands, Português, Türkçe and 中文.

Аббревиатура ESB и связанная с ней SOA - могут стать причиной путаницы. ESB расшифровывается как Enterprise Service Bus. SOA - Service Oriented Architecture.

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

Вся правда

Давайте представим, что происходит, когда Вы входите в фронтенд-приложение Вашего банка:

  1. Показывается Ваше имя
  2. Отображается баланс Вашего счета
  3. Показываются Ваши кредитные и дебетовые карты
  4. Там может быть список Ваших паевых инвестиционных фондов
  5. Вы также получаете список предварительно рассчитанных ссуд, в которых Вы можете быть заинтересованы

С большой долей вероятности можно сказать, что все эти кусочки информации принадлежат к разным системам и приложениям, каждое из которых предоставляет данные через какой-то интерфейс (HTTP, JSON, AMQP, XML, SOAP, FTP, CSV или любой другой):

  1. из CRM, работающей под управлением Linux и Oracle
  2. из COBOL системы, работающей на z/OS мейнфрейме
  3. говорят, эта информация поступила из системы на мейнфрейме, но эти ребята слишком молчаливы, чтобы сказать что-то кроме того, что они предпочитают CSV всему остальному
  4. из смеси PHP и Ruby, работающих на Windows
  5. из PostgreSQL, Python и Java, работающих на Linux и Solaris

Вопрос состоит в том, как Вы можете заставить фронтенд-приложение общаться с системами 1-5? Ну, никак.

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

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

Заметьте, мы даже не показали ни одного высокоуровневого процесса (App1 вызывает App2 и либо App3, либо App5, в зависимости от того, был ли предыдущий ответ от App6 успешным, для того, чтобы App4 могло позже взять данные, которые были сгенерированы App2, но только если App1 не запрещает этого и т. д.).

Также, заметьте, мы не говорим о серверах - каждая из систем может работать на 10 физических серверах, так что как минимум 60 физических компонентов будут обмениваться информацией друг с другом.

Тем не менее, некоторые вопросы становятся очевидными.

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

Если Вы думаете, что можете управлять 6-ю приложениями, как на счет 30?

А сможете справиться с 400? А с 2000? Каждое приложение может быть своей уникальной экосистемой, требующей десятка серверов или других устройств для работы, так что это - 20 000 движущихся частей, распределенных по континентам с всяческими техническими и культурными границами. И все эти части постоянно и без остановки хотят обмениваться сообщениями все время без каких бы то ни было простоев, вообще. (Мы избавим Вас от схемы.)

Есть отличное название для такой ситуации - беспорядок.

Как Вы можете исправить ситуацию?

Первым делом стоит признать, что ситуация вышла из-под контроля. Это позволяет искать решение без ощущения сильного чувства вины. Хорошо, это произошло, Вы не знали, как сделать лучше, но есть шанс, что все это можно исправить.

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

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

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

Если данная функциональность системы удовлетворяет этим трем требованиям:

  • I nteresting (интересная)
  • R eusable (многократного использования)
  • A tomic (атомарная)

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

Давайте обсудим подход IRA на нескольких примерах.

Переменная Заметки
Окружение CRM-система электрокомпании
Функциональность Возврат списка клиентов, которые были активны на портале самообслуживания в III квартале 2012
Это интересно? Да, достаточно интересно. Это можно использовать для генерации всех видов полезных отчетов и статистики.
Это можно Нет, не очень. Не смотря на то, что это позволяет создавать
многократно высокоуровневые конструкции, такие как статистика за весь год,
использовать? явно видно, что это нам не понадобится в 2018.
Это атомарно? Скорее всего, да. Если уже существуют похожие сервисы для других кварталов, то можно будет просмотреть весь год.
Как сделать из этого IRA?
  • Заставить получать произвольные даты начала и конца периода, вместо указания только квартала.
  • Заставить получать произвольные приложения, не только портал. Дать возможность указывать приложение для получения информации в качестве входного параметра.
Переменная Заметки
Окружение сайт электронной коммерции
Функциональность Возврат каждого кусочка информации, который когда-либо был собран для указанного пользователя
Это интересно? В общем, да. Если у Вас есть доступ к целому - Вы всегда сможете выбрать, что Вам нужно.
Это можно Как ни странно, не совсем. Будут всего-лишь несколько
многократно приложений, если вообще будут, которым будет интересно
использовать? использовать абсолютно каждый кусочек информации.
Это атомарно? Однозначно нет. Этот монстр функциональности обречен быть логически составленным из десятков меньших частей.
Как сделать из этого IRA?
  • Разделить на несколько меньших частей. Подумайте, что описывает покупателя - у них есть адреса, телефоны, любимые продукты, предпочтительные методы связи с ними и так далее. Каждый из этих пунктов должен быть превращен в независимый сервис.
  • Используйте ESB для создания составных сервисов из атомарных.
Переменная Заметки
Окружение Любая CRM-система где угодно
Функциональность Обновление колонки CUST_AR_ZN в таблице C_NAZ_AJ после того, как кто-то создал учетную запись
Это интересно? Абсолютно неинтересно. Это внутренняя функция CRM-системы. Никто в своем уме не захочет иметь дело с такой низкоуровневой функциональностью.
Это можно Да, вероятно. Учетная запись может быть создана через
многократно несколько каналов, так что это кажется чем-то многократно
использовать? используемым.
Это атомарно? Кажется, да. Это простое обновление одной колонки в таблице.
Как сделать из  
этого IRA? Даже не пытайтесь сделать из этого сервис. Это неинтересно. Никто не хочет думать о конкретных колонках и таблицах в одной системе. Это сложная деталь CRM-системы и, даже не смотря на то, что это можно многократно использовать и это атомарно, из этого не стоит создавать сервис. Это Ваша и CRM, ответственность думать об этом, не заставляйте других нести ее тоже
Переменная Заметки
Окружение Оператор мобильной связи
Функциональность Пополнение карты предоплаченной связи в биллинге
Это интересно? Чрезвычайно. Все хотят использовать это, через текстовые сообщения, IVR, IM, порталы, подарочные карты и т. д.
Это можно Да. Это может принимать участие во многих высокоуровневых
многократно процессах.
использовать?  
Это атомарно? Да, с точки зрения вызывающего приложения, карта может быть пополнена, либо нет. То, что биллинг реализует это через серию шагов - не важно. С точки зрения бизнеса это атомарно, это - неделимый сервис, предоставляемый биллингом.
Как сделать из Это уже IRA.
этого IRA?  

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

Доступность сервисов в ESB и SOA

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

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

Так что, если, как в схеме вверху, у Вас 8 систем — тогда у Вас 16 интерфейсов (по одному в каждое направление) для создания, обслуживания, управления и обеспечения.

Без ESB у Вас было бы 56 интерфейсов для создания и управления (допуская, что каждая система общается с любой другой).

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

Один этот факт должен побудить Вас рассмотреть внедрение ESB.

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

Когда Вы станете “дышать” IRA-сервисами на регулярной основе, Вы сможете начать думать о составных сервисах.

Помните сервис “дайте-мне-все-что-можете-про-этого-клиента”, представленный выше?

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

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

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

Это потребует времени, терпения и скоординированных усилий, но это вполне выполнимо.

Но берегитесь...

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

В лучшем случае попытка спрятать что-то под ковер, как в схеме внизу, не приведет ни к чему:

Ваши IT-ребята будут ненавидеть систему и, хоть поначалу менеджеры будут терпеть ESB в качестве нового решения, впоследствии оно станет посмешищем. “Что, это та самая новая серебряная пуля? Хахаха.”

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

Так, получается, ESB только для банков и подобных им?

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

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

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

Все, что требует интеграции в понятном, четко определенном окружении, вполне вероятно хорошо подходит для ESB сервиса. Но, как всегда, решение о том, действительно ли что-то подходит для интеграции приходит с опытом. Само собой, команда Zato может помочь.

Но я слышал, что SOA это XML, SOAP и веб сервисы

Да, некоторые люди хотели бы, чтобы вы верили именно в это.

Если люди или вендоры, с которыми Вы работали, отправляли закодированный в BASE64 CSV-файл в защищенном посредством SAML2 SOAP-сообщении, тогда вполне понятно, откуда у Вас сложилось такое впечатление.

XML, SOAP и веб сервисы - имеют свои сценарии использования, но как и все - они могут быть неправильно использованы.

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

Если архитектор проектирует прекрасное здание, он не может слишком сильно повлиять на цвет интерьера.

Так что нет, SOA - это не XML, SOAP и веб сервисы. Они могут быть использованы, но они лишь часть, а не основа.

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

Дальше - больше

Эта глава покрывает только самые основы, но тем не менее должна дать четкое понимание как должны выглядеть ESB и SOA и что требуется для достижения успеха.

Другие темы, не затронутые здесь, включают (но не ограничены):

  • Как получить поддержку от менеджеров для введения ESB
  • Как собрать SOA-архитекторов и аналитические команды
  • Представление канонической модели данных (Canonical Data Model - CDM) в организации
  • Ключевые показатели эффективности (Key Performance Indicators - KPI) - теперь, когда у Вас есть общий и унифицированный метод предоставления сервисов между системами, Вы должны начать наблюдать и анализировать, что на самом деле Вам предоставляется
  • Управление бизнес-процессами (Business Process Management - BPM) - как и когда выбрать BPM-платформу для управления сервисами (ответ - не слишком скоро, сначала познакомьтесь с тем, как строить приятные и полезные сервисы)
  • Что делать с системами без API? К примеру, должна ли ESB получить прямой доступ к их базам данных (ответ - по разному, золотого правила нет)

Так что же такое Zato?

Zato - ESB и сервер приложений, написанный с использованием Python и может быть использован для построения промежуточных и бэкенд-систем. Это программное обеспечение с открытым исходным кодом с коммерческой поддержкой и поддержкой сообщества. И Python - язык программирования, известный своей простотой и эффективностью.

Использование Python и Zato позволяет увеличить производительность и тратить меньше времени впустую.

Zato был написан прагматиками для прагматиков. Это не еще одна наспех сооруженная вендором система на волне ESB/SOA шумихи.

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

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

Увидимся в здесь!