Esb шина данных. Подходы к интеграции приложений Enterprise Service Bus. Подход "от реализуемых процессов"

09.02.2020

ESB (Enterprise Service Bus) - дословно можно перевести как «сервисная шина предприятия». ESB описывает вполне реальный программный продукт, в задачи которого входит упрощение вызова службы за счет управления всеми взаимодействиями на пути от потребителя службы к поставщику и обратно. Двумя наиболее часто упоминаемыми возможностями ESB являются преобразование сообщений и их маршрутизация. На шину ESB в архитектуре SOA возложена важнейшая задача обеспечения взаимодействия систем из слабосвязанных сервисов в сети. Аналитики Gartner определяют ESB как новый тип программного обеспечения промежуточного уровня, который объединяет функциональные возможности других уже существующих типов промежуточного обеспечения. Корпоративная сервисная шина поддерживает Web-сервисы, реализуя протокол SOAP (Simple Object Access Protocol, Простой протокол доступа к объектам) и используя язык WSDL (Web Services Description Language, Язык описания Web-сервисов) и спецификацию UDDI (Universal Description, Discovery and Integration, Универсальное описание, обнаружение и интеграция).

Основные функции ESB

Обеспечение интерфейсов взаимодействия
Отправка сообщений и маршрутизация
Преобразование данных
Сенсоры событий
Управление политиками

Архитектура ESB

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

Достоинства и недостатки

Достоинствами ESB является:

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

К числу недостатков ESB относят:

Сложность реализации
Требует больших ресурсов.

Разработка Enterprise Service Bus

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

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

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

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

Шлюз служб

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

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

Web-службы шлюза, а точнее их прокси-службы являются также обнаруживаемыми. Шлюз дает такую возможность в виде UDDI -службы. Чтобы найти адрес вызова службы потребитель подает запрос в UDDI-службу шлюза список провайдеров необходимой WSDL -операции и получает обратно адрес прокси-службы шлюза для этой операции.

Шина сообщений

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

Если в этот момент провести аудит IT-инфраструктуры, типичный диагноз будет выглядеть примерно так:

1) Существующая IT-инфраструктура содержит слишком много взаимосвязей (подчас скрытых и плохо документированных) между системами и, следовательно, предполагает множество согласований и доработок при внесении любых, даже минимальных изменений.

2) Отсутствует единое контролирующее звено, ответственное за актуализацию и предоставление данных из различных информационных систем.

3) Отсутствует контроль процессов обмена: нет единой среды обмена данными между информационными системами.

4) Присутствует «Технологический зоопарк»: многообразие информационных систем и применяемых протоколов обмена данными, множество коннекторов (зачастую разработанных под заказ или самостоятельно) и т.п.

Решение комплекса подобных проблем – в переходе к построению IT-инфраструктуры на основе концепции сервис-ориентированной архитектуры (Service Oriented Architecture, SOA), ключевым элементом которой является Интеграционная сервисная шина. Шина – это программное обеспечение, позволяющее объединять большое число платформ и приложений, а также организовать взаимодействие между ними на основе сервисов. При этом технологии, на которых реализованы системы и их сервисы не имеют значения, это может быть JAVA, .NET или другая платформа.

Интеграционная шина, как правило, предоставляет следующие функции:

Преобразование сообщений, а также их передача, алгоритмическое перенаправление, постановка в очередь и отслеживание;

Работа с сообщениями в режимах: синхронном, асинхронном, «точка-точка», «публикация-подписка»;

Поддержка XML и SOAP сообщений;

Возможность подключения множества систем через готовые адаптеры и API для написания новых адаптеров;

Оркестровка (автоматическое размещение, координация и управление) служб.

Концептуально архитектура с использованием Интеграционной сервисной шины выглядит так:

Рисунок 1 Архитектура с использованием интеграционной шины

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

Внести данные клиента
Проверить, существует ли запись о данном клиенте
Получить список счетов клиента
Получить список сервисов, которыми пользовался клиент
Получить агрегированные данные по истории выплат по кредитам
Получить данные для отчета
Получить баланс счета
Рассчитать кредитный рейтинг
Сформировать отчет для рассмотрения менеджером
Обновить данные по счету
Сформировать уведомление для клиента

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

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

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

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

Рисунок 2 ИТ-архитектура банка до и после внедрения шины

В настоящее время на рынке интеграционных шин выбор достаточно широк. Представлены как коммерческие системы, так и продукты с открытым исходным кодом. Среди производителей интеграционных шин – лидеров по внедрениям в России можно выделить IBM и Oracle; в число зарубежных лидирующих вендоров можно включить TIBCO.

Рассмотрим внедрение интеграционных шин в нескольких крупных международных банках.

Chinatrust Commercial Bank (Коммерческий банк Чайнатраст) использует интеграционную шину для поддержки своих продуктов и сервисов. Сервис-ориентированная архитектура на основе интеграционной шины объединяет более семидесяти систем на множестве платформ, таких как: автоматизированная банковская система, сетевой банкинг, ипотечная система, лотерейная система, система автоматизации рабочих процессов, интерактивное голосовое меню и т.д. В режиме реального времени стали доступны такие сервисы, как: агрегация данных, сводка по счету, входящие и исходящие переводы, трансферы, уведомления (задействован функционал событийно ориентированных коммуникаций) и другие. Расходы на интеграцию новых систем снизились в среднем на 30..40%.

В настоящее время интеграционная шина банка поддерживает 100 000 ежедневных транзакций в корпоративном секторе и 50 000 в ритейле. Количество транзакций онлайн банкинга возросло с 150 000 до 1 200 000 в сутки.

Сингапуро-малазийский банк OCBC недавно поставил себе цель в пятилетний срок повысить эффективность работы на 25% и снизить затраты на разработку новых программных интерфейсов на 30%. Первый сервис на основе SOA был запущен в 2006 году. Через шесть месяцев работало 116 единичных сервисов, каждый из которых пригоден к использованию в составных сервисах. 50 единичных сервисов являлись частью нескольких составных. Для поддержки интеграционных процессов банк создал Центр Интеграционных Компетенций. В OCBC полагают, что для достижения заявленных целей SOA играет ключевую роль.

В Японии конкуренция в области интернет-банкинга чрезвычайно высока. Банк Sumishin Net Bank, Ltd. поставил целью предложить на рынок широкий набор продуктов за более короткий промежуток времени, чем прочие финансовые институты. Для достижения этой цели банку необходимо было соответствовать строгим техническим стандартам, накладываемым на японский банковский сектор и одновременно с этим развивать конкурентные преимущества. Была разработана сервис-ориентированная архитектура с использованием десяти программных продуктов, в том числе интеграционной шины. Всего лишь в течение 18 месяцев после запуска новой линейки услуг в банк было вложено ориентировочно 600 млрд. йен (около $6 млрд.), открыто 400 000 счетов. Была достигнута невероятная гибкость в добавлении новых сервисов. Существенно снизилась стоимость их разработки.

В России интеграционные шины применяются на многих крупных предприятиях, в том числе операторах связи, банковской сфере, а также в комплексе систем электронного правительства Российской Федерации. Внедрение интеграционных шин, как правило, ведется системными интеграторами. В частности, наша компания АМТ-ГРУП, входящая по данным cnews.ru в Топ 20 российских компаний – поставщиков IT услуг для банков, имеет успешный опыт работы с интеграционными шинами и их внедрения в разных сферах деятельности, включая банковский сектор. Наши специалисты имеют богатый опыт создания сервис-ориентированных архитектур на основе интеграционных шин, включая аудит бизнес-процессов и их последующую автоматизацию, создание коннекторов для интегрируемых систем и оптимизацию рабочей среды.

В статье использованы материалы из открытых источников:
http://www.tibco.com/multimedia/ss-ctcb_tcm8-15110.pdf
http://www.eawriter.com/images/case_studies/TIBCO_2.pdf
http://www-01.ibm.com/software/success/cssdb.nsf/CS/JSTS-7V4BWP?OpenDocument&Site=corp&cty=en_us

Оценить:

4 15

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

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

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

Интеграция по типу «точкаточка»

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

Интеграция «точка-точка»

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

Интеграционный «фарш»

Единая сервисная шина

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

Основными компонентами, составляющими современную сервисную шину, являются:

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

Преимуществами использования единой сервисной шины можно назвать:

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

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

Enterprise Service Bus

Управление бизнес-процессами

Существенная доля интеграционных сценариев подразумевает, что в информационный обмен вовлекаются не только приложения, выступающие в роли источников или приемников информации, но и люди - сотрудники организации, выполняющие различные задания или принимающие решения. В этом случае мы можем говорить о выходе за рамки «чистой» интеграции и появлении в фокусе нашего внимания новой сущности - бизнес-процессов, а в требованиях к интеграционной платформе - новой функциональности по управлению бизнес-процессами (Business Process Management, BPM). При наличии BPM-требований интеграционная платформа должна предоставить в распоряжение разработчика:

средство визуального проектирования бизнес-процессов - оптимально, чтобы этими средствами могли воспользоваться люди, далекие от ИТ, - например бизнес-аналитики или методологи. Кроме того, чрезвычайно полезным является возможность переноса моделей бизнес-процессов из специализированных средств моделирования в среду разработки. Это же средство должно давать возможность проектировать формы заданий для участников процессов, причем максимально ограждая разработчиков от программирования;
среду исполнения бизнес-процессов - специальный движок, обеспечивающий обработку бизнес-правил, передачу заданий между пользователями и информационными системами в соответствии с разработанными моделями бизнес-процессов, а также обработку исключительных ситуаций (например, превышения исполнителем времени, отведенного для выполнения задания);
портал участников бизнес-процессов - специализированный портал, позволяющий пользователям запускать процессы, участвовать в них, контролировать ход запущенных процессов и осуществлять административные воздействия в соответствии с установленными для них правами;
средства мониторинга и контроллинга. Возможность оперативного и ретроспективного анализа протекания бизнес-процессов - важная часть любой платформы BPM.

На данный момент многие производители ПО склонны объединять BPM-среду и интеграционную шину в единую платформу промежуточного ПО, убирая существовавшее несколько лет строгое разделение между BPM-системами и средствами для интеграции приложений. Такой подход очень прогрессивен. Некоторые вендоры идут еще дальше и присоединяют к платформе профессиональные средства для моделирования бизнес-процессов. Пионером в этом является компания Software AG, предлагающая решение, объединяющее в себе известное средство моделирования ARIS Platform и интеграционную/BPM среду webMethods.

Комплексное использование интеграционной платформы

Предложения на рынке

На текущий момент можно выделить три группы предложений ПО для построения ESB. Эти группы разнятся как по цене, так и по предлагаемой функциональности.

Первая группа - предложения от фирм, чьи продукты лидируют в исследованиях аналитических агентств по всем обозначенным в статье категориям (ESB, SOA Governance, BPM, B2B). В эту группу входят:

IBM с линейкой продуктов WebSphere;
Software AG c интеграционной платформой webMethods;
Oracle с целой серией предложений;
Tibco с линейкой Business Integration.

В принципе, тем, кто не любит компромиссы, можно выбирать любого из этих производителей - все перечисленные компании предлагают полноценные линейки продуктов (правда, в случае с Oracle не всегда понятно, о каком именно продукте идет речь, поскольку после покупки ряда компаний Oracle предлагает сразу несколько продуктов, не всегда в достаточной степени интегрированных между собой). Немного особняком стоит Tibco, так как размер этой компании гораздо меньше размера остальных участников данной четверки, что может вызвать некоторые сомнения в ее стабильности. Software AG - пока не очень известный на российском рынке производитель, но у платформы webMethods, которая является сегодня ключевым предложением этой компании, большой потенциал. IBM и ее продукты знают и используют уже очень многие предприятия, но у некоторых из них возникают претензии по стоимости самого внедрения и обслуживания системы.

Вторая группа предложений - это компании, сконцентрированные в основном на «чистом» ESB-функционале и достигшие здесь успеха. В эту группу попадают: Sun (Glassfish), Progress (Sonic) и Fujitsu.

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

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

Заключение

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

задумывайтесь о построении интеграционного решения, не дожидаясь, когда проблемы взаимодействия приложений прижмут вас к стенке. Чем больше завал, тем сложнее его разгребать;
тщательно подойдите к выбору платформы. Ищите вендора, который удовлетворяет вас по всем позициям, благо сейчас есть из чего выбрать. Вас должны интересовать и технологические параметры платформы, и методологические аспекты внедрения;
думайте о перспективе. Функциональные требования, которые осознаются вами сейчас, могут существенно измениться через год, и если платформа не будет их удовлетворять, то вам придется «переезжать» на другую. А один переезд, как известно, равен двум пожарам.

На мой взгляд можно выделить два подхода к построению интеграционной шины предприятия:

"от интегрируемых систем";

"от реализуемых процессов".

Давайте рассмотрим данные подходы подробнее.

Подход "от интегрируемых систем"

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

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

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

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

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

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

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

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

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

Подход "от реализуемых процессов"

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

У данного подхода есть следующие плюсы:

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

Трудоемкость реализации как асинхронного, так и синхронного обмена примерно одинакова.

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

У данного подхода есть следующие минусы:

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

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

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

Выбор подхода осуществляется по следующему алгоритму:

Получить от аналитиков список и описание интегрируемых систем и типов сообщений.

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

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

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

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

Понравилось сообщение -

В Москве с 1958 года существовала 3-я улица Строителей, но в 1963 году её переименовали - теперь это улица Марии Ульяновой, а дом 25 по этой улице - хрущёвская пятиэтажка. В Ленинграде (Санкт-Петербурге) 3-ей улицы Строителей не существовало никогда…

Я снова про интеграцию приложений. Читал сегодня отечественный стандарт межведомственного документооборота ГОСТ Р 53898-2010 И стандарт вроде бы «правильный» на XML-е писанный и поля там всякие полезные на 53-х страницах приведены и все дела. Помнится, в конце прошлого века я всячески ратовал за появление стандартов электронных сообщений на страницах журнала Компьютера в заметке Фактор Internet в развитии систем «клиент-банк» В конце прошлого века все выглядело оптимистичней, чем в начале нынешнего. Дот-комы еще не рухнули, небо было выше, трава зеленее, социальные сайты вызывали доверие, а Филдинг еще не защитил диссертацию с названием Representational State Transfer. Что же случилось за десять с небольшим лет и почему идея стандартизации формата электронного документа больше меня не прикалывает? Да ничего важного, просто парадигма интеграции приложений изменилась.

Как это было раньше? Один банк отправлял другому электронное сообщение (Уж извините, я тогда в Инкомбанке работал, потому про банки буду рассказывать). Второй банк сообщение получал и отправлял на него квитанцию. Все это десять раз шифровалось, заверялось цифровой подписью, в квитанцию включалась хеш-функция исходного сообщения … номера входящих и исходящих, отметки времени (тоже, кстати, криптографические) и т.д. и т.п. Наиболее обсуждаемый вопрос тех лет, а нужно ли на квитанцию формировать квитанцию о получении квитанции и что делать, когда квитанция не доставлена. В общем, страшно вспомнить до какого уровня сложности можно довести процесс синхронизации состояний множественных виртуальных образов одного реального документа. С бумагой было проще. По крайней мере, до изобретения ксерокса.

Возвращаемся в современность. Если очереди сообщений существовали для того, чтоб безопасно и гарантированно сообщения доставлять, то сервисная шина появилась для того, чтоб обмен сообщениями исключить. И не надо мне рассказывать, что эта самая шина как раз и осуществляет обмен сообщениями. Я это знаю, мы и сами так делаем, только это не очень правильно. Изначальная идея сервисной шины, тем более Enterprise Service Bus (ESB) состоит не в том, чтоб передавать сообщения, а в том, чтоб любое приложение не заботилось о необходимости создания своего локального экземпляра объекта. Смысл сервиса в том, чтоб всегда можно было такой объект получить. Нужен вам документ – вбили URL и методом HTTP GET документ получили и почитали. Захотели документ изменить – по тому же самому URL, методом HTTP PUT документ изменили. POST-ом добавили, DELETE-ом удалили, ну что может быть проще? Присвойте вы документу URL. Воспользуйтесь протоколом в стиле WebDAV чтобы взять документ, поработать и в новом статусе вернуть на его место, то самое, определенное в качестве мастер-копии, т.е. на тот же URL с которого взяли

Иначе – апокалипсис. Квитанции и уведомления об изменении статуса – это еще полбеды. Необходимость одинаково толковать поля документов, а для этого синхронизировать справочники – вот это беда. Третья улица строителей в Москве и 3-я улица строителей в Питере, как это известно из главного новогоднего фильма, далеко не одно и то же. Пожалуй, единственный справочник одинаково трактуемый в разных ведомствах это григорианский календарь. И то, я до конца не уверен. Или другой пример — моё имя в загранпаспорте не совпадает с моим же именем на британской визе, вклеенной в тот же загранпаспорт. В паспорте написано MAXIM, а в визе — MAKSIM. Я из-за этого границу пересекать боюсь 🙂 Прибавим к этому различие наборов состояний документа в разных системах, разные графы переходов, составные документы, включающие в себя набор других документов, электронные конверты и пр. Мы получаем задачу невероятной комбинаторной сложности. А если документ не в одно ведомство пойдет, а сразу в несколько? В одном его исполнят, в другом отвергнут, в третьем – потеряют. Потому процессные человечки очень скоро добавят к этому документу маршрут, лаконично выраженный в нотации BPMN на десятке страниц. Исключения, возвраты, отмены, неверные результаты проверки ЭЦП, недоставленные квитанции, просроченные ключи… Матрица отдыхает (зато программисты продолжают работать)

Похожие статьи: