пїњ

ј–’»“≈ “”–ј »Ќ“≈√–ј÷»ќЌЌќ… ќЅЋј„Ќќ… ѕЋј“‘ќ–ћџ

”ƒ  004.4 UDC 004.4
ј–’»“≈ “”–ј »Ќ“≈√–ј÷»ќЌЌќ… ARCHITECTURE OF INTEGRATION CLOUD
ќЅЋј„Ќќ… ѕЋј“‘ќ–ћџ PLATFORM
≈ловиков јндрей ≈вгеньевич Elovikov Andrey Evgenevich
 омпани€ NA UMEN, ≈катеринбург, –осси€ NA UMEN Company, Yekaterinburg, Russia
¬ статье рассмотрены элементы облачной This article presents the elements of the integration
интеграционной платформы, задачи, которые она cloud platform, the tasks it solves, the components of решает, ее компоненты и взаимосв€зи между the platform and the relationships between them. The
ними. ќпределены типы приложений платформы types of applications of the platform are defined and
и описано взаимодействие между ними the interactions between them are described
 лючевые слова: ќЅЋј„Ќџ≈ ¬џ„»—Ћ≈Ќ»я, Keywords: CLOUD COMPUTING, IPAAS, CLOUD IPAAS, »Ќ“≈√–ј÷»я ¬ ќЅЋј ≈, ћ»√–ј÷»я INTEGRATION, DATA MIGRATION, ROUTING
ƒјЌЌџ’, ѕЋјЌ ћј–Ў–”“»«ј÷»», PLAN, INTERIM TRANSFORMATION
ѕ–ќћ≈∆”“ќ„Ќјя “–јЌ—‘ќ–ћј÷»я
Ёволюци€ IT-систем приводит к тому, что в компани€х существует множество систем, отвечающих за различные аспекты внутренних процессов компании, что приводит к необходимости структурировать взаимодействи€ этих систем между собой [1]. Ётой проблемой занимаетс€ область интеграции.
ќблачные вычислени€ в насто€щее врем€ €вл€ютс€ одной из самых быстро развивающихс€ IT-технологий. ѕоэтому задача интеграции IT-систем часто представл€ет собой задачу интеграции облачных или облачных и не облачных систем. «начимость решений по интеграции облачных вычислений растет по мере увеличени€ степени их распространенности.
 ак отмечаетс€ в исследовании [2], более половины опрошенных участников IT бизнеса назвали проблемы в области интеграции как основную причину отказа от использовани€ SaaS-приложений. Ќеобходимость решени€ проблем интеграции облачных приложений привело к созданию технологии интеграционных облачных платформ Integration Platform as Service (iPaaS).  лючевыми функци€ми платформы iPaaS €вл€ютс€ [3]: средства поддержки потоков интеграции;
средств разработки и сопровождени€ жизненного цикла интеграции; управление и мониторинг потоков приложений;
обеспечение множественности владельцев приложений.
ќбзор современного мирового состо€ни€ предложений по интеграции приведен в [4]. “ам же показано, что основные современные решени€ реализуют не все ключевые функци€ми платформы iPaaS.
¬ работе [5] рассмотрены основные варианты построени€ интеграционной платформы и обосновано использование в качестве базового варианта построени€ интеграционной платформы решени€ по миграции данных.
ѕринципы построени€ интеграционной платформы
ѕлатформа интеграции, реализующа€ решение по миграции данных между IT-системами, представленными облачными и не облачными системами, должна удовлетвор€ть следующим принципам:
платформа выполн€етс€ по модели SaaS;
платформа имеет визуальный редактор настройки маршрутов и
трансформаций. Ётот редактор расположен в облаке;
одним из режимов работы платформы должен быть такой, при котором
поток пользовательских данных движетс€ только в пределах
пользовательской инфраструктуры (не уходит в облако);
поток пользовательских данных должен быть защищен;
поскольку платформа расположена в облаке, то протокол взаимодействи€
отдельных частей должен быть распространенным и поддерживаемым в
услови€х работы облака, а также межоблачного взаимодействи€;
отказ одного из приложений не должен вли€ть на работоспособность
платформы в целом.
ѕлатформа интеграции, реализованна€ как решение по миграции данных, должна обеспечивать:
возможности горизонтального масштабировани€; поддержанию необходимого уровн€ отказоустойчивости; реализацию многопользовательской среды.
√оризонтальное масштабирование должно позвол€ть при необходимости увеличивать количество однотипных компонент дл€ повышени€ общей производительности платформы.
ƒл€ поддержани€ необходимого уровн€ отказоустойчивости должна быть предусмотрена возможность поддерживать несколько реплик составл€ющих (и подсистем, и компонентов) дл€ возможности продолжить работу в случае возникновени€ отказа.
ќрганизаци€ компонент платформы интеграции
»нтеграционна€ платформа состоит из следующих компонент: компонент моделировани€ маршрутов интеграции; компонент применени€ планов маршрутизации и трансформации; компонент настройки промежуточных трансформаций; компонент управлени€ развертыванием исполнительных модулей; исполнительных модулей;
компонент оповещени€ о текущем ходе процесса.
ƒалее будут рассмотрены назначение и организаци€ компонент платформы.
 омпонент моделировани€ маршрутов интеграции предназначен дл€ обеспечени€ решени€ задачи простой и удобной настройки интеграции. ƒл€ этой цели компонент должен включать визуальный редактор, с помощью которого пользователь может произвести настройку интеграции на интуитивно пон€тном уровне. Ќаиболее подход€щим дл€ решени€ указанной задачи представл€етс€ реализаци€ компонента в форме интерактивного редактора маршрутов.
 омпонент применени€ планов маршрутизации и трансформации предназначен дл€ приведени€ в действие интеграционных планов, заданных пользователем.  омпонент должен обеспечивать:
наличие необходимого числа коннекторов к системам; предоставление разнообразных форм трансформации сообщений;
обеспечение необходимого дл€ приложений уровн€ производительности.
ƒл€ обеспечени€ требований по производительности данный компонент должен быть горизонтально масштабируемым. ƒл€ упрощени€ масштабируемости компонент должен быть реализован как отдельное приложение.
ѕлатформа интеграции должна обеспечивать трансформацию данных из формата одной системы в формат другой. Ётот процесс также должен управл€тьс€ пользователем. ƒл€ задани€ правил преобразовани€ данных одной пользовательской системы в данные другой пользовательской системы при миграции, предназначен компонент настройки промежуточных трансформаций. “ак же как к любому компоненту, реализующему настройку тех или иных процессов пользователем, основные требовани€ к компоненту Ч нагл€дность описани€ процесса трансформаций, пон€тна€ визуализаци€ процесса трансформаций. ƒл€ реализации этих требований наиболее подход€щей представл€етс€ реализаци€ компонента настройки промежуточных трансформаций в виде интерактивного редактора трансформаций.
»сполнительные модули, которые реализуют собственно процесс миграции данных, должны разворачиватьс€ динамически. Ёто св€зано с тем, что исполнительные модули €вл€ютс€ специфическими дл€ каждого клиента. ѕоэтому при каждой регистрации нового клиента требуетс€ выделение исполнительных модулей, соответствующих специфике этого клиента. ”правление развертыванием исполнительных модулей и их администрированием входит в задачи компонента управлени€ развертыванием исполнительных модулей.
ѕосле того как процесс миграции данных начал исполн€тьс€, пользователь должен иметь возможность получать максимально возможную информацию о ходе выполнени€ процесса. Ќа основании этой информации пользователь должен иметь возможность прин€ти€ оперативных решений по изменению настроек интеграционного процесса.
ќсновные требовани€ к компоненту оповещени€ о текущем ходе процесса: возможность получени€ данных в режиме, приближенном к режиму реального времени;
возможность визуализации получаемых данных (их предоставлени€ в виде графиков, отчетов и т.д.).
Ёто обуславливает целесообразность построени€ данного компонента в виде графического редактора настройки получаемых и отображаемых данных о текущем ходе процесса.
 онцептуальна€ модель системы управлени€ маршрутизацией, коммутацией и трансформацией потоков данных
–ешение интеграции в облаке лучше всего подпадает под архитектуру Master/Worker (мастер/работник). јрхитектура Master/Worker представл€ет собой применение клиент-серверного подхода дл€ реализации распределенных вычислений. ћастер (сервер) регистрирует подключени€ клиентов (работников) и, по их запросу, передает задани€ дл€ вычислений. –аботники рассматриваютс€ как ненадежные и не требующие наличи€ посто€нного соединени€ с мастером. ѕользователь производит настройку на мастере, которой распредел€ет задани€ (интеграционные планы) на исполнительные приложени€. ѕроблема масштабировани€ в этом случае решаетс€ за счет динамического изменени€ количества работников, а так же за счет разделени€ интеграционных планов между работниками.
¬ ѕлатформе каждое приложение идентифицируетс€ с помощью определенного значени€, которое генерируетс€ при его запуске. Ёто значение уникальным образом идентифицирует экземпл€р и сессию работы приложени€. ¬се приложени€ в платформе раздел€ютс€ на:
ћастера;
–аботники;
ќчереди (Queue).
ћастер представл€ет собой центральное приложение, которое отвечает за регистрацию пользователей, настройку и презентацию настройки пользователю (визуализацией маршрутов и трансформаций), а так же занимаетс€ развертыванием рабочих процессов.
ѕользователь взаимодействует с ћастером посредством веб-интерфейса (по HTTP протоколу), в то врем€ как остальные приложени€ (–аботники и ќчереди) используют дл€ взаимодействи€ с мастером REST-интерфейс.
¬се остальные приложени€ при начале работы должны быть зарегистрированы в ћастере, а при ее завершении Ч также уведомить ћастера.
ѕри начале работы приложение отправл€ет по REST-интерфейсу следующую команду:
/announce?id=<id>&type=<type>, где idЧ идентификатор сессии работы приложени€, a type Ч тип приложени€ (–аботник/ќчередь).
ѕри получении этой информации ћастером по команде POST происходит регистраци€ данного приложени€ во внутренних структурах данных мастера, и он готов принимать запросы от зарегистрированного приложени€.
ѕри завершении работы приложение отправл€ет по REST-интерфейсу следующую команду:
/failure?id= <id>, где idЧ идентификатор сессии работы приложени€.
ѕри получении этой информации ћастером по команде POST происходит дерегистраци€ данного приложени€ во внутренних структурах, а зависимые элементы приложени€ мигрируют на существующие работающие приложени€ такого же типа.
–аботник представл€ет собой приложение, содержащее исполнительный компонент и готовое выполн€ть интеграционные планы на мощност€х, выделенных процессу операционной системой. ¬ ходе своей де€тельности –аботник устанавливает несколько соединений. ќдно из таких соединений €вл€етс€ управл€ющим (соединение с мастером), с помощью него –аботник получает команды и отдает статистику. “акже устанавливаетс€ соединение, через
которое перемещаютс€ пользовательские данные.
ѕри запуске приложени€ –аботника генерируетс€ уникальный идентификатор сессии этого приложени€.
–аботник соедин€етс€ с ћастером по Ђхорошо известномуї доменному имени ћастера, заданному в конфигурационном файле –аботника.
ƒл€ того чтобы зарегистрировать приложение у ћастера и получать от него информацию, позвол€ющую работнику выполн€ть действи€ по миграции, работник делает POST запрос на адрес ћастера. ¬ ответ приходит сообщение с указанием текущей конфигурации маршрутов, и адресом приложени€ Ч очереди сообщений.
–аботник начинает выполн€ть свой рабочий цикл Ч периодически опрашивать очередь на предмет новых сообщений. ѕри поступлении сообщени€ работник пытаетс€ применить переданную конфигурацию. ¬ случае невозможности передачи данных в соответствии с указанной конфигурацией, приложение-работник отправл€ет POST запрос на адрес ћастера дл€ своей дерегистрации.
ѕриложение ќчередь служит промежуточным звеном между ћастером и –аботником. ќно необходимо дл€ решени€ проблем масштабировани€. ѕри установлении соединени€ ћастера с –аботником ћастер передает –аботнику информацию об очереди, с которой должен быть ассоциирован рабочий процесс. ѕомимо доставки сообщений ќчередь еще выполн€ет функцию наблюдени€ за работоспособностью работника. Ёто происходит при помощи механизма heartbeatТовЧ работник получает сообщени€ от очереди через равные промежутки времени (polling). ≈сли данный промежуток времени превышен, а ответ от работника не получен, то это означает, что работник находитс€ в недопустимом состо€нии. ¬ этом случае происходит уведомление всех заинтересованных приложений (в частности, ћастера).
ѕри запуске приложени€ типа ќчередь генерируетс€ уникальный идентификатор сессии этого приложени€. ќчередь соедин€етс€ с мастером по
Ђхорошо известномуї доменному имени мастера, заданному в конфигурационном файле очереди.
ƒл€ того чтобы зарегистрировать приложение у мастера, очередь делает POST запрос на адрес мастера. ѕосле этого приложение ќчередь готова принимать запросы на создание очередей и производить запись сообщений в очереди.
ѕосле получени€ POST сообщени€ о регистрации очереди у мастера, приложение ќчередь создает очередь и возвращает ее идентификатор ћастеру с помощью REST интерфейса.
ƒалее ќчередь получает GET и POST сообщени€. ѕри получении GET сообщени€ очередь возвращает одно сообщение, которое было ранее поставлено в очередь. ѕри получении POST сообщени€ приложение добавл€ет одно сообщение в очередь.
“аким образом, интеграционна€ платформа состоит из нескольких приложений, которые общаютс€ друг с другом путем передачи сообщений по протоколу HTTP.
¬заимодействие приложений схематично можно представить так, как это показано на рисунке 1.
–исунок 1 Ч —хема взаимодействи€ приложений платформы
∆изненный цикл каждого приложени€ состоит из двух фаз: фазы инициализации и исполнени€.
ѕунктирными лини€ми на рисунке 1 показаны действи€ компонентов на этапе инициализации.
ѕри инициализации каждый компонент обращаетс€ с POST запросом по Ђхорошо известномуї URL мастера. “аким образом, приложени€ дают сигнал о том, где они расположены и как к ним обращатьс€.
¬ общем случае фаза инициализации происходит следующим образом. ѕосле получени€ запроса ћастер регистрирует приложение в базе данных. ≈сли это необходимо, то ћастер обращаетс€ к приложению ќчереди с запросом на выделение очереди. ѕосле этого мастер отдает инициализируемому приложению ответ, в котором содержитс€ необходима€ дл€ приложени€ информаци€ и текуща€ полна€ конфигураци€ приложени€, как это показано на рисунке 2.
–исунок 2 - ¬заимодействие приложений по запросу на инициализацию приложени€
–абота выполнена при финансовой поддержке ћинобрнауки –оссии по государственному контракту от 31.07.2012 г. є 14.514.11.4001 в рамках ‘÷ѕ Ђ»сследовани€ и разработки по приоритетным направлени€м развити€ научно-технологического комплекса –оссии на 2007-2013 годыї.
—писок литературы:
1. How to integrate with the cloud. David Linthicum. InfoWorld. [Ёлектронный ресурс]. Ч http://www.infoworld.eom/d/cloud-computing/how-integrate-the-cloud-714.
2. »нтеграци€: большой вызов облакам: [Ёлектронный ресурс].
Чhttp://www.mulesoft.com/integration-clouds-hig-challenge.
1. Integration Platform as a Service: Moving Intergation to the Cloud. Gartner RAS Core Research Note G00210747, Massimo Pazzini, Benoit J. Lheureux, 7 march 2011.
2. ≈ловиков A.E. Ќовые тенденции интеграции в облаке / ј.≈. ≈ловиков // ѕолитематический сетевой электронный научный журнал  убанского государственного аграрного университета (Ќаучный журнал  уб√ј”) [Ёлектронный ресурс]. -  раснодар:  уб√ј”, 2012. - є09(083). —. 485 - 494. - IDA [article ID]: 0831209036. - –ежим доступа: http://ej.kubagro.ru/2012/09/pdf/36.pdf, 0,625 у.п.л., импакт-фактор –»Ќ÷=0,577
3. ≈ловиков ј.≈. ѕринципы построени€ облачной платформы / ј.≈. ≈ловиков // ѕолитематический сетевой электронный научный журнал  убанского государственного аграрного университета (Ќаучный журнал  уб√ј”) [Ёлектронный ресурс]. -  раснодар:  уб√ј”, 2013. - є04(088). —. 498 - 508. - IDA [article ID]: 0881304033. - –ежим доступа: http://ej.kubagro.ru/2013/04/pdf/33.pdf, 0,688 у.п.л., импакт-фактор –»Ќ÷=0,577
References
1. How to integrate with the cloud. David Linthicum. InfoWorld. [Jelektronnyj resurs], Ч http://www.infoworld.eom/d/cloud-computing/how-integrate-the-cloud-714.
2. Integracija: bol'shoj vyzov oblakam: [Jelektronnyj resurs],
Чhttp://www.mulesoft.com/integration-clouds-big-challenge.
3. Integration Platform as a Service: Moving Intergation to the Cloud. Gartner RAS Core Research Note G00210747, Massimo Pazzini, Benoit J. Lheureux, 7 march 2011.
4. Elovikov A.E. Novye tendencii integracii v oblake / A.E. Elovikov // Politematicheskij setevoj jelektronnyj nauchnyj zhurnal Kubanskogo gosudarstvennogo agrarnogo universiteta (Nauchnyj zhurnal
KubGAU) [Jelektronnyj resurs]. - Krasnodar: KubGAU, 2012. - є09(083). S. 485 - 494. - IDA [article ID]: 0831209036. - Rezhim dostupa: http://ej.kubagro.ru/2012/09/pdf/36.pdf, 0,625 u.p.l., impakt-faktor RINC=0,577
5. Elovikov A.E. Principy postroenija oblachnoj platformy / A.E. Elovikov // Politematicheskij setevoj jelektronnyj nauchnyj zhurnal Kubanskogo gosudarstvennogo agrarnogo universiteta (Nauchnyj zhurnal KubGAU) [Jelektronnyj resurs], - Krasnodar: KubGAU, 2013. - є04(088). S. 498 - 508. -IDA [article ID]: 0881304033. - Rezhim dostupa: http://ej.kubagro.ru/2013/04/pdf/33.pdf, 0,688 u.p.l., impakt-faktor RINC=0,577

пїњ