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

Бурное развитие IT-отрасли привело к тому, что на предприятиях накопится большой объем программ, используемых для решения разнообразных производственных задач, работающих на разнородных аппаратных, программных платформах, по разным протоколам. Поэтому используют интеграцию. Интеграция – мера вынужденная, весьма затратная, и было бы правильным постараться ее избежать [11]. Это можно сделать, если сами разработчики приложений выполнят ее на этапе создания наборов приложений, но унаследованные приложения необходимо интегрировать. Интеграция приложений и интеграционные платформы постепенно становятся существенной статьей ИТ-бюджета.

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

ЭТАПЫ ЖИЗНЕННОГО ЦИКЛА ПЛАТФОРМЫ ИНТЕГРАЦИИ

Создание интеграционной платформы, как и любой другой ИС, – многоэтапный процесс, направленный на получение качественного информационного продукта, требующий четкой орга-

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

Этапы разработки интеграционной платформы можно представить в виде последовательности действий (рис. 1).

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

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

При разработке интегрированных информационных систем значительный акцент делается на моделировании, особенно на моделировании бизнес-процессов. Активное использование MDA (Model-Driven Architecture), UML (Unified Model Language), BMP (Business Process Modeling), включение в среды моделирования средств генерации кода и создание моделей на базе кода, подключение средств моделирования к IDE (Integrated Development Environment) - все это указывает на то, что классические этапы анализа и проектирования все больше замешаются моделированием.

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

Информационная система		Интеграционная платформа
Подготовка		Подготовка
Планирование		Планирование
Анализ		Моделирование
Проектирование
Реализация		Реализация
Тестирование		Тестирование
Развертывание		Развертывание
Сопровождение		Сопровождение
		Развитие платформы

Рис. 1. Соотношение этапов классического [8] жизненного цикла разработки ИС и интеграционной платформы необходимо проверить на соответствие требований, полученных на этапе подготовки и планирования, на полноту и адекватность.

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

Рассмотрим подробнее перечисленные работы по созданию интеграционной платформы.

ВЫБОР ПОДХОДА К ИНТЕГРАЦИИ

На сегодняшний момент технологий интеграции можно разделить по нескольким подходам (см. табл. 1), каждый из которых имеет свои границы применения.

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

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

Число 5 для ограничения применимости архитектуры «каждый с каждым» выбрано из следующих соображений (если доступ ко всем ПП или большей части унифицирован, то эта цифра может быть и больше). Количество возможных связей между системами можно вычислить с помощью формулы N(N-1)/2. Если интегрируется три системы, то и количество связей между ними тоже равно трем. В таком случае интег- рация по принципу «каждый с каждым» оправдана. Если же систем 10, то количество связей равно 45-ти, а это - уже довольно значительная величина [14].

Среди этих технологий ЕSB и SOA (некоторые исследователи включают ESB в SOA) являются наиболее популярными и обсуждаемыми технологиями интеграции, с ними сегодня связываются повышенные ожидания, т.к.. с одной стороны, методология EAI достигла своей зрелости, а с другой — развеялась иллюзия покрыть всю деятельность организации одной суперсистемой. Важную роль сыграла также маркетинговая активность крупных поставщиков, направленная на продвижение новых сервисных платформ интеграции, таких как ESB [2].

Выбор метода и средства моделирования

Для построения моделей разного уровня существует множество подходов и методов (см. табл. 2).

Бизнес-процессы являются основными моделями (на практике часто используются паттерны проектирования и для конкретной системы строятся модели, учитывающие специфику производства). Для моделирования бизнес-процессов часто в SOA-проектах используют также BPMN (достоинством является совместимость с языком описания бизнес-процессов BPEL, входящего в стек протоколов SOA). Наиболее популярным моделями являются диаграммы UML (рис. 3), т.к. они могут использоваться при моделировании на разных уровнях и поддерживаются основными методологиями управления информационными проектами (RUP, ARIS, ICONIX и т.д.).

Модели UML также разделяют на: модель анализа, проектирования и реализации. Модель анализа показывает, как будет реализована система, проектирования – реализация модели анализа, представляющая собой абстракцию модели реализации. Модель реализации представляет собой физическое объединение реали-

Таблица 1. Подходы к интеграции [5].

Подход Описание Интеграция "каждый с каждым" состоит в создании специализированных интерфейсов обмена данными для каждой пары обменивающихся приложений, используется для небольшого числа приложений Интеграция на уровне пользовательских интерфейсов приложения могут использовать друга через пользовательский интерфейс (screenscraping), используется для сравнительно простых Web - приложений Интеграция на уровне данных Синтаксический [3] Консолидация (интеграция на физическом уровне) – технологии ETL (Extract-Transform-Load) и ECM (Enterprise Content Management) – данные собираются из нескольких первичных систем и интегрируются в одно постоянное место хранения. Федерализация (интеграция на логическом уровне)- EII (Enterprise Information Integration) - обеспечивает единую виртуальную картину нескольких первичных источников данных. Распространение – технология EDR (Еnterprise Data Replication) - подразумевает их копирование из одного места в другое. Этот подход обычно используется для операций реального времени и является событийно управляемым. Гибридный подход использует несколько технологий. Семантический [13] Подход основывается на знании и учете природы данных, вместе с данными хранятся метаданные, для описания метаданных могут использоваться онтологии. Интеграция на уровне корпоративных приложений EAI (Enterprise Application Integration), совместное использование исполняемого кода, а не внутренних данных приложения, программы разбиваются на компоненты, которые интегрируются с помощью стандартизованных программных интерфейсов и специального связующего ПО. Интеграция при помощи Web-сервисов SOA (Service-oriented architecture), ESB(Enterprise Service Bus), основан на обеспечении стандартного для Web-служб интерфейса доступа к приложениям и данным, они могут работать всюду, где можно использовать WWW-технологии. зации в терминах реализуемых подсистем и элементов реализации (директорий, файлов, данных, исполняемых файлов, исходного кода) [2]. При наличии моделей уровня реализации код часть «interface» может быть сгенерирован CASE-средствами. Поэтому перед началом моделирования необходимо выбрать и CASE-средство.

CASE-средство, используемое для разработки платформы интеграции, должно осуществлять поддержку анализа и проектирования бизнес-процессов, баз данных и программных продуктов. Значит, должно быть выбрано CASE-средство класса как минимум Workbenches или Environments. Дополнительным требованием к CASE-системе является наличие SOA-шаблонов (паттернов).

Из наиболее популярных CASE пакетов, представленных на рынке, данным классам соответствуют продукты фирм IBM семейства Rational, ARIS от IDSScheer, Together от Borland, пакет DeveloperSuite от Oracle, PowerDesigner от Sybase.

МОДЕЛИ ЭЛЕМЕНТОВ ИНТЕГРАЦИОННОЙ ПЛАТФОРМЫ НА БАЗЕ SOA

ДЛЯ ПОДДЕРЖКИ ЖЦ АВИАЦИОННОЙ ТЕХНИКИ

Интеграционная платформа для авиационного предприятия требует поддержки систем инженерных расчетов (CAE), управления данными об изделии (PDM), конструкторского проетиро-вания и моделирования (CAD / CAM), автоматизированного проектирования технологических процессов (CAPP), управления ресурсами (ERP / MRP), взаимодействия с клиентами (CRM), управления поставками (SCM) и другие [7].

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

Подход вытесняется технологией

SOA

Коли чество ПП< 5

нет

ПП –Web-приложен ия

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

Требуется да персонал, владеющ ий те хнологие й, не подходит для систе м реального времен и

Нет возможности ст роить новые за просы к объединенным да нным

технологии

Недостатком этого подхода являе тся нет

спользую тся www-

сложн ость (заран ее точно не оцени ваемая) , высокая .стоимость.

да

Систе ма реаль ного времени

В ПП общий исполняемый ко

Данные в разных источниках в разны х истемах измерени

Необходимо хранение историческихданных и внедрение B да

Технология слабо развита

Интеграция «каждый с каждым»

Инте грация на уровне по льзова-тельских интерфейсов

Инт еграция с помощью We b-сервисов

Интегр ация корпоративных приложений

Инте грация уровня данных: распро странени е

Интеграция уров ня данны х: федерализация

Интеграция уровня данных: семантическая

Интеграция уровня данных: к онсолида ция кон ец

Рис. 2. Алгоритм выбора подхода к интеграции

*ПП- программный продукт ции на уровне приложений используют ESB (рис. 4).

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

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

Любой проект в области SOA – это, по сути, проект модернизации всей информационной

Диаграммы поведения

структуры

объектов

прецедентов использования

конечных автоматов

деятельности взаимодействия

компонентов

последовательности действий

пакетов

коммуникаций

развертывания

обзора взаимодействий

композитной структуры

Рис. 3. Диаграммы UML.

синхронизации

Рис. 4. а) Классическая схема использования ESB б)Совместное использование сервисной шиныи шины данных [12]

Таблица 2. Методы моделирования [5, 10]

Уровень	Методы	Год	Описание
Предприятие	ZachmanFramework	1987	Представляет собой таксономию для упорядочения архитектурных артефактов (другими словами, проектной документации, спецификации и моделей), в которой учитываются лица, которым адресован артефакт (например, владелец бизнеса и строитель), и конкретная проблема (например, проблема с данными и функциональностью), которую необходимо устранить.
	Архитектура федеральной организации     (FEA), ранее         структура архитектуры федеральной организации (FEAF)	2002 (1999)	Включать следующие пункты: Точка зрения, с которой будут рассматриваться архитектуры предприятия (модель сегмента , которая вкратце будет рассмотрена ниже) Набор эталонных моделей, описывающих различные точки зрения на архитектуру предприятия (пять перечисленных выше моделей) Процесс создания архитектуры предприятия Процесс перехода от старой парадигмы (до создания архитектуры предприятия) к новой (после создания архитектуры предприятия) Таксономия для классификации активов, которые попадают в область действия архитектуры предприятия Методика, позволяющая оцен ить успешность использования архитектуры предприятия для повышения ценности бизнеса
	The Open Group Architecture Framework (TOGAF)	2003	Архитектура предприятия подразделяется на четыре категории: Архитектура бизнеса — описывает процессы, используемые для достижения бизнес-целей Архитектура приложений — описывает структуру конкретных приложений и их взаимодействие друг с другом Архитектура данных — описывает структуру корпоративных хранилищ данных и процедуры доступа к ним Технологическая архитектура — описывает инфраструктуру оборудования и программного обеспечения , в которой запускаются и взаимодействуют приложения
	Методология Gartner	2005	Представляет собой набор рекомендаций по построению архитектуры предприятия от одной из наиболее известных в мире исследовательских и консалтинговых ИТ-организаций — компании Gartner.

Окончание таблицы 2

Бизнес-процессы UML (activity diagram) 1996 Диаграмма активности универсального языка моделирования, описывает последовательности активностей (действий). BusinessProcessModel(BPM) 2005 Процессная модель описывает бизнес-процессы компании в стандарте WFD. Применяется для описания бизнес-процессов нижнего уровня. IDEF 70-е методология функционального моделирования, позволяющая описать процесс в виде иерархической системы взаимосвязанных функций. Event-driven Process Chain (EPC) 90-е цепочка процессов, управляемая событиями Процессная модель аналог классического стандарта WFD. Применяется для описания бизнес-процессов нижнего уровня. Службы UML (activity, sequence diagrams) 1996 основан на объектно-ориентированном подходе к проектированию, т.е. основное внимание при его использовании уделяется объектам и их поведению в системе, а не данным, которые они обрабатывают. Блок –схема 50-е Графическое представление алгоритма Компоненты UML (Component diagram) 1996 статическая структурная диаграмма, показывает разбиение программной системы на структурные компоненты и связи (зависимости) между компонентами. В качестве физических компонентов могут выступать файлы, библиотеки, модули, исполняемые файлы, пакеты и т. п. Средства IDE Средства сред разработки для описания компонентов Объекты UML(class, object diagrams) 1996 описывает структуру системы, показывая её классы, их атрибуты и операторы, а также взаимосвязи этих классов и объектов Средства IDE Средства сред разработки для описания объектов и классов. системы компании, а не ее отдельных элементов. Фактически проект SOA – это задача обобществления полезного для бизнеса компании прикладного ПО, представленного в унифицированном виде (программные компоненты, обеспечивающие те или иные бизнес-сервисы) [6].

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

Модели SOA переводят разработку на более высокий уровень абстракции, что позволяет сосредоточиться на бизнес-сервисах. Модели позволяют абстрагироваться от деталей реализации и сосредоточиться на тех проблемах, от которых зависят архитектурные решения [1].

Рассмотрим примеры разноуровневых моделей для платформа для авиационного предприятия. На рис. 6 представлена модель требований подсистемы интеграции (учтены базовые функции ESB).

Системы ERP, PDM, CAD и т.д. будут являться или поставщиками или потребителями

Уровень предприятия ><

Уровень процесса ><

Уровень служб

Уровень компонентов

><

Уровень объектов

Рис. 5. Уровни абстракции SOA [2].

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

Пример модели бизнес-процесса представлена на рис. 7. Диаграмма деятельности позволяет увидеть последовательность выполняемых действий, а также сообщения, которые переда-

Таблица 3. Минимальный набор функций ESB [9]

Связь	Интеграция
-    Маршрутизация и адресация сервисов для обеспечения прозрачности размещения; -    Фун кция администрирования для управления адресацией и именованием сервисов; -    По меньшей мере одна из форм парадигмы обмена сообщениями (например, запрос/ответ, публикация/подписка и т. п.); -    Поддержка по меньшей мере одного транспортного протокола, который является или может стать общедоступным .	Поддержка нескольких средств интеграции с поставщиками сервиса, например, коннекторов Java 2, Web-сервисов , асинхронного обмена сообщениями, адаптеров и т. п.
Взаимодействие сервисов
Открытая и независимая от реализации модель обмена сообщениями и организации интерфейсов, которая должна изолировать код приложения от специфических условий маршрутизации сервисов и транспортных протоколов, а также обеспечение возможности замены реализации сервиса.

«ncLide*»

Администратор

Рис. 6. Диаграмма прецедентов использования для подсистемы интеграций (ESB).

«include»

гарантированная передача сообщенйЙк,епй

■■include»

обнаружение

Управление ГТ

пто

Основное производство

Конструкторгко технологическая подготовка проитводства

Канцелфия

Управление ГК

^ ЭТД завода

Комплект КД на оснаску

Ведомость замечаний

Рис. 7. Диаграмма деятельности информационно-аналитической подсистемы

*ГТ–главный конструктор; ГТ – главный технолог; ПТО – производство технической оснастки; КД – конструкторская документация; ЭТД – эксплуатационно-техническая документация

и-«приемо кд

Запрос к КБ

Конструкторская подготовка производства

Производство СТО, ® сопровождение в жсплуатацт

Технологическая подготовив производства

изготовление

"C++ class» ©MessaBePlugm

«C++ Class» o Cail

«C++ Class-Э Message

• •    g+tHeadei ( )

• •    getcontest ( )

» getBorty ()

• •    getFault (j

• •    getAttachnsent { )

e getType ()

• 6    getPropertes ( )

• 6    copy ()

• • Message ()

+ -Message [ )

e createBodyType ( )

getType ()

МеяадеР+вп, @ иею+gePlugn ()

О -Me$$»gefltvi f )

«C++class-

QHeader

■ F*jlt l

Message

- Header

Message

* дегСЯ ()

* setCal()

* Header ()

• -Header ()

■ Body

«C++ Class" 0 Attachment

«C++ Class- 0 properties

Header -    .

«C++Class-

0 Fault

e getcode ()

e setcode ()

* getteascri ( )

e setReason ( )

6 getCause (}

• •    Fault ()

• •    -faAO

• •    getFWpaty ( )

• •    getPitfety ( ) e setPrcperty { ) e remove (]

• •    sea ()

e Properties ( )

• •    -fra+r t« ( J

■ Oet ( ) ■ put ( ) a remoye () a getNam+s () a IteniAt () в remgveltemAt [) a replKeltemAt () i additem () a additemAt ( ) * getlinriamedCoiint () * getmamedcount () + Attachment ( } • -Attachment ( 1

«C++ Class- QBorly

+ ailt) e get О e getContents {) e addO e get() в remore ( ) • replace ()

• •    merge {) + getNames [ )

• •    Body О

• •    -Body()

• •    cal ( )

• •    СЯО

• • ся о

e setio () e getTO ( ) e se№rsm () e getFrom () e setReciyTo () e getReph'To [) • setfaiitTo [) • getFJLitre () e SetRelatesTty [ ] a getRetotesTo () • copy( ) e setAction () e getArb;tr [ ) e entity () e setMessagelD ( ) e getMessagelO () e testing t) • strm^aum ()

• еЯ[)

e copyt) e -^il()

Рис. 8. Фрагмент диаграмма классов ются из одной подсистемы в другую.

Диаграммой уровня реализации является диаграмма классов. На рис. 8 представлен фрагмент диаграммы для подсистемы интеграций. Классы описывают сообщения, передаваемые через шину (примерами сообщений являются сообщения из диаграммы деятельности).

Моделирование интеграционной платформы предприятия средствами UML дает возможность одновременного рассмотрения и оценки нескольких альтернативных вариантов проектных решений и в целом повышает достоверность и качество окончательно выбранного варианта.

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

Работа выполнена при частичной финансовой поддержке Министерства образования и науки РФ в рамках Государственного контракта № 07.514.11.4131.