ПОДХОД К ИНТЕГРАЦИИ СЕРВИСНОЙ ШИНЫ ПРЕДПРИЯТИЯ

АННОТАЦИЯ

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

Ключевые слова: сервисная шина предприятия, ESB, сервис-ориентированная архитектура, SOA.

Сервисные шины предприятия (Enterprise Service Bus, ESB), как полноценный программный продукт, появились в середине 2000-ых годов как развитие программного обеспечения класса брокеров сообщений. Однако сама история таких продуктов значительно дольше и первые упоминания о таких продуктах относятся к концу 60-ых годов прошлого века [5, с. 14].

Сервисная шина предприятия рассматривается как решение в рамках сервис-ориентированной архитектуры (Service-oriented architecture, SOA), которая является особым, модульным подходом к разработке комплексов программного обеспечения [4, c. 8].  

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

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

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

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

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

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

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

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

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

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

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

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

Существуют многочисленные зарубежные продукты, такие как IBM Integration Bus, Microsoft Biztalk ESB, Oracle ESB, Mule ESB. Отечественный рынок представлен такими продуктами как Datareon ESB, Mediator ESB, 1С: Интеграционная шина. Таким вариантом можно воспользоваться при наличии у внедряемого продукта наличия нужных характеристик. Недостатком такого решения является то, что их возможности, как правило многократно превышают требования корпоративных систем, на которых они внедряются. В этом случае более оптимальным вариант собственной разработки.

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

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

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

Список литературы:

1. Сервисная шина предприятия (https://ru.wikipedia.org/wiki/Сервисная_шина_предприятия).
2. Сценарии и решения использования шины Enterprise Service Bus в сервис-ориентированной архитектуре (https://www.ibm.com/developerworks/ru/library/ws-esbscen).
3. Gartner Says Worldwide Application Infrastructure and Middleware Market Grew 12 Percent in 2017 (https://www.gartner.com/en/newsroom/press-releases/2018-06-04-gartner-says-worldwide-application-infrastructure-and-middleware-market-grew-12-percent-in-2017).
4. Kevin C. JBoss ESB Beginner's Guide / Kevin Conner, Tom Cunningham, Len DiMaggio, Magesh Kumar B, 2012: Packt Publishing, Livery Place 35 Livery Street Birmingham B3 2PB, UK.
5. Software engineering, report on a conference sponsored by the NATO SCIENCE COMMITTEE Garmisch, Germany, 7th to 11th October 1968.