В Москве с 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 на десятке страниц. Исключения, возвраты, отмены, неверные результаты проверки ЭЦП, недоставленные квитанции, просроченные ключи… Матрица отдыхает (зато программисты продолжают работать)

), прежнее название - Axelot Datareon ESB, предназначена для построения распределённого информационного ландшафта предприятия. Программный продукт обеспечивает взаимодействие всех интегрируемых приложений в одном центре, объединяя существующие источники информации и предоставляя централизованный обмен данными между разными информационными системами.

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

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

Функциональные возможности

• Поддержка различных стандартов и сценариев интеграции
• Централизованное управление интеграционным ландшафтом с помощью экосистемы Eclipse
• Трансформация данных (многошаговые алгоритмы преобразования данных с контролем различных условий)
• Передача данных любого размера (вертикальное и горизонтальное масштабирование)
• Простая интеграция с продуктами на платформе «1С:Предприятие 8»
• Обеспечение безопасной передачи данных
• Диагностика и мониторинг состояния всей сети передачи данных

Решаемые задачи

• Передача данных между различными информационными системами (с маршрутизацией или «точка-точка»)
• Формирование единого информационного пространства в гетерогенных средах
• Построение распределённой системы на основании событийной модели в следующих вариантах:
  • построение приложений со сквозными бизнес-процессами на основании событийной модели;
  • создание системы с синхронизацией бизнес-приложений в различных информационных системах
• Получение масштабируемой архитектуры управления уровня предприятия/холдинга
• Развертывание системы обмена данными на транспортном уровне и на уровне бизнес-логики
• Делегирование задачи построения информационных потоков аналитическим отделам
• Уменьшение общей сложности интеграционной схемы и снижение требования к пропускной способности каналов
• Увеличение общей стабильности транспортного уровня передачи данных
• Снижение транзакционных издержек при обмене данными между различными подразделениями

2017

Axelot Datareon ESB 2.1.0.0

Решение AXELOT Datareon ESB вошло в список компетенций Gold Application Development - факт, подтверждающий высокое качество продукта и его совместимость с продуктами Microsoft .

AXELOT Datareon ESB предоставляет для бизнеса ряд ключевых преимуществ:

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

Основные возможности системы:

• Большое количество коннекторов к различным системам: 1С:Предприятие 8 , SOAP-сервисы, REST-сервисы, MS SQL , IBM DB2 , Oracle DB , PostgreSQL , SharePoint , OData, TCP, Siemens TeamCenter и другие;
• Механизм плагинов для самостоятельной разработки коннекторов;
• Поддержка различных языков программирования и технологий при разработке сценариев взаимодействия: 1С:Предприятие 8, JavaScript, T-SQL;
• Настройка многошаговых сценариев трансформации данных с использованием визуальных механизмов мэппинга и произвольных XSLT-преобразований;
• Работа с различными форматами данных (XML, JSON, XLS, DBF, CSV, Base64 и другие);
• Статическая и динамическая маршрутизация информационных пакетов;
• Высокая скорость взаимодействия и отказоустойчивость: пониженные требования к пропускной способности сети, балансировка нагрузки, изоляция информационных доменов, возможности мониторинга состояния узлов интеграции;
• Поддержка событийной модели, синхронные и асинхронные вызовы, гарантированная доставка;
• Изменение интеграционных сценариев систем-подписчиков (механизмов выгрузки/загрузки, трансформации и маршрутизации) в "горячем" режиме без необходимости их остановки (включая конфигурации на платформе 1С:Предприятие 8);
• Диагностика и мониторинг всех процессов интеграции, возможности отладки и трассировки информационных пакетов.

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

Серверные компоненты "AXELOT: ESB Сервисная шина данных" разработаны на языке С++. Администрирование и настройка "AXELOT: ESB Сервисная шина данных" осуществляется в среде разработки Eclipse и может выполняться совместно с разработкой систем на платформе "1С:Предприятие 8" в "1С :Enterprise Development Tools". "AXELOT: ESB Сервисная шина данных" является мультиплатформенной и поддерживает операционные системы MS Windows и Linux .

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

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

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

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

Заключение

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

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

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

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


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

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

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

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

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


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


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


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


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

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


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


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

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

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

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

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


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


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

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

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


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


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

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

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


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


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


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

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