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