Что такое корпоративная шина данных

Что такое корпоративная шина данных

Enterprise Service Bus (ESB) / Корпоративная сервисная шина (КСШ) = ПО, обеспечивающее централизованный и унифицированный обмен сообщениями между различными ИС предприятия. Подробнее в wikipedia.
Если в «дошинную» эпоху общепринятой концепцией была интеграция различных систем друг с другом напрямую, т.н. соединение «точка-точка», то с появлением шины — она становится главным транспортным узлом в интеграционной архитектуре предприятия, в определённом смысле объединяя в себе все API предприятия:

КСШ собой эволюционный виток архитектурной мысли в рамках сервисно-ориентированной архитектуры в «домикросервисную эпоху». Хорошо подходит для средних размеров предприятий с относительно небольшим количеством ИС (десятки).

Оглянувшись на свой и чужой опыт, можно извлечь несколько уроков использования КСШ:

1. Заклинаю, не надо совать в Шину бизнес-логику, проблем потом не оберётесь. Использовать Шину следует только как транспорт.
   Да и вообще идея вставлять бизнес-логику в вендорные решения и фреймворки — нарушение принципов DDD и заключение вашего предприятия в т.н. vendor-lock;
2. ESB могут стать «узким горлышком», когда множество команд других ИС ждёт доработок от команды ESB. Больше зависимостей —> больше общий TTM (time to market).
   Всё это может значительно усугубиться в ситуации, когда в вашей компании количество специалистов, знающих Шину — стремится к нулю.
3. На Шину со множеством адаптеров обязательно нужны автотесты, руками регресс десятков-сотен кейсов адаптеров не покроется, особенно если необходимость в регрессе возникает раз в несколько дней или чаще, ведь на Шине с большой связанностью постоянно будет что-то меняться. Вопрос: стоит ли «вешать» разработку и тестирование на вендора?
   Автотесты требуют всегда актуальных артефактов п.4;
4. Должен быть выстроен процесс сохранения и актуализации артефактов проектирования, разработки, тестирования Шины и всех ИС, работающих с Шиной. Нужны Архитекторы, и они должны быть «пишущие».

В основном это касается крупных ESB, на которые «нацеплены» большая часть ИС предприятия.
Если мы говорим о «небольших» шинах типа Kafka и RabbitMQ, то с ними всё гораздо проще, кроме того, они часто задействованы в микросервисной и service-mesh архитектуре, а также в смешаной архитектуре.

Источник

Шины Данных (Enterprise Service Bus, ESB)

Почему компании делают выбор в пользу Шины Данных

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

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

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

Enterprise Service Bus (ESB)

Архитектура ESB строится на 3 компонентах:

• набор коннекторов
• очередь сообщений
• платформа

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

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

К основным преимуществам современных ESB-решений относятся:

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

Пример действующего решения

К настоящему времени на рынке представлено более двух десятков шин данных, однако наибольшее распространение получили следующие решения:

• Integration Bus (IBM)
• Oracle Service Bus (Oracle)
• BizTalk (Microsoft)
• ActiveMatrix Service Bus (TIBCO)
• MuleESB (MuleSoft)
• JBoss Fuse ESB (Red Hat)

По результатам проведенного анализа различных Шин Данных нашей компанией был сделан выбор в пользу программного продукта JBoss Fuse. В число критериев входили такие вопросы как: наличие широкого спектра адаптеров (включая работу с web-сервисами), возможности маршрутизации и трансформации сообщений, оркестровка, поддерживаемые протоколы обмена, удобство администрирования, стоимость приобретения и поддержки. Данное решение по своим функциональным характеристикам не уступает аналогам от IBM, Oracle и Microsoft, но при этом доступно для бесплатного использования (лицензия приобретается только на поддержку).

На рисунке показан пример реализации web-сервиса, который по запрошенному идентификатору выдает из базы данных информацию о клиенте. Задача решена в инструменте редактирования JBoss Fuse, входящем в состав Jboss Fuse ESB.

Заключение

Внедрение Шины Данных в IT-ландшафт организации позволяет не только структурировать, привести к единому стандарту и упростить поддержку процедур обмена информацией между системами, но также снизить временные затраты на интеграцию новых подсистем и, как следствие, сократить стоимость поддержки и развития всей IT-инфраструктуры компании.

Источник

DATAREON ESB (корпоративная сервисная шина данных)

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

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

Программный продукт DATAREON ESB официально включен в единый реестр российских программ для электронных вычислительных машин и баз данных, которые могут закупаться государственными и муниципальными учреждениями ( https://reestr.minsvyaz.ru/ ).

Для интеграции 2-3 информационных систем в небольших компаниях DATAREON предлагает программный продукт, созданный на базе DATAREON ESB — DATAREON MQ.

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

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

Задачи, решаемые с помощью корпоративной сервисной шины данных

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

Преимущества корпоративной сервисной шины данных DATAREON ESB

Менеджеры DATAREON будут рады ответить на все вопросы по тел. +7(495)280-08-01. Также вы можете написать нам через форму

Источник

Что такое корпоративная шина данных

Среди лучших практик интеграции сложных информационных систем — построение логических витрин данных, а также создание централизованных инфраструктур обмена данными при помощи MDM-систем и корпоративных сервисных шин (ESB, Enterprise Service Bus). Наши решения, в том числе система АрхиГраф.MDM, пригодны для использования в составе операционной системы специального назначения Astra Linux Special Edition, а также Alt Linux.

Зачем нужна интеграционная шина?

Любая компания, использующая больше двух программных продуктов, работающих с пересекающимися наборами информации, знает, какова цена отсутствия связи между ними. Не синхронизированные списки клиентов или номенклатуры товаров и другой информации между ERP, CRM иными корпоративными приложениями, несут постоянные потери времени, ресурсов, репутации компании. Единственным правильным решением подобной проблемы является внедрение корпоративной сервисной шины (ESB), в связке с системой управления мастер-данными (MDM).

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

Внедрение интеграционной шины

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

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

Проекты по интеграции мы выполняем совместно с партнерами на основе решений IBM WebSphere MQ, Integration Service Bus, WSO2 Message Broker, Apache Synapse, а также шины «Бизнес Семантика».

Часто проект по внедрению интеграционной шины выполняется в рамках общего реинжиниринга информационной архитектуры предприятия.

Корпоративная сервисная шина — «бюджетный» подход к решению задач интеграции

Подготовлено: по материалам зарубежных сайтов
Перевод: Intersoft Lab

Продолжая знакомить читателя с различными подходами к интеграции, мы решили остановиться на относительно новой и весьма привлекательной технологии — корпоративной сервисной шине (Enterprise Service Bus, сокр. ESB).

Что же такое корпоративная сервисная шина и как она соотносится с рассмотренной в предыдущих номерах Журнала Клуба знатоков DWH, OLAP и XML интеграцией корпоративных приложений (EAI)? По сложившейся традиции сначала предоставим слово экспертам в данной области.

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

Чем же так привлекательна корпоративная сервисная шина? Прежде всего, своей относительной дешевизной. Продукты ESB, как правило позиционируются как доступные по цене, или, как говорят, «бюджетные», решения.

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

Говоря о достоинствах корпоративной сервисной шины, стоит привести слова вице-президента и члена исследовательского отдела компании Gartner Ройя Шульте (Roy Schulte): «Обычное программное обеспечение промежуточного уровня уже не может поддерживать новые приложения, которые используют сервис-ориентированную (Service Oriented Architecture, сокр. SOA) и управляемую событиями архитектуры (Event Driven Architecture, сокр. EDA), Web-сервисы и управление бизнес-процессами. Это и является основной причиной, почему архитекторы и менеджеры информационных систем должны усилить свои корпоративные информационные инфраструктуры с помощью ESB».

Ведущий аналитик Gartner выделяет группы поставщиков ESB. К первой группе он относит продукты ESB, которые позиционируются как «бюджетные» интеграционные решения, оптимально подходящие для поддержки композитных приложений и SOA. Вторая группа — это продукты, предназначенные для рынка Web-сервисов, наконец последние — это программные средства, обеспечивающие поддержку EDA. По оценке Ройя Шульте, на протяжении следующих лет произойдет уплотнение рынка ESB, что объясняется усиливающимся спросом на Web-сервисы и многопротокольные и управляемые событиями решения.

Интересно, что в ряде компаний ESB трактуют не как категорию продуктов, а как архитектуру. Например, в IBM корпоративную сервисную шину считают «архитектурной моделью» (architectural pattern).

Таким образом, можно констатировать, что до сих отсутствует четкое определение, что такое же ESB. Фактически, дискуссия разворачивается вокруг двух вопросов:

Является ли ESB архитектурой (причем такой, которую не нужно даже стандартизировать), «односторонним подходом» или же самостоятельным продуктом.

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

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

На данный момент на обозначенные вопросы нет окончательных ответов.

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

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

ESB и XML

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

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

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

• Синтаксический разбор всего документа: как правило, требуется разбирать документы целиком, даже если для маршрутизации и фильтрования необходимо извлечь только его фрагмент. Если документы становятся большими, время ожидания увеличивается.
• Повторное сканирование. Документы часто разбираются повторно — на каждом этапе бизнес-процесса, другими словами, одни и те же документы могут сканироваться несколько раз. Поскольку такая практика чрезвычайно ресурсозатратна, ухудшается производительность и пропускная способность.

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

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

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

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

В чем отличие сервисной шины предприятия(ESB) от брокеров сообщений (например RabbitMQ)?

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

Заключение

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

Действительно, поддержка открытых стандартов (и особенно XML) позволяет получить недорогое, но эффективное решение и гарантирует быструю окупаемость инвестиций, т.е высокий показатель ROI. Как отмечает вице-президент Консорциума по интеграции Стив Крэггс (Steve Craggs), «ESB является базисом для интеграции, обеспечивает гибкую и настраиваемую среду, которая позволяет плодотворно, успешно и планомерно реализовывать интеграционные проекты».

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

Публикации

1. Бесс Голд-Бернштейн (Beth Gold-Bernstein) «Нужна ли вам корпоративная сервисная шина» (Is an ESB Critical To Your Future?).
2. Найджел Томас (Nigel Thomas) и Уоррен Бакли (Warren Buckley) «Появление корпоративной сервисной шины» (Rise of the ESB).
3. Материалы, опубликованные на сайте Консорциума по интеграции (Integration Consortium).

Что такое 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 на нескольких примерах.

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

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

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

Сервисная шина предприятия

Программный продукт DATAREON ESB официально включен в единый реестр российских программ для электронных вычислительных машин и баз данных, которые могут закупаться государственными и муниципальными учреждениями ( https://reestr.minsvyaz.ru/).

Для интеграции 2-3 информационных систем в небольших компаниях DATAREON предлагает программный продукт, созданный на базе DATAREON ESB — DATAREON MQ.

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

Задачи, решаемые с помощью корпоративной сервисной шины данных

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

Преимущества корпоративной сервисной шины данных DATAREON ESB

Функциональные возможности
Цены и лицензионная политика
Техническая поддержка и сопровождение
Сравнительный пример интеграции

Менеджеры DATAREON будут рады ответить на все вопросы по тел. +7(495)280-08-01. Также вы можете написать нам через форму обратной связи.

Корпоративная сервисная шина DATAREON ESB.

Зачем разработчикам нужна Enterprise Service Bus?

Назначение классов и маршрутов передачи данных. Урок 4

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

Урок 4 посвящен работе с объектами «Класс информационных пакетов» и «Маршруты передачи данных», настройке интеграции номенклатуры и сегментации потоков данных.
Сервисная шина данных DATAREON ESB построена на компонентной архитектуре со слабыми связями, где интегрируемые системы работают независимо друг от друга, а для обработки сообщений не требуется сведения об источниках или получателях сообщений.
Для обеспечения такого алгоритма работы все передаваемые данные должны отвечать общим требованиям и правилам, вне зависимости от системы-источника или приемника.
Для типизации и описания структуры сообщений вводятся классы информационных пакетов.
Маршруты используются для определения получателей сообщения, а также для сегментации потоков данных.

Источник