Сервис-ориентированная архитектура

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

Цель сервис-ориентированной архитектуры – организация строго определенного взаимодействия между отдельными независимыми программными модулями. Каждый модуль выполняет функции (часто говорят «предоставляет сервисы») в интересах других программных модулей или людей. Ключевой концептуальный момент SOA – предоставляемые сервисы независимы: сервис и приложение ничего не знают друг о друге. Сервис-ориентированная архитектура может быть реализована с помощью различных технологий, включая веб-сервисы и обмен сообщениями.

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

Примерами наиболее часто применяемых стандартов реализации являются:

● SOAP: простой протокол доступа к объектам (Simple Object Access Protocol) – протокол обмена структурированными сообщениями в распределенной вычислительной среде;

● RESTful API: набор архитектурных принципов построения сервис-ориентированных приложений. REST – сокр. от англ. Representational State Transfer (передача состояния представления). RESTful – прилагательное, употребляющееся по отношению к сервисам, которые соответствуют принципам REST;

● JMS: служба сообщений Java (Java Message Service) – стандарт обмена сообщениями между приложениями, выполненными на платформе Java;

● RMI: удаленный вызов методов (Remote Method Invocation) – программный интерфейс для вызова удаленных процедур на языке Java.

 

Модель публикации и подписки

Модель публикации и подписки (publish and subscribe) предусматривает наличие систем, поставляющих данные («издателей»), и систем, получающих эти данные («подписчиков»). Системы, поставляющие данные, вносятся в каталог сервисов данных, а системы, которым эти данные требуются, должны подписываться на услуги провайдера. После публикации данные автоматически рассылаются подписчикам.

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

Модель публикации и подписки идеально подходит для распространения данных среди всех заинтересованных сторон.

 

Извлечение, преобразование и загрузка

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

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

 

Задержка при обработке

В зависимости от требований по интеграции данных процедуры ETL могут выполняться в режиме периодической пакетной обработки или обработки по мере доступности новых или обновленных данных (в режиме реального времени или управляемой на основе событий – event driven). Обработка данных о текущих операциях обычно проводится в режиме реального времени или в режиме, близком к реальному времени (near real-time), а данных, требуемых для анализа и отчетности, – по графику, в пакетном режиме.

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

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

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

 

Оркестровка данных

Потоки данных в интеграционном решении должны быть спроектированы и документально оформлены. Оркестровка данных как раз и представляет собой описание потоков данных от «старта» до «финиша», включая промежуточные шаги, требуемые для выполнения преобразования и транзакции. Можно рассмотреть, например, такой набор действий, которые могут образовывать единую транзакцию: разместить заказ, произвести оплату, запросить доставку, отменить заказ, вернуть платеж, отменить доставку. Оркестровка пакетной интеграции данных должна также предоставлять сведения о частоте перемещения и преобразования данных. Отдельные задачи, c помощью которых реализуется пакетная интеграция, обычно описываются в планировщике, который и запускает их в указанное время, с указанной периодичностью или по наступлении заданного события. Расписание задач может включать множество взаимозависимых шагов.

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

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

 

Проверка качества данных

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

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

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

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

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