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

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


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

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

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

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

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


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


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


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


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

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


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


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

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

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

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

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


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


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

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

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


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


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

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

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


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


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


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

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

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

Блог компании PNN ,

Разработка веб-сайтов

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

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

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

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

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

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

Вызов служб

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

Для начала, я должен объяснить терминологию. Web-служба во многом похожа на функцию в процедурном программировании: она имеет имя, параметры и результат. Именем является Uniform Resource Identifier (URI – унифицированный идентификатор ресурса), который провайдер Web-службы использует для того, чтобы Web-служба стала доступна как оконечная точка . Провайдер Web-службы использует URI оконечной точки в качестве адреса для нахождения и вызова Web-службы. В запросе присутствуют конкретное действие и параметры, которые потребитель передает Web-службе при вызове оконечной точки. После выполнения службы оконечная точка передает ответ обратно потребителю, в котором сообщается об успешном выполнении (или об ошибке) и содержится результат работы службы. То есть, потребитель вызывает оконечную точку провайдера, передает запрос и получает назад ответ.

Текущее определение способа реализации Web-службы – это WS-I Basic Profile 1.1, который состоит из протокола "SOAP 1.1 over HTTP 1.1", описанного на языке Web Services Description Language (WSDL) 1.1 (ссылка на саму спецификацию приведена в разделе " "). В "SOAP over HTTP" потребитель вызывает службу, используя передаваемый по HTTP в HTTP-запросе SOAP-запрос. Потребитель синхронно блокирует работу по HTTP-сокету, ожидая HTTP-ответ, содержащий SOAP-ответ. API оконечной точки описан ее WSDL – контрактом между потребителем и провайдером службы.

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

Сравнение синхронного и асинхронного вызовов

Потребитель может вызвать службу синхронно либо асинхронно. С точки зрения потребителя различие заключается в следующем:

• Синхронный . Потребитель использует один поток для вызова службы; поток передает запрос, блокируется на время выполнения службы и ждет ответ;
• Асинхронный . Потребитель использует два потока для вызова службы; один - для передачи запроса, второй – для приема ответа.

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

• Синхронный . Если у потребителя возникает аварийная ситуация во время блокирования при работе службы, нельзя повторно подключиться к этой службе после перезапуска, поэтому ответ теряется. Потребитель должен повторить запрос и надеяться на отсутствие аварийной ситуации;
• Асинхронный . Если у потребителя возникает аварийная ситуация во время ожидания ответа на запрос, после перезапуска потребитель может продолжать ожидать ответ, то есть ответ не теряется.

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

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

1. Синхронный прямой вызов;
2. Синхронный вызов через посредника (брокера);
3. Асинхронный вызов через посредника (брокера).

Каждый вариант я рассмотрю отдельно

Синхронный прямой вызов

Метод вызова Web-службы "SOAP over HTTP" является прямым: аналогично вызову функции потребитель знает адрес оконечной точки и вызывает ее напрямую. Для успешного вызова Web-служба должна функционировать при вызове оконечной точки потребителем и должна дать ответ до истечения времени ожидания потребителем. Если Web-служба разворачивается в новом месте (например, другой интернет-домен), потребитель должен быть уведомлен о новом URI оконечной точки. При развертывании нескольких провайдеров службы одного типа оконечная точка каждого провайдера должна иметь различный URI. Для выбора конкретного провайдера службы потребитель должен знать каждый такой URI.

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

Для решения этой проблемы существует спецификация Universal Description Discovery and Integration (UDDI), описывающая Web-службу, которая является каталогом (аналогичным телефонной книге) для поиска других Web-служб. Идея заключается в развертывании UDDI-службы по хорошо известному потребителю адресу; потребитель может использовать UDDI для поиска других Web-служб.

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

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

1. Потребитель запрашивает у UDDI список провайдеров службы;
2. Потребитель выбирает оконечную точку провайдера из списка, полученного из UDDI;
3. Потребитель вызывает эту оконечную точку.

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

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

Синхронный вызов через посредника

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

Одним из способов упрощения проблемы является введение брокера, работающего как промежуточное звено при вызове Web-службы. Потребитель больше не вызывает службу провайдера напрямую, а вызывает прокси-службу брокера, который, в свою очередь, вызывает службу провайдера. Потребитель должен знать URI оконечной точки прокси-службы и поэтому использует UDDI для поиска адреса, но, в данном случае, UDDI возвращает только один URI, и потребитель не должен делать выбор. Потребитель может даже и не знать, что оконечная точка является прокси-службой; он знает только о том, что может использовать этот URI для вызова Web-службы. Брокер связывает потребителя с провайдерами служб (см. рисунок 3).

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

На рисунке 4 показана схема использования брокера потребителем при вызове службы. Алгоритм работы следующий:

1. Потребитель запрашивает в UDDI список провайдеров службы. Возвращенный из UDDI URI фактически является прокси-службой. UDDI вернет только один URI, а не несколько, поскольку брокер имеет только одну прокси-службу для каждой конкретной службы;
2. Потребитель вызывает службу, используя URI прокси;
3. Прокси-служба выбирает провайдера службы из списка доступных провайдеров;
4. Прокси-служба вызывает оконечную точку выбранного провайдера.

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

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

Асинхронный вызов через посредника

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

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

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

Этот подход использует шаблон Request-Reply для вызова Web-службы. Вместо указанного в WS-I BP 1.1 протокола HTTP транспортные функции могут теперь выполнять очереди сообщений. SOAP-запрос и ответ является таким же, как и с WS-I BP, но они заключены в сообщения системы обмена сообщениями.

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

1. Потребитель передает SOAP-запрос в виде сообщения в очередь запросов. Потребитель заканчивает работу и может использовать данный поток для выполнения других задач;
2. Каждый провайдер является потребителем очереди запросов, что делает их конкурирующими потребителями. Система обмена сообщениями определяет, какой провайдер может получить сообщение, и гарантирует его получение только одним провайдером. Как это работает на самом деле, зависит от реализации системы обмена сообщениями;
3. Победивший провайдер получает сообщение из очереди запросов;
4. Провайдер выполняет службу;
5. Провайдер передает SOAP-ответ в виде сообщения в очередь ответов. Теперь провайдер заканчивает свою работу и может использовать свой поток для других задач (например, для ожидания следующего запроса);
6. Прослушивающий поток потребитель получает сообщение, содержащее SOAP-ответ.

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

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

Теперь вы знаете варианты типов соединения для вызова служб. Рассмотрим дополнительные интеграционные возможности, которые тоже могут быть полезными, а затем, как разработать ESB, предоставляющую нам эти возможности.

Другие интеграционные возможности

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

Передача данных

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

Для передачи данных может использоваться вызов службы, что эквивалентно вызову метода setter, но передача данных осуществляется по принципу RPC. В действительности передача данных больше похожа на передачу файлов: данные экспортируются отправителем и импортируются получателем без явного указания получателю, что делать с данными. Это больше похоже на SOAP-сообщение в стиле документа, чем на сообщение в RPC-стиле.

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

Дополнительную информацию по технологии передачи данных можно найти в шаблоне Document Message (более подробно об этом смотрите в книге "", ссылка на которую приведена в разделе " ").

Уведомление о событиях

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

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

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

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

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

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

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

Брокером часто начинают называть ESB. Так как же ESB вписывается в уже принятые проекты и шаблоны?

Самоописание и обнаруживаемость

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

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

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

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

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

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

Шлюз служб

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

Если службами, которые координирует шлюз, являются Web-службы, то они обладают способностью к самоописанию. Каждая служба объявляет свой интерфейс при помощи WSDL, который состоит из следующих четырех частей:

1. Типы портов – Набор операций, выполняемых Web-службой. Типом порта может быть stockBrokerServices с портами/операциями, например, getQuote .
2. Сообщения – Формат запросов и ответов, например, getQuoteRequest (который содержит символ акции) и getQuoteResponse (который содержит цену).
3. Типы – Типы данных, используемых Web-службой, например, symbol и price (или просто xs:string и xs:decimal).
4. Связи – Адрес для вызова операции, например, http://stockbroker.example.com/getQuote.

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

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

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

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

Такая шина сообщений является сущностью ESB, и здесь нет ничего нового. Интеграторы приложений использовали эту технологию более десятилетия, применяя такие продукты обработки очередей сообщений как WebSphere® MQ и TIBCO Enterprise Message Service. И на самом деле часто говорят, что если вы используете продукты корпоративного обмена сообщениями, то у вас есть ESB. Клиенты IBM уже некоторое время пользуются этими возможностями с WebSphere Business Integration Message Broker и WebSphere MQ.

Итак, является ли ESB только шиной сообщений? Нет, шина сообщений определенно является основой асинхронной ESB, но полная ESB – это нечто большее. ESB обладает способностями, которые никогда не имели шины сообщений: вышеупомянутыми способностями самоописания и обнаруживаемости.

Лучшая шина сообщений

Итак, если шина сообщений не является полной ESB, тогда что еще делает ESB?

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

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

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

ESB нуждается в аналогичной службе каталогов с UDDI-подобным API, используя который потребитель мог бы запросить адрес службы, реализующей желаемую WSDL-операцию. ESB возвращает адрес соответствующей пары каналов запросов и ответов. То есть, ESB-клиент, аналогично UDDI-клиенту, не должен знать ничего кроме следующего:

1. WSDL, описывающий службу, которую хочет вызвать.
2. Адрес службы каталогов ESB (который может быть производным от корневого адреса ESB).

Этого достаточно для обнаружения каналов запросов и ответов службы и для начала вызова службы. Более того, эта служба каталогов является просто еще одной службой, предоставляемой ESB, как бы главной службой для поиска других служб.

Синхронный или асинхронный?

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

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

Заключение

Как вы увидели, служба может быть вызвана любым из следующих способов:

1. Напрямую и синхронно;
2. Синхронно через брокера;
3. Асинхронно через брокера.

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

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

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

Интеграция информационных систем при помощи корпоративной сервисной шины (ESB)

Среди лучших практик интеграции сложных информационных систем — построение логических витрин данных, а также создание централизованных инфраструктур обмена данными при помощи 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, а также шины «Бизнес Семантика».

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

2005 г.

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

Подготовлено: по материалам зарубежных сайтов
Перевод: 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. Фактически, дискуссия разворачивается вокруг двух вопросов:

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

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

2. Каковы место и перспективы продуктов 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 на нескольких примерах.

Переменная	Заметки
Окружение	CRM-система электрокомпании
Функциональность	Возврат списка клиентов, которые были активны на портале самообслуживания в III квартале 2012
Это интересно?	Да, достаточно интересно. Это можно использовать для генерации всех видов полезных отчетов и статистики.
Это можно	Нет, не очень. Не смотря на то, что это позволяет создавать
многократно	высокоуровневые конструкции, такие как статистика за весь год,
использовать?	явно видно, что это нам не понадобится в 2018.
Это атомарно?	Скорее всего, да. Если уже существуют похожие сервисы для других кварталов, то можно будет просмотреть весь год.
Как сделать из этого IRA?	Заставить получать произвольные даты начала и конца периода, вместо указания только квартала. Заставить получать произвольные приложения, не только портал. Дать возможность указывать приложение для получения информации в качестве входного параметра.

Переменная	Заметки
Окружение	сайт электронной коммерции
Функциональность	Возврат каждого кусочка информации, который когда-либо был собран для указанного пользователя
Это интересно?	В общем, да. Если у Вас есть доступ к целому — Вы всегда сможете выбрать, что Вам нужно.
Это можно	Как ни странно, не совсем. Будут всего-лишь несколько
многократно	приложений, если вообще будут, которым будет интересно
использовать?	использовать абсолютно каждый кусочек информации.
Это атомарно?	Однозначно нет. Этот монстр функциональности обречен быть логически составленным из десятков меньших частей.
Как сделать из этого IRA?	Разделить на несколько меньших частей. Подумайте, что описывает покупателя — у них есть адреса, телефоны, любимые продукты, предпочтительные методы связи с ними и так далее. Каждый из этих пунктов должен быть превращен в независимый сервис. Используйте ESB для создания составных сервисов из атомарных.

Переменная	Заметки
Окружение	Любая CRM-система где угодно
Функциональность	Обновление колонки CUST_AR_ZN в таблице C_NAZ_AJ после того, как кто-то создал учетную запись
Это интересно?	Абсолютно неинтересно. Это внутренняя функция CRM-системы. Никто в своем уме не захочет иметь дело с такой низкоуровневой функциональностью.
Это можно	Да, вероятно. Учетная запись может быть создана через
многократно	несколько каналов, так что это кажется чем-то многократно
использовать?	используемым.
Это атомарно?	Кажется, да. Это простое обновление одной колонки в таблице.
Как сделать из
этого IRA?	Даже не пытайтесь сделать из этого сервис. Это неинтересно. Никто не хочет думать о конкретных колонках и таблицах в одной системе. Это сложная деталь CRM-системы и, даже не смотря на то, что это можно многократно использовать и это атомарно, из этого не стоит создавать сервис. Это Ваша и CRM, ответственность думать об этом, не заставляйте других нести ее тоже

Переменная	Заметки
Окружение	Оператор мобильной связи
Функциональность	Пополнение карты предоплаченной связи в биллинге
Это интересно?	Чрезвычайно. Все хотят использовать это, через текстовые сообщения, IVR, IM, порталы, подарочные карты и т. д.
Это можно	Да. Это может принимать участие во многих высокоуровневых
многократно	процессах.
использовать?
Это атомарно?	Да, с точки зрения вызывающего приложения, карта может быть пополнена, либо нет. То, что биллинг реализует это через серию шагов — не важно. С точки зрения бизнеса это атомарно, это — неделимый сервис, предоставляемый биллингом.
Как сделать из	Это уже IRA.
этого IRA?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Но берегитесь…¶

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

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

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

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

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

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

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

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

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

корпоративная сервисная шина

Само собой, команда Zato может помочь.

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

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

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

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

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

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

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

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

Дальше — больше¶

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• Быстрая интеграция
• Высокая надежность
• Возможность многократного использования ресурсов