Технические аспекты использования сервис-ориентированной архитектуры при организации обмена данными информационных систем. - Публикации - ЭСК-Центр
Внедрение систем ИСКС для управления и оперативного учета проектов капитального строительства.
Консалтинг, методическое обеспечение и регламентация процессов КС.
Комплексные решения по интеграции систем.

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

Журнал "Сlub-3D. Инновационное проектирование" №3


Волкова М.В. , генеральный директор  «ЭСК Центр»;
Стоклицкий С.А., к. ф-м.н, технический директор «ЭСК Центр».

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

В настоящее время основная часть информационного обмена между ИСУП НИАЭП и  ИСКС КАЭС-4 осуществляется на основе процессов документооборота (бумажного или электронного). В числе недостатков такого подхода можно выделить:

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

В случае обмена большими объемами документов - проектных, исполнительных, финансовых и др. -   характерными при сооружении АЭС, становятся актуальными задачи:

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

Автоматический обмен данными (документами) организуется  между различными информационными системами, в основе которых находятся, как правило, реляционные (или объектно-реляционные) СУБД, такие как Oracle, MS SQL Server, IBM DB2 и т.д. В контексте реляционных СУБД документ представляет группу записей таблиц, связанных ссылочными отношениями, причем количество таблиц, определяющих содержание документа, может быть весьма велико (несколько десятков). Можно условно выделить два возможных варианта архитектуры автоматического обмена:

  • «Простая (транзакционная) архитектура». Обмен данными на основе системных транзакций (все изменения, сохраненные в таблицах БД – источника передаются в БД – приемник с сохранением порядка транзакций и системных идентификаторов), например: Oracle Streams, Oracle Standby Database и аналогичные продукты других производителей. В «простой» архитектуре требуется полное совпадение платформы и структуры данных СУБД–приемника и СУБД-передатчика, а также необходима передача всех транзакций без исключения для обеспечения ссылочной целостности.
  • «Сложная (базирующаяся на документах) архитектура». Обмен данными на основе передачи бизнес-документов с реализацией специальных бизнес-правил, фильтров и трансформации данных (например, документ не передается до тех пор, пока не установлен статус «Готов к отправке»). В рамках данного подхода процесс обмена может быть реализован между различными по структуре (и платформе) СУБД. В «сложном» случае обязательно требуется наличие специального интерфейсного слоя (программных адаптеров), обеспечивающего логику сложных бизнес-правил и трансформацию передаваемых данных.

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

Сервис-ориентированная архитектура  (англ. SOA, service-oriented architecture) — модульный подход к разработке программного обеспечения, основанный на использовании сервисов (служб) со стандартизированными интерфейсами.
Компоненты программного обеспечения SOA могут быть распределены по разным узлам сети, где они публикуются как независимые приложения. Программные комплексы, разработанные в соответствии с SOA, реализуются как набор web-служб, интегрированных при помощи известных стандартных протоколов (XML, SOAP, WSDL, BPEL и др.).

Web-служба, используемая, как компонент  SOA, обязана опубликовать описание своих методов и параметров как URL-ресурс формата WSDL (англ. Web Service Description Language). Система или программный компонент, который обращается к web-службе, формирует XML-сообщение формата SOAP (англ. Simple Object Access Protocol) на основе WSDL-описания и получает ответ от web-службы также в формате XML (SOAP).

http://www.oasis-open.org/committees/download.php/19679/soa-rm-cs.pdf

Интерфейс компонентов SOA предоставляет инкапсуляцию деталей реализации конкретного компонента (операционной системы, платформы, языка программирования, вендора, и т. п.) от остальных компонентов. Таким образом, SOA предоставляет гибкий и элегантный способ комбинирования и многократного использования компонентов для построения сложных распределённых программных комплексов.

SOA хорошо зарекомендовала себя для построения крупных корпоративных программных приложений. Целый ряд разработчиков и интеграторов предлагают инструменты и решения на основе SOA (например, платформы Oracle SOA Suite, Intel SOA Expressway, JBoss SOA Platform, IBM WebSphere, Software AG webMethods, Oracle/BEA Aqualogic, Microsoft Windows Communication Foundation, SAP NetWeaver).

В настоящее время (срок реализации – конец 2011) в рамках развития системы ИСКС КАЭС-4 и НИАЭП создается система автоматического двухстороннего обмена данными между эксплуатируемыми системами заказчика (ИСКС КАЭС) и генподрядчика (ИСУП НИАЭП). Система должна обеспечить передачу документов ПСД (заглавные листы, сметы (со строками), заказные спецификации (со строками) и др.), документов по освоению сметного лимита (акты КС2, КС3) и др. Диаграмма основных информационных потоков при обмене данными показана на Рис.1. Так как БД ИСУП НИАЭП и БД ИСКС КАЭС не идентичны по структуре и бизнес-функциям (общей является только платформа – Oracle 10G), а правила передачи являются сложными (отбор по объектам строительства и статусам, трансформация идентификаторов), проект реализуется на основе SOA – архитектуры.

Сервис- ориентированная архитектура в проекте ИСКС создается на платформе Oracle SOA Suite. Основным аргументом в пользу выбора данной платформы является высокая совместимость с объектно-реляционной моделью Oracle Database 10G и наличие готовых адаптеров и шаблонов для работы с объектами БД Oracle (Advanced Queues, хранимые процедуры, PL/SQL web-службы и др.). Компоненты SOA разворачиваются на платформе сервера приложений  (J2EE). В проекте используются два типа компонентов:

Web-службы. Для каждого бизнес-документа, участвующего в информационном обмене создается web-служба, предоставляющая стандартные методы «Get» (возвращает полный набор данных документа системы-источника в формате xml (SOAP)) и метод «Set» (создает документ в системе-приемнике на основе входного параметра (xml-сообщения с полным набором данных документа)). Web-службы разрабатываются на основе стандартов WSDL, XML и SOAP и являются SOA-совместимым API систем ИСКС и ИСУП.

BPEL – сервис.  Для реализации полномасштабного обмена документами между двумя системами недостаточно создать набор web-служб, но также необходимо обеспечить инициализацию процессов передачи сообщений и согласованную передачу (маршрутизацию) xml-сообщений от одних служб (источников) к другим (приемникам). Организацию согласованной группы процессов маршрутизации принято называть «оркестровкой» (“Orchestration”). В проекте ЕИП для «оркестровки» web-служб используется специальный BPEL – сервис на платформе Oracle Soa Suite, выполняющий сценарии, разработанные на языке BPEL (Business Process Execution Language).

Типовая диаграмма «оркестровки» web-служб при обработке xml-документа показана на рисунке 2:

  1. В системе-источнике происходит событие, требующее передачи документа в систему-приемник (например, установлен статус документа «Готов к передаче»)
  2. Система-источник размещает идентификатор документа в очередь документов.
  3. BPEL-сервис опрашивает очередь (имеется специальный адаптер очередей) и обнаруживает новый (или измененный) документ.
  4. BPEL-сервис обращается к web-службе и запрашивает полные данные документа.
  5. Web-служба обращается к БД-источнику, формирует набор данных документа (5.1) и передает его BPEL-сервису (5.2). BPEL-сервис маршрутизирует документ на вход web-службы системы-приемника (5.3). Web-служба системы-приемника обрабатывает документ и сохраняет его в системе-приемнике (5.4).
  6. Web-служба системы-приемника возвращает BPEL-сервису подтверждение успешной обработки в системе-приемнике, идентификатор документа в системе-приемнике или сообщение об ошибке (протокол).
  7. BPEL-сервис обращается к web-службе системы-источника и передает данные протокола.
  8. Web-служба системы-источника записывает данные в таблицу прокола. На этом процесс передачи документа считается законченным.

Типичная BPEL-диаграмма процесса SOA показана на рис.3.

Использование SOA технологий при информационном обмене данными Генерального подрядчика и Заказчика проекта сооружения КАЭС-4 обеспечивает новый, более высокий уровень стандартизации процессов обмена данными. Создаваемая в рамках данного проекта общая шина обмена данными общепринятого формата (XML/SOAP) упрощает процесс сопровождения и обеспечивает интеграцию в состав ЕИП новых участников информационного обмена. Следует отметить, что разработка данной технологии в проекте КАЭС-4 стала необходимой в результате проводимой работы УКС КАЭС и ОАО «НИАЭП»  по  внедрению новых технологий  при проектировании и сооружении АЭС, созданию структурированных архивов данных проектов сооружения  в ИСУП НИАЭП.  Использование сервис-ориентированной архитектуры создает широкие возможности для интеграции с разрабатываемыми и внедряемыми в НИАЭП ERP и PLM системами, такими как SAP R3 и ENOVIA.

Рис. 1 Информационные потоки в проекте обмена данными ИСУП - ИСКС

Рис. 1 Информационные потоки в проекте обмена данными ИСУП - ИСКС


Рис. 2 Схема маршрутизации документов в SOA ЕИП НИАЭП.
Рис. 2 Схема маршрутизации документов в SOA ЕИП НИАЭП.


Рис. 3. BPEL - диаграмма процесса передачи данных.
Рис. 3. BPEL - диаграмма процесса передачи данных.