3.4Требования к основным компонентам целевой архитектуры 3.4.1Требования к единой платформе для обслуживания граждан через электронные каналы
Единая платформа должна реализовываться на базе промышленных программных стандартов.
Единая платформа должна реализовывать логику обслуживания граждан независимо от канала и предоставлять ее в виде набора сервисов их другим компонентам ИТ, реализующим особенности конкретного канала. Данные сервисы должны обеспечивать реализацию асинхронного взаимодействия и поддерживать в обязательном порядке протоколы взаимодействия SOAP/HTTP и JMS. Единая платформа обеспечивает актуальность наполнения и статуса подаваемой заявки гражданина независимо от канала. При этом платформа сохраняет промежуточное наполнение заявки гражданина и обеспечивает продолжение работы с заявкой в канале отличном от канала первичного заведения заявки.
Единая платформа должна включать в себя системы хранения данных и обеспечивать кэширование данных, необходимых для поддержки обслуживания гражданина Москвы. При этом, кэширование справочных данных должно быть организовано на долговременной основе, а быстро изменяемые данные должны обновляться по принципам EDA (архитектура, основанная на событиях), по событиям на стороне источника данных.
3.4.2Платформа интеграции 3.4.2.1Платформа интеграции приложений (ESB)
Ключевым инфраструктурным компонентом, обеспечивающим интеграцию приложений г. Москвы, является сервисная шина (Enterprise Service Bus, ESB). ESB обеспечивает единый механизм, благодаря которому интеграция приложений выполняется централизованным, унифицированным и управляемым способом, благодаря переходу от прямых интерфейсов между системами, интегрированных по принципу «точка-точка», на использование промежуточного слоя, предоставляемого ESB. При взаимодействии приложений с использованием сервисной шины используется схема преобразования данных по принципу ASBO-GBO-ASBO. Данная схема подразумевает преобразование данных из формата модели данных приложения-потребителя к формату канонической модели данных, а потом к формату модели данных приложения-поставщика. На этапах преобразования данных ASBO-GBO и GBO-ASBO может происходить обогащение данных с использованием систем управления мастер-данными. Это позволяет реализовать следующие преимущества:
Переход от хаотичной к централизованной интеграции;
Обеспечение прозрачного обмена информацией по шине между приложениями;
Уменьшение времени на интеграцию приложений в информационный ландшафт г. Москвы
Обеспечение возможности использования сервис-ориентированного подхода за счет создания соответствующей интеграционной инфраструктуры.
К сервисной шине предъявляются следующие функциональные требования:
Поддержка интерфейсов интеграции с информационными системами, форматов данных, коммуникационных протоколов и SOA-стандартов:
JMS;
WebServices (SOAP over HTTP);
MQ;
SCA.
Поддержка функциональности по преобразованию протоколов и форматов данных и взаимодействию между сервисами;
Поддержка различных шаблонов обмена сообщениями: publish/subscribe, One-Way, Request/Response и Request/Callback;
Наличие встроенных компонентов по управлению посреднической логикой, а также поддержка программируемых расширений;
Поддержка средств безопасности взаимодействия сервисов;
Обеспечение транзакционной работы между потребителями и поставщиками сервисов
Для целей интеграции систем конкретного департамента необходимо иметь возможность использования локальной ESB департамента или сегмента общей сервисной шины;
К сервисной шине предъявляются повышенные требования в части доступности, надежности и масштабирования:
Возможность быстрого восстановления после сбоев.
Возможности по масштабированию, включающие в себя возможность построения распределенного решения.
Наличие встроенного или внешнего механизма для идентификации, управления и мониторинга ошибок.
Для обеспечения взаимодействия систем на транспортном уровне требуется применение транспортной подсистемы. Основной задачей транспортной подсистемы является гарантированная доставка порций данных, называемых сообщениями, от системы-отправителя к системе-получателю.
В транспортной подсистеме выделяются следующие основные элементы:
Сообщения. Сообщениями принято считать некоторую порцию информации или запрос. При помощи них происходит взаимодействие приложений.
Очереди сообщений. Представляют собой основное место хранения и обработки сообщений. Управление очередями полностью скрыто от прикладных программ - приложения могут получить доступ к очередям только через интерфейс, предоставляемый транспортной подсистемой.
Менеджеры очередей сообщений. Программные компоненты, отвечающие за управление очередями сообщений и прием вывозов от прикладных программ.
За счет того, что управление очередями скрыто от системы-получателя и отправителя сообщений, транспортная подсистема предоставляет возможность гибкого взаимодействия приложений, не требующего детального знания у системы-отправителя сообщения о системе-получателе или наличия сведений о ее текущей доступности.
Требования, предъявляемые к транспортной подсистеме:
Наличие механизма одноразовой гарантированной доставки сообщений, включая логирование операций;
Поддержка основных моделей обмена информацией – «точка-точка» и «издатель-подписчик».
3.4.2.2Платформа управления интеграцией данных (ETL)
Построение целевой архитектуры г. Москвы невозможно без применения политик и средств управления интеграцией данных. Ежедневно в процессе работы накапливаются большие объемы данных, которые требуют не только агрегации и преобразования, но и интеграции с другими системами. Наличие большого количества источников данных (множество разнородных информационных систем), разнообразие входных форматов и способов представления информации, требования по производительности и валидации данных приводит к необходимости включения специализированных средств управления интеграцией данных в качестве одного из компонентов целевой интеграционной архитектуры.
Общепринятым стандартным подходом для решения подобного класса задач является использование средств ETL. Этот подход основан на выполнении задачи интеграции данных в три этапа:
Извлечение. На первом этапе производится извлечение информации из источника данных. Источником может служить как реляционная база данных, так и выгруженные файлы разного формата.
Преобразование. На втором этапе производится преобразование данных, которое может включать валидацию данных, преобразование форматов, использование данных из справочников, агрегацию и консолидацию данных из нескольких источников.
Загрузка. На третьем этапе происходит загрузка данных в систему- потребитель. Загрузка может осуществляться напрямую в базу данных, или в файлы определенного формата, понятном системе-потребителю.
Целевая интеграционная архитектура включает применение общего ETL-средства для интеграции данных между приложениями.
К платформе ETL предъявляются следующие требования:
Поддержка широкого ряда входных и выходных форматов данных и источников данных, включая реляционные базы данных, плоские файлы, данные в формате XML, интерфейсы JDBC и ODBC, а также MQ-транспорта для передачи данных;
Поддержка больших объемов данных и высоких скоростей загрузки, развитые возможности по масштабируемости;
Возможности по управлению процессом загрузки данных, запуск процессов по событию, по расписанию и вручную;
Возможности по предоставлению процессов загрузки данных в качестве сервиса, вызываемого другими системами;
Поддержка возможности расширения стандартной функциональности продукта при помощи разработки собственных программных расширений;
Возможности по профилированию процессов загрузки данных.
|
