Сейчас на рынке сформировалась тенденция, когда все крупные структуры, использующие раздробленную, не целостную автоматизацию, начинают понимать необходимость переноса имеющегося взаимодействия между приложениями на совершенно новый уровень. Решением здесь может стать использование ESB - Enterprise Service Bus – Сервисная Шина Предприятия. На рынке фигурируют продукты компаний Progress, IBM, Microsoft, TIBCO и некоторые другие. Каждая из них имеет свои положительные и отрицательные стороны. Но общие механизмы интеграции остаются неизменными. Используются технологии XML, XSLT, XSD, WSDL, SOAP и прочие. Все предлагаемые системы ESB имеют возможность использования Web-services.

Если проанализировать стандартный процесс общения двух систем через ESB, то получаем нечто следующее:

Рис. 1  Процесс общения двух систем через ESB

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

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

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

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

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

Взаимодействие двух и более прикладных систем посредством обмена данных.

Необходимые компоненты для интеграции.

• Адаптеры прикладных систем к серверу ESB для отправки и приема сообщений.
• ESB, которая должна состоять минимум из:
• Транспортная система (MQ)
• Преобразование формата и данных сообщения
• Маршрутизация (контентная) сообщений между прикладными системами. 

Рис. 2 Взаимодействие двух и более прикладных систем посредством обмена данных.

Стандартные бизнес-требования.

• Гарантированная и однократная доставка сообщений
• Надежность работы при сетевых, программных и аппаратных сбоях (отказоустойчивость)
• Высокая производительность
• Короткий цикл разработки интеграционного проекта
• Возможность легкого наращивания и повторного использования компонентов системы
• Низкая стоимость владения и обслуживания системы

В качестве стандарта тела сообщения принимаем стандарт XML.
В качестве стандарта описания интерфейса системы принимаем стандарт XSD.
В качестве стандарта модификации XML сообщений принимаем стандарт XSLT.
В качестве языка доступа к телу сообщения берем язык XPATH.

Данные стандарты хорошо отлажены и имеют широкую поддержку.

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

Рис. 3  Преобразования формата сообщений в XML-сообщения.

Не факт, что вторая система поймет те данные, которые выгружает первая. В таких случаях мы предлагаем рассмотреть вариант использования промежуточного формата. Выглядит это примерно так:
 
(С1 –прикладная система 1, С2 – система 2)

В случае если форматы С1 и С2 - не XML, преобразователи могут являться специфическим программным продуктом. Но даже в этом случае, преобразование из XML в простой несложный формат (к примеру, comma delimited) можно выполнить с помощью XSLT-преобразования. Действия по преобразованию форматов можно легко вынести на уровень ESB, поступающие в ESB данные будут преобразовываться в промежуточный XML формат, а на выходе будут преобразовываться к формату системы получателя. Сами прикладные системы не придется дорабатывать в связи с этим, т.к. все преобразования выполняются  на уровне ESB.

Если формат является XML, преобразование можно выполнить посредством XSLT преобразования.

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

Следует иметь в наличии файловые адаптеры, которые будут подхватывать файлы из некоторого каталога и посылать их в качестве сообщений в очередь сервера сообщений ESB. Также они должны настраиваться на прием сообщений с очереди сервера сообщений. Лучшим вариантом являются инвариантные к ОС адаптеры, для этого отлично подходят адаптеры, написанные на JAVA. Инвариантность программного обеспечения очень важна, так как существует много продуктов, которые работают не только на ОС Windows, но и на Linux, AIX, Sun Solaris и прочих. По большому счету, не важно, какая ОС требуется для работы сервера сообщений. Важно то, что для выбранной ESB должен существовать JAVA API.

Когда систем становится больше трех, для их интеграции уже становится невыгодным использование конвертеров, которые производят перевод из формата первой системы в формат второй системы. Системы могут обмениваться различными документами, для каждого из них может понадобиться уникальный преобразователь к формату той системы, которая должна будет использовать этот документ. Так, к примеру, АБС может выдавать 40 видов документов, 15 могут поступать в одну систему, 15 во вторую, 10 в обе. В таком случае надо писать 15 + 15 + 10*2 = 50 преобразователей. И это только для передачи документов в одну сторону, а ведь зачастую появляются ответные документы, которые  надо также преобразовывать, только уже в обратную сторону. В случае использования промежуточного формата документов при таком варианте получаем 40 преобразователей в промежуточный XML-формат и по 25 преобразователей из промежуточного языка в интерфейс систем, итого 90 преобразований. Для чего тогда так делать, если необходимое число преобразований становится больше? Причины следующие:
• Общий формат документа легко описать понятным для разработчиков языком XSD. Возможно, есть возможность доработать интеграционные компоненты таким образом, чтобы исходящие документы соответствовали этому стандарту.
• За общий формат может браться стандарт самого крупного компонента в интеграции, в банках это обычно АБС, если банк имеет XML интерфейс для обмена данными, то это совсем хорошо. Либо за общий формат может быть взят какой-либо хорошо распространенный и поддерживаемый промышленный стандарт. Это уже будет  зависеть от отрасли бизнеса.
• Документ, хранящийся в промежуточном формате, должен быть легко конвертируемым в форматы других систем. Идеальным форматом таких документов является XML. Преобразование XML документов осуществляется с помощью XSLT преобразования.
• При добавлении новой системы или замене уже имеющейся, необходимо будет описать конвертер формата документа этой системы в/из промежуточного формата. Это значительно экономнее, чем писать отдельные преобразователи к каждой системе при интеграции.

Идеальным вариантом является такой случай:
• Все используемые системы имеют XML-интерфейс для взаимодействия.
• За промежуточный формат взят формат самого крупного компонента (например, АБС).

При таком положении дел имеем:
• Число необходимых преобразований документов минимально. Если внешней системе нужен документ или она отправляет свой документ в ESB, ставится XSLT-преобразование документа к общему формату. Для описанного выше примера понадобиться 50 XSLT-преобразований, и при добавлении внешней системы, необходимо будет добавлять по одному преобразованию на каждый документ.
• Общий формат можно расширять дополнительными документами, которые ходят между системами. Для этого следует описать новый документ с помощью XSD- схемы.
• Все необходимые преобразования можно вынести на уровень ESB, тогда прикладные системы не придется дорабатывать (доработка прикладных систем может очень затянуться и быть достаточно дорогой).

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