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

Видео:Корпоративная сервисная шина данных DATAREON ESB. Знакомство с объектами ESB. Урок 2Скачать

Сравнение ESB-решений, популярных на российском рынке.

Часть 2: особенности систем

Продолжаем цикл статей о ESB-системах, популярных на российском рынке.

В прошлой статье мы рассматривали, как в системах Talend, Mule, Red Hat Fuse и WSO2 реализованы компоненты ESB-слоя: студия, брокеры сообщений, мониторинг, логирование. Теперь подробнее остановимся на том, что представляет собой каждая из этих систем, как выглядит их интерфейс, каковы свойственные им плюсы и минусы в разработке и поддержке интеграций. В дополнение мы поделимся собственными впечатлениями от реализации каждой из этих систем.

Видео:Вебинар "InterSystems IRIS как сервисная шина предприятия (Enterprise Service Bus)"Скачать

Зачем в проекте ESB: техническая сторона вопроса

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

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

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

Плюс команде разработки придётся делать «обвязку» системы, чтобы контролировать работоспособность интеграции. А это непростая и объёмная задача. Нужно не только разработать интеграцию, которая работает без сбоев, но и дать команде поддержки понятные регламенты работы с теми сбоями, которые всё же могут возникнуть.

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

Второй вариант — передача данных через интерфейс API или, к примеру, GraphQL. Тут есть нюанс: API, который система использует для обмена данными с внешним миром, пассивен. Система может только отвечать на запросы — отдавать данные вовне или изменять их по «инициативе» другой системы.

Видео:Плюсы и минусы сервисной шины данных I Enterprise service bus (ESB) I kt.teamСкачать

Путешествие в мир сервисных корпоративных шин на IBM WebSphere ESB

Данной статьей хочется открыть цикл, посвященный IBM WebSphere ESB (далее — ESB) в разрезе разработки под этот продукт. И, в первую очередь, придется познакомиться поближе с технологиями такого рода.
Enterprise service bus (сервисная шина предприятия) — связующее программное обеспечение, обеспечивающее централизованный и унифицированный событийно-ориентированный обмен сообщениями между различными информационными системами на принципах сервис-ориентированной архитектуры.
Конечно же, можно и без специального ПО (возможно, что-то общее таки придется разработать) строить корпоративную систему основываясь на таком подходе, и то, что в результате получится, называть сервисной шиной. Но в продукте от IBM есть не только уже готовый аппарат для централизованного обмена сообщениями и контроля этого процесса, но и полный набор возможностей для разработки гибких сервис-ориентированных приложений специально под ESB. В итоге, можно выделить следующие возможности и преимущества IBM WebSphere ESB:

• Порядок и единообразие архитектурных связей
• Централизованное управление
• Конфигурация приложений на стороне сервера
• Реализация технологии Service Component Architecture (SCA) в духе принципов сервис-ориентированной архитектуры
• Протоколо-независимость разрабатываемого программного кода
• Широкие возможности конфигурирования шины и приложений

При этом ESB обеспечивает транзакционный контроль, преобразование данных, сохранность и гарантированную доставку сообщений. Доступ ко всем сервисным службам через единую точку позволяет осуществлять конфигурирование коммуникации сервисов централизованно. Так же централизованно можно управлять сбойными событиями для массовой обработки ошибок.
Классическая топология сборки ESB – кластер, обеспечивающий горизонтальную масштабируемость и отказоустойчивость. По официальным рекомендациям, увеличение количества членов кластера увеличивает производительность более эффективно, чем наращивание мощности сервера при stand-alone топологии. Кроме этого, кластер можно перезагрузить (или его часть может отказать) без остановки обслуживания.
Обычно ESB используется как сервисная прослойка в IBM BPM, но вполне может играть ведущую роль в построении модели взаимодействия корпоративных систем как мощный интеграционный аппарат (имеется в виду ESB как надстройка над IBM WebSphere Application Server).
Это, по сути, требуется от ESB, так как это «точка сбора сервисов» — если вам нужен сервис, который будет работать с другими сервисами (возможно, внешними), то интеграцию между этими сервисами логичнее всего сделать именно на ESB. Для внешних или гетерогенных сервисов можно сделать «обертку» ESB-сервисом. Немного проиллюстрируем удобства использования «единого жилья» для сервисов:

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

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

Централизованное управление
Всегда удобнее производить настройку систем централизованно – будь то конфигурирование, адаптация к переезду серверов, обеспечение отказоустойчивости, распределение нагрузки, обработка ошибок либо мониторинг и аналитика.

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

Читайте также: Зажимает шину при пилении

Конфигурация на стороне сервера
«Единое жилье» для сервисов, с точки зрения конфигурирования, позволяет достичь нескольких полезных целей. Во-первых, это повторное использование конфигурации (по аналогии с повторным использованием кода и модулей, которое так полезно в SOA), поскольку разные модули и приложения могут использовать одни и те же параметры соединения с БД, ресурсы, параметры аутентификации, переменные среды и прочее.

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

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

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

SCA
Эта архитектура основывается на принципе предоставления компонентой своей функциональности в виде сервиса, доступного другим компонентам. В рамках одного модуля компонентами выступают программные блоки (java код), полностью реализующие некий функционал, описанный соответствующим интерфейсом. Логика выполнения компонент реализуется связыванием их в структуру по интерфейсам и reference’ам (Partner Reference).

Такую структуру модуля очень удобно разрабатывать, проверять, развивать, изменять и поддерживать. Атомарность функционала, реализованного в компонентах, позволяет оперировать компонентами в целом, не опускаясь до уровня кода. С другой стороны, она логично необходима ввиду выполнения имплементаций компонент в транзакционном контексте.
У каждой компоненты есть интерфейс(ы), имплементацию которого она предоставляет. Таким образом, связывая между собой компоненты, нет необходимости знать их внутренние особенности – достаточно того, что они реализуют необходимые интерфейсы.
Посредством данной архитектуры также можно решить все задачи, требующие параллельной работы, без «ручного» управления потоками (например, можно выполнять асинхронные вызовы нескольких компонент с отсроченным ответом).
Не java-компоненты, например, типов Export и Import, позволяют предоставлять сервисы для внешнего использования либо использовать внешние сервисы соответственно; компонента Mediation Flow обеспечивает низкоуровневый доступ к сообщениям, которыми обмениваются другие компоненты и позволяет производить различные преобразования при работе с гетерогенными интерфейсами.
Помимо интерфейсов, очень полезные возможности предоставляет IBM business object framework. Бизнес-объекты (БО), представлены xsd-схемами, используются как объекты для передачи данных в интерфейсах, как между компонентами, так и для коммуникации между модулями. Они же напрямую интегрируются, например, в wsdl-схему для описания веб-сервисов. То есть, например, если модуль «А» предоставляет свой функционал в виде веб-сервиса, модулю «Б» для его использования достаточно подключить интерфейс и готовые БО, и он сможет в полной мере работать с таким сервисом без создания каких-либо дополнительных java-объектов для передачи данных. БО также удобно использовать при обмене данными с БД, если эти данные используются другими компонентами (это, конечно, идет в разрез с паттерном «DAO», но избавляет от лишних java-объектов и операций переписывания данных «туда-сюда»).

Протоколо-независимость программного кода
Как можно было заметить, протоколо-независимость кода достигается путем использования компонент Export и Import. Поскольку связь с этими компонентами идет по интерфейсам и reference’ам, программный код полностью независим от используемого для взаимодействия протокола. Один и тот же функционал можно легким движением сделать доступным по любому количеству поддерживаемых протоколов и по любым нужным интерфейсам. На следующем рисунке показано добавление экспорта с SCA привязкой к компоненте, которая уже предоставляет свой интерфейс как HTTP, JMS и Web-сервис.

Удобства очевидны – гибкость, универсальность, повторное использование кода, быстрота разработки и модификации.
Кстати, SCA привязка использует особый протокол и предназначена для сообщения между модулями в рамках одного сервера/кластера. Взаимодействие через эту привязку менее ресурсоемкое и более быстрое по сравнению с другими протоколами.

Конфигурирование
Конфигурирование сервера и приложений осуществляется через IBM console сервера.
В ESB, как и в IBM WebSphere в общем, довольно много специфических возможностей и артефактов. Например, при использовании тех же импортов и экспортов, можно «на лету» конфигурировать end-point’ы соответствующих сервисов. Для вызовов сервисов можно настраивать policy set’ы с разнообразными правилами (например, можно установить поддержку механизма WS-AT, который позволяет вызывать веб-сервис в той же транзакции, в которой работает клиент; но транзакционность – это уже тема для полной статьи), устанавливать параметры аутентификации, подключать сертификаты и прочее.
Через конфигурирование можно настроить некоторые механизмы автоматической реакции на исключительные ситуации (например, автоматическое повторение выполнения компонент при ошибках). Можно «на лету» настроить трассировку компонент или изменить уровни логирования. Также доступен сервис управления сбойными событиями, который можно осознанно использовать для массовой обработки ошибок.
Ну и, конечно же, можно настроить много чего другого согласно спецификации Java2EE, которая, иногда довольно строго, реализована в IBM Application Server.

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

В статье использованы следующие изображения: 1 2 3 4 5

Видео:Корпоративная сервисная шина DATAREON ESB. Назначение классов и маршрутов передачи данных. Урок 4Скачать

На шаг ближе к Open Banking с WSO2 API Manager

Привет! Меня зовут Сергей Кривонос, я Solution Architect платформы WSO2 в Росбанке. Если вкратце, то WSO2 API Manager — это комплексная, интуитивно понятная и масштабируемая платформа, предназначенная для создания и управления API. Она примечательная тем, что является опенсорсной при сопоставимой с энтерпрайз-решениями функциональности. В статье я немного расскажу о самой платформе и поделюсь опытом Росбанка в работе с продуктами WSO2 — в целом, весьма позитивным.

Зачем это нужно

Росбанк столкнулся с потребностью развивать Open Banking и предоставить больше сервисов для своих партнеров. Сейчас мы активно работаем в направлении Bank-as-a-Service (BaaS). Под «BaaS» мы подразумеваем способность банка предоставлять свои продукты и услуги сторонним дистрибьюторам (финансовым игрокам или нет), чтобы они могли легко интегрировать их в свои собственные циклы взаимодействия с клиентами (B2B2B или B2B2C).

Читайте также: Станок для комплектовки шин

Чтобы подобный проект стал возможен, необходим стандартизированный набор открытых банковских API (OpenAPI). Такие стандарты представил Банк России в октябре минувшего года, которые размещены на его портале.

У нас уже есть большой набор устоявшихся в инфраструктуре API, и привести его к единому стандарту, а также обеспечить адекватную защиту — задача непростая. Само по себе управление зоопарком API усложняется из-за нескольких факторов:

использования разных протоколов обмена,

использования различных механизмов аутентификации,

Чтобы решить все эти проблемы, необходим промежуточный middleware-слой — для управления взаимодействием между поставщиками и потребителями через API.

Этот middleware-слой реализуется в виде отдельного компонента API Manager — класса софта, о котором мы будем подробно говорить. Здесь каждый провайдер (API) подключается к потребителям через управляемый интерфейс, а не напрямую. Middleware-слой ликвидирует все связи типа «точка-точка» между поставщиком и потребителем. Чем-то похоже на традиционную интеграционную шину (ESB) в SOA, правда? Но API Management — это совершенно другой компонент, который берет на себя такие важные функции, как:

обеспечение безопасности (аутентификация и авторизация),

QoS, а именно приоритизация трафика, защита серверной части от внезапного всплеска запросов,

преобразование запросов и ответов.

Командой информационной безопасности банка был выработан отдельный стандарт защиты API, который реализуется как при разработке API, так и при публикации их в интернет. Необходимо было также внедрить технологию по обеспечению безопасности API на протяжении всего их жизненного цикла. После сравнения лидеров рынка по возможностям, архитектурным особенностям и total cost of ownership решение было принято в пользу WSO2.

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

Из чего состоит WSO2 API Manager

В Росбанке в качестве middleware-слоя мы выбрали и внедрили платформу WSO2 API Manager для управления API:

проектирования, прототипирования и публикации,

версионирования и управления жизненным циклом,

контроля доступа и обеспечения безопасности,

монетизации, подписки и управления ключами.

Основные недостатки WSO2 API Manager сводятся к потенциальным рискам, связанным с появлением дополнительного слоя в инфраструктуре, а также к небольшому увеличению времени ожидания ответа. Список преимуществ гораздо внушительнее:

единая точка входа в банк для всех запросов от внешних систем,

простота контроля и ограничения доступов к API,

возможность ограничения числа запросов (защита от DDoS),

единый механизм авторизации через OAuth 2.0,

контроль пользователей подписок,

наличие статистики по использованию,

возможность монетизации сервисов и внедрения дополнительной логики в целях контроля и логирования запросов.

В архитектуру WSO2 API Manager входят следующие компоненты: Publisher, Developer Portal, Gateway, Key Manager и Traffic Manager. Функции многих понятны из названий, но для полноты картины вкратце перечислим их.

Схема WSO2 API Manager. Источник: WSO2

API Publisher отвечает за:

публикацию API (регистрацию, проверку SLA, безопасности и производительности),

мониторинг работы API, их пользователей, сбор обратной связи,

управление жизненным циклом, версиями, политиками и ключами API.

API Developer Portal – за:

поиск и упорядочивание API по разным параметрам,

рейтинги API, комментарии и запросы пользователей,

возможность протестировать API онлайн,

регистрацию приложений, покупку ключей, подписку на обновления.

API Gateway в зависимости от места установки может работать как шлюз для сервисов внутри сети или для внешних партнеров/клиентов.

Эта часть платформы реализует:

валидацию в рамках политик безопасности,

сбор статистики по использованию.

Key Manager занимается доступами, а Traffic Manager отвечает за то, чтобы количество запросов к API на платформе соответствовало прописанным в соответствующих политиках.

Высокоуровневая схема взаимодействия с WSO2 API Manager. Источник: WSO2

Кстати, в актуальном на сегодня отчете Forrester по решениям для API-менеджмента (3 квартал 2020 г.) WSO2 попала в категорию лидеров, наряду с такими гигантами, как IBM и Google. Среди пользователей платформы — Ebay, Schneider Electric, Всемирный банк, T-Systems и множество других компаний из разных отраслей.

Почему мы переходим на продукты WSO2

Сейчас в Росбанке в качестве интеграционной шины используется IBM Integration Bus. Как нетрудно догадаться, это масштабное энтрепрайз-решение, требующее отдельной строки в CAPEX, помимо регулярных расходов. А продукты компании WSO2 — WSO2 API Manager, WSO2 Enterprise Integrator и др. — это opensource-решения, которые можно просто скачать с гитхаба и пользоваться в свое удовольствие. Теоретически.

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

Учитывая opensource-происхождение, можно подумать, что WSO2 API Manager предлагает более скромные возможности, чем энтерпрайз-аналоги. Но в рамках наших задач — создание единой среды Bank-as-a-Service для партнеров банка — WSO2 API Manager по функциональности не уступает IBM API Connect. Подробное сравнение заслуживает отдельного материала — пишите в комментариях, если вам интересно. Если не вдаваться в детали, то WSO2 API Manager — это единственный opensource-продукт в своей нише, который может полноценно конкурировать с энтерпрайз-решениями. Есть маршрутизация, есть настройка протоколов обмена, композитные сервисы, оркестрация, энтерпрайз-паттерны, удобный тулкит. Вот полный список возможностей:

Читайте также: Шина нулевая 6х9 12 отв

дизайн и прототипирование API до реальной разработки (архитектура API First);

реализация заглушек API c использованием JavaScript;

публикация REST, JSON, SOAP, XML сервисов как API;

публикация API как для внешних, так и для внутренних пользователей;

тонкие настройки прав доступа к API;

управление жизненным циклом API, версионирование;

публикация как Production (производственной), так и Sandbox (тренировочной) версий API;

ограничение доступа к API по домену и/или IP;

поддержка протоколов OAuth2, Open ID Connect, SAML 2.0, XACL, JWT и многих других для обеспечения любых вариантов интеграции, аутентификации и авторизации;

портал разработчика с удобным интерфейсом а-ля «магазин» для поиска и подписки на интересующие API;

встроенная в портал разработчика консоль для тестирования API;

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

мощная аналитика по различным аспектам использования API.

Наш опыт использования продуктов WSO2

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

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

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

В другом проекте — по слиянию Росбанка и Русфинанс Банка — все интеграции между информационными системами двух банков также были успешно и быстро реализованы через WSO2 Enterprise Integrator.

В рамках пилота для интеграции наших внутренних информационных систем мы также используем WSO2 Enterprise Integrator вместо IBM Integration Bus в качестве интеграционной шины. Благодаря low-code среде разработки, упрощается реализация интеграционных сервисов. WSO2 предлагает простую IDE на базе Eclipse, где логические блоки накидываются драг-н-дропом и соединяются стрелками. Чтобы реализовать любой интеграционный сервис, не нужно ни одной строчки кода. Платформу WSO2 вместе с комплектом шаблонов мы предоставляем как сервис (PaaS) всем командам банка для создания необходимых им интеграционных сервисов. А перед деплоем просто проверяем через CI/CD, что всё работает нормально.

Работа с техподдержкой WSO2

В России у WSO2 есть официальный партнер, который помогает работать напрямую с техподдержкой разработчика. Для многих отечественных компаний это важно. Можно заключить договор на поддержку вендора (WSO2) и/или поддержку интегратора (официального партнера).

Какие опции включает поддержка вендора:

исправить баги и недочёты в продуктах;

обновить настройки безопасности;

проконсультировать по общим вопросам (несколько часов) — архитектура, использование продуктов и т.д. — это оценивается на основе общей стоимости договора.

Какие опции включает поддержка интегратора:

обеспечить бесперебойную работу решений, которые запускаются на вендорских продуктах;

пообщаться с ТП вендора (по взаимному согласию).

Если случится авария на проде, вендор не будет поднимать и перезапускать API Manager. А если обнаружится проблема в ядре API Manager, интегратор не полезет вносить исправления. Планы поддержки дополняют друг друга. У нас бесперебойную работу платформы обеспечивает отдельная команда в штате, поэтому мы пользуемся только поддержкой вендора.

По нашему опыту специалисты компании быстро решают все проблемы, подсказывают, как лучше реализовать наши планы, по необходимости объясняют документацию. Все взаимодействие удобно реализовано через Jira. Если запрос требует лишь консультации, ее предоставляют за день. Если нужен патч, это занимает чуть дольше — 2–7 дней, но всё в рамках SLA. Патчи раскатывают для всех клиентов официальной техподдержки, так что некоторые проблемы решаются еще до того, как с ними столкнемся мы ?

Команда из WSO2 выручала нас уже много раз: была улучшена работа с русскими символами в swagger-документации, исправлен ряд ошибок, связанных с XML, оказана помощь с настройкой деплоя приложений в Openshift 4, настройкой серверов, CI/CD и было сделано еще много чего полезного. Мы рады, что коллеги помогли добавить новые фичи в WSO2 Enterprise Integrator, например, создание API из swagger-файлов и reload конфигурационных файлов без рестарта сервера.

Заключение

Сейчас мы стремимся к тому, чтобы любой API в банке — в том числе и для внутреннего использования — сразу появлялся в среде WSO2 API Manager. Для этого мы разворачиваем WSO2 API Manager внутри сети банка. Это позволит значительно упростить как управление API, так и предоставление доступов к этим API.

Параллельно мы ведем пилотный проект по миграции WSO2 на OpenShift, что позволит нам получить автоматическое масштабирование, удобный мониторинг и при этом убрать даунтайм при деплое новых версий.

В будущих материалах мы планируем более подробно рассказать о WSO2 API Manager и Enterprise Integrator, их развертывании и особенностях использования, которые открыли сами. Если вам интересно узнать что-нибудь конкретное об этих и других продуктах вендора, задавайте вопросы в комментариях. Будет интересно почитать и о вашем опыте работы с WSO2 ?

• Свежие записи
  • Нужно ли менять пружины при замене амортизаторов
  • Скрипят амортизаторы на машине что делать
  • Из чего состоит стойка амортизатора передняя
  • Чем стянуть пружину амортизатора без стяжек
  • Для чего нужны амортизаторы в автомобиле

  
  

  источники:

  https://fasad-adelante.ru/servisnaya-shina-predpriyatiya-wso2

  💥 Видео

  Error handling with WSO2 Enterprise Service BusСкачать

  

  Шины данных и интеграции | ESB шина данных | Интеграция 1С ERPСкачать

  

  Интеграционная шина предприятия. Структура правила экспортаСкачать

  

  Интеграционная шина - обмен данными между подразделениями предприятияСкачать

  

  Опыт внедрения ESB интеграционной шины в ПАО «Газпром Нефть» Михаил ХаритоновСкачать

  

  Сравнение ESB-систем | Ключевые отличия от брокеров сообщений | kt.teamСкачать

  

  Установка и настройка шины DATAREON ESBСкачать

  

  Интеграция систем 1С с помощью сервисной шины предприятия DATAREON ESBСкачать

  

  Корпоративная сервисная шина данных DATAREON ESB. Алгоритм работы подсистемы 1С. Урок 6Скачать

  

  Интеграция и управление системами с помощью ESB. Владимир Кислицин, CTO Prodengi.kzСкачать

  

  Корпоративная сервисная шина данных DATAREON ESB. Взаимодействие с 1С. Урок 5Скачать

  

  WSO2Con EU 2016 : Managed File Transfer with WSO2 Enterprise Service BusСкачать

  

  DATAREON ESB. Коротко о главномСкачать